Splunk Observability Cloud Reviews

I use the solution in my company primarily for distributed tracing and metrics troubleshooting. I use the tool to troubleshoot incidents and find the root cause of errors when something goes wrong. I also personally use it to have a developer's understanding of what is going on in my application. Sometimes, there is a case where you might put your application in a library or a new library, and that library also makes calls somewhere. Splunk APM's monitoring can show you that there is a call you are making now that you never used to make in the prior version of the library. In these cases, which you may not know just by looking at the external view of the application code, the tracing part traces everything, including the lowest types of supports.

The main benefit of the tool I have noticed in the solution is reduced time for the resolution of incidents. The meantime to resolve can help pinpoint the root causes of the issues because you see the connections on the graph in Tag Spotlight. It is easier to pinpoint who is responsible for the incident, especially when you have a larger organization. You have teams that ride services where they need to talk to different services from different teams rather than having to hand off instant resolutions from one team to another. You can often find it much more quickly from the first instance of the problem occurring with the product in place. The tool specifically helps your sites move up more frequently, and then when it does go down, the solution finds the root cause and gets it back up as fast as possible.

The most valuable feature of the solution, and my favorite, is always Tag Spotlight, especially considering the way they slice and dice all of Splunk APM's traces by span attributes. 

I like the tool because it looks at a whole set of traces in aggregate, which means that it can find statistical similarities between different traces. Often, the cases are such that you will find some traces that show an error and have some other common attribute, which is much more apparent when you look at the feature known as Tag Spotlight rather than just looking at an overall metric. I like Tag Spotlight as it is one of the most simple to use features.

The meantime to resolve, or MTTR, can help pinpoint the root causes of the issues because you see the connections on the graph in Tag Spotlight. I don't personally have metrics associated with MTTR. I am more of the implementer of making certain that all the data is going in and looking at the debugging part. I am not a part of the set of people who keep track of the tool's MTTR.

In our company's case, we have reasonably good metrics related to the meantime to detect. I can't get a rough number when it comes to the meantime to detect, so I don't know for sure. My guess is that we often detect problems reasonably well. Our company figures out that there is some problem, but we just don't know where it is, so I feel that if there is an improvement, then it is mostly in the area of meantime to resolve. When it comes to the meantime to detect, I think our existing metrics are probably sufficient, and adding Splunk APM makes it much easier to detect the resolution time.

The tool has improved our organization's business resilience. In terms of resilience, in the tool, it is possible not to have downtime and make certain things up and running. The faster you get to web pages working again, the more people can actually do things that they want to do, such as trade players on their NFL Fantasy teams. In general, it gives out a better business result.

In our company's case, we have some very high throughput services, so they might be getting 10,000 requests per second. Currently, Splunk APM and Splunk Observability want to do things in a way that wants you to send every single span for every single request that is a part of the 10,000 requests per second. The process may give you all the data in the back end, but a lot of data, including CPU memory and network costs, is involved in sending data to Splunk. My feeling is that it would be nice if there were an easier way to send only a sample of my traces, which means that I send 10 percent or 5 percent, and then Splunk would extrapolate on the back end. It is obvious that with 10 percent of traces, the real metrics are something like ten times with a plus or minus margin of error. I am okay with the plus or minus margin of error because I think when you have a high enough request rate, you will see such problems appear even in a lower sample population. The process is political polling. You don't call all 150,000,000 people in the US and ask them who they are going to vote for, and I feel it is better if you choose to take a sample of maybe 10,000 and then extrapolate your findings to the rest. I feel the same should be applicable to trace something in Splunk APM.

I have been using Splunk APM for two years.

I really haven't noticed anything going wrong with the tool's stability, and I haven't seen any downtime. I don't know if my company is necessarily measuring the stability part by ourselves, but at least for me, it is a pretty growing and solid solution.

There is one issue with the tool's scalability. In our company, we are fairly big in terms of the number of containers we have, especially since we can run very large clusters. When you look at some of the charts, it will say 30,000 time series, reached the limit, and cannot show anymore, or it states that a particular data may not be complete. For me, it is a problem that I would like to see fixed. I have spoken to Spunk's team about it, and they have told me that they do recognize the issue and that other people have also mentioned the same problem. Once you see the issues related to the scalability part, you need to understand that it is a warning triangle. After seeing the warning triangle, you need to realize that you cannot trust any of the numbers you see in the chart because it is not a complete, full data set. I want the tool to either tell me that it can't show me the numbers or that I need to find some way to show all the numbers in a more summarized view. The tool asks you to filter things down more, but it would be nice to offer specific suggestions as to what you could filter down to get it into a more specific or reasonable number. In some cases, my company just has to have a number, considering that we have 1,00,000 containers. If I want to know how many containers are running, currently, the way the backend works in a way where it requires to know how many different time series there are, and then it just says that the 30,000 limit has been reached, but when it happens, I don't know whether it is for 1,00,000 containers, 1,20,000 containers or 80,000 containers.

