Splunk Observability Cloud Reviews

Our use cases are basically just bringing log aggregation like application logs into Splunk, working on the integrations with observability. Unfortunately, with our current setup, we just have to implement Log Observer in a couple of instances so that we can have that integration with Splunk Observability Cloud. But mostly, we are working on getting logs into Splunk, so one of the primary things we've been working on is ingesting Azure logs through Event Hub into Splunk and trying to correlate across our disparate platforms.

I don't use any of those. We actually have a security team that works with Splunk Observability Cloud, and we have SOAR, but that's not me. I'm more focused on Splunk Cloud.

My understanding was it was just Splunk. A review of Splunk in general was supposed to be conducted, but there was nothing that specified Splunk Observability Cloud, because I'm not involved with that.

Probably my favorite feature is just the integration through Log Observer, but unfortunately, the PCI requirements we have working with WestJet prevents us from fully implementing Log Observer just because when you do Log Observer, you have to sign a document that states your responsibility for PCI compliance could be broken. That was a hard sell, but we were able to work around it. Other than that, the visibility to track observability traces directly to the application logs was really cool.

It has helped improve the operational performance of our operations. As we start getting our services mapped out in observability, we've been able to bring insights into aspects of the WestJet operations that have surfaced. We recently had an outage that showed up in observability but didn't appear elsewhere. In hindsight, we were able to identify the error from inferred services with visibility into them and now we have alerting set up to notify the team. Just because of the third-party vendor that went down, we were able to show in our observability that this inferred service was not working properly. That was a huge win.

From our experience, the quality of the out-of-the-box dashboards and detectors is okay as a starting point, but we've had to do a lot more custom work. We are working on templating our observability setup for Kubernetes so that when new applications are implemented, they auto-populate existing dashboards and all related components. We're putting in significant effort to build that template out.

Looking at other tools and comparing them to Splunk, the ability to curate the data that is being ingested is a lot more labor-intensive and not as intuitive as some of the competitors. The Edge Processor that Splunk has really needs a redo to be easier to use and more intuitive for setting up custom ingestion rules to ensure PCI information such as payment card details is masked. We've seen other tools that do it well, but I am looking forward to the new Splunk upgrade, which appears to be adding a bunch of new features to the Edge Processor.

We don't have any other observability solutions, but we are kind of aware and looking at the market. The Edge Processor has been the biggest issue, and we've noticed that the integration with Microsoft isn't as strong as it could be, with limited visibility into function apps and integration with other Azure components needing improvement.

I've been using Splunk Cloud for just over three years.

Splunk Cloud has been quite stable. We did experience an outage during the Victoria upgrade, which didn't go well and caused some downtime, but other than that, it's been good.

From our perspective, it's scalable since it's a hosted solution. We haven't run into any limits based on our licensing; everything has been fine. As we increase our observability, we may have to look at expanding our licensing as more teams adopt it. A lot of our storage issues are due to not curating data, and we're currently doing a Splunk cleanup to better leverage the tool after inheriting some poor configuration.

I have contacted technical support.

Quality and speed in my case have been quite good; I've had no concerns with Splunk support.

For support, I would rate them an eight.

Splunk Cloud was already in place when I joined the company, and I got hired because of my previous experience with on-prem Splunk.

It's starting to help reduce our Mean Time to Detect (MTDD) because the visibility we gain is unprecedented, allowing us insight into applications that we've never had before.

Splunk is a very expensive tool, and I think that's one of the problems they face as competitors in the marketplace offer better value. They might need to reevaluate their pricing since competitors are catching up, and the cost is very high.

Splunk Cloud doesn't require maintenance from our end since it's hosted, but some maintenance doesn't get coordinated well with us. Maintenance is often scheduled without giving us enough time for proper change management on our side, which could be improved.

At this point, we're still in the early stages of implementing observability. We definitely see the value and potential it has, but leveraging it effectively will be crucial to justify its cost.

I am not involved with using Splunk Observability Cloud; that's a different team.

I would rate this review a seven.

I work for a managed service provider, so I have different clients that require help in assessing various tools. I work with Splunk, ScienceLogic, and Nagios most frequently because I have small clients as well.

We have Splunk Observability Cloud for some customers. The dashboards are good, and everything is nice, but unfortunately, it doesn't have long-term storage of the logs. So you need to use a data lake to store the logs.

I would like to see agentless deployment and better integration with ticketing systems like ServiceNow, which is the biggest.

