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.

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.

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.

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.

I have been working with it for the last two years. Before that, it was an enterprise solution. Now it is cloud-based.

I cannot relate any stability issues to my experience with Splunk Observability Cloud.

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.

We have raised multiple questions when we face any issues. Our support is prompt and usually within a day, I will get my answers.

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.

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.

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.

The main use case with Splunk Observability Cloud is to capture the logs from the SD-WAN in order to check the health of the network and the flow of data from different sources to the central place.

The best feature of this product is the latency and processing of all the telemetry that is being received, which gives full visibility at the right time.

One cannot protect and operate what they don't know. When there is this observability, it helps to see exactly what is present, the problems that may exist, and hence, it increases digital resilience by having proactive actions ahead, which increases the availability of the service.

The teams have utilized the ability to enrich data with custom metrics, as this enrichment is one of the key aspects used to have a clear understanding of which assets are being attacked, enabling necessary actions to be taken. The data has been enriched by adding customized information from customers' databases from different sources.

The pricing would be one area for improvement.

I have used the SIEM solution since 2019 and have had experience with Splunk Observability Cloud for the last year.

I would rate their customer service and technical support an eight out of ten.

I work for SI, and we deliver to different organizations based on their requirements. We are responsible for implementation, so we implement and they see the value out of it.

Splunk Observability Cloud has improved the operational performance of our clients.

It is expensive.

The AI component is one of their strengths; currently, most competitors are moving in the same direction. As SI professionals, we are seeing different improvements in the AI domain for different products, and they are at the leading edge with many vendors following them.

My overall rating for Splunk Observability Cloud would be a seven out of ten.

My main use cases for Splunk Observability Cloud are indexing, dashboards, alerts, and reports.

The dashboards are the features of Splunk Observability Cloud that I appreciate the most, providing visual representation of all data and text. These features have benefited my organization by speeding up people's jobs, allowing a place to monitor all logs, as there are usually thousands of entries coming in which can become very disorderly. Users can monitor everything and write queries to organize the data and build dashboards to visualize it. This creates one-stop shops to get answers on how products and applications are performing, as opposed to having to jump onto servers and look through numerous logs.

The main improvement I would suggest for Splunk Observability Cloud would be offering the ability to implement custom apps, specifically allowing Python scripts that Splunk Cloud could host. Currently, we cannot create custom apps through Splunk Cloud. Additionally, continuous performance improvements for faster searching and indexing would be beneficial.

I have been using Splunk Observability Cloud for over the last year.

I would assess the stability and reliability of Splunk Observability Cloud as good. There have been some performance issues, though not necessarily crashes, occurring approximately 20% of the time or less.

Splunk Observability Cloud scales smoothly with the growing needs of my organization. There have been some cases of performance loss due to rapid onboarding. We are handling multiple terabytes of data daily, so we expect some hiccups, but otherwise, it has scaled effectively for our fast-paced migration.

My experience with customer service and technical support has been very present and super responsive. When we submit a case on Splunk support, they usually reach out within the same day or next day. They have consistently helped us resolve any issues we've encountered.

I used Splunk Enterprise before adopting Splunk Observability Cloud. While other parts of the company were leveraging different logging tools, we primarily revolved around Splunk. When Splunk Cloud became available as the next option, we were ready to migrate.

I haven't had personal experience with pricing, setup cost, and licensing as it's managed by our managerial side.

I have seen a return on investment with Splunk Observability Cloud through faster debugging and troubleshooting capabilities with enhanced observability. A significant return on investment comes from not having to host Splunk Enterprise ourselves. Having servers on Splunk's end allows us to focus more on development, monitoring, and our products, rather than maintaining our own local version of Splunk.

I would rate Splunk Observability Cloud overall as a solution 9 out of 10.

My main use case is end-to-end monitoring for the application.

We utilize the APM and auto-detectors, as the core metrics and core alerts are available for us, which are the features of Splunk Observability Cloud that I appreciate the most.

We lead the SRE, so our job is to ensure reliability, stability, and uptime, and without good observability monitoring, there is no way we can accomplish that. This is the main tool that we would use.

I would evaluate the effectiveness of Splunk Observability Cloud in improving digital resilience by saying that the idea is to minimize incidents. If any incident happens, the first thing I would do is go back to see why Splunk Observability Cloud did not detect that. I will take it back, do the reverse engineering to find out where it was missed out, and then work with the team to ensure these things are identified.

I have yet to experience the No-Sample Tracing feature in Splunk Observability Cloud, however, I am only in conversation with the teams where distributed tracing is required, and we want to provide the traces. My teams utilize the ability to enrich data with custom metrics in Splunk Observability Cloud, and I appreciate the feature supported within the Observability Cloud. Custom metrics could also be introduced from within the microservices, so I am yet to explore the OTEL library. I gave this feedback to the Splunk team that they should have their dedicated .NET library that customers can embed and start using; I do not think that is there today.

