Splunk ITSI (IT Service Intelligence) Reviews

In my recent projects, we have used ITSI to monitor the entire infrastructure using multiple features, such as service KPIs, aggregation policies, base searches, correlation searches, notable events, dashboards, blast tables, service analyzers, and drill-downs.

It helps in every respect, including performance, monitoring, or visualization of the important indicators. It improves the quality of service to the clients. It is crucial that the clients have no website failures because that means the loss of business. ITSI helps us track those issues. We've seen fewer environmental failures since we started using ITSI.

We saw immediate benefits from Splunk ITSI. For example, let's say you have a project for monitoring hybrid Linux servers running JBoss, SAP, and any server containing a client's critical data. It isn't easy to monitor each of these through the back end. 

Splunk ITSI shows you all the data on the screen and lets you visualize the data from various applications. We can see all the applications running on the server and issues with CPU or memory utilization. We have that data in Splunk and can immediately see the alerts triggered. If there are any failures in the environment, we can fix them in seconds. 

The solution has helped us streamline our incident management. We can monitor server KPIs, which trigger an alert if the server is impacted. We can track all the notable events and integrate ServiceNow with Splunk. ITSI is integrated with the ticketing tool, so when an alert triggers, it automatically creates a ticket on ServiceNow. 

ITSI has also reduced the alert volume. Before ITSI, we were unsure why an issue happened. We would see the alerts triggered in bulk and log them one by one for every server. ITSI gives you a feature that lets you drill down to find the precise issues on the server. 

It has a service KPI feature that allows you to monitor exceptions that may lead to server failure. For example, we might be in trouble if the value exceeds 10. We put five or eight values in the threshold field with a high criticality, so it triggers an alert whenever the count is breached. 

ITSI reduced our alert noise because it was very hard to monitor every aspect when we used search and reporting. After running the query, we needed more insights, and ITSI gave us a clearer picture of the incident. That helps you reduce issues.

Many use cases can be automated through ITSI because we previously built our reports manually.  After introducing ITSI, we sent all the data via the forwarders to Splunk. Once we have the data, we create and schedule all those queries and reports so that the management can see them without any IT involvement. It previously took us two or three hours daily to create all those reports, so automating reports saves almost 60 hours each month. We're automating 10 to 15 daily.

The most valuable feature of ITSI is the service KPIs. No other tool provides you with the same level of observability and enterprise security or the search and reporting applications. 

ITSI has everything. We can create searches, email alerts, and dashboards. It's the only application that offers the KPI concept where we can monitor different KPI parameters. We can configure the KPIs to trigger alerts when they breach a set threshold.

You can use the core concepts to optimize performance optimization. And you can create a lot of correlations and onboard the data from every project application. You can play with the data to create those KPI services and crash modes. It's possible to establish service health using the KPIs through the service analyzer. On a single screen, you have a lot of tiles showing you the service KPIs and high-level insights.  

When I started working on ITSI, there was some lag in releasing predictive analysis. Since then, there have been several updates, and we see that it works. We can predict any fluctuation in the data that might lead to failure. Using the historical data, we can set up the adaptive threshold. ITSI analyzes the historical data and sets an analysis for the future.

ITSI is an almost perfect tool, but there is room for improvement in a few features like the deep dive and multi-KPI alerts. We're using most of the features like service API, coding searches, and aggregation, but our team members hardly use multi-KPI and deep dive. We don't use the multi-KPI or deep dive because everything is available in the service KPI. I don't think this feature is necessary. 

People mostly use ITSI to monitor alerts. The most important features are within the service KPI. When we configure the alerts in service KPI, we don't need to do any deep dives because the client is more interested in the raw data, so we run the queries on the raw data instead of going into the deep dive. 

I have used Splunk ITSI for seven years.

I rate Splunk support nine out of 10. It is very helpful. Whether you are connected to priority one, two, or three depends on the issue and its impact. You can also get help from the Splunk community. If you create a P2 ticket, they will reach out to you within an hour and resolve the problem in eight hours. They have different SLAs. 

They might take one or two days to resolve issues. We need to upload the tags over the server to the portal. After that, they will start working on it. They have solved all the issues in the last four or five months within two to three days maximum.

