Splunk Observability Cloud Reviews

My main use case for Splunk Observability Cloud is for customer support.

Using Splunk Observability Cloud for customer support helps expedite my customer's needs and ensure that I have access to all the right data to answer questions quickly and effectively.

I have seen that Splunk Observability Cloud made a difference when it helped me with a critical customer workload when a part of their database was impacted by an event. I was able to quickly determine what was impacted and how to quickly isolate and do damage control. Thanks to Splunk Observability Cloud, I would not have been able to gather the information I needed so quickly.

The best features that Splunk Observability Cloud offers are all of the metrics and dashboards that are most important to myself and the management team.

What I appreciate about the metrics and dashboards in Splunk Observability Cloud is that they're easy to configure and edit and give me access to all of the data that I need.

Splunk Observability Cloud has impacted my organization positively by allowing management access to the logs, dashboards, and metrics they need to operate a high functioning team and product.

The specific outcomes I've seen with Splunk Observability Cloud include faster response times and lower MTTR. Some of the specific improvements I've seen are in faster mean time to resolution and easier damage control during critical outages and failures.

Regarding how Splunk Observability Cloud can be improved, there are few opportunities for improvement, but perhaps one area of improvement is greater integration with partners and clearer ability to quickly gather the information I need to supercharge my AI workloads using Splunk Observability Cloud.

The customer support for Splunk Observability Cloud is thorough and gave me everything I needed to make sure I was well supported.

On a scale of one to ten, I would rate the customer support for Splunk Observability Cloud a nine.

My experience with lowering the cost of unplanned digital downtime using Splunk Observability Cloud has been positive, as we've been able to lower our mean time to resolution and make sure that we are resilient and quickly recover from disasters.

My experience with pricing, setup cost, and licensing for Splunk Observability Cloud was very straightforward, and I felt supported the whole way through. There wasn't a moment in which I felt we could not get the information we needed on pricing and setup.

The advice I would give to others looking into using Splunk Observability Cloud is to take your time getting to know the product and make sure to get involved with the support team. Make sure that you feel comfortable adjusting what you need to adjust and have fun. I would rate this product a nine overall.

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.

Positive

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.

The solution involves observability in general, such as Application Performance Monitoring, and generally addresses digital applications, web applications, sites, and mobile applications. I worked with it in two companies: one in the energy sector and one in the hotel sector.

The Splunk teams helped us with data collection, instrumentation, and many other options.

The testing and monitoring of infrastructure is useful. We also use it for many metrics and can use it effectively for troubleshooting and for detection. It's very helpful. 

With Splunk Observability Cloud, I appreciate working with open telemetry. The standards of open telemetry are especially useful for collecting data such as traces, matrices, and logs. Splunk respects the standards of open telemetry. This is beneficial. Many clients work with AWS and the cloud in general with multiple solutions such as Datadog, Dynatrace, and Splunk. Working with the standard open telemetry is very advantageous. Splunk Observability Cloud is very simple for users in general, including developers, DevOps, and data teams. It's more straightforward compared to Dynatrace.

There are many out-of-the-box solutions proposed by Splunk, such as dashboards for AWS instances, EC2, Fargate, and Lambda. It's very helpful for beginning, especially for monitoring, and the detectors for alerting help understand how the platforms work.

The no-sample feature is great. It eliminates blind spots.

After completing the instrumentations, we have many dashboards and tests for monitoring infrastructure, particularly CPU and memory. We also use applicative metrics such as JVM, Java Runtime, and many other applicative metrics and testing. For troubleshooting, we can detect problems in seconds, which is particularly helpful for digital teams.

AI analytics have the potential for a lot of functionality. The detectors for alerting may prove useful.

When we deploy the instrumentation in the application, we can start using the dashboards immediately. The dashboard building is very helpful for starting work.

It's beneficial for monitoring performance and infrastructure, especially when deploying applications with multiple versions with Git. It's important to detect performance issues, such as CPU consumption or memory consumption, particularly over time in Java and Python.

For other teams, they need help and guidance to use custom metrics. For observability engineers and specialists, it's straightforward, but for others, it can be challenging.

The solution overall is very valuable for me.