The technical support team for the solution is good for our company. My company has a weekly meeting with Splunk's sales support team, and if there are any issues, we bring them up for discussion. I have seen that the technical support team is super responsive.

My company has its own internal solution, which was built ten to fifteen years ago, and it has progressed over time, but it is only ever used to support metrics and events, not for tracing. In short, it is not used for Splunk APM-related stuff, which is a big change that makes a difference for us.

The product's deployment phase is good and very easy because it is done with OpenTelemetry for most of the parts. The product's deployment is not some custom thing where you have to deploy a particular agent that belongs to a particular company and put it on every single host. It is very easy to follow OpenTelemetry's models for the most part. Splunk is a very big contributor to OpenTelemetry, and I value it. It consists of the reasons I recommend using Splunk as a backend provider. In my company, we are more open to being more of an OpenTelemetry-compliant organization instead of going for other vendors.

I can't speak about the tool's ROI since I get paid, but I don't have to spend money on the product.

I don't have much insight into the costs and licensing area attached to the tool. I am the engineer and developer, not the person who writes the checks in the company. I know that my company has a Splunk Enterprise Security license which is used for logging and even for Splunk Observability.

I think the tool has the best trace aggregation features compared to what I have seen in different products, and I feel Tag Spotlight is a good example of it. A lot of the other products support tracing, but when you look at them, you see that they show one trace at a time. I can deep dive into one trace at a time, but what I want to find is commonality across the traces. I think it will give the tool a high grade for all its features. I rate the tool highly since it offers a very good Kubernetes integration. With a lot of data, you can see which part the Kubernetes host is running on, switch between them, and see the application metrics and the actual infrastructure metrics. Seeing it all together can be very useful.

I rate the tool a nine out of ten.

We use Splunk APM to understand and know the inner workings of our cloud-based and on-premises applications. We use the solution mainly for troubleshooting purposes and to understand where the bottlenecks and limits are. It's not used for monitoring purposes or sending an alert when the number of calls goes above or below some threshold.

The solution is used more for understanding and knowing where your bottlenecks are. So, it's used more for observability rather than for pure monitoring.

The solution's service map feature allows us to have a holistic overview and to see quickly where the issues are. It also allows us to look at every session without considering the sampling policy and see if a transaction contains any errors. It's also been used when we instrument real use amounts from the front end and then follow the sessions back into the back-end systems.

Splunk APM should include a better correlation between resources and infrastructure monitoring. The solution should define better service level indicators and service level objectives. The solution should also define workloads where you can say an environment is divided up by this area of back end and this area of integration. The solution should define workloads more to be able to see what is the service impact of a problem.

I've been using Splunk APM in my current organization for the last 2 years, and I've used it for 4-5 years in total.

Splunk APM is a remarkably stable solution. We have only once encountered an outage of the ingestion, which was very nicely explained and taken care of by the Splunk team.

I rate the solution a 9 out of 10 for stability.

Around 50 to 80 users use the solution in our organization. The solution's scalability fits what we are paying for. On the level of what we pay for, we have discovered both the soft limit and the hard limit of our environment. I would say we are abusing the system in terms of how scalable it is. Considering what we are paying for, we are able to use the landscape very well.

We have plans to increase the usage of Splunk APM.

Splunk support itself leaves room for improvement. We have excellent support from the sales team, the sales engineers, the sales contact person, and our customer success manager. They are our contact when we need to escalate any support tickets. Since Splunk support is bound not to touch the consumer's environment, they cannot fix issues for us. It's pretty straightforward to place a support ticket.

Positive

We have previously used AppDynamics, Dynatrace, and New Relic. We see more and more that Splunk APM is the platform for collaboration. New Relic is more isolated, and each account or team has its own part of New Relic. It's very easy to correlate and find the data within an account. Collaborating across teams, their data, and their different accounts is very troublesome.

With Splunk APM, there is no sensitivity in the data. We can share the data and find a way to agree on how to collaborate. If two environments are named differently, we can still work together without infecting each other's operations.

If you're using the more common languages, the initial deployment of Splunk APM is pretty straightforward.

The solution's deployment time depends on the environment. If the team uses the cloud-native techniques of TerraForm and Ansible, it's pretty straightforward. The normal engagement is within a couple of weeks. When you assess the tool they need and look at the architecture and so on, the deployment time is very, very minimal. Most of the time spent internally is caused by our own overhead.

We have a very good conversation with our vendor for Splunk APM. We have full transparency regarding the different license and cost models. We have found a way to handle both the normal average load and the high peak that some of our tests can cause. Splunk APM is a very cost-efficient solution. We have also changed the license model from a host-based license model to a more granular way to measure it, such as the number of metric time series or the traces analyzed per minute.

We have quite a firm statement that for every cost caused within Splunk, you need to be able to correlate it to an IT project or a team to see who the biggest cost driver is. As per our current model, we are buying a capacity, and we eventually want to have a pay-as-you-go model. We cannot use that currently because we have renewed our license for only one year.