Positive

We had Dynatrace. It was integrated to onboard the data and create correlation searches to monitor those parameters.

Setting up Splunk ITSI wasn't difficult. A few files needed to be placed over the indexers, and a few more needed to be placed over the license master. I didn't have any issues installing ITSI from scratch. It takes 15 to 20 minutes, depending on the project. It can be set up with one to three people. When service KPIs are installed, we need to validate them after the installation and upgrade ITSI. 

My friend works with OpenSearch. They are moving from Splunk to Cribl and OpenSearch. Splunk is pretty expensive, but it gives you a decent insight into the data. It is easy to learn, and ITSI has a great interface. You can run those queries and pass the data. I don't find any product attractive, and we need to put more thought into it. 

I rate Splunk ITSI nine out of 10. I have worked on multiple projects in the last seven years, and I've never found any product like ITSI. We can monitor everything through that. It's an excellent product.

Setting up and mapping the searches with the aggregation policies can be a little complex. Once you've mastered that, you can do anything with the ITSI. You can monitor the whole project infrastructure. You don't need any other tool to monitor and visualize the data. ITSI is enough.

We use Splunk ITSI for monitoring and analytics.

We spent two months evaluating Splunk before deploying it in production, and by the end of that period, I fully realized the tool's benefits.

Splunk allows us to size resources to match the demand.

Splunk significantly improved our organization's efficiency. Previously, identifying application failures required manual checks or creating custom email templates. However, this process has been fully automated since Splunk was integrated into our applications. We now receive instant email alerts for any issues, reducing our response time from hours to minutes and seconds.

It reduced the mean time for detection by 60 percent.

Since implementing Splunk ITSI, we now receive alerts within seconds of detection.

Splunk ITSI has significantly reduced the time spent on routine tasks. Previously, locating errors could consume minutes or even hours, but now it takes seconds.

It is easily integrated and capable of ingesting data efficiently.

I particularly appreciate two features of Splunk ITSI: data forwarding and the marketplace. Data forwarding allows us to ingest data from at least three different sources directly into Splunk. The marketplace, on the other hand, empowers us to create and share custom applications or functionalities that aren't already available.

The user interface visualization could be improved. Splunk ITSI currently utilizes a candid design.

I have been using Splunk ITSI for 11 months.

Splunk ITSI is stable on the Cloud.

Our project generated millions of lines of data every ten minutes, which Splunk ITSI successfully processed.

We migrated from New Relic over to Splunk ITSI because of budget constraints.

The deployment is straightforward. 

I would rate Splunk ITSI eight out of ten.

A dedicated Splunk team deals with maintenance.

Before using Splunk ITSI, it is recommended to take advantage of the free trial period to explore the application and thoroughly read the documentation. This will allow you to determine if it meets your needs before diving in.

I worked on multiple projects using Splunk ITSI for log monitoring, including monitoring mobile data usage for a telecom company, working with an insurance company and a retail application, and monitoring payment applications for a bank.

The integration with Splunk ITSI allowed us to monitor and track issues through alerts. This integration also reduces the Mean Time to Identify as the team is quickly made aware of problems through the ITSM tool, and respective incidents are raised to the application team. Depending on the issue's type, we can prioritize the incident, even giving it a P1 priority. With this, the team is made aware, and since we track our issues in ServiceNow, related incidents can be deployed, which also helps reduce the Mean Time to Resolve. The application team then knows what actions to take.

Event management utilizes event correlation and event aggregation instead of generating numerous alerts that cause panic within the team because multiple areas might be affected by a single issue. This can be achieved through Splunk's native capabilities, like notable event aggregation policies and episode reviews for ITSM, or by utilizing third-party tools such as Netcool. By employing event management tools like Netcool and then sending aggregated incidents to ServiceNow or using ServiceNow's item model for implementation, the number of alerts is reduced, and the troubleshooting team receives relevant information instead of overloading. This approach helps mitigate panic and provides the team with the resources to effectively address issues.