The time to value was immediate. Once we deployed, we started to use the dashboard directly and began detecting issues. 

Saving time with automation can save us weeks. It's improving our resilience. It helps us detect issues and increase performance. 

The solution has been very useful for helping us focus on business-critical initiatives.

Regarding dashboard customization, while Splunk has many dashboard building options, customers sometimes need to create specific dashboards, particularly for applicative metrics such as Java and process terms. These categories of dashboards would be very helpful for customers.

I started working with Splunk Observability Cloud in 2023.

The system is relatively stable. We rarely have problems accessing the dashboard or the page. We encounter problems in the Splunk platform very rarely.

It's very scalable. We haven't experienced any problems with the instrumentation or scalability. On a scale of one to ten, I'd rate it a ten.

We've used the solution across more than 250 people, including engineers.

I would rate Splunk technical support at six out of ten.

When we have a problem and need to create a case, the response isn't quick. They often require multiple questions, with five or six emails to get a response. Problem resolution typically takes between two and five days, which isn't very helpful. However, sometimes we do receive quicker solutions.

Neutral

We used legacy solutions such as Grafana and Prometheus. There are several differences between Splunk Observability Cloud and these solutions. We used Grafana as a monitoring solution, however, it's not truly observability. We used OpenSearch for logs, Prometheus for metrics, and Grafana to work with Prometheus. That said, it's not equivalent. Observability is different.

We're also familiar with Datadog and Dynatrace.

The implementation took between two and three weeks.

For cloud deployment, it's straightforward. We can use GitLab and DevOps CI/CD. For on-premise deployment, such as Linux and deployment with satellite, it's easy yet requires some work to configure the configuration files.

Updates are generally needed, especially for the open telemetry version or SDK. However, regarding the platform itself, we don't need to do anything.

I worked with my company when they used the solution, so I'm not certain about the history of how long it took to detect problems. However, for mean time to detect, and mean time to respond, I'm sure it's very helpful, and we can estimate a minimum improvement of 20%.

We're a customer and end-user.

Currently, in France, we cannot use the artificial intelligence option. While this option is enabled for the United States and many countries, it's not yet available in France. However, the solution with detectors, especially for alerting, is important for us.

I recommend it, especially for teams using legacy monitoring.

I would rate Splunk Observability Cloud nine to ten out of ten.

Splunk Observability Cloud is used for day-to-day operations and monitoring of our Azure Kubernetes environment.

Splunk Observability Cloud monitors our Azure Kubernetes infrastructure, including our pods, nodes, and clusters in our Azure environment.

For monitoring of Kubernetes environments, we track pod health and node health using Splunk Observability Cloud.

Recently, Splunk Observability Cloud was used for monitoring our Kubernetes cluster. We have around 35 to 40 Kubernetes clusters. One of the pods was down and we received an alert. We investigated why the pod was failing, looked at the logs in Splunk Cloud and were able to troubleshoot the issue and resolve it soon.

Splunk Observability Cloud is used for day-to-day operations and monitoring of our Azure Kubernetes environment.

Splunk Observability Cloud monitors our Azure Kubernetes infrastructure, including our pods, nodes, and clusters in our Azure environment.

For monitoring of Kubernetes environments, we track pod health and node health using Splunk Observability Cloud.

Recently, Splunk Observability Cloud was used for monitoring our Kubernetes cluster. We have around 35 to 40 Kubernetes clusters. One of the pods was down and we received an alert. We investigated why the pod was failing, looked at the logs in Splunk Cloud and were able to troubleshoot the issue and resolve it soon.

The options I refer to include getting visualization of the data. For instance, when you configure your Kubernetes clusters, those will automatically pop up, which is a pretty good feature.

When there is an incident, we look at the dashboards. The beneficial aspect is that Splunk Observability Cloud has its own scenarios.

Unified visibility is not there.

Almost two years.

Whenever I go to Splunk Observability Cloud platform, the first thing I do is go to infrastructure. I look for Kubernetes, I look for pod health, and node health.

The first thing I do is look out for the Azure Kubernetes cluster. I have 35 to 40. I look at one to see how the pods, nodes, and everything is happening.