We are using Splunk Observability Cloud as a SaaS solution, but we have implemented Splunk APM on-premises, hybrid, and in the cloud. We are using it for Azure, AWS, and Google. Initially, the solution's implementation took a couple of months. Now, we are engaging more and more internal consumers on a weekly basis.

We implement the code and services and send the data into the Splunk Observability Cloud. This helps us understand who is talking to whom, where you have any latencies, and where you have the most error types of transactions between the services.

Most of the time, we do verification tests in production to see if we can scale up the number of transactions to a system and handle the number of transactions a business wants us to handle at a certain service level. It's both for verification and to understand where the slowness occurs and how it is replicated throughout the different services.

We can have full fidelity and totality of the information in the tool, and we don't need to think about the big variations of values. We can assess and see all the data. Without the solution's trace search and analytics feature, you will be completely blind. It's critical as it is about visibility and understanding your service.

Splunk APM offers end-to-end visibility across our environment because we use it to coexist with both synthetic monitoring and real user monitoring. What we miss today is the correlation to logs. We can connect to Splunk Cloud, but we are missing the role-based access control to the logs so that each user can see their related logs.

Visualizing and troubleshooting our cloud-native environment with Splunk APM is easy. A lot of out-of-the-box knowledge is available that is preset for looking at certain standard data sets. That's not only for APM but also for the available pre-built dashboards.

We are able to use distributed tracing with Splunk APM, and it is for the totality of our landscape. A lot of different teams can coexist and work with the same type of data and easily correlate with other systems' data. So, it's a platform for us to collaborate and explore together.

We use Splunk APM Trace Analyzer to better understand where the errors originate and the root cause of the errors. We use it to understand whether we are looking at the symptom or the real root cause. We identify which services have the problem and understand what is caused by code errors.

The Splunk Observability Cloud as a platform has improved over time. It allows us to use profiling together with Splunk Distribution of OpenTelemetry Collector, which provides a lot of insights into our applications and metadata. The tool is now a part of our natural workbench of different tools, and it's being used within the organization as part of the process. It is the tool that we use to troubleshoot and understand.

Our organization's telemetry data is interesting, not only from an IT operational perspective but also to understand how the tools are being used and how they have been providing value for the business. It is a multifaceted view of the data we have, and it is being generated and collected by the solution.

Splunk APM has helped reduce our mean time to resolve. Something that used to take 2-3 weeks to troubleshoot is now done within hours. Splunk APM has freed up some resources if we are going to troubleshoot. If you spend a lot of time troubleshooting something and can't find a problem, we cannot close the ticket saying there's no resolution. With Splunk APM, we can now know for sure where we have the problem rather than just ignoring it.

Splunk APM has saved our organization around 25% to 30% time. It's a little bit about moving away from firefighting to be preventive and estimate more for the future. That's why we are using it for performance. The solution allows us to help and support the organization during peak hours and be preventative with the bottlenecks rather than identify them afterward.

Around 5-10 people were involved in the solution's initial deployment. Integrating the solution with our existing DevOps tools is not part of the developer's IDE environment, and it's not tightly connected. We have both subdomains and teams structured. Normally, they also compartmentalize the environment, and we use the solution in different environments.

Splunk APM requires some life cycle management, which is natural. In general, once you have set it up, you don't need to put much effort into it. I would recommend Splunk APM to other users. That is mainly due to how you collaborate with the data and do not isolate it. There is a huge advantage with Splunk. We are currently using Splunk, Sentry, and New Relic, and part of our tool strategy is to move to Splunk.

As a consumer, you need to consider whether you are going to rely on OpenTelemetry as part of your standard observability framework. If that is the case, you should go for Splunk because Splunk is built on OpenTelemetry principles.

Compared to other tools using proprietary agents and proprietary techniques, you may have more insights into some implementations. However, you will have a tighter vendor lock-in, and you won't have the portability of the back end. If you rely on OpenTelemetry, then Splunk is the tool for you.

Overall, I rate the solution a 9 out of 10.

We use the solution to monitor and calculate the number of systems, applications, and DR sites we have. Then, if there is any problem, we can detect the information on which server belongs to which application. This really helps us.

We have seen 28% to 29% optimization and performance with Splunk Infrastructure Monitoring. You will know the moment you see any anomaly in the system, the server, or the infrastructure. The solution has given us more visibility not only from the infrastructure or server point of view but also from the network perspective.

Splunk's GUI and dashboard capacity are the most valuable features of Splunk Infrastructure Monitoring.

Compared to Microsoft Azure, Splunk Infrastructure Monitoring can ingest all the log sources. You can ingest all the data in one single source. Then, it accumulates the data, calculates internally, and gives you the right information you're looking for. Splunk Infrastructure Monitoring is the optimal solution, where you can see everything on one screen.

Our organization monitors multiple cloud environments, including GCP (Google Cloud Platform) and AWS (Amazon Web Services).

We're all completely dependent on Splunk's end-to-end visibility into our cloud-native environment to see everything, including any incident that comes.