We utilize the ability to enrich data with custom metrics in Splunk Observability Cloud to create tickets in ServiceNow. It is integrated with ServiceNow, but we enrich the tickets by putting the logs in the tickets and things of that nature, so it helps us. However, even that is a mixed approach. From Splunk Observability Cloud, you cannot put the logs directly in the tickets. Instead, it will create a ticket and send you an email with the logs. That integration could be improved.

Splunk Observability Cloud has helped me improve my operational performance and my customer's operational performance because we use alerting, so we find when things are not working.

I think it is very good for evaluating the effectiveness of Splunk Observability Cloud in improving digital resilience within my customer's environment.

It does provide some return on investment. It is beneficial in terms of finance to use it.

The dashboards in Splunk Observability Cloud are amazing. If you configure them correctly, they are amazing, and it is quite fast as well.

That is a very good feature of Splunk Observability Cloud because it helps us and it gives more trust in the alerts.

There are not complexities with the installation of Splunk Observability Cloud, but with the configuration of alerts and everything because Splunk has its own language in the background. You need to know Splunk in order to configure everything that you want.

It requires some in-depth knowledge of the product. It should be more plug-and-play, similar to ScienceLogic. ScienceLogic uses whatever it finds. You can use PowerShell, you can use scripts that you make. Splunk is more on the old style. It uses agents, and you have to deploy the agents.

The out-of-the-box customizable dashboards provided by Splunk are okay, but usually, I have to create new dashboards because every user wants to see something else. The out-of-the-box dashboards help to get started faster, but in the end, I will have to redo them.

I would like to see agentless deployment and better integration with ticketing systems such as ServiceNow, which is the biggest.

We utilize the ability to enrich data with custom metrics in Splunk Observability Cloud to create tickets in ServiceNow. It is integrated with ServiceNow, but we enrich the tickets by putting the logs in the tickets and things of that nature, so it helps us. However, even that is a mixed approach. From Splunk Observability Cloud, you cannot put the logs directly in the tickets. Instead, it will create a ticket and send you an email with the logs. That integration could be improved.

I have been working with Splunk Observability Cloud for about two years.

I cannot speak to lowering the cost of unplanned digital downtime using Splunk Observability Cloud because the client will get the bills. However, it reduces the downtime for systems. It improved visibility when you do changes and you do patching and you do emergency changes, so you can see if they were applied correctly or not, if the servers are still down.

If it is a new deployment and you have a medium client with about 2,000 users or computers or servers, it will take about six months just to install and configure.

The technical support is very good with Splunk.

Positive

I worked with ScienceLogic before actually working with Splunk.

There are not complexities with the installation of Splunk Observability Cloud, but with the configuration of alerts and everything because Splunk has its own language in the background. You need to know Splunk in order to configure everything that you want.

I do not spend any time personally because I have a team that does it. I have 27 people in my team.

It does provide some return on investment. It is beneficial in terms of finance to use it.

I think the pricing for Splunk Observability Cloud is still at a good price. If you are looking at Dynatrace, it is way higher.

I am familiar with the Dynatrace operator but I am not actually working with them. I am just looking into differences and tooling and what will benefit my clients better.

You need to know Splunk in order to configure everything that you want.

The out-of-the-box customizable dashboards provided by Splunk are okay, but usually, I have to create new dashboards because every user wants to see something else. The out-of-the-box dashboards help to get started faster, but in the end, I will have to redo them.

We utilize the ability to enrich data with custom metrics in Splunk Observability Cloud to create tickets in ServiceNow. It is integrated with ServiceNow, but we enrich the tickets by putting the logs in the tickets and things of that nature, so it helps us. However, even that is a mixed approach. From Splunk Observability Cloud, you cannot put the logs directly in the tickets. Instead, it will create a ticket and send you an email with the logs. That integration could be improved.

I would rate this product an 8 overall.

I have been using Splunk Observability Cloud for five years now.

My main use case for Splunk Observability Cloud includes infrastructure monitoring, synthetics, APM, and RUM. For infrastructure monitoring, Splunk Observability Cloud serves as my primary tool for monitoring all the hosts or VMs that my technical organization provides for the rest of the company.

Regarding synthetics or RUM, they are used on a case-by-case basis because I do not want to turn them on for everybody. That is not part of my standard offering, where any applications that are internet facing that require more traceability and more digital experience are when those parts are used. IAM is my primary module that caters to almost 15,000 plus servers in the company.

The best features that Splunk Observability Cloud offers are the ease of configuration and the UI, along with the navigation which is simple to grasp for a non-Splunk user.

What makes the UI and navigation easy to use in Splunk Observability Cloud is the simplicity and the layout of the modules.

