What is our primary use case?
I am using Splunk Observability Cloud as a log-based monitoring tool for my databases. We have ingested our database logs and OS system logs into Splunk Observability Cloud and are creating dashboards and alerting features over those alerts. One of my major use cases is that all kinds of databases I am currently working with have database logs that capture all information, warnings, and error messages. These database logs are moving to Splunk Observability Cloud. The first use case is that I no longer need to maintain a long list of flat files on my server for all those logs. Those can be directly ingested into Splunk Observability Cloud. The benefit I am seeing from here is that I can get pattern-based analysis of what kind of errors I am commonly getting and what the date patterns of those errors are. I can get dashboards over that and I can also create alerts. I can also incorporate those alerts with some back-end Git workflow for automatic remediation. This is one of the solutions.
Another use case for Splunk Observability Cloud that we are seeing is that there are multiple times when there is a requirement to publish some kind of data. So instead of publishing an alert if those data breaches occur or if some kind of dashboard needs to be created, instead of sending data directly to the users, if that data is not PII, we are also ingesting that into Splunk Observability Cloud in a JSON format and then again, dashboards and other alerting can be created. These two are the main major use cases for which I am using Splunk Observability Cloud.
How has it helped my organization?
With the help of the alerting and observability mechanism, resiliency, and automatic automation of issue remediation based on alerts and workflows, it actually reduces the cost and increases the uptime of my system and customer satisfaction. There are multiple indirect benefits I am getting when using Splunk Observability Cloud.
Currently, with the growth of the organization, I am seeing an increasing use of Splunk Observability Cloud in a more dynamic way. We are continuously creating new dashboards, ingesting logs in JSON, and trying to bring the best value out of it. I am seeing a dynamic and drastic increase in the use of Splunk logs and the Splunk data we are ingesting.
There are two aspects to expanding the usage. Organic growth of the environment actually puts new systems into Splunk Observability Cloud, and exploring new opportunities for what all can also be ingested into Splunk Observability Cloud. Previously, I can see that memory dumps are there. We are also looking at whether we can ingest memory dumps so that if the system is about to crash, those memory dumps can be captured into Splunk Observability Cloud so that it can create alerts over that and I can also perform analysis. I can also see if any other system is facing the same kind of memory dump issues. So that maybe it is one alert for one system for me, but for the complete farm, there may be different servers with different teams or business units facing the same issues. When I have Splunk Observability Cloud on all systems, I can actually create a consolidated report and see that this is the pattern which particular farms are having this kind of issues, and maybe something is broken. This is the way the plan is to increase the availability or the usage of Splunk Observability Cloud.
What is most valuable?
The performance and speed are valuable. Previously when Splunk offered the enterprise solution, I needed to install Splunk and maintain my local server. There was a limitation that only a certain number of servers could be supported in one instance and I would need to have multiple instances if I was in an enterprise system setup. When I am in the cloud, a single instance can support N number of systems. It is pretty fast, no matter how much data is there. Dashboards are pretty good with multiple functions available. The alignment or integration that can trigger automatic solutions with the workflow for automatic remediation of the alerts is the best thing. These three or four things are the best Splunk Observability Cloud features that I am seeing.
The point in time alerting, the point in time data capture, and automatic remediation with the integration of good workflows or Ansible workflows is definitely the key to any resiliency and increasing the uptime of any system.
After moving to Splunk Observability Cloud, it is almost zero downtime. We never face downtime because when I was in the enterprise setup, I needed to maintain my servers and maintain hygiene of vulnerabilities, patches, and all. Now when I am in the cloud, everything is automatic. Almost zero downtime plus the perfect alerting feature and log-based analysis are available. Metrics alerting is also there in Splunk Observability Cloud through queries. This is one of the features that keeps me updated with the current health of my system and helps me to keep my system up and running fine and available for my customers.
Splunk Observability Cloud incorporated a new AI agent feature that is really good. Sometimes I need to create queries and Splunk queries for filtering the data and some pattern-based analysis. This agent is really good in helping me and suggesting the queries. This means I do not need to have a Splunk expert or Splunk query expert. I can just ask that agent that I need pattern-based analysis or I need to create this kind of filters for this kind of data and it can suggest to me. Once it suggests a sample query to me, I can do the tweaking and I can have my data ready. It actually reduces my time to perform my analysis and to reach the conclusion about what exactly is causing issues in my system and what are the repetitive issues in my system. This AI feature really helps for newcomers to Splunk Observability Cloud to perform deep diving analysis with the data captured by it.
Custom metrics are valuable. In Splunk Observability Cloud, some infra-level metrics are not available, but through custom metrics, I can achieve it. This is an add-on feature that Splunk Observability Cloud is providing and without any additional monitoring tool. If that feature was not there, then I would need to plan some other monitoring tool for metrics-based alerting, but this custom one helps me to achieve it in the same monitoring tool. The consolidation and integration of metrics-based alerting and log-based alerting in a single tool is actually the lovable feature. I do not need to worry about or look for multiple tools. I can have my own data and own health available in a single tool, in a single view.
What needs improvement?
The dashboards are good, but the only limitation I see currently is that they need particular formats only to create a dashboard. They need to have a particular JSON format or time series format. This sometimes creates additional work for me so that when I am ingesting logs in Splunk Observability Cloud, it should be in a specific format. Either Splunk Observability Cloud should have multiple formats available or multiple dashboards available for different kinds of formats. At least Splunk Observability Cloud has everything available at a Splunk level. They can do some kind of analysis and see what are the major top ten or top twenty types of logs they are getting and they can have dashboards according to those logs. Instead of forcing customers to design their logs in the way of Splunk Observability Cloud, Splunk Observability Cloud can create dashboards based on the customer requirement. This will actually ease things up for the end users.
The current dashboards are good. The feedback is that Splunk Observability Cloud is forcing me to modify my logs that I am ingesting in Splunk Observability Cloud in a specific format. If Splunk Observability Cloud can leverage it and make it open for any format, that would be great. If that is not feasible, at least the top ten or top twenty logs that Splunk Observability Cloud is getting should be readable by Splunk Observability Cloud without any changes. That actually is one of the major feedback items I can provide which can actually ease the life of the end users or any layman. As a newcomer to Splunk Observability Cloud, I may not know JSON. I now need to hire someone or I need to look for someone who knows JSON and who can convert my logs into JSON format and then I will ingest them into the logs if I want to create a dashboard. If I do not want to create a dashboard, that is okay. On the other hand, Splunk Observability Cloud is giving me a usability and easy to go interface, but for a dashboard, I need to have an understanding of JSON so that I can ingest the log in JSON format. That is a dilemma that they have and they should work on.
Currently, Splunk Observability Cloud is not the only solution which any organization is using. There is also Grafana and PagerDuty. If Splunk Observability Cloud can plan some kind of integration with PagerDuty and Grafana, then those things can be controlled from a single position and if something else is happening at one location, it can update things at all levels. That can also bring great value to the users. Currently, I have to maintain three systems separately, but if some kind of integrations can be developed with these three vendors, then that can be a great thing because all these three have now become the industry pillars or industry standards for observability and resiliency.
For how long have I used the solution?
I have been working with it for the last two years. Before that, it was an enterprise solution. Now it is cloud-based.
What do I think about the stability of the solution?
I cannot relate any stability issues to my experience with Splunk Observability Cloud.
What do I think about the scalability of the solution?
Scalability is pretty smooth. I just need to deploy the Splunk forwarder and the config file that specifies which servers it should connect to and it will get connected. My data will start populating. It is pretty straightforward. I do not see any challenges there, even when it was in enterprise and now when it is in the cloud. The deployment and onboarding of new servers and ingesting the logs is pretty straightforward. Anybody can learn it within a day without having any prior knowledge.
How are customer service and support?
We have raised multiple questions when we face any issues. Our support is prompt and usually within a day, I will get my answers.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
Previously I was on Splunk Enterprise. I have been using Splunk for seven to eight years before we moved to the cloud in the last eighteen months.
How was the initial setup?
The initial setup is pretty smooth. I just need to deploy the Splunk forwarder and the config file that specifies which servers it should connect to and it will get connected. My data will start populating. It is pretty straightforward. I do not see any challenges there, even when it was in enterprise and now when it is in the cloud. The deployment and onboarding of new servers and ingesting the logs is pretty straightforward. Anybody can learn it within a day without having any prior knowledge.
What other advice do I have?
I appreciate that your organization collects reviews about the product so that it can be shared with the vendor or the product owner as appreciation or as feedback for improvement. Everything has been smooth in my experience. I would rate this product a ten out of ten.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Other
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.