Splunk Infrastructure Monitoring has helped drastically improve our meantime to resolve, detect, and investigate.

The solution has helped reduce our mean time to resolve by 28%, which is a huge number. We aim to reduce it by 30% to 37%, but that would definitely require some AI concept and new enterprise security. That's our plan for next year.

Splunk Infrastructure Monitoring has helped improve our organization's business resilience. The moment you receive an incident, you have full visibility. You can go deep into the investigation, do threat hunting, and find the root cause analysis. That's the visibility and performance we look for in enterprise security solutions like Splunk.

Splunk's unified platform helps consolidate networking, security, and IT observability tools. When you have multidimensional solutions and a multi-cloud environment, you have specific applications for finance and patient care. You can see everything consolidated in one solution.

DevOps and GRC compliance solutions come into one solution, and visibility extends. That gives you confidence, and we build trust with the business. Businesses are confident when they're going outside. Because we have full visibility, we provide that trust to the patient and my health care entities that we are safe.

The utilization of the use cases is not available. You need to write custom out-of-the-box use cases. There's no standard use case available where you can see the utilization of the number of use cases I have. For example, if you have 200 use cases, do you know if you are utilizing all 200 and if they are actually clicking at the right time?

If I can work 20 use cases out of 200, it is 20% utilization for the use cases. So, I'll focus more on 20% and try to optimize them based on my business requirements rather than focusing on 200.

I have been using Splunk Infrastructure Monitoring for six years.

The solution's scalability is marvelous because we can just add on. We are currently using two TB, and the solution gives us the flexibility to add an extra 500 GB next month.

Sometimes, we face technical difficulties because of the limitations of the connectors. Integrating Splunk with post-relational databases like InterSystems is challenging because such applications or databases are not very much publicly exposed. The technical team faces a lot of challenges when integrating because they need to write some custom connectors to integrate the data.

We have some clinical applications specific to a particular specialty, and you have different applications and databases for that. For that, you need to write custom connectors. Sometimes, the technical team lingers on and passes the time because they're also exploring.

I rate the solution's technical support seven and a half out of ten.

Neutral

We previously used a different solution called RSA. We switched to Splunk because RSA was not providing the latest changes and many of the upgrades we were expecting. Also, a lot of functionality we were expecting, like XDR, optimization processes, and connectors, was not available. We used RSA for four and a half years. RSA had performance issues, and a lot of use cases were not met because it was an old solution.

We had a system integrator who initially helped us integrate and deploy the solution. They helped us to deploy the solution, and we take their help to develop any new use cases.

We have seen a return on investment with the solution. Our KPIs have become smooth. When we have more visibility, our KPIs definitely increase. We can easily measure meantime to detect and meantime to resolve. You will definitely be up to the mark when your incident response capability increases. Our performance has increased. Our IT environment and DevOps team have more visibility and are more transparent now.

The solution's pricing is costly. We're now looking for a cloud version that would have a completely different pricing calculation.

Splunk Infrastructure Monitoring has use case capability, visibility capability, and performance. It also has a vast dashboard capability that no other solution currently provides. There are many solutions in the market, but Splunk stands out separately. With Splunk Infrastructure Monitoring, you can correlate data and ingest any kind of data with your connectors. Flexibility is another important functionality of Splunk.

Overall, I rate the solution an eight out of ten.

We use Splunk APM to monitor the performance of our applications.

Splunk APM offers end-to-end visibility across our entire environment. We need to control how many types of metrics are ingested by Splunk APM from all incoming requests. While we allow some metrics to be collected, Splunk APM provides the ability to track each request from its starting point to its endpoint at every stage.

Splunk APM trace analyzer allows us to analyze a request by providing its trace ID. This trace ID gives us a detailed breakdown of how the request entered the system, how many services it interacted with along the way, and its overall path within the system. We can also identify any errors that occurred during the request's processing and track any slowness or latency issues. This information is very helpful for troubleshooting performance problems in our application.

Splunk APM telemetry data has been incredibly valuable. While we faced challenges with Splunk Enterprise, such as the lack of a trace analyzer, Splunk APM's user interface is modern and highly flexible. The wide range of data it provides has significantly improved our incident response times, allowing us to quickly create alerts and adhere to the infrastructure as code principle. Splunk APM also proves beneficial during load testing, contributing to a positive impact on our overall infrastructure performance analysis.

Splunk APM helps us reduce our mean time to resolution. With its fast and accurate alerting system, we can quickly identify the exact location of issues. This pinpoint accuracy streamlines the investigation process, leading to faster root-cause analysis.

Splunk APM has helped us save significant time. We're now spending less time resolving production incidents and analyzing performance data. This focus on Splunk APM allows us to dedicate more time to other areas.

Detectors are a powerful feature. They create signal flow code in a format similar to Splunk APM language. For example, if we select five conditions, the detector can automatically generate the code for that signal flow. This code can then be directly integrated into our Terraform modules, streamlining the creation of detectors using Terraform. This is particularly helpful because our infrastructure adheres to a well-defined practice, and detectors help automate this process.

