The data recovery has room for improvement.

Microservices is the only area where Splunk ITSI can be improved. When things come from one EC2 instance to another, there's a lack of exposure to microservices, so we can't know what's happening. Apart from that, it's doing pretty well.

Predictive analytics, in terms of preventing incidents before they occur, still needs time to mature. I am not very, I would say, convinced of the prediction feature's capabilities.

It does not have a release comparison on the server comparison feature. For example, if you have an application, and you introduce a new feature, and you're going to deploy it, then the release comparisons should show automatically or generate a report to show the impact of the feature on the overall application. It should show what you can do to optimize it. 

We can take actions based on NEAPs, like emails and service now tickets. It is pretty basic at the moment. The solution should integrate more features in NEAP.

It could be a little easier to use with the thresholding. We've struggled a little bit with thresholding.

We're using predictive analytics, and there are three or four algorithms. It would be helpful if this process were more standardized and scalable. 

One issue we have with Splunk Cloud is that the service team is sometimes not very helpful. This is because the team is outsourced, and they often cannot provide us with the information we need. This is a major complaint of mine, and it is unacceptable given the large amount of money we pay for the service. Splunk Cloud outsources its support team, and the people who are supposed to be helping us are not very knowledgeable. They often give us unhelpful or incorrect answers.

The UI needs improvement. With real-time monitoring, we can have a service structure, but we cannot easily adjust the graphical interface. For example, if we have a long name or a 2005 feature, we cannot easily move it slightly to the right on the web page. This can be a real pain.

Our large-scale system is noisy, making it difficult to pinpoint the exact cause. This is a trade-off for using Splunk as a central monitoring tool, as we cannot give everyone access to everyone else's AWS environment. We are investigating ways to reduce the noise, but I am not sure if it is a specific ITSI problem.

Quality-of-life features have room for improvement. The search function and other features are fine, but there are a few UI changes I would make. For example, I would like to be able to extend the graphical user interface so that we can see the full name by moving the window around. It is currently difficult to work with. 

We can create a correlation search, but when we save the page, it redirects us to the search system. We should be able to save the page and stay on the page, which is a bit annoying.

We have a lookup file, but it doesn't work very well. In fact, it doesn't work at all. I hope Splunk fixes this at some point. When we make a change, it completely wipes out the change. It also says to type in the search bar, click on what we need, and if we make a slight adjustment, it will completely wipe out the search bar and we have to start over. This is very annoying.

It would be advantageous to enhance the dashboard by incorporating sections for monitoring, service health, and a filter for the KPIs.

If the product had some prebuilt machine learning features, it would add value to our use cases. It would be very good if the product had some in-built predictive analytics and future forecasting features.

Splunk ITSI's predictive analytics has room for improvement. Currently, it is limited to predicting only the health score for the next thirty minutes of the business. Consequently, we are unable to predict our health score for a full day or even for seven days. The system's capability is limited to the next thirty days, and we need enhancements to enable us to predict the health score at least seven days in advance. Furthermore, the available algorithms are also quite limited, with only around eight to nine algorithms, including linear regression and classification. We lack a diverse range of machine learning algorithms within Splunk ITSI, which is a contributing factor to the issue. Additionally, the implementation process for Splunk ITSI is quite challenging, as we struggle to find well-trained resources capable of translating our business use cases into technical outcomes effectively using Splunk ITSI. This is a crucial aspect that needs attention. 

Splunk ITSI generates numerous false positives and has the potential for enhancement.

The solution is okay. I am not sure whether the current release has already moved to the new framework where instead of the glass tables, we can directly use the Dashboard Studio. It would be nice to have that integrated into the same framework.

If you are using Splunk ITS and Splunk Enterprise Security, you have to run different searches. You cannot run both on the same server. You can bifurcate it however you want, however.

The license cost is expensive. When I want a premium application it's extra. I need to pay for this on top of my base license. 

We'd like to see more use of artificial intelligence. There's no easy knowledge-base bot. It would help if they had a ChatGPT-like AI that could show them the knowledge base information they could use to address tickets.