Whenever there is a health problem with the pod or node, I am able to find out that it is having some problem and I am able to view it.

Splunk Observability Cloud is deployed in a hybrid environment in my organization.

We use Azure as the cloud provider in our hybrid environment.

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

My overall review rating for this product is 6 out of 10.

I mostly work with the performance metrics of the CPU, or host metrics, as well as application metrics and traces. Overall, I use these mostly for real-time monitoring based on the application to track application performance.

For the monitoring of infrastructure, it is quite insightful because in-depth, I can see what is going on in the infrastructure. If something goes down or some crons fail inside the infrastructure, the alerts are quite helpful for more visibility on the cloud-native side.

This is quite helpful for improving the application observability and the infrastructure side as well. I would rate observability above an eight.

I am not that much involved in the business side because I work as a DevOps engineer, so I do not know how much it helps on that front. However, it helps in tracking traces and metrics quite generously well and helps us improve the application side for more reliability on the business side.

It is very helpful and really enhances the AI-powered analytics, which helps us for troubleshooting the application and to get more insightful information while troubleshooting application error rates.

AI-powered guidance is really helpful because it provides more actionable insights and highlights anomalies automatically. I do not need to go through it manually, and it also helps us with smart alerting and recommendations.

It helped operationally because due to the insights of the applications, I get more insight for our application to enhance it further. It detects anomalies and correlates data while guiding us to the root causes, so we can enhance our application accordingly.

I have seen that mean time to resolution was reduced around 30 to 50 percent. The main reason for this combination is because of real-time monitoring and AI-powered anomaly detection and distributed tracing. Instead of manually checking the logs and metrics across multiple tools, the platform quickly highlights the issues, correlates data, and points us towards the root cause.

After implementing Splunk Observability Cloud, there was a deep learning curve for the new tool. It took one or two months to get proper insights from it. After configuring, I have seen that it is very useful for tracking traces and metrics of our application, servers, and clusters. Adoption time is usually after two months, or after a few weeks of getting Splunk Observability Cloud.

Splunk Observability Cloud is highly effective in improving digital resilience. Real-time visibility and proactive alerting and fast root cause analysis, distributed tracing, and AI-driven insights enable anomaly detection, which allows us to quickly understand failures and recover faster. This is critical for maintaining system availability and helps us handle failures in complex distributed environments since we can see how services interact and where breakdowns occur.

Regarding features, it helps us for better understanding of how the application works and in-depth tracking of application monitoring.

It can be more enhanced using additional AI power. I can get more reliability using AI because AI-driven guidance is more useful nowadays. It can really improve more on the AI side because it will help us to reduce manual intervention with the system and root cause analysis will be much better with AI over human analysis.

I would say that it is quite helpful, but for different kinds of applications, it could be improved because sometimes it might provide a cloud judgment of the root cause analysis. I need to do manual intervention using a dedicated human for root cause analysis for better understanding of the root cause. This is how the agentic side can be improved.

I have been working with Splunk Observability Cloud for around a year.

It is quite scalable. Right now, it is providing much better insights and can be more enhanced over several aspects. I would rate scalability an eight to eight point five.

I have tried other solutions, but they were not that great in terms of functionalities and overall performance. Splunk Observability Cloud is much better than the others because it provides AI alongside the solution. This is very helpful due to the AI-driven solutions and guidance for root cause analysis. Splunk Observability Cloud goes through the details of application traces and metrics in depth, so I get better observability over the application. This is why I have preferred Splunk Observability Cloud over other monitoring tools.

I have tried SignalFx, but it was not quite insightful. I have tried Splunk Observability Cloud over SignalFx.

Splunk Observability Cloud is quite insightful and helpful for improving the observability side. I provide this solution an overall rating of eight.

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.

Positive

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 is the APM model, as we have the APM and since I mentioned I have all the flavors of Splunk, from Splunk Cloud, Splunk ITSI for specific event management, Splunk Observability Cloud is specific to the APM model. When I say APM model, it is infrastructure monitoring, synthetic transaction monitoring, and real user monitoring.