Splunk Observability Cloud positively impacts my organization as it is my primary infrastructure monitoring tool, and I believe it helps avoid outages related to OS and systems. It saves hours and hours of potential downtime or efficiencies using that platform.

Since using Splunk Observability Cloud and the Ansible Automation Platform, the overall mean time for resolve has reduced by 30x, averaging from 120 minutes down to 6.2 minutes, and I have potentially avoided 12,000 hours of downtime.

I believe that the ability to implement RBAC eventually will be a good thing for Splunk Observability Cloud. I know the product is slowly evolving in that area, but the sooner the better.

To improve Splunk Observability Cloud, I think seamless integration into Splunk Cloud, ensuring that there is a single UI for customers to use both products, is what will be a winner.

I think being able to deploy and manage the OpenTelemetry agents at scale is important for Splunk Observability Cloud. Upgrading or fixing and restarting that agent takes a lot of time and effort, so being able to make that experience seamless would help.

I chose eight out of ten because I think there are still improvements needed, such as fleet management and unified navigation. Once those are in place, I think it would definitely be a solid ten.

I find Splunk Observability Cloud stable so far.

Splunk Observability Cloud's scalability is pretty flexible and good.

Splunk Observability Cloud's customer support could be better as I think response times are pretty slow compared to the Splunk Cloud product. I would rate Splunk Observability Cloud's customer support a three out of ten.

I previously used an old tool called OSS that was rudimentary and utilized old industry standards, so I changed to Splunk for more modern industry standards.

Regarding my experience with pricing, setup cost, and licensing for Splunk Observability Cloud, I think pricing could be a little more flexible in terms of being able to draw from a pool license or being charged for what I consume versus buying a fixed count ahead and having to revise the licensing over and over year-on-year.

Before choosing Splunk Observability Cloud, I evaluated other options including Sumo Logic, ScienceLogic, LogicMon, and a couple of others.

I have not used Splunk Observability Cloud's AI capabilities enough to comment on its governance and security.

I have not used that product related to its AI capabilities, so I do not have any thoughts or experiences regarding accuracy and reliability of output.

I use AWS as my cloud provider.

I did not purchase Splunk Observability Cloud through the AWS Marketplace.

Splunk Observability Cloud has helped improve my operational performance and my company's resilience. Since it is my primary infrastructure monitoring tool, it is how operations get notified about potential degradations to the servers they cater to.

It is important for my organization that Splunk Observability Cloud has end-to-end visibility into my cloud-native environments, though I am more focused on-premise versus cloud-native. Cloud-native is still important, but my focus is primarily on-premise.

I assess Splunk Observability Cloud for helping my organization scale as effective because it determines what growth I would expect in terms of OS and server counts year on year. Being able to have a flex license pool model which does not restrict me to a certain number of hosts would be helpful.

I am not sure how I could calculate if Splunk Observability Cloud has helped reduce my mean time to detect (MTTD), so I do not know.

My impression of Splunk Observability Cloud's out-of-the-box dashboards and detectors is that they are good and easy to set up with less learning curve to get those up and running.

I assess this solution with an overall rating of eight out of ten.

I mainly use Splunk Observability Cloud to monitor the performance of our cloud-native infrastructure. Because we have created multiple infrastructures, we use it to handle and monitor everything.

Splunk Observability Cloud helps us manage latency across any of our projects and APIs. It is particularly valuable for detecting issues before they occur. We can predict features and errors in advance. Recently, we discovered problems in seven of our APIs that we were able to solve because of this predictive capability.

The best feature of Splunk Observability Cloud is that I can identify the root cause of any problem, including API latency. The real-time alerts and smart alerting system are exceptional, allowing me to know what is happening in real-time.

Detectors in Splunk Observability Cloud are very useful, and I have recently used them with great results.

Regarding the no-sample tracing feature, we collect multiple data from various sources. This feature is very useful since we recently shifted to it, and it is working very well.

The AI-powered analytics that Splunk provides allows me to get a smart analyzed version of any report.

Splunk Observability Cloud has greatly impacted our operations by reducing timing requirements. We get smarter solutions and overall use cases in a smart way. I have reduced our manpower requirements and time commitment significantly. Splunk Observability Cloud reduces our mean time to detect by approximately one to two hours.

The LLM in Splunk Observability Cloud is very powerful, and the vector database infrastructure is excellent. This is why we switched from our previous tools, and I believe it was a very good decision that has resulted in better outcomes.

The AI-powered analytics that Splunk provides delivers a smart analyzed version of reports, and it is quite good, but it is very generic. The issues identified could be better addressed through deeper AI thinking to provide a more effective solution.

