Currently, we are in the process of migrating from on-premises to Splunk Cloud as well as Observability. For metric-based monitoring, we can monitor via Observability and are migrating it there. We are setting up private locations to monitor synthetic tests, such as ping checks, port checks, and URL monitoring. The rest is metric-based monitoring, which is being done by Splunk using Splunk OTeL, which is an OpenTelemetry agent for Observability. This agent brings metrics from end devices to Observability. Based on these metrics, we set detectors and rules to trigger alerts.

Our observability is not yet live in production with Splunk Observability Cloud. It is currently being built, and we are adding new components, but it is not yet fully ready.

Comparing to Cloud, Splunk Cloud, or any other solution, the most valuable feature of Splunk Observability Cloud is that it is entirely based on metrics. The agent is also very lightweight compared to Splunk UF and does not consume much compute resources on the end server or host from which we are pulling data. However, it can only monitor metrics and cannot monitor logs.

Regarding how Splunk Observability Cloud has benefited our organization, we are yet to go live, but most of the configuration that requires conditions and triggers on Splunk Cloud involves writing queries. With Splunk Observability Cloud, the process is quite simple. We can directly get metrics flowing, set thresholds, and everything is UI-based. This requires less time to set up and use. I do not have that much visibility with Splunk Observability Cloud at this time as I am working as an administrator. It has helped us create dashboards for visualization purposes.

There is one thing that could be improved in Splunk Observability Cloud. We have the capability in Splunk to connect to Splunk agents such as Splunk forwarders from a deployment server and update the end agents and forwarders using server classes. We can push and update configurations from our own hosted servers without needing to access the end device. In Splunk Observability, the OTeL agent cannot be updated from our end. Every time we need to update, we have to reach out to users or gain access to the host to update the configurations. There should be a solution to update OTeL agents from Splunk Observability Cloud itself.

I have been working with Splunk Observability Cloud for approximately five to six months.

Splunk Observability Cloud is reliable based on my experience with stability and reliability so far.

We were facing some challenges with the stability of Splunk Observability Cloud regarding the login page. It was not working several times and was not accepting SSO authentication. The observability team found a solution for this issue, though I am not fully aware of the details. There were several times when opening the page did not directly log in and showed some errors.

I have not encountered any scenarios regarding the scalability of Splunk Observability Cloud. It should be good because it is cloud-based. I am not aware of the licensing model and how it scales or what the rules are for scaling.

I was not directly involved with technical support for Splunk Observability Cloud, but I am aware that my teammates reached out to support. They were finding issues regarding configuration, installation, and deployment of Observability for specific components. Since Observability is cloud-based and hosted by Splunk, the components we own on-premises are the OTeL gateways, agents, and private locations. They reached out to the vendor regarding these components, and the support was quite smooth. They have raised some bugs as well for the vendor to fix. I would rate the technical support from Splunk an eight out of ten.

Since it is cloud-based, Splunk Observability Cloud was ready to use upon deployment. The OTeL gateways were built by our team and required configuration. I was not part of that process but am aware that we needed to configure the OTeL gateways to route data to them as an endpoint and from there it would be ingested to Observability or forwarded to Observability. There were no significant issues with this process and it was quite smooth. However, configuring private locations on a few gateways was quite difficult to set up and maintain because Docker was going down at times. There were some issues that were discussed with Splunk vendor, and they provided guidance on how to fix them.

My use case for Splunk Observability Cloud is primarily for monitoring and cloud management, and it serves us well.

The best features in Splunk Observability Cloud that I appreciate the most include its comprehensive monitoring capabilities and its user-friendly interface.

The solution has significantly helped improve my operational performance and my company's resilience by providing real-time insights. The enhancements to my operational performance and resilience are noticeable.

It has saved me a considerable amount of time and resources by streamlining our monitoring processes.

My impression of the AI-powered analytics and guidance provided by Splunk Observability Cloud is that they are very effective and enhance our decision-making.

I do use the no-sample tracing feature to eliminate blind spots in data collection, and it is quite helpful.

My team has effectively utilized the ability to enrich data with custom metrics to improve our analytical capabilities.

The out-of-the-box customizable dashboards are effective, and they help showcase IT performance to business leaders quite effectively.

In Splunk Observability Cloud, the areas that have room for improvement include usability enhancements to make it even better.

I have been using Splunk Observability Cloud for a considerable time, and I can share my experience with it.

Regarding stability, I would rate the stability of Splunk Observability Cloud as a 9, indicating it is very reliable. Splunk Observability Cloud performs exceptionally in terms of stability under varying conditions.

From 1 to 10, I would rate the technical support as an 8 since it is generally responsive and helpful.

The solution was purchased through a partner, and my experience with the partner has been generally positive. My experience with the partner has been satisfactory as they provided the needed support throughout the process.

My experience with lowering the cost of unplanned digital downtime has been positive as it has indeed reduced downtime.

Regarding the pricing of Splunk Observability Cloud, while I believe it can be improved, I would rate it around 7, leaning towards being expensive.

I would compare Splunk Observability Cloud with other solutions as more feature-rich and user-friendly based on my concerns.

For others looking into this product, I would recommend trying it out with a proof of concept to see its benefits firsthand.

Approximately 50 users in my company use Splunk Observability Cloud to leverage its capabilities effectively.

The solution does require some maintenance, but it is quite straightforward in managing it.

In terms of my company's relationship with Splunk, we are currently a customer making the most of their offerings.

I would rate Splunk Observability Cloud a solid 8 from 1 to 10 based on my experience and satisfaction with its performance.