With the help of Splunk Observability Cloud, I can monitor all the real-time transactions happening in the entire application. With the help of OpenTelemetry, I installed everything and got the logs, traces, and metrics. I created the dashboard since I have the data within the Splunk Observability Cloud. As I have the observability data within Splunk Observability Cloud, this observability cloud will not go with event management.

If I want to go with event management, we will be sending the data to Splunk ITSI. Combining these, Splunk Cloud, Splunk ITSI, and Splunk Observability Cloud, we achieve the Splunk full-stack observability. This means I can monitor the overall application availability, including the REM, synthetics, all the APM, and the network observability coming from the arm. We can achieve full-stack observability with the help of all these Splunk stacks.

Splunk Observability Cloud has enhanced our operational performance and our company's resilience, ultimately contributing to improved customer satisfaction. Regardless of the business, customer satisfaction shouldn't compromise or degrade performance; it should remain optimal. Since I have these features available and inbuilt within Splunk Observability Cloud, building all these functionalities only takes seconds. I might encounter a little distraction; I can't say it is 100% perfect, however, it is about 95 to 96% resilient to whatever business we have.

The best features of Splunk Observability Cloud include the Splunk Assistant and the Splunk AI Assistant, which help in triaging issues and identifying them immediately, allowing me to create dashboards in a matter of some minutes or seconds. We can monitor all the Kubernetes, Docker, and whatever platform we have, including AWS, Azure, and GCP.

We can monitor all the AWS CloudWatch logs, GCP stacks, and storage. Everything can be monitored because we have the out-of-the-box dashboard add-ons. You don't need to do anything, but you might have to work a little bit; however, everything might be inbuilt, allowing me to fetch everything and monitor from all platforms, whether private cloud, public cloud, or data centers like Equinix.

The benefits I can see from using Splunk Observability Cloud include faster and quick resolution, allowing me to identify the root cause analysis, or RCA, for whatever issue is currently going on. This is the first analysis and first RCA. That is one of the most significant advantages or features we can achieve with the help of observability, offering simple and fast resolution.

Splunk Observability Cloud has indeed helped reduce downtime, as it has inbuilt operations that send triggers in real time, even for false alerts or positives, within seconds. It can identify anomalies and future forecasting. If an anomaly continuously occurs, it indicates something has gone wrong. It may not be a real issue, but something is about to happen. In such cases, we raise an incident or utilize the ITSM tool integration to immediately inform the next dealer group, ensuring quick action is taken.

Regarding blind spots, I haven't seen significant issues in this aspect with Splunk Observability Cloud. However, if one wants to eliminate blind spots, it may require writing some technical mix, which I haven't explored in depth.

In terms of AI-powered analytics and guidance provided by Splunk, we have two AI features: the Splunk AI Assistant and the Splunk Commander AI. The Commander AI embodies a generative AI functionality, connecting with LLMs. According to LLM standards, various algorithms are written to perform specific functions. As soon as the request comes from Splunk, it connects with the respective LLM, which will select the algorithms you need. This is an inbuilt AI module within Splunk, and the only requirement is a specific add-on called the Splunk MLTK, which stands for Machine Learning Toolkit. Having this MLTK add-on, tightly coupled with AIOps capabilities and ML, yields good results in AIOps operations.

Regarding the effectiveness of the out-of-the-box customizable dashboards provided by Splunk Observability Cloud, they showcase IT performance very well. It includes multiple add-ons and intelligent integrations, but it is crucial to ensure that data comes to Splunk Observability Cloud via the OTel Collector and universal forwarder. Once data is received, I can create dashboards for GCP utilization or AWS CloudWatch details. Although there may be numerous metrics to monitor from AWS and GCP, not all are critical, so the dashboards have been constructed to focus on the critical parameters we want to monitor.

In my organization, we have built observability for many applications. Although I cannot disclose specific account information, I use it for development purposes with a minimum number of users. User numbers can extend based on infrastructure, environment size, and data ingestion rates. The maintenance of Splunk Observability Cloud is very easy; it's manageable.

For potential areas of improvement, I find that while Synthetics, APM, and infrastructure management models are fine, an enhancement could be seamless integration with some third-party tools. It should better support interactions within Splunk tools.