It has been a large learning curve. We used Splunk Enterprise. The dashboards are pretty simplistic for the developer at first, but when they went into ITSI, it was a different world. We lacked training. We played with it a little bit, and then we brought the Splunk team in, and they did a service decomposition and whiteboarding, and it made more sense, but it was an intimidating tool for us to jump into at the beginning.

After upgrading Splunk ITSI from version 4.11 to 4.13, the analyzer stopped finding values for KPS and services. We had to manually deploy a script to resolve this issue.

Splunk ITSI could function even better, particularly when it comes to refreshing the service infrastructure. If we could have the option to go back not just sixty minutes, but also one or five minutes, it would enhance our capabilities.

The service analyzer component is excellent, particularly the default analyzer. However, I believe the refresh time should be faster. If it also takes five minutes to complete, as suggested by the KPI requirements, then the refresh time should be significantly reduced. If the data doesn't load within five minutes, our service and KPI will not function properly. Therefore, it is crucial to make it faster.

I would appreciate having more customizable dashboards to assist with in-depth analyses.

Splunk ITSI consumes a lot of CPU resources. I would like a more lightweight solution in terms of resource consumption.

The price has room for improvement.

We have problems doing upgrades and operating alternate new versions.

The migration of the existing glass tables needs improvement. There were at least two upgrades where we had to heavily update the existing glass tables to get them to work with the new version. 

That's something that Splunk could improve on. They should simplify the upgrade process. 

There are no areas I can pinpoint that need improvement because the product is working well. It would be good if an interface was included in the next release.

In Splunk ITSI, thresholds automatically trigger incidents when a service value falls below the threshold. This prevents us from automatically triggering alerts for situations where the service value is within the acceptable range. We've identified this as an issue with the ITSI product and are working with Splunk for guidance on how to implement the desired behavior.

While the overall Splunk documentation is detailed, the documentation for specific premium apps, like Splunk ITSI, is more brief.

The technical support has room for improvement.

ITSI could benefit from a security model that would allow operations team members to get involved in model building, KPI implementation, and model maintenance while maintaining appropriate segregation of duties. To date, all of our ITSI development is being done by our Splunk Admins, while our KPIs and much of the modeling work are managed by our Splunk developers. Future development of templates and ready to use add-ons could facilitate faster time to value, as many IT infra and even Packaged Application data models are consistent across organizations and could be plugged in easily. 

Something that we did find with the product (they may have resolved since then), had to do with the ability to contextualize the data sources. For example, we might bring in data for 50 applications from one source, but for each one of those applications, we would have to set up a different data source connection. Because of this, I had to set up one connection each for application A and then B and then C, rather than being able to set up one connection and then segregate the data coming in for those dashboards. That was probably the biggest challenge that we faced. We also faced challenges relating to UI development — being able to get the UI the way we wanted it to look performance-wise. Some of the customization levels of the UI just weren't there.

Integration is the most critical area to improve in Splunk IT Service Intelligence (ITSI). It wasn't a great experience because you had to do a little back and forth to integrate the solution.

I want more integrations in the next release of Splunk IT Service Intelligence (ITSI), and the solution should be seamlessly connected with other solutions during integration.

We haven't come across any shortcomings. 

We'd like them to show more inputs on the dashboard. 

The Wizard should be easier to use. 

The dashboard queries should be improved. More queries should be suggested in order to produce better dashboards.

Splunk ITSI lacks out-of-the-box solutions for enterprise users. Currently, everything needs to be created from scratch.

In their next release, Splunk should offer API integrations with products like ThousandEyes, and AppDynamics, or some other network monitoring tools or dashboards. 

The problem becomes the price, as Splunk is an expensive product. In some regards, it's not a large issue because when you compare apples to apples and not look only into the price tag, but, look at the infrastructure, the platform,  office time, and the people that you need to operate the other products, you will see that it's not necessarily an expensive product. It may even be cheaper than the others when looking at the bigger picture.

Some of our customers occasionally require the development of the connectors when there are no native connectors so that we can develop in Python or for customer slash comments as well. If they could adjust that, it would be ideal.