End-to-end visibility for application monitoring in our use case required us to consider all involved components. We addressed this by creating hierarchical dashboards. This approach provided everyone, from business stakeholders to operations, with visibility into application health through relevant metrics. Business stakeholders, for instance, focus on high-level metrics like application health, user experience, revenue, and performance rather than technical details like CPU usage. Therefore, we tailored the dashboard hierarchy for different roles: business executives, operation leads, project managers, and operations staff. The operations dashboard provided end-to-end visibility by configuring all components of the application's functioning. Leveraging the familiar network architecture, we utilized the same topology to present metrics, creating a comfortable and easily understandable dashboard layout. By plotting all entities with their availability and performance metrics, we achieved comprehensive end-to-end visibility.

We have set up the environment correctly for the predictive analytics, and our metrics are flowing continuously. We have the required data, so we can configure at least 30 minutes of lead time to predict the metrics and their thresholds for potential impact. I can set this up, but I only had the opportunity to work on the project until anomaly detection. Predictive analytics was not a requirement, so I did not implement it. However, I understand it entirely and have explored and learned about it in their documentation.

For our telecom project, we focused on promotions as a use case. We aimed to identify the most popular promotions among users, especially during festivals and special occasions. Analyzing business metrics revealed that Promo Code 350 was the most frequently used, generating significant revenue. We presented these findings to the business team, showcasing how different promotions performed during various events. This information empowered them to design more effective offers and strategies, ultimately improving the customer experience. The business team appreciated our contribution, recognizing the value of data-driven insights in shaping their marketing efforts.

Splunk ITSI is a tool that helps our clients streamline their incident management. By integrating Splunk ITSI with ServiceNow and NetCool, we can reduce the burden of keeping up with the number of incidents and ensure they're updated.

Splunk ITSI helps reduce alert noise. We receive multiple alerts for each event when using any APM tool, Splunk, or log monitoring tool. Aggregating these alerts has always been helpful, and we've utilized Splunk's notable event aggregation policy to reduce alerting for each KPI to a single episode review.

Splunk ITSI reduces our mean time to detect.

Splunk ITSI is resilient and highly capable of tracking issues, provided the necessary logs are configured. With proper configurations, metric values are obtained, allowing us to monitor KPIs and quickly identify any adverse effects. In such cases, we can seamlessly delve into the logs to pinpoint the exact root cause of the issue.

I enjoy designing glass tables, hierarchy dashboards, and the preview for ITSI. I particularly like the preview feature because it provides a prompt experience for impact analysis. We can directly track which specific service is impacted and identify the underlying affected entity. Also, we can quickly view the affected metrics. Overall, the Glass table preview is the most valuable feature.

Currently, Glass tables in ITSI only display metrics related to KPIs. I proposed adding an option to show metrics related to entities. This would eliminate the need for custom SPL to achieve this functionality. Since KPIs already have an entity split feature, extending this capability to dashboards makes sense.

I have been using Splunk ITSI for five years.

I would rate the stability of Splunk ITSI nine out of ten.

Splunk ITSI is scalable. It offers clustering for search indexes, and we have the deployment service.

I previously used AppDynamics but switched to Splunk after learning about it and finding it more interesting.

The deployment is straightforward.

Splunk ITSI is expensive compared to other tools.

I would rate Splunk ITSI eight out of ten.

Other APM tools have limited features, so I recommend Splunk because it allows you to go beyond pre-built functionalities. With Splunk, you can create custom rules for application monitoring and tailor data visualization for enhanced visibility. Splunk's flexibility extends to designing personalized dashboards and metrics, providing a limitless monitoring experience.

Splunk ITSI requires maintenance for upgrades either annually or biennially.

Splunk is a comprehensive solution that offers log monitoring and the ITSI observability suite, eliminating the need for multiple tools and the associated complexities in maintenance and cross-team coordination. Splunk's flexibility allows for adopting features like APM as needed and seamlessly adding further monitoring capabilities in the future, such as user experience monitoring, synthetic monitoring, or additional log monitoring. This adaptability, along with Splunk's ability to correlate data across different monitoring areas, makes it an ideal unified platform for comprehensive monitoring and observability.

We are using the solution for correlation searches. We've integrated Splunk with ServiceNow. We're creating aggregation policies to trigger actions in ServiceNow. We use it with the ServiceNow add-on. When something happens in ServiceNow, it's correlated to ITSI as well. 