APM dashboards are another valuable tool. They provide more comprehensive information than traditional spotlights. One particularly useful feature is the breakdown of a trace ID. This breakdown allows us to see the entire journey of a request, including where it originated, any slowdowns it encountered, and any issues it faced. This level of detail enables us to track down the root cause of performance problems for every request.

We currently lack log analysis capabilities in Splunk APM. Implementing this functionality would be very beneficial. With log analysis, we could eliminate our dependence on Splunk Enterprise and rely solely on APM. The user interface design of APM seems intuitive, which would likely simplify setting up log-level alerts. Currently, all log-level alerting is done through Splunk Enterprise, while infrastructure-level alerting has already transitioned to Splunk APM.

The Splunk APM documentation on the official Splunk website could benefit from additional resources. Specifically, including more examples of adapter creation and management using real-world use cases would be helpful. During our setup process, we found the documentation lacked specific implementation details. While some general information was available on public platforms like Google and YouTube, it wasn't comprehensive. This suggests that others using Splunk APM in the future might face similar challenges due to the limited information available on social media. It's important to remember that many users rely on social media for setup guidance these days.

I have been using Splunk APM for 1.5 years.

While Splunk APM occasionally experiences slowdowns, it recovers on its own. Fortunately, these haven't resulted in major incidents because most maintenance is scheduled for weekends, with ample notice provided in advance. We have never experienced any data loss that occurred during previous slowdowns.

Splunk APM customer support is helpful. They promptly acknowledge requests and provide regular updates. They've been able to fulfill all our information requests so far. However, Splunk APM is a constantly evolving product. This means there are some limitations due to ongoing industry advancements. They are actively working on incorporating customer feedback, such as the CV request. Overall, the customer support is excellent, but the desired features may not all be available yet.

Positive

Previously, we used Grafana, but we faced challenges that led us to switch to Splunk APM. Since then, Splunk has become our primary tool for data analysis. In our experience, Splunk offers several advantages over Grafana. Setting up and using Splunk is significantly easier than Grafana. Splunk provides a user-friendly interface that allows anyone to start working immediately, while Grafana's setup can be more complex. Splunk also boasts superior reliability. Its architecture utilizes a master-slave node structure, with the ability to cluster for redundancy. This ensures that if a node goes down, another available node automatically takes over, minimizing downtime. Ultimately, our decision to switch to Splunk was driven by several factors: user-friendliness, a wider range of features, cost-effectiveness, and its established reputation. Splunk is a globally recognized and widely used tool, which suggests a higher level of trust and support from the industry.

We use Splunk Enterprise and Splunk APM. Splunk APM offers a comprehensive view of various application elements. We primarily migrated to APM to gain application-level metrics. This includes latency issues, which are delays in processing user requests. Splunk APM generates a unique trace ID for each user request. This allows us to track the request from the user to our servers and identify any delays or errors that occur along the way. 
Additionally, Splunk APM utilizes detectors to create alerts based on specific metrics. We've implemented alerts for CPU and memory usage, common issues in our Kubernetes infrastructure. We can also track container restarts within the cluster and pinpoint the causes. Another crucial area for us is subscription latency. Splunk APM allows us to monitor this metric and identify any performance bottlenecks. This capability was absent in Splunk Enterprise, necessitating the switch to APM. Furthermore, Splunk APM enables us to track application status codes, such as 404 errors.

Splunk APM facilitates the creation of informative dashboards using collected metrics. Additionally, the Metrics Explorer tool allows us to investigate specific metrics of interest and generate alerts or customized spotlights. 
Spotlights are tailored visualizations that track metrics for critical application areas. They can trigger alerts based on unexpected changes, such as a sudden increase in error codes over a set timeframe. This provides a more proactive approach to identifying potential issues compared to traditional detector-based alerts.

Splunk APM empowers us to effectively monitor various metrics during load testing. This includes analyzing memory usage across ten to eleven metrics, tracking container restarts during flow testing, and verifying the functionality of auto scaling mechanisms. The comprehensive visualization capabilities of Splunk APM surpass those of Splunk Enterprise, making it ideal for analyzing large sets of metrics and graphs.

We're currently exploring the integration of an OpenTelemetry agent with Splunk APM. This will enable us to collect and transmit a wider range of data, including application metrics, latency metrics, and basic infrastructure metrics such as CPU, memory, etc.

During the initial Splunk deployment, I found that most information available on social media platforms catered to enterprise deployments. Fortunately, many of our new hires had prior Splunk experience, which eased the initial learning curve. Splunk's widespread adoption across industries also meant there was a general familiarity with the tool among the team. Additionally, the comprehensive documentation proved helpful. Overall, the initial rollout went smoothly, though there were some challenges that we were able to resolve.

