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.

I work with Splunk Observability Cloud.

Splunk Observability Cloud is effective for detecting anomalies and preventing system outages.

There are pre-built dashboards where I can check service centers and monitor spikes in errors and traces. I can also check error logs, and everything is consolidated while providing anomaly alerts in case there is any deviation from the baseline.

The personalized dashboard helps my team. Splunk Observability Cloud has its own query language that can be used to build easy dashboards. Multiple teams can build their own, replicate them, and also have role-based access control, which is beneficial.

The application management feature helps with end-user experiences because front-end monitoring helps track user issues and any back-end issues that may be causing them. It shows how the user experience is overall and identifies any outages. Front-end monitoring is very useful.

As an integrator, I think the biggest advantage of Splunk Observability Cloud is because it is part of the Splunk ecosystem, it is good to correlate logs with application data through traces and metrics. Overall, it is an evolving product, not top class, but it is getting there.

I see many good things about the product and many advantages. Regarding the negative side, I think the licensing can be much better because it is based upon host units and there is additional licensing for the number of traces that I can bring in. A simplified licensing model would be much better, similar to what other tools offer. Pricing could be either based upon ingestion or directly based upon host units, rather than multiple different trackers. There are licenses for custom metrics, licenses for the number of traces that I can ingest, and host unit licensing. A better licensing plan would be beneficial.

I have been using Splunk Observability Cloud for more than two years.

I have not seen any issues with stability. The solution is very stable.

Regarding scalability, I do not think there is an issue with scaling. I have never encountered any issues with that.

Support is good.

I have worked on Coralogix, which is also an observability tool. I worked in the product company itself. I have also worked on Dynatrace, and now I am working on Cribl.

The installation and deployment process is somewhat challenging, but there are multiple ways of deployment that give me a lot of options. I would say it is acceptable and not that complicated. I can deploy agents with Splunk deployment server, which is beneficial. However, there is some dependency on the deployment server.

As an integrator, I deployed it and made it workable with OpenTelemetry.

I am able to observe significant ROI with Splunk Observability Cloud. When I worked with a previous solution, it was one-third of the cost of Dynatrace, so there was definitely an exceptional return on investment. It helped reduce costs by almost 50%.

Splunk Observability Cloud is affordable. I have visited the PeerSpot website and downloaded reports on Azure, Grafana, and Splunk Observability Cloud.

When I compare Splunk Observability Cloud to other vendors, the good part is the branding because the support is good. There is a large community where I can look for known issues. However, experience-wise, DataDog is far more superior and easier to use. DataDog has its own agent for tracing, so I just deploy one trace. With Splunk Observability Cloud, they are dependent upon OpenTelemetry, and there is a learning curve because it is open source. The onboarding is not as smooth as DataDog or Dynatrace.

I deploy both on-cloud and on-premise options for clients. I have deployed Splunk Observability Cloud on Splunk Cloud. I have not used threat detection because there is a separate tool for it. I have not deployed a solution on AWS Cloud or purchased it from AWS Marketplace in my career. I would rate this review 7.5 out of 10.

My main use case for Splunk Observability Cloud involves performing visualized performance metrics and tracing capability, making sure that all troubleshooting is faster during incident response. We also integrate it to ensure that every data point and operational data is monitored.

A specific example of how I have used Splunk Observability Cloud in a real situation is that we make use of it to ensure that every operational data point is being monitored, traceable, and visible.

Regarding my main use case for Splunk Observability Cloud, I would add that we really utilize it in the area of cost management, along with the smarter alerting system and the log search performance.

The dashboard and lead time metrics from Splunk Observability Cloud really improve our workflow, making every workflow more visible and understandable for our stakeholders as well.

Splunk Observability Cloud has positively impacted my organization. Although we have not noticed any specific outcomes, we really recommend it for handling higher data volumes effectively, especially its scalability, which is suitable for us during enterprise environments, monitoring, and alerting.

The best features that Splunk Observability Cloud offers include APM monitoring, the fast alerting system during incident response, and the dashboard that provides real-time metrics.

To improve Splunk Observability Cloud, I wish they could develop more in the area of pricing and cost transparency, provide a smoother learning curve, and enhance the log management experience, ensuring that log navigation is not solely focused on metrics and tracing but also has good search performance to understand larger data sets.

I would also like to see a very good user interface and onboarding experience that is smoother for new users.

Before we wrap up, I want to emphasize the need for improvements in the log search performance and the smarter alerting system.

I have been using Splunk Observability Cloud for over a year.

In my experience, Splunk Observability Cloud is very stable in the area of real-time monitoring and analytics.

When handling higher data volume and scalability, I can say that we have over 70% efficiency now.