We can check to see if dependent services are aligned. The service analyzer allows us to see the health of the services. 

It's been very good for noise reduction. We have alerts that trigger visually and it helps us prioritize. We can create performance-related dashboards so teams will have a clear overview according to their unique requirements. 

The infrastructure monitoring is very useful. In our scenario, we can see the performance of logs across parameters like memory or security. We can analyze the data. We can create our own logic and alerts to send to the correlated teams to take care of incidents. 

The end-to-end visibility is very good. With the service analyzer, we're able to see if something goes down. It's inspecting the health of services. It's color-coded, so we can check to see if there are any serious issues. We can do deep dives if something is red. 

We use the predictive analytics on offer. We have some use cases in which we create forecasts around CPU and memory-related alerts. We can use it to predict costs based on the past 30 or 40 days. We're also trying to use this for anomaly detection. We can make good predictions on the basis of data and trends. As long as we have past data, we can use it to build some predictions for the future. We can use this to create and send predictive reports to our teams to help them take pre-emptive action.

It's helped us to right-size resources to match demand. 

The solution has helped us streamline our incident management. We've been able to increase efficiencies through automation.

We've been able to reduce incident volume. If a host is generating frequent tickets, for example, we're able to see it and work on it directly to help us reduce incident counts. 

We've been able to effectively reduce alert noise. We can create logic to create tickets. It will create one ticket per episode so that multiple tickets are not created for one single episode - and this helps us reduce noise. 

We can automate routine tasks. We're able to create alerts, reports, scheduled searches, et cetera. It's helping us to save time.

When we check the service analyzer, and we have custom inputs, there are issues. Sometimes our inputs are not taken or recognized. Alerts are not being automatically generated. Also, if someone comes and creates a maintenance window, we can't properly identify who created it. We have to create our own queries before we can identify anything. 

I've been using the solution for three years. 

The solution is very stable. 

The solution is scalable. Depending on your infrastructure, it can be a bit tricky. 

I haven't had to escalate any issues to technical support. 

We're using SolarWinds and Splunk in our current environment. 

I helped with the initial deployment. We have multiple servers sending data to Splunk. The process is straightforward. For the setup, we had three people involved in the process. 

It's not a difficult solution to maintain. 

The licensing is based on data ingestion. However, they do have multiple licensing options.

The pricing is reasonable. 

Splunk is good. It gives good customized options. Any logic or Python script we need to add, we have the freedom to do so. Most solutions aren't as customizable. 

I'd recommend the solution to others. I'd rate it eight out of ten. 

It monitors every level of infrastructure in our environment, including remote locations across the world.

Splunk ITSI has end-to-end visibility into the cloud-native environment. This is important but not as important because we are primarily on-prem in every aspect of our IT infrastructure. However, for things that we do have in the cloud, it is important that we have visibility there.

Splunk ITSI has helped reduce our mean time to resolve. We can see very quickly when things are down and where they are down. I have taken steps to reduce the time to identify and time to resolve with Splunk ITSI.

The unified platform helps consolidate networking, security, and IT observability tools. It forces certain groups to work together and more closely, as they should. It increases awareness of the current statuses of other environments, which is important.

Instant usability of gathered event metrics is available. We have metrics data from systems, and we can use that to instantly get system status and trends.

There should be entity conflict resolution, specifically regarding duplicate entities. There should be case sensitivity for various keys amongst entities, specifically host names. We need IT metrics-based indexes and more content packs. I know they are coming out with these features.

I have been using Splunk ITSI for two years.

Its stability is great.

It is handling well what it is supposed to handle for some parts of our setup, and with the new version, it is only going to get better.

I have never used their support. Community is the first place I go.

I started with the company two years ago. They had it long before that.

I would rate Splunk ITSI an eight out of ten. It is pretty good, but there are some inflexibilities with the analyzer that can be annoying. 

Splunk ITSI is a product for operations. I use it for detecting issues in the operations and generating alerts for them.

It is an intelligence platform for operational excellence.

The end-to-end visibility is a great thing about Splunk ITSI. It provides an end-to-end view to any user, from a normal engineer to a high-level manager.

We were able to realize the benefits of Splunk ITSI immediately.