We are the first project within the company for a fully cloud-native application, so we will set the ground for the rest of the teams to get motivated. Therefore, I expect that I will have the best experience to become an example for others.

The integrations need to be improved for Splunk Observability Cloud. Currently, they do not have great support for Azure. We are on Azure, and I know they invested a lot of time in AWS yet not in Azure.

I had given feedback to the teams here, as the integration from Azure Cloud, how we supply the logs and the metrics, is not clearly documented yet, which was acknowledged by the team. For example, the OTEL collector has a thousand parameters, and we need a very specific use case with 10 parameters required for our integration. We can't go through the thousand parameters; we can, however, that is basically why I think some integrations need to get better for Azure.

There's a lot of talk about AI-powered analytics and guidance in Splunk Observability Cloud. I didn't get a great sense of how much of it is actually working; there are a lot of AI hallucinations. I think it probably needs much more improvement to contextualize it so that it is very clear and precise about what it randomly thinks, but it needs to match the context better.

Customer service and technical support need some improvement. We had issues with technical support, and the professional services were struggling as well.

I've been using Splunk Observability Cloud for six months.

I would assess the stability and reliability of Splunk Observability Cloud by saying no crashes or performance issues have been experienced.

On a scale of one to ten, I would rate customer service as eight.

My experience with deployment has been good. It's just the routing, the matrices, and the integration is where we were struggling a little bit. That said, having the cloud as observed to provision was never a problem.

I hope to see a return on investment with Splunk Observability Cloud. I have not applied this for production. That said, we already use Splunk Cloud for production, and we are good with that, so I see the value.

The cost is fine, and we are good with what is given. It's a centralized tool for my organization, so at the org level, a lot of things were decided, but we are actually happy with the cost we received because I know I have to approve my budget, and it's within our range, so we are okay with it.

My advice to Splunk is to mix Splunk Cloud and Splunk Observability Cloud into one. Don't make oObservability only needed in Splunk Cloud, too. You don't want to have two products competing with each other; you want to compete with someone outside your organization. Combine this, as there's a lot of confusion. Even in different classes and training sessions meant only for Splunk Cloud, they were not for Splunk Observability Cloud, and they are different today. The acquisition of SignalFx, which is not its own, adds to the confusion. So, to the customer, provide one interface, and combine them.

On a scale of one to ten, I rate Splunk Observability Cloud an eight overall.

Our main use cases for Splunk Observability Cloud are to observe our application, our websites, and our infrastructure metrics.

What I appreciate the most about Splunk Observability Cloud is the APM part and the log analytics part. These features can help us with troubleshooting our problems between multiple systems.

Distributed tracing is very useful to us, and the infrastructure part can help us identify problems with the infrastructure. Splunk Observability Cloud has helped improve our operational performance and our company's resilience on the path of adopting it, and I expect more improvements in the future.

The RUM part of Splunk Observability Cloud can be improved significantly. We are currently struggling to use it since our application is mixed mobile and non-mobile. Some AI features in the search functionality could be beneficial in the next release of Splunk Observability Cloud.

In GCP, Cloud Run is not natively supported by Splunk, and we are challenged with bringing data from Cloud Run to Splunk. Native support of it in the future would be great for us.

We started using Splunk Observability Cloud one year ago.

I would assess Splunk Observability Cloud as quite reliable. The only problem is the graphical interface, which sometimes is buggy. It crashes, doesn't display data, and requires reloading the browser. I have experienced downtime with Splunk Observability Cloud only once, which lasted one hour due to issues that prevented us from logging into the platform.

Splunk Observability Cloud scales with the growing needs of our organization quite efficiently. I have expanded the usage of Splunk Observability Cloud, and the process of expanding usage was smooth apart from one part.

Customer service and technical support respond very quickly. That said, sometimes the solutions take too long to implement.

Before adopting Splunk Observability Cloud, we used DataDog, and before that, we had no solution. The factors that led me to consider the change were mainly because my company has different IT offices. My IT office used DataDog, another IT office used New Relic, and others used different tools. We needed to adopt Splunk across the group to have something standard in my company.

My experience with deploying Splunk Observability Cloud was quite good, mainly since we almost have everything on cloud and that makes deployment quite easy.

My advice to other organizations considering Splunk Observability Cloud is to adopt it if you don't have anything else as it's a very good tool, and having something for observability is very good. Not only for the observability part but for all the Splunk platform, that's great.

On a scale of one to ten, I rate Splunk Observability Cloud a seven out of ten.