The Splunk deployment was done on multiple environments. We started with development and then deployed to a staging environment, which sits between development and production. As expected, the development deployment took the longest. The total time for the entire deployment, including my cloud setup, was 2 to 3 weeks. It's important to note that this timeframe isn't solely dependent on Splunk implementation. Other factors can influence the timeline, such as network requests, firewall changes, and coordination with IT teams for license purchases. While the development deployment took longer, promoting Splunk to the staging and production environments was significantly faster. It only took 1 week for each environment.

Our cloud deployment didn't require a consultant, but we used one for our on-premise enterprise deployment, which was a bit more complex.

I would rate Splunk APM 9 out of 10.

The maintenance required is minimal because the cluster deployment helps ensure there is always 1 node working.

My main use cases for Splunk Observability Cloud include Application Performance Monitoring, Real User Monitoring, and Synthetic Monitoring.

Splunk Observability Cloud has proven to be beneficial for our organization. In evaluating its effectiveness in improving digital resilience within my organization, I have experienced lower costs of unplanned digital downtime.

The solution has helped improve operational performance and company resilience.

Splunk Observability Cloud can be optimized to its full potential. 

I have been using Splunk Observability Cloud since this year.

The stability and reliability of Splunk Observability Cloud has been satisfactory. Customer service and technical support have been evaluated positively.

Splunk Observability Cloud scales effectively with the growing needs of my organization.

Positive

I have always used Splunk products.

My experience with the pricing, setup costs, and licensing has shown a return on investment with Splunk Observability Cloud.

I would recommend organizations to consider implementing Splunk Observability Cloud. 

On a scale of one to 10, I would rate Splunk Observability Cloud overall as nine.

We use Splunk Infrastructure Monitoring to monitor our hybrid infrastructure.

We implemented Splunk Infrastructure Monitoring to help us monitor our infrastructure as we scale.

Splunk Infrastructure Monitoring is easy to use. It helps us quickly analyze how our infrastructure is performing across various services.

It helps with proper log management, allowing us to monitor our systems and analyze log data regularly. It also provides security operations capabilities for monitoring system health and ensuring uptime. We noticed these benefits immediately.

Our operational efficiency has been increased. It has improved our system health by monitoring the performance of data on servers, virtual machines, and containers, along with overall background processes.

Splunk Infrastructure Monitoring provides end-to-end visibility into our cloud-native environment. This is crucial because any data corruption can impact all the information we've deployed. It also aids in log management, offering parameters that extend its functionality as a comprehensive monitoring tool for CPU, memory usage, and network traffic.

It has helped reduce our mean time to detect by four hours.Our mean time to resolution has been reduced by two hours. By providing access to all our network parameters, it simplifies log ingestion through streamlined calculations.

Splunk Infrastructure Monitoring provides us with faster and more comprehensive insights into our infrastructure, allowing us to focus on critical business initiatives.

We saw the time to value immediately after deploying Splunk Infrastructure Monitoring.

The data collection from our VMs, containers, databases, and backend components is valuable.

Splunk Infrastructure Monitoring's data analytics can be improved by including suggestions for various types of continuous monitoring.

I have been using Splunk Infrastructure Monitoring for three years.

The network uptime and monitoring are great.

The scalability of Splunk Infrastructure Monitoring is excellent.

The technical support is good.

Positive

We previously used Datadog but it doesn't offer network monitoring features like CPU utilization or overall server performance, which Splunk Infrastructure Monitoring does, so we switched.

Splunk Infrastructure Monitoring offers more functionality and visibility, making it a better choice for handling cloud architecture compared to Datadog.

The initial setup was straightforward. One person was required for the deployment.

I would rate Splunk Infrastructure Monitoring 9 out of 10.

Splunk Infrastructure Monitoring offers automated, continuous monitoring and diagnostics, delivering real-time reports for all your data with enhanced functionality compared to other solutions.

We have 200 users of Splunk Infrastructure Monitoring.

Splunk Infrastructure Monitoring is the best solution for monitoring networks, parameters, CPU, memory usage, and network traffic cases. 

I use it for monitoring and troubleshooting the performance of cloud-native applications.

Providing comprehensive visibility throughout the environment, it monitors my system, enhances career performance, and offers insights into the user experience.

Troubleshooting and visualizing a cloud-native environment is made easy with Splunk APM. It provides complete visibility into software tools, swiftly monitoring business performance and applications.

It possesses the capability to conduct distributed tracing within our environment. This includes monitoring the speed of tracked access, extending from end users to the Internet, system, and network services, and supporting my software application. Consequently, it offers an end-to-end overview of potential bottlenecks.

Splunk APM has significantly enhanced our organizational efficiency. Initially, my responsibilities included tracking website application performance, managing applications, and handling license releases. Now, it provides real-time user monitoring, transforming the way I handle these tasks.

It significantly impacts our organization's telemetry data, improving operational performance and user experience. The platform provides insights into application performance and effective log management. Ensuring accurate tracking of all performance-related logs contributes to building up the application performance percentage with comprehensive data.

It contributed to a daily reduction of six hours in our mean time to resolve.