Splunk ITSI helps to right-size resources to match the demand. It improves the quality. It is more organized. It can definitely help in rightsizing.

It helps to avoid duplicated alerts. If rightly implemented, it can reduce the duplication of alerts and provide more specific and accurate context.

Splunk ITSI has helped reduce incident volume. The reduction is implementation-dependent. If it is rightly implemented, we can reduce it to a very low percentage. Out of 100, we get only 10 alerts. If the context is correct, we only need one alert. This can be achieved with ITSI.

Splunk ITSI has helped reduce our alert noise, but I do not have the numbers because the initial implementation was not right. There were so many alerts, but when we corrected the implementation, it reduced them by a lot. I do not have the numbers, but thousands have become hundreds.

Splunk ITSI has helped reduce our mean time to detect (MTTD). It is at least five minutes. The mean time to resolve is dependent on the team. I do not have control over that because, in Splunk ITSI, we generate alerts for multiple teams, not just one team. It all depends on their SLAs.

Splunk ITSI helps us to automate alerting and automatically generate alerts or create incidents. It is not an automation tool to reduce mundane tasks.

Splunk ITSI helped us save costs by reducing downtime and manpower costs or avoiding SLA penalties.

The service analyzer view and automatic creation of incidents are valuable.

Better documentation would definitely help. Many people do not know about it, so better documentation and use case explanations would be helpful. There should be more YouTube videos about how to implement ITSI

The biggest improvement area is making it open to developers. Right now, it is very closed. It can only be downloaded by people who have a license to and not everyone. If it is open to everybody, more people will use it.

It has been quite a long time. It has been more than four or five years.

It is pretty stable. If we have the proper infrastructure, this tool is very stable. It does not crash.

Its scalability is high. It can scale very well. You can increase the size of the cluster. You can increase the capacity vertically and horizontally. It is very scalable.

They are good. They respond based on the SLAs. The quality of service depends on how informative you are when you provide the case details to them, but they have the ability to escalate it to higher levels and get help. They have the skills, but sometimes, the support is not in the UK. It sometimes comes from the US, so there may be time constraints when you set up a call. Otherwise, they are good.

Neutral

I have used other solutions. In the old days, I used a BMC system. Splunk ITSI is a completely different type of alerting system.

The BMC solution is more monotonic. It does not have the intelligence like Splunk ITSI to reduce the noise. It just picks up a metric and alerts based on that threshold, whereas, in ITSI, we have the control to reduce the number of alerts generated on the same threshold by adding some intelligence to it. It has the ability to do that Intelligence part. That is why it is called ITSI.

We have both on-premises and cloud deployment models. Its deployment is difficult for a beginner user. You need a consultant or somebody experienced in Splunk ITSI to implement it properly. Splunk ITSI is a premium product. You need very good Splunk infrastructure initially to run this on top. To run it properly, you should have good knowledge. You should at least have Splunk Architect-level certification. Otherwise, you can implement it, but it will not work properly or as you expect.

It is mostly a clustered solution. It is not normally done on a single server. We need to build the entire cluster. The initial build probably can take two weeks. Configuring everything can take a long time. Six months can be considered a good time to make it run properly for enterprise usage.

It needs regular upgrades, backups, and time-to-time updates to the system configurations. It requires a dedicated team. Once it is properly set up, less than ten people can manage it.

I am an ITSI consultant, so I am not a user. I set it up for customers.

The number of people required depends on how much data we need to bring in. If we have a lot of data and a variety of systems, more people are required. If we are just focusing on a singular system, one person can do the job.

In an enterprise environment, there are a multitude of systems and monitoring requirements. Usually, there is a team onboarding data and setting it up. 10-15 people are a good choice for a big enterprise, like a banking client.

It is more of a premium product. I do not have much visibility into pricing because it is taken care of by high-level enterprise customers. I just ask for the license that I need and they negotiate. It all happens between Splunk and the company. I know that it is expensive, but I do not think there is another solution that can do similar things for that price.

To someone who already has an IT alerting and incident management solution but is considering switching to Splunk ITSI, I would say that it will add value to their organization. It can reduce a lot of noise. I would suggest going for it, but it should be the right implementation. You should have knowledgeable people to implement it from the beginning.