I have been using Splunk Observability Cloud for more than eight or nine months.

Splunk Observability Cloud experienced a significant outage recently when it went down for approximately five to six hours. This impacted us considerably because we were actively working during that time.

I would rate the technical support for Splunk Observability Cloud as 9.5 out of 10 because we received their support during our deployment. They were very helpful in assisting us to create a good infrastructure.

I find Splunk Observability Cloud to be very good. I previously used DataDog for observing everything, but Splunk Observability Cloud is more accurate and a better solution.

Previously with other applications, analyzing and controlling our API latency required almost five to six hours a day of resources. With Splunk Observability Cloud, I only need to allocate one to two hours maximum per day to accomplish the same tasks.

I highly recommend Splunk Observability Cloud. If you are using any other third-party tool, Splunk Observability Cloud is significantly better than the alternatives.

I highly recommend creating better documentation for Splunk Observability Cloud. This documentation could be integrated with AI to provide specific use case solutions so that users do not have to search through Splunk documentation every time. Instead, users could directly ask about the issues they are facing and receive targeted solutions. My overall review rating for Splunk Observability Cloud is 9 out of 10.

Splunk Observability Cloud is primarily used for expanding APM and IM monitoring, correlating metrics, traces, and logs for better insights, and reducing MTTRs and MTTDs. In the SRE space, especially for digital mobile technology, it is set up to gather metrics and traces from applications. The RUM component is used to understand customer behavior, with traces and metrics ingested via the Splunk OTEL collector and RUM embedded through the Splunk RUM SDK. Dashboards have been built on this data to enhance correlation.

The main use case is seeing the correlation of metrics, logs, and traces in a single pane of glass, which we have successfully achieved.

The best features of Splunk Observability Cloud include the APM service map and real-time RUM monitoring, which track customer experiences. The service map helps understand the journey and identify pain points in services during issues. Correlating real user monitoring through RUM has significantly enhanced our understanding of customer pain points, allowing visualization of issues under APM.

Splunk Observability Cloud positively impacts our organization by enabling us to build dashboards around customer experiences and API backend layers. Previously, there were many hops with open-source tools like Grafana and Prometheus. Now, with metrics and traces consolidated, we gain a single view for correlation, significantly reducing MTTD, enabling detection of issues in under five minutes.

From an admin perspective, there are pain points such as difficulty exporting data into Excel and a cumbersome setup process. Improving the setup for data uploads via Excel and providing an option to download RUM data for analysis would be valuable improvements.

I have been using Splunk Observability Cloud for the last eight months.

Splunk Observability Cloud is stable.

We are expanding from one to ten applications next year. While there are no performance issues in viewing dashboards or when detectors fire, challenges remain with repetitive, manual setup processes. There is no templatization for quick growth, a feature we would love to see.

Customer support for Splunk Observability Cloud is adequate; it meets our needs but is not exceptional.

We previously used a combination of Grafana and Prometheus along with Splunk Enterprise. The limitations of these tools, coupled with the introduction of database monitoring and native Splunk OTEL capabilities in Splunk Observability Cloud, drove our transition.

There is a return on investment in terms of time saved. Traditional debugging required multiple interfaces and hours of effort, while now, with Splunk Observability Cloud, MTTD has decreased significantly, reducing investigation times from several hours to a maximum of thirty minutes.

My experience with Splunk Observability Cloud's pricing, setup cost, and licensing is positive.

We evaluated options including DataDog, Dynatrace, and Grafana plus Prometheus. DataDog is advantageous but expensive, making Splunk Observability Cloud the right fit for our budget.

My advice for those considering Splunk Observability Cloud is to ensure readiness in terms of data and integrations; simply using it for APM will not yield significant benefits. It is important to have a well-prepared OTEL strategy and to use RUM for its exceptional correlation capabilities.

Splunk Observability Cloud will help our organization scale over time, particularly with features related to database monitoring. SRE adoption and technical teams, such as DBAs, will benefit from more depth in database monitoring. Expanded adoption of Splunk Observability Cloud is due to its significant advantages.

It is very important for our organization that Splunk Observability Cloud offers end-to-end visibility into our cloud-native environments. Comprehensive visibility through improved adoption can significantly enhance operations.

We encountered significant challenges implementing Splunk AI assistant in the bank due to governance and security procedures. The absence of a BYOK model raises concerns about data exposure outside the environment.

We have not yet used Splunk AI capabilities in a production environment, so from our test environment perspective, we cannot assess accuracy until we implement AI capabilities in production. I would rate this review an eight out of ten.