If a customer utilizes third-party tools and wants to forward data from Splunk Observability Cloud, seamless integration would be beneficial. This is crucial for passing data to tools such as Dynatrace or Grafana, as integrating some third-party add-ons can be challenging, involving many implementation and configuration steps.

I have been using Splunk Observability Cloud for around two years.

Stability within Splunk Observability Cloud is reliable; I rate it a seven out of ten. I haven't experienced any significant stability issues, though it does depend on the environment's size, and multiple factors come into play when assessing stability.

From a scale of one to ten, I rate the technical support an eight, based on my experiences raising tickets for Splunk Cloud and Splunk ITSI, where I receive proper support. I haven't raised a ticket specifically for Splunk Observability Cloud, but I hope that the support levels are consistent across the board.

Positive

The deployment is easy.

The costs of Splunk Observability Cloud are a bit higher compared to AppDynamics and Dynatrace. I'm not saying it's prohibitively expensive for Splunk Observability Cloud, however, it is on the pricier side.

It's noteworthy, however, that both AppDynamics and Splunk are Cisco products, and there is discussion about possibly consolidating these licenses into a single offering soon, though I'm not certain on that.

When comparing Splunk Observability Cloud with other products or solutions on the market, it tends to stand out. It has improved significantly over time. Initially, when it was acquired from SignalFx, it lacked many functionalities and was not very useful, even if the features existed. Now, after a couple of years, it has become much faster and improved in functionality.

Splunk Observability Cloud is a solid choice if you're considering APM solutions, especially as it is likely to combine with AppDynamics soon due to their shared Cisco ownership, which should enhance its market position.

I would recommend Splunk Observability Cloud to others because it allows for faster resolution and root cause analysis. In any business, flaws are common, but Splunk Observability Cloud is a tool that provides quick results. For industries such as retail, where every second counts with high traffic, Splunk is particularly beneficial, enabling effective tracing and metrics collection.

I'd rate the solution seven out of ten.

The use cases for Splunk Real User Monitoring (RUM) are almost the same as Dynatrace, for people who want to do infrastructure monitoring, application monitoring, or check their front-end monitoring, such as monitoring for the real user. They are actually using Splunk Real User Monitoring (RUM).

The best advantages and features in the product are notable. Splunk Real User Monitoring (RUM) seemed to have advantages in 2015, but when Cisco acquired AppDynamics, they stopped upgrading for a few years. Their advantage now is that they are the only solution that can monitor above SAP. Apart from that, Datadog and Dynatrace have superior features. Splunk Real User Monitoring (RUM) has one great advantage in that if they have SAP users, they can monitor their SAP applications.

In terms of features, UI, or the ability to do monitoring of RUM, the picture by UI or the ability to actually do the monitoring is pretty good, but not as good as Dynatrace, Catchpoint, Datadog, and New Relic.

My thoughts on room for improvement in general relate to Cisco trying to mount the Cisco cloud solution when they have AppDynamics, but after acquiring Splunk, they changed their roadmap. It's inevitable that when a big company has resources but changes the roadmap, it takes time to establish well-structured manuals and guidelines. I believe they will get better, but right now, they need some improvement.

I have been selling Splunk Real User Monitoring (RUM) for almost the same duration as NetScout; it's been 3 years.

In terms of deployment, Dynatrace is the easiest by far. For Datadog and Splunk Real User Monitoring (RUM), you have to work with scripts, meaning you need an engineer for deployment; Dynatrace is straightforward and really easy.

Regarding stability of RUM, stability is also a problem because during the POC, we ask customers not to deploy RUM or EUM scripts in the actual stage. We encourage them to test in staging because even if those solutions are certified and tested, customers have many different environments. Unlike NetScout or regular agents for APM, RUM has many problems during the POC phase because customer environments vary widely.

In terms of scalability, the solution is scalable enough, but sometimes implementation is hard. However, it doesn't take more than a month. The issue is mainly about pricing because if they want to monitor more, it costs money. Those who have a great pricing plan or volume table will gain an advantage.

Support from Splunk is not very helpful because Splunk doesn't have a dedicated APM; they only have one APM engineer in Korea.