I have been using Splunk Observability Cloud for the past one year in my career. Splunk Observability Cloud has been introduced to our project for end-to-end monitoring for applications, providing complete visibility of applications, services, tech stacks, and CIs, which constitutes the whole monitoring solution for an entire application.

Previously, we were using different monitoring systems such as Dynatrace, the competitors of Splunk, and even Splunk Cloud Platform or Enterprise platforms for logging alone. Now we have the entire solution under one name and one platform, which is Splunk Observability Cloud, and that is why we mainly introduced Splunk Observability Cloud to our project.

The UI is quite understandable, making it not as complex when compared to the other previous platforms I have worked on. Another thing I could specifically point out is that we can have entire visibility for the entire application performance when we look into Splunk Observability Cloud, and it is much easier to navigate across various aspects such as real user monitoring, application performance monitoring, or synthetic tests, making it stand above the other previous applications I have worked on previously.

One thing I should point out is that there are some auto-detectors which are defaultly present in Splunk. For example, if you are configuring a detector for AWS RDS service, you have an auto-detector which detects what the technology is, and you will have a readily available detector, needing only to configure your specific metrics on that, which is one advantage. The dashboards especially stand out, being different compared to the other platforms. Even previously, Splunk Enterprise also had dashboards, but this is different as we can have live metrics through the dashboards, which is quite impressive with how Splunk Observability Cloud has been introduced and it is performing better than the previous Splunk versions.

When we have too many detectors in place for one particular app, such as when I have created 50+ detectors through my account, the entire page becomes a bit loaded when creating the 51st detector, feeling heavy and taking time to load. Additionally, it throws random errors; for example, when we try to save one detector, it might throw some random error which is not even related, with something else being wrong, not that particular error, but the underlying root cause might be different. Sometimes the error is just "some problem occurred," and we are not able to point out what the real cause is.

This mainly happens when we have too many detectors or too many alerts in place rather than a standard number. One more thing is in the alert rules; if we have a main general alert, and instead of creating a new detector, we are adding a new rule under one detector, when the number of rules also increases, such as when we have 10 or 15 rules under one generic detector, that again creates the same kind of problem, taking some time to save that particular newly added rule, and it might not save at times, just keeps on spinning. Those are the two drawbacks which I spotted recently; other than that, everything looks perfect.

There was an outage which occurred about three or four months ago; that was the only outage I faced entirely in one year, and I believe that was a global outage from Splunk's side, which prevented us from logging in for a couple of hours. The Splunk team was working on it, and they resolved it within five or six hours, which was the only outage I faced in one year. Other than that, everything was smooth.

Splunk Observability Cloud is quite scalable compared to the other platforms I have worked on, and I do not find any difficulty in scaling up or even scaling down.

For particular kinds of issues which we were not able to resolve, we have raised Splunk tickets a couple of times before contacting the technical support or customer support. The support is an eight out of ten. The speed is actually quite good; they would respond within 48 hours, and the solutions they are giving are quite good, as we were able to solve most of the issues with their solutions.

I have used Dynatrace and DataDog as alternatives to Splunk Observability Cloud.

The initial deployment of Splunk Observability Cloud is actually easy. With the clear documentation we have in place, it is quite straightforward. We even have examples of code snippets in the documentation, making it quite straightforward.

One or two people can manage the deployment; you do not need a team of five. I have myself worked on an entire project, and with one of my colleagues, I have worked on a much bigger project. I believe one or two people can easily manage the deployment process.

Splunk Observability Cloud has helped me reduce my mean time to detect. We have worked on around 80 applications last year for one particular client, and since the MTTR has improved drastically, they have given us 245 applications, which is around 150 applications added to the previous number of applications. This is definitely a performance improvement.

The pricing area I am not particularly aware of because that is centrally managed by the company which I work for. However, I feel that we are not spending too much on the licensing cost; it is manageable for how much we are working with currently for the number of applications we have at present, which is what I believe is not too much.

I would prefer Splunk Observability Cloud any day when comparing these solutions to Dynatrace and DataDog because the first thing is that the documentation Splunk has is perfect, and anybody who is new, even new to the platform, can gain knowledge reading through the documents, which are perfectly explained for configuring various kinds of technologies and integrating various kinds of technologies with Splunk Observability Cloud. The second thing is the UI, which is much more user-friendly compared to Dynatrace and DataDog.

The No-Sample Tracing helps me eliminate any blind spots in my data collection because we have particularly many services, and for example, using Mule, it is an added advantage to use no-sampling traces provided by Splunk Observability Cloud, giving us the exact points where the service is emitted and the exact spans between the two endpoints. It helps us break down where the actual issue is rather than just getting sample trace data and looking into each point entirely, which takes much time, providing a particular breakdown of that span and how it navigates across endpoints and pointing out the particular error which occurs when we access a service or when a service travels across two endpoints.

As of now, we are not using any AI tools in Splunk Observability Cloud, but we are planning to onboard them, considering that the number of applications we have is increasing day by day. We are planning to automate a few applications to generate the detectors and synthetics automatically as soon as we have the metrics in place. For that, we are developing code that can integrate with Splunk Observability Cloud platform and generate the results, which will be a time saver for us.

The recent UI changes have been more streamlined. Initially, the UI was a bit different, but later, I believe a couple of months ago, maybe one month before, they re-modified the menu options, and that has also resulted well for us in navigating across the panes.

I have utilized the ability to enrich data with custom metrics in Splunk Observability Cloud; I did it for custom metrics for AWS services, and for a couple of MQ, IBM-based MQs, we have worked on custom metrics, integrating easily in both cases. My company may have partnerships with Splunk, but I am not sure of that. I would rate this review as a nine 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.