It is not something that you just buy and switch on and will start working. It needs a lot of configuration and proper configuration to make it run properly. That is an important part for Splunk ITSI. It is not just the product. The person who is implementing it should be very good. Then only its value can be seen. Otherwise, you have the application but may not get the right value out of it.

Overall, from my experience, I would rate Splunk ITSI an eight out of ten.

We used Splunk ITSI to monitor service health and key performance indicators across various servers, such as CPU, memory, and disk utilization—advanced detection capabilities based on defined thresholds and triggered alerts. Splunk ITSI, integrated with ServiceNow, facilitated alert generation and management. Additionally, we leveraged ITSI for event analytics and created glass tables based on configuration items. We monitored specific KPIs and generated alerts via ServiceNow based on established thresholds to meet customer requirements.

Some clients have Splunk ITSI deployed in the cloud, and others are on-premises.

Using a client example, I'll explain the end-to-end visibility provided by Splunk ITSI. We have over a hundred clients in our environment. Once we onboard client data, such as cloud data, we subscribe to that cloud service and integrate the data into our Splunk environment. We then create data models and correlations integrated with the ITSI service. Within ITSI, we create correlation searches and schedule them to run regularly. Each time the Splunk schedule runs, it generates notable events and checks policies to determine if an event qualifies for a ticket. If it qualifies, an episode is created in ITSI, and a ticket is automatically generated in ServiceNow. This is the complete end-to-end process within Splunk ITSI.

We use predictive analytics based on the threshold values to help prevent incidents before they occur.

It does not take long after deployment for our clients to realize the benefits of Splunk ITSI because it immediately reduces alert noise.

Both Splunk ITSI and Splunk Enterprise Security handle incident management, but Enterprise Security utilizes common data models for improved detection. ITSI employs an "episode review" concept to analyze incidents, examining their generation, root cause, trigger alert, and any alerting failures. This provides comprehensive observability of each episode. Similarly, when integrating Enterprise Security with customer systems, pre-built common data models generate alerts that require monitoring to determine their cause, priority, and severity.

Splunk ITSI, using the correlation through event management, can reduce our alert noise.

We can correlate information to receive only relevant alerts, allowing us to quickly respond to issues.

The most valuable feature is event correlation, which ensures that only one ticket is generated per issue, eliminating duplicates and reducing noise from multiple alerts. This significantly streamlines issue tracking and resolution. Additionally, the system analyzes service performance by identifying areas of impact and tracking key performance indicators. This deep-dive analysis allows for the precise identification of issues and facilitates data-driven improvements.

While integrating services and KPIs in ITSI is straightforward, I found it challenging to analyze them with the service analyzers; specifically, using the deep dive feature to pinpoint the exact source and time of an issue proved difficult. Although I'm proficient in service analytics management, the deep dive aspect requires further development.

I have been using Splunk ITSI for two years.

Splunk ITSI is stable.

Splunk ITSI is scalable. It is easy to scale on the cloud platform.

The Splunk support team is adequate, but their response time is slow.

Positive

The deployment is straightforward. We acquired a license and integrated it into our current Splunk environment.

Splunk ITSI is a premium application and comes with a premium price tag.

I would rate Splunk ITSI nine out of ten. Splunk ITSI is a valuable tool for IT and operations teams.

I recommend Splunk ITSI. It's an excellent tool for infrastructure monitoring, direct management, and service analytics, providing a clear, consolidated view of your IT environment.

I use ITSI for different companies but with the same objective: to correlate alerts from different sources and assess them according to multiple frameworks. For example, I can combine the alerts from different sources into a single episode. The analyst can resolve the issue without looking in multiple places to get the necessary information.

ITSI was initially challenging, but you can pick it up quickly once you understand the concept. It also depends on the goal. Combining different sources into episodes is one thing, but integrating ITSI with automation or other ITSM solutions may take longer. 

The solution has a forecasting module. You must have a good infrastructure because AI takes a lot of processing, but it works well. Based on previous data, you can assess it in 30 minutes or so. Having that predictive ability is a lifesaver. 

It can streamline incident management. ITSI has a feature called Teams that lets you control access to different services to control which teams are responsible. You can control permissions and everything else. Everyone is assigned to a team with a unique experience while using the frame of the platform.