If I were to rate technical support for Splunk Real User Monitoring (RUM) from 1 to 10 points, I would give it a score of 5.5. I appreciate the engineer, but since there's only one person doing everything, it's not easy. Cisco doesn't hire enough personnel, and I heard they don't have enough staff in APAC. Datadog and Dynatrace, especially Datadog, cover a huge market share in Asia, and that's why other competitors are not investing enough at this time.

Neutral

My clients, such as Hyundai and POSCO, are using RUM; most of them use Dynatrace. For those using Splunk Real User Monitoring (RUM), it took time to implement because our engineer tried really hard.

Regarding whether the solution provides ROI or savings, I understand that even Dynatrace, Datadog, or Splunk has a low price per transaction, but it concerns the number of data and sessions. People struggle to comprehend the total budget, which might be massive. Customers need to understand this, and I'm not sure if it's possible; maybe some companies just decided to take the entire market and cut down prices, but anyone working in front-end management should recognize the market price to see the true value of end-user monitoring.

I am the general manager of this company, and a team leader focusing on Dynatrace, Cisco AppDynamics, and NetScout, while we used to do some other APM solutions but not extensively. We only focus on those three solutions.

We try to sell Splunk User Behavior Analytics, but we haven't been able to sell it so far because Splunk used to be a great company in Korea. After Cisco acquired it, it's complicated because when two companies merge together, they have issues with who will be the product seller, the sales personnel or the engineer. Their organization is not fully merged yet, which leads to fewer marketing and sales activities.

The integration in real user monitoring from Splunk is actually another problem because of some vacancies when they merged the companies and changed the organizations; there are issues with the manual not being complete. When you work with integration, Datadog and Dynatrace have issues but have to work with the manual; AppDynamics has many people and support. The satisfaction level is around six compared to Dynatrace, which might be a seven or eight. The innovation level is not complete, but they are working on it.

When using real user monitoring to analyze performance bottlenecks, the most critical metrics include data from Catchpoint, which has extensive data to gather, and Dynatrace also gathers substantial data. However, sometimes it's unnecessary because customers in charge of front-end monitoring should see the problems immediately and act with reporting to their superior. A simple UI is crucial; that's perhaps why Datadog has the advantage with their comprehensive UI.

Regarding pricing for RUM, it becomes another problem because Splunk and Dynatrace and Datadog don't ask customers to use RUM for every single session. Many large customers want to monitor every session, resulting in a big gap. For example, Korean Air, which is among the top five air travel companies in the world, uses Datadog but changed to Dynatrace because, even with a limited budget, Dynatrace managed to persuade them to monitor just 10% of user sessions to reduce the budget, and they are satisfied with the results.

This review rates Splunk Real User Monitoring (RUM) 5 out of 10.

Splunk Observability Cloud's main use case for my organization is related to infrastructure monitoring, application monitoring, synthetic monitoring, and detection across all of them, while simultaneously gearing up for real user monitoring.

In my day-to-day work, I develop different sorts of dashboards across Splunk Observability Cloud, build different sorts of synthetic test detectors and alerting criteria for different requirements and KPIs, and occasionally onboard new agents and collectors over Splunk Observability Cloud. It covers everything.

The best features I have observed with Splunk Observability Cloud are the Splunk AI Observability AI assistant, which is very helpful, and the recently added AI troubleshooting for APM-related metrics. Detectors and active alerts are very helpful as well.

I am really excited to see the new fleet management, which I have been exploring initially. Fleet management would make a bigger difference since it allows us to control and manage YAMLs across all agents, and if remote upgrades become available in the future, that will be really helpful.

It has positively impacted my organization in terms of observing different sorts of metrics and tracing across different applications, and it is really helpful.

Many of the fleet management features are still not as updated as required, and I am looking forward to those improvements. Some of the Oracle DB configuration is still not very easily configurable currently, which requires more attention.

The agentic observability and AI observability look very promising based on what I observed in the keynotes, and I am looking forward to all these changes. Once available, I think we will be able to add more capabilities to our implementation.

I have been using Splunk Observability Cloud for the past three years, and I started working on it when it was on version 0.86. I have been working with the recent version of .160 and have deployed all of the recent versions in the past.