The most valuable features are troubleshooting and optimizing application performance. 

Another value lies in the resilience and quick recovery capabilities offered by the SIEM. It enables thorough monitoring across our landscape, providing insights into the number of running software applications. The tool furnishes comprehensive information across microservices, significantly enhancing our proficiency.

Enhancing system availability and optimizing service performance are crucial. It is essential for the monitoring tool to deliver quick response times when generating analytical reports, instead of prolonged delays.

I have been using it for two years.

It provides good stability capabilities.

It has the capacity to scale. There are approximately two hundred users and one administrator that use it.

I would rate its customer service and support eight out of ten.

Positive

The initial setup was straightforward.

The deployment process took six hours. During this time, a clear understanding was established regarding which technical applications—whether cloud-based, native, or others—needed monitoring and improved performance. These categories were identified in-house, with two individuals overseeing the process.

It allowed our IT staff to focus on other projects by freeing up their time. In total, it saved around four hours.

We evaluated Grafana.

It can serve as an analytical application for enhancing performance, ensuring all dependencies are effectively addressed. Overall, I would rate it eight out of ten.

We use the solution to do a lot of email checking. We also use the tool to monitor different embassies, server IPs and some of the teams.

Splunk Infrastructure Monitoring has helped our organization tremendously. We have onboarded Splunk for the last four years, and we have 30 to 40 contractors who use Splunk daily. The solution has helped not just a small organization like ours but the whole DOS (Department of State).

The solution monitors attacks or unauthorized access to the information we want to protect. There is a dashboard called ISSO that monitors pretty much everything worldwide. We also monitor almost 300 embassies and consulates.

The solution's machine learning deployment is hard and should be made user-friendly. Even if a team doesn't have a data scientist, they should be able to use the machine learning toolkit for monitoring purposes. The solution should include more algorithms and SPL commands that people can use.

I have been using Splunk Infrastructure Monitoring for four months.

We haven’t faced any issues with the solution’s stability.

Splunk Infrastructure Monitoring is highly scalable. We were able to do monitoring and some of the advanced analytics.

I have not contacted Splunk's technical support. We have contacted our account manager for issues, and she's been awesome.

We have different vendors who do deployments, which is different for the government than regular businesses.

We have seen a return on investment with Splunk Infrastructure Monitoring regarding the kind of threats we can identify.

Splunk Infrastructure Monitoring is an expensive solution.

Our organization monitors multiple cloud environments using Splunk Infrastructure Monitoring, which works well. This is the only tool we use, and we aren't considering moving or having additional tools.

It is important for our organization that Splunk Infrastructure Monitoring has end-to-end visibility into our cloud-native environments. Our job is critical and very sensitive, so having end-to-end visibility is really helpful.

Splunk Infrastructure Monitoring has helped reduce our mean time to resolve. Looking at the solution's dashboards has helped tremendously because we don't have to look at the individual index or events.

Our business is different from that of a private organization, and Splunk Infrastructure Monitoring has helped improve our organization's business resilience. The machine learning toolkit allows us to do clustering, and we have a couple of deployments on the clusters. That has helped cluster different events based on their critical or security threats.

We have seen time to value using Splunk Infrastructure Monitoring.

Splunk's unified platform has helped consolidate networking, security, and IT observability tools. We don't have to integrate Splunk with a different tool and worry whether those two will integrate. Having everything in one platform helps us create dashboards, alerts, and monitoring tools in one place.

Overall, I rate the solution an eight or nine out of ten.

We mainly use it for different divisions and departments within our company to keep track of our systems' health. We also ingest log files to get data and alerts for different groups.

We used to use a number of different tools before we were introduced to Splunk. We used to have a very hard time getting this data in and being able to effectively use it because we had such a massive amount of data. We also could not find a way to organize it effectively. Splunk helped us to effectively use all the data that we collect in a valuable way for different customers and groups that we have in our company.

It has definitely helped reduce our meantime to resolve (MTTR). A lot of our customers have difficulty getting to root cause analysis of different problems and situations. They also do not have the data to perform analytical responses for different problems that there could be within our industry. They are now able to use this data effectively, not just for alerting, but also for preventative maintenance.

It has definitely improved our organization’s business resiliency by a lot. I do not have the actual data to share at this time, but there has been a marked improvement in the organization. We are now able to keep track of all the raw data that we pull in and then use it effectively. This helps our organization run more efficiently.

It has improved our organization's ability to predict, identify, and solve problems in real time. We are able to use data and search for it effectively. We have different analytical forms and data that we can use to improve in different ways. 

The most valuable thing that we have seen within our group is the ability to ingest all this raw data and have it organized in a certain way so that different groups can get effective alerting from this massive amount of raw data that is out there.