ITSI has a feature called NetFlow. It depends on what you plug into it, but in my use case, we usually click alerts before they become incidents and measure how many alerts become incidents to get an idea of how much it's helping to resolve things before they turn into incidents and have an impact. 

It has helped to reduce alert noise because we can group alerts from different sources into one ITSM ticket with information from various sources. This helps our team resolve the issue because they only need to look at a single ticket instead of opening multiple ITSMs to gather all the necessary information to assess the problem.

The amount of alert noise reduced depends on the maturity of the environment. When you set up rules to aggregate events, you have to know some information about those events, like the team that created them, the system they belong to, the impact, and whether they're infrastructure, a service, or an application. If you have those all set up, it could be a 75 percent noise reduction.

ITSI reduced our meantime to detection because ITSI is plugged into each search, and as soon as an event is detected, it's processed and sent to the responsible team. It has helped us to detect issues and resolve them faster so we can provide more information upfront to IT.

It helps the IT team resolve things faster, but it depends on the information that ITSI is grouping. If you have enough information to find the root cause, it can help to resolve everything quicker. For example, let's say an analyst is looking at five impacted services, but one of them is the root cause. If we can provide that information upfront to the analyst, he can resolve the issue much faster because he doesn't have to look at each separately to assess the cause. 

ITSI has helped us automate some tasks. Many issues aren't easily solved. You must have good communication with the team and analysts to see the steps they take to resolve something, but it can tackle the most common issues and free up time. But you must be careful not to automate something a developer should fix. Automation helps a lot, but you can't automate everything. 

What I like the most is the event correlations. It's a file structure, and ITSI has a correlation layer where you can normalize the events from different sources. Once these events are normalized, you set up rules to aggregate them into different or the same attributes. After the rules are defined, you can automate the process to solve the issue automatically. 

Generally, the visibility is decent, but you need to set it up properly to have good visibility in a way that makes sense to see the issues you need to see. In ITSI, you have the concept of services and a service tree. If it's set up correctly, it can help you find the root cause of a problem. You need someone who understands ITSI and your business. 

One thing ITSI could improve on is the maintenance windows. I have a huge case where I had to implement something related to the maintenance window. If you try to look up the issues in ITSI, you have to check the incidents individually, and putting hundreds of hosts in maintenance can be a hindrance. 

I have used Splunk ITSI for four years.

I rate ITSI nine out of 10. I've had issues before, but they are usually caused by the configuration or infrastructure. You have to be careful when deploying Splunk across your infrastructure. 

ITSI is scalable, but its engine is somewhat of a weakness. The engine runs on one machine, but ITSI is scalable because even though the engine runs on one machine, it assigns processes to other machines to work on. You can do well with ITSI horizontally, but sometimes, you need to think vertically because the processing takes some memory.

I rate Splunk support seven out of 10. Like any support, how fast they respond depends on the priority. Overall, they've helped a lot and were willing to enter a call to see the environment and the issues themselves. I would say do a good job overall.

Neutral

The complexity depends on your infrastructure. It's a lot easier if you have a single instance, but deploying on a cluster requires a little care. The package formats are specific to the roles of your cluster. We have to be careful with that. It's not too difficult. You can set it up in a day or two if you read the documentation. 

One person can set it up, depending on the size of the cluster. For example, if it only has two machines, one person can do it easily. You can set up a batch script to accelerate the installation. If you have that setup, you can do it easily in a day with one person. If you don't have that, it could take up to two days if you don't have much experience with ITSI.

I rate Splunk ITSI eight out of 10. I would recommend Splunk ITSI, depending on the company's context. If the ITSM solution they have serves them well, I don't think it's necessary to switch to ITSI because it's costly. I would only recommend it to someone who knows they will get a return and have the capital to invest. Small companies probably have a bit of difficulty using ITSI. If you're a big company having issues, ITSI can help you out. 

I recommend new users read the documentation carefully and watch a few videos on it. The first thing is to wrap your head around the concept. If you try to speculate at once without understanding a few things, it could be a lot more difficult. It's helpful if they stop and read the documentation to understand each piece.