There are some issues sometimes, especially with the US zero realms, for which the team is responsive. However, there are recurring issues with the US zero realm, so I think it requires more stability.

I am hoping that after having fleet management, scaling would be comparatively easier. There are still dependencies across different teams for scaling purposes, so I am looking forward to fleet management for the same. I think it is improving.

Customer support is good.

Splunk Observability Cloud is a good product and one of the major products when it comes to observability. They provide us with a better template to prepare. I would rate this review an 8 out of 10.

My primary use cases for Splunk Observability Cloud include creating dashboards for metrics, detecting incidents, and ensuring overall observability of applications, service connections, and integrations, along with reporting and Slack integrations.

By visualizing the integration of the service, I can understand the flow of the data, which is one of the features I appreciate most about Splunk Observability Cloud.

With the metrics collection, I can proactively find incidents and work on the major issues when they happen and predict these issues.

With alerting and the detectors, we can inform the engineers that are on call to take over the service responsibility.

With the metrics and the dashboards, we can have a clear view of how the system is performing. Splunk Observability Cloud has helped improve my operational performance by detecting, analyzing tracings, and detecting alerts.

50% of our metrics on Splunk Observability Cloud are custom metrics, so we heavily rely on that. The out-of-the-box customizable dashboards provided by Splunk Observability Cloud are excellent, especially with the Amazon ones, AWS, memory cache, and Kubernetes dashboards, which are complete for the Kubernetes needs.

The UI of Splunk Observability Cloud is one of the major issues; it's old and has been there for more than 10 years, acquired by other applications from other companies. It's time to reinvent how the UI is going to work with the AI modules and integrations, making it softer and cleaner.

Splunk Observability Cloud is comprehensive in terms of functionality and features, so educating users has to be more functional. Users need to know how to be educated about certain views or pages they're working on.

I have been using Splunk Observability Cloud for five years.

I assess the stability and reliability of Splunk Observability Cloud as built on top of reliability because of the Cisco networking and infrastructure. That's not a concern for me; I totally rely on it. I've experienced downtime, crashes, and performance issues with Splunk Observability Cloud, as with any other solution. Comparing it with other monitoring solutions, Splunk has been excellent with availability. When I experienced issues, they were communicated through maintenance windows, resulting in 100% satisfaction with how they conduct this.

Splunk Observability Cloud scales very well with the growing needs of my organization. We didn't have scaling issues as the application evolved. I expanded usage of Splunk Observability Cloud when the company opened new coverage areas in different countries. Adding those metrics or new indexes to Splunk wasn't much of an issue in scaling.

I evaluate customer service and technical support for Splunk Observability Cloud as having only great experiences working with people at Splunk.

Positive

Prior to adopting Splunk Observability Cloud, I was using Datadog, which would accomplish 70% of what Splunk does currently.

There have been so many challenges that I can't name one right now. There is always a challenge in deploying open source material, like the open telemetry modules, that don't have the reliance on Splunk. It's just an integration challenge that we have the most. Deploying Splunk itself wasn't that much of a big deal.

I see ROI with Splunk Observability Cloud. My company is heavily dedicated to analytics, so the Splunk deal is significant. I cannot imagine how the business would run without it currently.

I had low pricing and setup costs for Splunk Observability Cloud, and overall, my company has received a good deal on all the features that we have. We just have to understand how to explore it further.

Not directly because of Splunk, but the visualization that I have with the main aspects of scaling made us create custom dashboards that proactively detect the changes in scale, and then we can get ready for those changes. We don't have to spend time testing the new capacity when it's already being defined and envisioned by Splunk.

My advice to other organizations considering Splunk Observability Cloud is to watch out for your budget. If I could assess the impact of not having Splunk Observability Cloud, there would be a monetary impact with other solutions. For the business, we would lose resiliency of the system. To imagine the impact, it would be catastrophic.

Splunk has to think about how to redesign Observability Cloud. It came from SignalFx and AppDynamics to Splunk Cloud. It's a merge of different platforms into one, and this merge is being done at a pace where I expected more velocity.

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