The company would know exactly where to look!īiz KPIs -> App KPIs -> Infra KPIs. Because of that slow app performance, they’re not able to book orders at the necessary pace and miss their quarterly estimates….even though they had the business! If the CFO was looking at an ITSI glass table, he would see orders were slow and instead of sending everyone on a wild goose chase (is it SAP? Is it DB issue, was it a firewall change?) What he does care about is that high CPU made SAP performance degrade while they are trying to close out the books end of quarter. The CFO doesn’t care about an alert firing for high CPU. Yes infrastructure & app KPIs are important but C suite, LOB owners and other high level execs don’t care about them as standalone metrics. KPIs tied to revenue, customer satisfaction etc. ITSI shines when you have true business KPIs to track. Hopefully this helps create a view of the similarities, but important differences between the two products, how they can operate individually and together.Īgree with everything Shifty said. It was all under Splunk and problems got solved faster with less finger pointing - ITSI 1000% points the finger at who is responsible for what. We never had to ask another team to produce reports and data from other tools. The first time I encountered ITSI, it was a game changer for me and several teams that used it. That has its own costs outside of dollars like training and hopping between tools to get answers. We had dozens of tools to implement and manage. This removes the need to procure, implement and learn different tools that can be done under one platform.Īnecdotally, I've worked in small and extremely large and complex networks with thousands of servers, applications. The core Splunk search experience means that when you need to put hands on keyboard, everyone has the same experience, same platform and same page. The nice thing about having both (if it applies to your org) ITSI and Observability is that you can feed ITSI with Obserability data to enhance what ITSI already does very well. The output of reports and alerts helps devs quickly regroup and do what they need to do. From a software dev optic, Splunk Observabilty is extremely valuable for CICD developement methods so that when they push code, they can see if it does what it was supposed to do, crash, cause regressions, impacts user experience, etc. They need different data to do their job effectively, accurately and efficiently. Back to the doctor analogy, this would be for health specialists like a Cardiologist. So, it is more low-level and focused on those folks. Splunk Observability is geared towards software developers and application managers running traditional server-based applications to containerized applications. ITSI is focused on Virtualization platforms like VMWare, traditional Windows/Linux servers, applications logs, performance monitoring and summarizing that all as Service Health scores.įor Observability, it is a bit different in terms of "who" is it for. How you treat that is just like how a IT Ops engineer dives into "why" is that happening, "how" do we solve it and "what" worked or didn't work to increase the health score. For example, blood pressure KPI when high, can be caused by many other factors and falls under cardiovascular disease and can be binned as "hyper-tension". They measure different KPIs to determine how healthy you are and what conditions or diseases contributes to that. Just because something is up and running doesn't mean it is healthy. No KPI should be treated equally unlike other APM tools out there. It allows Service Owners/Managers to gauge and weigh different KPIs per service, sub/supporting services. ITSI is geared toward "Service Health" rather than individual KPIs like CPU, RAM, Disk, Networking.
0 Comments
Leave a Reply. |