A lot of customers had a hard time effectively searching within the data in Splunk. There is a learning curve from searches to indexes and using all the macros that we have created. It is a little difficult for somebody who has not used it quite a bit and does not have a lot of practice with it, but the AI features that we have been hearing about through Splunk will make it a lot easier for us to use human language to search this data. That is big. That is pretty powerful, and that will help a lot with our customers. At the Splunk conference, some of the talks have been about the AI platform and more effective and easier ways to search within Splunk through indexes and other things. These features will help correct some of the things with which we are having a hard time with some of our customers.

We have been using this solution for about four years.

We are not on the cloud. We are all on-prem. We have had certain issues with space on the servers and things like that, and while moving things up to what we need, we have not had any issues on the Splunk side.

It is great. We have not had any major issues with getting support from Splunk. With our monthly license, there are a certain amount of hours that we have with Splunk support. We are able to use it when we are getting close to the end of the month. In our meetings, we make a list of different topics that we would like to explore and discuss with Splunk. We create meetings for that, and they are always very helpful. We never had any issues in getting support from Splunk. I would rate their support a ten out of ten.

Positive

We used to use Tivoli. We also use AppDynamics in addition to Splunk for different parts, but we are starting to learn that Splunk does have a lot of similar toolsets. Splunk does the same as what AppDynamics does, and in some cases, there are more powerful tool sets that would help us. We are thinking of petering down our different tools to get into one tool, possibly Splunk. We already got rid of Tivoli, and we are using Splunk fully in place of Tivoli. We have seen a positive response to it.

We have seen cost efficiencies by switching to this solution. Because of the wider range of tools that Splunk offers, we were able to get rid of Tivoli and get rid of that licensing obligation on an annual basis. We are able to save a good amount of money on that and move that budget over to our Splunk budget to keep everything under one umbrella.

I was not involved in its deployment. I came on the year after.

We are currently on-prem, but we are working on developing and moving everything over to a Google Cloud platform. The announcement that Splunk is partnering with Google Cloud, in addition to AWS, is pretty good for us because we are working on moving over to the cloud in the next couple of years.

We have definitely seen an ROI. Our team is able to spend more time learning one tool as opposed to having to learn multiple different toolsets. Therefore, we are able to get more work done in a more efficient manner.

We have seen time to value using this solution. Our company has a very heavy push toward work-life management. Since we have been able to, especially in our group, switch to this tool, we could cut down on our on-call time and have our groups run on different patterns where people who are off are actually off. They do not have to be called in because essentially, everybody is able to access the tool and use it effectively because it is the one tool that we use as opposed to having different tool sets. Everybody knows how to use it, so it definitely has helped us in that way.

I know there was a panel and a team that was going through different tools. I was not a part of that process, but I know there were quite a bit of tools that they were looking at. Splunk must have worked out better than everything else.

I would rate Splunk Infrastructure Monitoring a ten out of ten.

Splunk Infrastructure Monitoring helps identify bottlenecks within the network domain, including issues related to server databases, application response times, and code. These problems can be resolved by our customers promptly.

It is easy to use. It offers a unique dashboard reporting tool called Ollie. Ollie is essentially an observability tool, and it's also referred to simply as "Ollie" for brevity. It's important to note that this product is agent-based only.

Splunk Infrastructure Monitoring helps improve the efficiency and performance of applications by up to 70 percent.

It has helped reduce our mean time to detect. It has helped to reduce our mean time to resolve by around 50 percent.

Splunk helps us focus on business-critical initiatives.

It integrates well with multiple sets of products.

The vibrant dashboards are valuable.

The main drawback of Splunk for network monitoring is its limited agent deployment. Splunk excels at collecting data from servers and databases where agents can be installed. However, it cannot directly monitor network devices, unlike Broadcom.

Broadcom offers Spectrum and Performance Management tools that primarily work on SNMP to collect data from network devices. Splunk doesn't have a directly comparable functionality for network devices.

While Splunk offers a wider range of data collection, including metrics, logs, and more, it can be more expensive. Splunk's licensing model is based on data volume (terabytes) rather than the number of devices. This can be costlier compared to Broadcom or similar tools, which often use device-based licensing.

The end-to-end visibility is lacking because Splunk cannot directly monitor network devices.

Broadcom provides a topology-based root cause analysis that is not available with Splunk.

I have been using Splunk Infrastructure Monitoring for 10 years. 

Splunk Infrastructure Monitoring is stable. 

Splunk deployment is simplified because it is cloud-based. The deployment takes no more than 15 days to complete.

Splunk's infrastructure monitoring costs can be high because our billing is based on data volume measured in terabytes, rather than the number of devices being monitored.

Replacing legacy systems with Splunk could cost up to $200,000.

I would rate Splunk Infrastructure Monitoring 7 out of 10.

The decision to move from another infrastructure monitoring solution to Splunk should be based on a customer's specific needs. While Splunk offers visually appealing dashboards and access to a wider range of data compared to Broadcom products, pricing can be a significant factor, especially in the Indian market.

Deploying Splunk for a customer can involve higher upfront infrastructure costs. This is because implementing Splunk effectively often requires writing custom queries to filter data and optimize license usage. While this approach minimizes licensing costs, it can be labor-intensive.