For scalability, I would rate it an eight, as it is very good in responding faster and monitoring larger data sets.

We have great feedback from the customer support of Splunk Observability Cloud, as they help solve and make bug alert management easier, respond quickly to incidents, and monitor data sets effectively.

I have not used any different solution before Splunk Observability Cloud.

I have seen a return on investment with Splunk Observability Cloud, with current metrics showing over 75% efficiency. It has really helped our workflow, saved time, reduced costs, and also saved employees' time.

My experience with the pricing, setup cost, and licensing for Splunk Observability Cloud was acceptable at first, though I believe they need to improve more in this area. I would rate it a seven, but overall, the costing and licensing were fine for me.

Before choosing Splunk Observability Cloud, I was recommended to it specifically.

Splunk Observability Cloud deserves an eight out of ten rating. I choose an eight because of their fast response and the monitoring of strong infrastructures.

I would advise others looking into using Splunk Observability Cloud because I am a witness to its effectiveness. It is very beneficial for workflow, making tasks easier and flexible while being able to track and monitor all data sets.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I am using Splunk Observability Cloud as a log-based monitoring tool for my databases. We have ingested our database logs and OS system logs into Splunk Observability Cloud and are creating dashboards and alerting features over those alerts. One of my major use cases is that all kinds of databases I am currently working with have database logs that capture all information, warnings, and error messages. These database logs are moving to Splunk Observability Cloud. The first use case is that I no longer need to maintain a long list of flat files on my server for all those logs. Those can be directly ingested into Splunk Observability Cloud. The benefit I am seeing from here is that I can get pattern-based analysis of what kind of errors I am commonly getting and what the date patterns of those errors are. I can get dashboards over that and I can also create alerts. I can also incorporate those alerts with some back-end Git workflow for automatic remediation. This is one of the solutions.

Another use case for Splunk Observability Cloud that we are seeing is that there are multiple times when there is a requirement to publish some kind of data. So instead of publishing an alert if those data breaches occur or if some kind of dashboard needs to be created, instead of sending data directly to the users, if that data is not PII, we are also ingesting that into Splunk Observability Cloud in a JSON format and then again, dashboards and other alerting can be created. These two are the main major use cases for which I am using Splunk Observability Cloud.

With the help of the alerting and observability mechanism, resiliency, and automatic automation of issue remediation based on alerts and workflows, it actually reduces the cost and increases the uptime of my system and customer satisfaction. There are multiple indirect benefits I am getting when using Splunk Observability Cloud.

Currently, with the growth of the organization, I am seeing an increasing use of Splunk Observability Cloud in a more dynamic way. We are continuously creating new dashboards, ingesting logs in JSON, and trying to bring the best value out of it. I am seeing a dynamic and drastic increase in the use of Splunk logs and the Splunk data we are ingesting.

There are two aspects to expanding the usage. Organic growth of the environment actually puts new systems into Splunk Observability Cloud, and exploring new opportunities for what all can also be ingested into Splunk Observability Cloud. Previously, I can see that memory dumps are there. We are also looking at whether we can ingest memory dumps so that if the system is about to crash, those memory dumps can be captured into Splunk Observability Cloud so that it can create alerts over that and I can also perform analysis. I can also see if any other system is facing the same kind of memory dump issues. So that maybe it is one alert for one system for me, but for the complete farm, there may be different servers with different teams or business units facing the same issues. When I have Splunk Observability Cloud on all systems, I can actually create a consolidated report and see that this is the pattern which particular farms are having this kind of issues, and maybe something is broken. This is the way the plan is to increase the availability or the usage of Splunk Observability Cloud.

The performance and speed are valuable. Previously when Splunk offered the enterprise solution, I needed to install Splunk and maintain my local server. There was a limitation that only a certain number of servers could be supported in one instance and I would need to have multiple instances if I was in an enterprise system setup. When I am in the cloud, a single instance can support N number of systems. It is pretty fast, no matter how much data is there. Dashboards are pretty good with multiple functions available. The alignment or integration that can trigger automatic solutions with the workflow for automatic remediation of the alerts is the best thing. These three or four things are the best Splunk Observability Cloud features that I am seeing.

The point in time alerting, the point in time data capture, and automatic remediation with the integration of good workflows or Ansible workflows is definitely the key to any resiliency and increasing the uptime of any system.

After moving to Splunk Observability Cloud, it is almost zero downtime. We never face downtime because when I was in the enterprise setup, I needed to maintain my servers and maintain hygiene of vulnerabilities, patches, and all. Now when I am in the cloud, everything is automatic. Almost zero downtime plus the perfect alerting feature and log-based analysis are available. Metrics alerting is also there in Splunk Observability Cloud through queries. This is one of the features that keeps me updated with the current health of my system and helps me to keep my system up and running fine and available for my customers.