My experience with Splunk Observability Cloud involves monitoring infrastructure, application performance monitoring, and real-time alerting. Although I am no longer working with Splunk Observability Cloud due to a recent position change that occurred approximately two months ago, I previously monitored servers, containers, Kubernetes, application performance, and Docker images. In terms of monitoring, I tracked response time, error rate, and latency. This capability helped in identifying performance issues or infrastructure issues before users were impacted. For instance, if Kafka failed, we knew about it before users experienced an impact and could resolve it before it caused maximum damage to our systems. I also used dashboards and alerts to monitor critical services and received notifications whenever issues arose.

The features of Splunk Observability Cloud that I found most valuable included application performance monitoring and distributed tracing, particularly when monitoring distributed systems or applications. Real-time alerting and Kubernetes monitoring were essential since Kubernetes is quite complex. I could effectively monitor Kubernetes using Splunk Observability Cloud. Additionally, the Smart Attack Detector, which I tried at the last moment, was a good feature, although I did not work extensively with it. The Log Observer was very fast and reliable, and the dashboards provided good visualization for troubleshooting and monitoring. If there was a network outage, I received notifications very quickly.

Splunk Observability Cloud helped me detect performance issues faster and reduce downtime in my organization. Earlier, I had limited visibility into my application performance. After implementing observability, I could see end-to-end transaction tracing and quickly identify where issues arose, which reduced troubleshooting time and improved overall application stability and availability for our customers and systems. This capability also helped in proactive detection.

I believe that areas of Splunk Observability Cloud that could be improved include the initial setup and instrumentation costs, which take more time for APM. Some dashboards and detectors require tuning, and I think the visualization needs enhancement. Additionally, alert noise remains an issue, and we need suppressions for when systems go down for short periods. Better integration with third-party tools and easier onboarding of data would also be beneficial.

When evaluating the stability and reliability of Splunk Observability Cloud, I can confirm it has been reliable. I would rate it eight out of ten for reliability.

Splunk Observability Cloud scales very well with the growing needs of my organization. I can demonstrate the scalability of our system to our customers, which is advantageous for business. This capability helped us secure business as we provide real insights to customers who were happy to purchase our systems and applications. The ROI has been good for us.

I communicated with the technical support of Splunk Observability Cloud regarding our issues, specifically when I was unable to monitor or set up Kubernetes to monitor our infrastructure. They were able to help us, and we purchased an on-demand call for assistance, which they provided.

I did not participate significantly during the initial setup and deployment of Splunk Observability Cloud, but I was part of the team. I know the process is straightforward. We simply needed to ensure that all data was in the correct format, matched current dashboard setups, and included all necessary fields for insights.

My experience with lowering the cost of unplanned digital downtime using Splunk Observability Cloud has been positive, as it helped us significantly. Our system was bottlenecking and consuming excessive resources, but with the ability to detect and resolve that issue, overall system usage was reduced without further bottlenecking.

Regarding metrics or data points confirming performance improvement and resilience, I found that during certain times, we experienced the most significant spike in our systems due to multiple users requesting the same service. We needed to change our overall architecture as we were not scaling adequately, and this was bottlenecking our systems. By observing this from the dashboards, I realized improvements could be made. After implementing the solution, our application's stability improved significantly. I can confidently say our availability improved by forty percent, and downtime was reduced by approximately seventy to eighty percent.

My impression of the No-Sample Tracing feature in Splunk Observability Cloud is that it helped us detect key metrics and real use cases, particularly in tracking and monitoring. I primarily tracked server uptime, application response time, API latency, and similar metrics. Combining these parameters instead of relying on a single factor improved our system. Specifically, I used distributed tracing to understand how requests flowed through our network and how different systems responded, which helped determine if any particular system impacted all our systems.

Regarding the AI-powered analytics and guidance provided by Splunk Observability Cloud, I have not actually used the AI features, particularly with ITSI, as I did not utilize that aspect for observability.

My teams effectively utilized the ability to enrich data with custom metrics in Splunk Observability Cloud. They found valuable insights from our systems and created reports that the application and infrastructure teams used to decide their workarounds and solutions. They developed different solutions, experimenting and improving our systems by relying on observability to understand what happens when we adjust parameters or change configurations.

When evaluating the effectiveness of the out-of-the-box customizable dashboards provided by Splunk Observability Cloud, I note that we mostly used the default dashboards. While we created a custom dashboard to track our overall system flow, we relied on pre-built dashboards for monitoring and representing our business perspective. When we needed to showcase our environment to customers, we demonstrated our scalability and system performance, including response time and downtime, providing insightful details from the dashboards for business use cases.

I would rate Splunk Observability Cloud an eight out of ten, where ten is the best and one is the worst.

My main use cases for Splunk Observability Cloud include Application Performance Monitoring, synthetic monitoring, and dabbling in infrastructure and what comes along with it; however, we do already have a tool that does infrastructure. We're debating about just switching it all over to Observability.

The features of Splunk Observability Cloud that I prefer the most are its all-encompassing licensing model, which is comparatively better than others in the market. We're switching off AppDynamics, and the licensing model always constrained us, so that is our main reason for switching to observability, as the licensing is all-encompassing.

The benefits of these features for my organization are significant. The license is all in one, meaning infrastructure, APM, synthetics, RUM, and the logs are all under one license, allowing us to offer that to our application teams more so than we were ever able to do before. 

We're currently trying to implement RUM, Real User Monitoring, with two applications just to get a feel for it, which we were never able to do before, since it was a completely separate license that we needed to purchase. So we're able to offer more of a full suite, more of a one-stop shop sort of thing, versus what we were able to do before.

The user interface of Splunk Observability Cloud needs a lot of work. I have been known to describe it as slapping lipstick on a pig. The pretty colors draw in everybody, however, the actual functionality of it has a lot that you cannot do, and how the user interface is organized is very difficult to navigate. This is a driving factor for us not to use the product.

The next release of Splunk Observability Cloud should include a feature that makes it so that when looking at charts and dashboards, and also looking at one environment regardless of the product feature that you're in, APM, infrastructure, RUM, the environment that is chosen in the first location when you sign into Splunk Observability Cloud needs to stay persistent all the way through. There's no reason that a user should have to keep having to restart all of their filters and select their environment anytime that they switch to a different area of the tool.

I have been using Splunk Observability Cloud for one year exactly.

I have not experienced downtime, crashes, or performance issues with Splunk Observability Cloud yet.

Splunk Observability Cloud scales with the growing needs of my organization, however, we very quickly always run into hitting the limit for custom metrics. This is something we've discovered that we have to manually manage, which is not fun, especially for large applications such as our huge tracking system, since we're a logistics company, as well as the two main revenue-generating applications. We are probably going to hold off putting them into Splunk Observability as we're constantly bumping the limit already.

I would evaluate customer service and technical support as hit or miss as I get the impression that the support folks assigned to our account might be spread a little too thin. They are good people and do good work; however, I get the impression they're spread a little too thin. If we put in a ticket, we do get a response in a decent amount of time, so that's not a problem.

Positive

Prior to adopting Splunk Observability Cloud, I used several solutions. The solutions we used include Zabbix, Splunk Core, Grafana, Prometheus, and AppDynamics, so a whole suite of things.

The deployment has been fine for cloud applications. It is very tumultuous for on-prem. That is supposed to be getting fixed over the next year. Right now, it's not there. So I always tell my management we're a year and a half too early for this tool.

I have seen ROI for our cloud applications, as we've been able to fully integrate with one application, which is a big revenue producer for the post office, and it's something that they were not able to do before, so we have been able to see that. In terms of ROI, I would say 100%.

We don't currently use the out-of-the-box customizable dashboards provided by Splunk Observability Cloud to showcase IT performance to business leaders. 

I will say we have not expanded usage to other applications since we're still stuck where we are. 

My advice to other organizations considering Splunk Observability Cloud is to wait until next year. 

On a scale of one to ten, I would rate this solution five or six.

We just started implementing Splunk Observability Cloud in my company as an ongoing project.

Our main use case for Splunk Observability Cloud is for our digital team for our website healthpartners.com, and that's the reason we decided to bring in a unified monitoring platform instead of using different monitoring tools. We are working with other teams as well at the same time, bringing their metrics and traces into Splunk Observability Cloud from other monitoring tools.

The other use case that we're working on regarding Splunk Observability Cloud is synthetic monitoring, and right now, we have some legacy solutions that have been used for the health checks, browser tests, and API tests, which have been moved over from a different tool to Splunk Observability Cloud. There is also one team that I'm currently talking to where we have set up the health checks in a legacy way using REST API inputs on the heavy forwarder, and we are planning to move that to Splunk Observability Cloud as well.

In my opinion, the best features Splunk Observability Cloud offers are the dashboards and some of the alerting features that I appreciate. I have also just found out that they are adding the incidents feature, which is really interesting, and I would to know more about that as well in the alert section to group all the alerts in a single incident, so that is going to be great.