Splunk Observability Cloud incorporated a new AI agent feature that is really good. Sometimes I need to create queries and Splunk queries for filtering the data and some pattern-based analysis. This agent is really good in helping me and suggesting the queries. This means I do not need to have a Splunk expert or Splunk query expert. I can just ask that agent that I need pattern-based analysis or I need to create this kind of filters for this kind of data and it can suggest to me. Once it suggests a sample query to me, I can do the tweaking and I can have my data ready. It actually reduces my time to perform my analysis and to reach the conclusion about what exactly is causing issues in my system and what are the repetitive issues in my system. This AI feature really helps for newcomers to Splunk Observability Cloud to perform deep diving analysis with the data captured by it.

Custom metrics are valuable. In Splunk Observability Cloud, some infra-level metrics are not available, but through custom metrics, I can achieve it. This is an add-on feature that Splunk Observability Cloud is providing and without any additional monitoring tool. If that feature was not there, then I would need to plan some other monitoring tool for metrics-based alerting, but this custom one helps me to achieve it in the same monitoring tool. The consolidation and integration of metrics-based alerting and log-based alerting in a single tool is actually the lovable feature. I do not need to worry about or look for multiple tools. I can have my own data and own health available in a single tool, in a single view.

The dashboards are good, but the only limitation I see currently is that they need particular formats only to create a dashboard. They need to have a particular JSON format or time series format. This sometimes creates additional work for me so that when I am ingesting logs in Splunk Observability Cloud, it should be in a specific format. Either Splunk Observability Cloud should have multiple formats available or multiple dashboards available for different kinds of formats. At least Splunk Observability Cloud has everything available at a Splunk level. They can do some kind of analysis and see what are the major top ten or top twenty types of logs they are getting and they can have dashboards according to those logs. Instead of forcing customers to design their logs in the way of Splunk Observability Cloud, Splunk Observability Cloud can create dashboards based on the customer requirement. This will actually ease things up for the end users.

The current dashboards are good. The feedback is that Splunk Observability Cloud is forcing me to modify my logs that I am ingesting in Splunk Observability Cloud in a specific format. If Splunk Observability Cloud can leverage it and make it open for any format, that would be great. If that is not feasible, at least the top ten or top twenty logs that Splunk Observability Cloud is getting should be readable by Splunk Observability Cloud without any changes. That actually is one of the major feedback items I can provide which can actually ease the life of the end users or any layman. As a newcomer to Splunk Observability Cloud, I may not know JSON. I now need to hire someone or I need to look for someone who knows JSON and who can convert my logs into JSON format and then I will ingest them into the logs if I want to create a dashboard. If I do not want to create a dashboard, that is okay. On the other hand, Splunk Observability Cloud is giving me a usability and easy to go interface, but for a dashboard, I need to have an understanding of JSON so that I can ingest the log in JSON format. That is a dilemma that they have and they should work on.

Currently, Splunk Observability Cloud is not the only solution which any organization is using. There is also Grafana and PagerDuty. If Splunk Observability Cloud can plan some kind of integration with PagerDuty and Grafana, then those things can be controlled from a single position and if something else is happening at one location, it can update things at all levels. That can also bring great value to the users. Currently, I have to maintain three systems separately, but if some kind of integrations can be developed with these three vendors, then that can be a great thing because all these three have now become the industry pillars or industry standards for observability and resiliency.

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

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

Scalability is pretty smooth. I just need to deploy the Splunk forwarder and the config file that specifies which servers it should connect to and it will get connected. My data will start populating. It is pretty straightforward. I do not see any challenges there, even when it was in enterprise and now when it is in the cloud. The deployment and onboarding of new servers and ingesting the logs is pretty straightforward. Anybody can learn it within a day without having any prior knowledge.

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

Previously I was on Splunk Enterprise. I have been using Splunk for seven to eight years before we moved to the cloud in the last eighteen months.

The initial setup is pretty smooth. I just need to deploy the Splunk forwarder and the config file that specifies which servers it should connect to and it will get connected. My data will start populating. It is pretty straightforward. I do not see any challenges there, even when it was in enterprise and now when it is in the cloud. The deployment and onboarding of new servers and ingesting the logs is pretty straightforward. Anybody can learn it within a day without having any prior knowledge.

I appreciate that your organization collects reviews about the product so that it can be shared with the vendor or the product owner as appreciation or as feedback for improvement. Everything has been smooth in my experience. I would rate this product a ten out of ten.