For the alerting features of Splunk Observability Cloud, right now, we have been setting detectors for all the synthetic monitoring tests that were set up and also some of the host metrics, and we are testing it out, notifying those alerts and sending them to the teams, and that has been helpful even for our team. For the dashboards, so far, there is one dashboard that was built for us, the gateway monitoring dashboard where we send metrics via the gateway, and when something happens on the gateway side, if there's a delay or if the metric stops streaming into Splunk Observability Cloud, we can check the dashboard, so I appreciate that feature too.

Regarding the features of Splunk Observability Cloud, maybe the fleet management is what I'm looking forward to, as I know that feature has been added recently and we are able to see the gateway collectors showing up on there. I am more interested to see how the OTel collectors or anything else show up in there, and how that can be useful for our team.

I don't think I've seen any missing features of Splunk Observability Cloud so far, as I'm still exploring it and learning as we work on the project, so I think it is going to be great.

I can't think of anything at this time, but the new incident feature is great, and I heard for the DB monitoring, there is something that is going to be added in Splunk Observability Cloud where we can add custom attributes in there, which might be helpful in the future.

Splunk Observability Cloud is stable in my experience so far.

I cannot say with certainty at this time regarding Splunk Observability Cloud's scalability, as we're still in the middle of the project, so I don't know how scalable this is. Right now, there's one task that I'm working on to bring in the SQL servers for DB monitoring into Splunk Observability Cloud, and right now, we don't have licensing for it, so we are working on getting the licensing. I would love to see once we have those metrics into Splunk Observability Cloud, how that is going to work and how scalable it is.

I did interact with Splunk Observability Cloud's customer support, and it is working and is good so far.

There are multiple different tools that have been used in my company; it's not just one. We have Foglight, Prometheus, Grafana, and we are moving towards having a unified monitoring tool or unified solution, which is the reason for the switch or migrating over.

I was not involved in any discussions about pricing, setup cost, or licensing for Splunk Observability Cloud, so I have very minimal experience with that.

I haven't seen any return on investment yet, but I do definitely expect to see ROI soon, once we bring in everything and reduce workload.

I was not involved in any discussions about pricing, setup cost, or licensing for Splunk Observability Cloud, so I have very minimal experience with that.

I am not sure if any other options or proofs of concept have been done before choosing Splunk Observability Cloud, as it was a higher-ups decision to go with it.

I have heard from one of the teams when they set up the synthetic monitoring, so they gave really positive feedback to us, which was good. The other teams, the problems they had with the other monitoring tools, I feel have been solved with Splunk Observability Cloud to some extent, so that is going well so far.

I think one of the issues that they had was with the alerting from their tool, and there is this one person who works with the developer teams and gathers all the information regarding the browser tests and API tests. He sets it up for the alerting; right now, we have the ServiceNow webhook integration that was set up to notify or generate the ServiceNow incident, and the way it was set up in Splunk Observability Cloud is that whenever the incident clears itself, it will notify the team, but it won't close the ticket out, so they can take a look and have human eyes on it before they close it out, and that was positive feedback that was given to me.

Regarding Splunk Observability Cloud's AI capabilities, we haven't had the AI capabilities enabled for our instance yet, so we have not had the AI assistant or any other features, but I'm looking forward to learning more or understanding the AI capabilities once we deep dive into the project.

For others looking into using Splunk Observability Cloud, I would first recommend taking a basic education course; if it is a user, maybe a free course or a basic course to understand how Splunk Observability Cloud works and what features are inside it. If it is a power user or admin, I think we need to provide the documentation to the users on how easily they can log in, go between the features, and understand where they can find the dashboards, alerting, metrics, and so on.

I'm looking forward to implementing, completing the project, and starting to use it, as well as our users starting to use Splunk Observability Cloud soon. I would rate this product an eight out of ten.

The primary use cases for Splunk Observability Cloud in our environment include log monitoring and detection controls, especially for the DI detection controls, and the application team uses it for all operational activities, to find issues, and to detect more issues before going live.

The resolution time is easy; it has led to a reduction of the MTTR for any incident, and it proactively identifies bugs before they go live for application teams, making issue identification simpler.

It helped us a lot in reducing the cost of unplanned digital downtime.

The strong points of Splunk Observability Cloud are an easy and consolidated view in one area, as we can query the log, customize it, and create some dashboards, which makes it easy for our operations team to detect the issues.

My impression of the No-Sample Tracing feature in Splunk Observability Cloud is that it has definitely helped us.

It has assisted in terms of eliminating blind spots in data collection.

The out-of-the-box customizable dashboards provided by Splunk Observability Cloud are definitely good; the customization is extensive, and it's really helping us based on my understanding.

Splunk Observability Cloud has indeed helped me improve the operational performance and resilience of my company.

Regarding drawbacks, something on the downside exists, but I have not elaborated on it yet.

Currently, we have not yet enabled the AI module in Splunk Observability Cloud, as we are just in the process of using the latest version. I can comment on that later, but I personally feel it really helps us, especially when we are running some SQLs, as it's guiding us a lot to optimize queries and provides many actions, particularly for those who work on SQL.

My team has not been able to enrich data with custom metrics provided by Splunk Observability Cloud.

I have been working with Splunk Observability Cloud for almost more than five years.

I would rate the technical support of Splunk Observability Cloud an eight; they are quite responsive.

Before adopting Splunk Observability Cloud, we did think of alternatives from different vendors, including some evaluations and reviews of several products, with Dynatrace being one of them.

Regarding deployment, it's quite simple; I don't see any difficulties.

As for time frames, it depends on the environment, but I would say if it's a very simple environment, it would be a few hours. For us, it's always days because it's a very large environment.

We do participate in the deployment process; we do have a dedicated team for that.

Globally, we have around 20 to 30 people in my team who are responsible for the implementation of solutions.

It's a combination of engineers, developers, and administrators; it's even more than that, so it's a very large environment.

You could see some improvement, and definitely there will be some return on investment, but not directly through my team; perhaps for the applications, which have multiple tools that can use this one consolidated platform for all log monitoring.

Price is always one of the factors; it's a little costlier when compared.

We purchase Splunk Observability Cloud products directly from the vendor, from Splunk itself. The overall review rating for this product is 8.

As part of the monitoring team called ESOC, Enterprise Security Ops, we use Splunk Observability Cloud to have a bird's eye view on all the applications and infrastructure, observing how they connect with each other and how workflows among them occur. When we detect incidents, we deep dive into Splunk Observability Cloud to see the flow of the signals and identify possible connection issues with other systems they're connected to. We have been using Splunk Observability Cloud extensively these days.

At Progressive Insurance, we have a huge claims presence where the applications related to claims are high priority. Recently, we encountered an issue with claims documentation, which resulted in disruptions that affected applications using documentation, especially claims documentation, causing them to struggle. During this time, Splunk Observability Cloud was incredibly helpful as we drilled down into root cause analysis to assist those application teams in identifying what could have gone wrong—whether it was API calls, network issues, or pods being down. It took some time, but Splunk Observability Cloud really facilitated our investigation.

Seeing the whole signal flow aspect was really beneficial. We could visualize how the signals moved from one module to another, even with inferred systems, and that visibility assisted us in our analysis significantly.

One great feature of Splunk Observability Cloud is how it transitions from monitoring to observability. While monitoring involves looking at potential issues and health checks, observability allows us to view the system more from a signal flow perspective, and the visuals are much better. I can see the system clearly represented in front of me, allowing for better visualization and flow assessment. I hope to benefit even more from this at the conference.

An example would be how we analyze the interconnections between applications and pods, monitoring pod health and determining whether a pod is in a crash loop or just down, or if an application has an excessive number of pods down, which helps us present data more effectively.

I am continuously exploring more about it. Although I have been working with it for around two years, I am eager to learn more, especially with the incorporation of AI, which excites me about using Splunk Observability Cloud further.

I believe increased adoption is essential. While usage is steady now, the more application teams embrace it and avoid working in silos, the easier it will be to create a more cohesive structure.

We are relatively new to this, and I aim to explore further, especially during classes and sessions at the conference. I am thrilled about how AI is being incorporated to enhance dashboard functionality and visibility. Once we become more seasoned, we will grasp more about the necessary improvements.

Regarding the AI capabilities of Splunk Observability Cloud, I think its governance and security need much exploration. I am uncertain about what governance teams are doing within my company, but there are growing conversations about backdoor channels and misuse, emphasizing the necessity for strict guardrails and governance as key factors for adoption.

I have been using Splunk Observability Cloud for two years.

Splunk Observability Cloud is stable.

So far, its scalability at the user level has been good, but I am uncertain about the configuration or administrative level.

Customer support has been really good.

On a scale of one to ten, I would rate customer support an eight.

Previously, we used AppDynamics and Splunk Enterprise. We have not fully switched yet, but we are growing toward observability.

Time saved is definitely a factor. While I do not decide on monetary matters within the company, I can confirm that there has definitely been a time-saving aspect.

I advise others looking into using Splunk Observability Cloud to practice more, explore extensively, and aim to customize as much as possible according to their needs. I would rate this review a seven out of ten.