My primary use case is for monitoring security logs and system logs. Apart from that, we create monitoring alerts and dashboards.

We also use it for Splunk application configuration, troubleshooting, and server patching. We have many other operations.

Integration with other systems and applications in the environment is easy. For example, we have Fortinet analyzer. We have to pull the logs from network devices into Splunk. We use Cribl pipeline.

For Cribl pipeline, we get that data to the Splunk syslog servers. From Splunk syslog servers, we're getting it into the indexes.

According to the license, suppose we have to onboard thousands of servers. Suppose a scenario, for thousands of servers, the user or client requires only specific events. So for that, we use props and cons and regex for specific events. And only specific events will be calculated in the license. That will consume the license also.

The incident response time depends on the query and alert configuration, and also on the environment and how the logs are streamed. By analyzing these factors, it takes a maximum of one to two days for one incident.

Alert scheduling, dashboard creation, and log monitoring are the most valuable features.

Federated search depends on the data we pull. We have three types of searches. We use federated search for long-running queries.

We have, like, 20% of MacBook Cloud environment. It is easy to monitor multiple cloud environments, but there are some onboarding challenges. We are onboarding from the back end and also using Hacktoken. Apart from that, we get data to Splunk using Cripple pipelines from Syslog servers.

Reporting is like this: if critical data is used by the client, we send it to the data user according to the schedule.

For log monitoring, we can definitely suggest Splunk is a good tool. And it helps with decision making processes.

For monitoring security logs, it's the best tool.

I use Splunk Cloud. Previously, I used Splunk Enterprise, but after that, we migrated to Splunk Cloud.

I have been using Splunk Cloud for more than three years.

It is a stable product. Right now, we are migrating from Datadog to Splunk, so I guess that's why Splunk is better than other tools.

It's deployed across multiple locations.

It does require maintenance. It depends on what Splunk vendor is being used.

The pricing depends on the logs and how many logs we monitor. On a daily basis, it depends on the events. Those licenses will be calculated in Splunk Cloud.

Overall, I would rate the solution a seven out of ten, with ten being best.

All the features for log monitoring, security, alerting, indexing of the data, parsing of the data are good. That feature makes sense and is helpful to everyone.

I would recommend it to others.

My role is in observability.

Some of our internal systems send data into Splunk Cloud. We had dashboards for our team's KPIs. We can check to see how fast the team reacts to events. Those reaction times a recordreed and sent to Splunk. From there, we can draw some dashboards. We can check to see who is doing well and who needs to improve. The power Splunk admins started moving into the Cloud.

The primary use cases are for team KPIs, log analytics, and error search. We would look for the relation of different events and draw dashboards to see how bad things were veering off from the timeline that we wanted to see.

Splunk helped us shape the picture of our team and enabled management to see who should be rewarded and who should be coached. It helped outline where KPIs were not being met. We could sit down and discuss what happened, and why it did not go as planned, and then we could make improvements in the processes. It helped us draw a broader picture of the entire team's capabilities.

With Splunk, everything is centralized, everything is in one place. We don't have to scramble and approach Splunk admins where to look.

In terms of networking, we managed to build good dashboards. We have a lot of firewalls and rules. If a new service comes up, if they don't have a firewall and nothing works, we can look at the Splunk dashboard and see the particular network flow and see if firewalls are blocking traffic. This is a Splunk function that people are happy and excited about. It shows us valuable information in an easy-to-understand way.

It's very important for us that Cloud Platform offers end-to-end visibility into our cloud-native environment. More and more functions are moving to the cloud, so it's not only for observability to see the system, but it's also for management and senior management to see that all of their applications are running as intended. If we try to spread out applications through multiple vendors, multiple regions, access groups, and whatnot, it becomes pretty important. It may become a challenge because of that spread. It brings resilience, but it also makes it more difficult to look after everything.

We want to achieve having everything in a single view. Senior management wants to make sure that everything is running well. The application team's developers want to have a granular review.

Splunk reduced our mean time to resolve by 30%. If an application starts misbehaving, we send logs to Splunk and check to see what's going on and see what's happening.

The dashboards are the most valuable feature. It's all of the information in one place. We can build it ourselves, so we can make it the way we like.

Since I work on data collection from external sources and send them into Splunk, I miss its ability to collect that data through REST API applications. I would like the ability to configure an endpoint, set it on Splunk, and set a schedule for it to pull information every ten minutes, and pull this endpoint information. I could search through it, look for keywords, restructure the data that's brought back to me, and then store it in the Splunk index. This is not available and if it is available, it is bare bones. I would like Splunk to have this function by default.

We started using Splunk seven years ago. We started with Splunk on-prem and then moved to Splunk Cloud.

I never had any stability issues.

I use support rarely but so far, it's been fine.

I would rate it an eight out of ten. My cases weren't that critical so it took a little longer to solve.

We have not achieved cost efficiencies by switching to Splunk. There will be some cost discussions in cost optimization.

We log a lot of data which may have impacted our licensing cost.

We also looked at Datadog but it wasn't cost-efficient to log with two tools.

We monitor multiple cloud environments. I heard that it's more straightforward to monitor multiple cloud environments with AWS. Azure doesn't work as intended, there were some issues collecting data from it.

I would rate Splunk Cloud Platform seven out of ten. I really miss REST API abilities.

We mainly use it for the purposes of analyzing application logs to get a bit of understanding of what is normal application performance and then use that to highlight errors and inconsistencies when they occur.

Resilience is incredibly important to us. We are in the medical field. It is insurance. When people are using our service, we should be able to provide that. Having that resilience is key for us because we are helping people. The resilience that Splunk offers has been valuable in that regard. There is peace of mind for us and our customers.

We have multiple cloud vendors that are being utilized in Splunk. It has been useful. Splunk is able to handle a lot of things out of the box. There is a good bit of value in being able to make sense of multiple types of logs in one environment and being able to cross-reference them. It has just taken a lot of effort out of that.

We have integrated it with other tools. At the moment, it has been with Cribl as a pipeline tool so that we can be agnostic with Splunk in some regards. Cribl handles the logs being sent to Splunk, and then from there, if there is anywhere else where we want to send them, Cribl can handle that too. That has been our main integration. The ease of integration varies. Splunk offers out-of-the-box support for some tools and applications. Integration with them has been quite simple. Other things have been a bit more difficult. Integration can be more difficult if it does not have a Splunk base, but there is a good range of things that are available out of the box.

Its reporting has been excellent. We have integrated it with tools like ServiceNow, so we are able to create an instance for teams and integrate it with our NOC. The reporting has been incredibly valuable.

I come from a monitoring background. I knew from the get-go the value that we could get from Splunk, but we actually started to see its value once we started enforcing logging standards. It made it very easy for us to validate if something was or was not following our standards.

It has been great from the compliance perspective. It began to show value to some of our customers when they were able to search multiple applications because of the standards and compliance built into it.

It has had an impact on the decision-making processes in our organization. It has been mainly around compliance. Given it is a financial and medical sector, decisions have been made around what information we are storing in the logs and how we are managing the data that comes directly from Splunk.

It has been good for helping our organization access data for compliance and privacy regulations. It has been useful for pinpointing things. We are able to ensure that we are abiding by those standards. It has been incredibly useful in that space.

Dashboarding has been very powerful. I work with a lot of different customers, so being able to tailor the data for different customers has been valuable. I am able to make visuals and have reports where they can self-serve.

It would be nice to see more comparisons between Splunk and other log management tools. There are some legacy tools that people are often coming off. It will ease the transition if you are coming off a Windows LogViewer or any other logging tool. Splunk could offer more advice on how to transition into it or onboard it.

I have been using this solution for two years.

I have not had any issues related to stability.

This is outside of my department, but it seems like it would be easy to scale up. However, there is a cost concern. That always seems to be the linchpin when people discuss Splunk. It comes at a cost.

When it comes to extensibility, they make it relatively simple, but it is an expensive tool. There are always going to be conversations that need to be had.

The quality of the answer has been good. We have had to leverage the support only a small number of times. We found the actual portal to get support difficult. Some members of the team were not able to raise certain types of requests. However, when we got through to support, we had no issues.

Prior to Splunk, we had a mixture of things. LogViewer and Graylog were used. Some folks had their logs locally. There was not one central system.

I was not directly involved in decision-making, but some of the things that I called out as useful were the analytical tools that Splunk offers. We can very quickly get to the root cause by using its query language. It provides a lot of power with little effort. That is what initially drew me to it.

Moving to Splunk allowed standardization. That is the key. It does not matter which part of the company you are from. Splunk has given us a mechanism to say that we expect the logs to look like this, and we all are going to abide by that. It has made standardization a lot easier. Previously, you would not know what you were getting while dealing with a logging problem.

I was involved in its deployment only in a small cluster. I was mainly involved in setting up standards around logging. It was challenging. It was dense, but it was manageable. The feature set of Splunk allowed us to know what we could or could not do.

The main part of maintenance is the ingestion of new logs. New teams and applications get stood up every day, or a new cloud vendor comes in, so there is some maintenance involved there.

We had Splunk technical support. We had a mixture of people from other departments. We had some folks from security, and we had some folks from operations. There were 15 regular faces and 2 Splunk contractors. We involved other teams on an ad hoc basis, but the core team had 15 people.

Overall, we had 20 to 30 people who directly worked with Splunk in some way or for some period of time. We also had to involve all of the teams to get their feedback and educate them on how to use Splunk.

I do not personally deal with that side, but from discussions, I know that it is one of the more expensive tools. I do not have anything to compare it with.

New users should focus on the Splunk free courses. They are an excellent resource. If you are a customer, you should take up the search and reporting classes. That is probably going to be what 99% of people are using it for day to day. If you are a sysadmin user or someone setting up the instance, there are free classes for managing licenses and ingesting data. I would highly recommend them. The free classes are a great start, and if you think it would be valuable, take some of the paid classes as well. They are incredibly detailed.

When it comes to security, we definitely have a stricter attitude when things are going to the cloud because they are not fully in our control. Going to the cloud is always a little bit scary, but we have put in a refined approach for the data going into Splunk.

I have not made much use of federated search. I have come across it, but it is not something I have leveraged.

I would rate this solution a seven out of ten. What it does, it does well, but I do have qualms with it here and there. There are obvious features that are missing from time to time, but I am happy with what is there.

We use the solution for application status alerting, user activities, and active directories. We use the solution for visualization, alerting, and analyzing events or incidents.

The most valuable feature of Splunk Cloud Platform is the alerting feature.

Currently, Splunk Cloud Platform is very easy to use and read. The solution's visualization for the end users is also good. However, setting up the solution or an alert is not straightforward. There's a lot of incompatibility and areas that you have to consider while setting up the solution.

All those things make setting up the solution very complex for regular people who know the business operation. So, they have to hire a third party or a technical person who doesn't understand the business to set it up for them, which usually creates a gap.

When someone who cares about the business and understands its operation sets up the solution, they would set it right. There's always a gap when a technical person or third party sets it up. It may lead to many workarounds to fix issues like alert fatigue or false security. Splunk Cloud Platform needs to be made more user-friendly because it's not user-friendly.

I have been using Splunk Cloud Platform for four to five years.

Splunk Cloud Platform is pretty stable, and I don't have any issues.

Splunk Cloud Platform is a scalable solution.

I usually go to forums and discussions to get answers to my issues. You might need a Splunk account username to talk to technical support. When most users I have talked to face a problem, they Google it. I don't know if the technical support would provide you with support if you were stuck.

I have previously used different solutions like DataStage, Datadog, Grafana, and ClickView.

We evaluated other options before choosing the Splunk Cloud Platform. But when a company buys Splunk services, the end users have to use what they have as a resource.

Splunk Cloud Platform is a really good tool for getting alerts and better information about incident management and maintenance. Because of the solution's complex setup, most alerts are set by developers or people who create multiple unnecessary alerts, creating alert fatigue. Compared to other systems, like Dynatrace, Splunk Cloud Platform is not a smart system for analyzing alerts.

As a project manager, I oversee the process of contacting the concerned parties, knowing what needs to be monitored and why they need the alerting mechanism. I was not directly involved in the scripting and adding Splunk Cloud Platform in the back end.

As business requirements change, Splunk Cloud Platform needs maintenance in terms of setting up different parameters, which is not an easy task.

Everybody uses the Splunk Cloud Platform in a different way. I would advise users to share their experiences about technical difficulties in the forums and community. Sometimes, others might go through the same problem without much documentation, and sharing your technical problems might help others.

Overall, I rate Splunk Cloud Platform a seven out of ten.

I was working as a DevOps engineer in India. I was working for the payments domain of a client. We were mostly using Splunk for monitoring the production, deployment of API, and traffic.

We had two cloud platforms. When I joined the team, we were deploying all our APIs in Pivotal Cloud Foundry (PCF). We then migrated to AWS Kubernetes. We were able to monitor both platforms in Splunk. When we migrated to Kubernetes, Splunk helped us. When we were having the transaction loss, we were able to find out which node was throwing the error. We were able to fetch the details according to the nodes in Splunk. We were using different keywords on these platforms for fetching the data.

We could create our own query, and we could create our own alerts for a particular API. We could also configure these alert notifications to be mailed to particular managers and owners. We could just go through the alert to check if the API was running well or needed to be fixed.

As compared to other tools, it is very easy. It is very easy to learn. It also integrates well.

The reporting features are very good. The dashboards are very nice. We could create our own dashboards to monitor any volume dips or transaction loss.

The search for bulk data needs to be improved. When we were looking for the flow, we had to search really hard. I wanted to request the Splunk team to add some features for better search because getting the flow of the bulk data was sometimes hard.

I have worked with this solution for almost three years.

It is stable, but we did experience two or three downtimes.

We had three or four monitoring tools other than Splunk. We had AppDynamics, Grafana, and others, but we were mostly concentrating on Splunk because we were able to fetch all the details from a particular transaction using Splunk. We were able to create our own dashboard so that we get alerts regarding errors or transaction loss for the customer. The most useful thing was that when we were fetching details from a payment ID or a grid, we were able to track the complete workflow for that API. We were also able to fetch the details about whether the issue was in our team or the external team. We were able to track that very accurately using Splunk.

It is not that complex. We just need the knowledge. We just need to know how to query the alert and set up dashboards. As compared to AppDynamics and Grafana, it is a lot easier.

Our dev team could set up a dashboard and deploy everything in two weeks.

It is not that expensive.

If the company is working on API-based deployment and API-based developments, then I would recommend Splunk. It is useful for tracking the flow and fetching the data.

Overall, I would rate it a seven out of ten.

I use Splunk on my phone, on-premises, and for the automation tasks that we carry out.

We use it to work on dedicated forms and infrastructure and have a lot of virtual machines and instances that are being run for every single application. Our infrastructure is purely based on Azure by Microsoft.

Keeping CMDBs of all the virtual machines is a heavy task. When you use it for your portal use, it might be two or three virtual machines. When a virtual machine is created, we use post-provisioning inside the virtual machine. While post-provisioning, we install Splunk agents so that any activity that is happening inside the VM is virtually monitored by Splunk.

We create a dashboard. We are able to monitor everything from that dashboard.

Splunk also offers enhancements and automation. Splunk plays a major role when it comes to automation. We extract the data from Splunk, and then we use it to automate using a jump server so that we can put in actions on any number of virtual machines.

The automation is the main advantage. When we need to search for data, as engineers, it's very easy.

I like that it's an independent cloud platform. It can work with AWS or Azure.

Its monitoring is completely automated. We do not have to put in other engineers just to maintain Splunk. It maintains itself, and it's very user-friendly. For the dashboards to be created or any sort of code that we want to do with Splunk, we can do it by ourselves. We do not need to have separate resources so it is very cost efficient. We do not require many people; it's resource-efficient as well.

We do use the federated search feature and find it helpful. Earlier, it was hard to withdraw data. We'd have to maintain it. Now, Splunk does it for us. It's a very time-efficient service. It's made a huge impact on automation. We can grab data in real-time any time we need to.

The solution integrates well with other applications and systems in our environment.

It could have a more efficient UI. If they could integrate more AI and make search more efficient so that other people can access and use it, not just engineers, that would be ideal.

It needs to mature; it's just getting established in the industry on a wider scale.

The API still needs some enhancements from a post-performance point of view.

From a monitoring point of view, Splunk is doing very well. However, if they could provide a post-provisioning aspect. Right now, we have to install a monitoring tool while we are post-provisioning every virtual machine. If they could be a provider that precluded having a virtual machine being created or provisioned, that would be ideal.

Alerting could be faster. Sometimes the actions that happen take some time to reflect on the Splunk dashboard. There is still latency. Especially when you work in a multi-cloud environment, you deal with a lot of regions. They still need to focus on availability across regions.

They need to have some security enhancements. Most users are using it with other single sign-on features like Okta. If they had their own SSOs that would be ideal. we'd be able to work independently. Right now, we have to log onto the virtual machines then move to Okta, then go to Splunk.

I've been using the solution for somewhere around a year or one year and a half.

The stability is okay. Sometimes it goes down. I have not witnessed that as I do not use it continuously after the deployment. The resiliency is good. I'd recommend it four out of five.

Everyone in the company uses Splunk.

The scalability is very good. It's extendible.

I don't directly deal with technical support. We have a dedicated team that would work with Splunk.

Generally, my understanding is that if we have a query, we raise a ticket. There may be a separate portal or mailbox we can access as well to get assistance.

We previously used Qualys. We switched mainly due to the costs involved. We also didn't want to migrate our resources to it. We simply wanted a monitoring tool, which is why we chose Splunk. Splunk in comparison is really cost-efficient.

I was involved in the deployment of the solution.

Whenever a new resource or a new agent comes into the picture, in an organization, it's always complex. I don't blame Splunk for it, or my firm. It's like two pieces of a jigsaw puzzle and it's the developers who need to cut the pieces. It works really well as of now.

The deployment took somewhere between six to eight months.

We did need a lot of resources or staff members for the deployment. We have a vast infrastructure. We have a dedicated team inside as well who manage incidents and tickets using platforms like ServiceNow, and we still have a lot of resources dedicated to maintaining Splunk. The number of resources that are required to maintain it is more than the number of resources we use for development, actually.

How many people you need depends on the region. I work for Asia and North America. So for us, it was not much personnel. We needed four to five people in the development. There were somewhere around ten to fifteen people working on different parts.

About 90% of the deployment was handled in-house.

I'm only aware of general pricing terms, however, they have enterprise agreements as well. I can't speak to the exact cost. It's reasonable, from my understanding. I'd rate the affordability seven or eight out of ten.

Evaluating other options would be a task reserved for the highest management personnel at our firm. I was not involved with that process.

We aren't using the solution across all cloud platforms. We use Azure. However, we would have the flexibility to gather insights from others. We just don't use that particular capability.

Right now, the solution does not affect our decision-making. It's still a very new platform. We're not relying on it completely. It's a work in progress. We need some time with it, to build up trust with it. Splunk is great so far, however, we still need more time and it needs more of a presence in the market.

Right now, in terms of compliance and privacy policy regulations, we limit the features that are not compliant with us. However, they are very flexible. We just use the features we can and block the ones that are unnecessary.

It hasn't had an impact on our security posture. We have very detailed security layers and several processes and teams. We haven't had any real use cases for Splunk. It hasn't actively blocked anything. We already have what we need in place.

I'd advise new users to check if this solution is reliable from a security point of view. Talk to Splunk about the cost as well. Splunk is really convenient for that. And whenever you deploy it in your infrastructure, make sure that the cloud providers or the on-prem solution that you are using are compatible with Splunk. We had issues in that some features that we were using in the cloud were not compatible with Splunk. So we had to make a lot of changes. That is something anyone who is trying to deploy Splunk needs to check - compatibility.

I'd rate the solution seven out of ten.

We are primarily using it for InfoSec, cybersecurity intelligence, information gathering, and forensics. We also do a little bit of application performance monitoring for some appliances that can only be monitored through log ingestion.

We are starting to monitor multiple cloud environments. We have our internal cloud, and we are migrating to AWS. We are engaged in that path. In terms of monitoring, it is more or less the same because we are using the same integration pattern, which is to use Ivy folders and gather logs. We use it at its minimum, but the way I see it at the Splunk conference, we can go further. Will we go further? That is a million-dollar question.

It has end-to-end visibility into our cloud-native environment. For sure, it is important for operation and application support, but we need to embark our staff and management for that. They are the ones who are committing big dollars to that.

It has not reduced our mean time to resolve because we are using other tools as well. We are aiming to go on that path in the coming months.

It specifically has not improved our organization's resilience. There are a myriad of modern tools that we are implementing. Splunk is one of them. It is one of them helping us.

Index Manager is most valuable because we do not have to bother about internal storage. It is all managed by the Splunk team.

The security connection should have a seamless integration. Other than that, the way we are using it, so far, it seems quite good.

We have owned Splunk Cloud Platform for the last year and a half.

The stability of the solution is quite good.

We had challenges with the sizing of the cloud tenant that we purchased, but that was based on past decisions, so we are stuck with that until our next move. That should come in the next year. At that time, we will resize the tenant in a more efficient way, so scalability does not apply because the tenant we bought is a closed one. There is no scalability on either side. I learned that after the fact, so I am not impressed because we did not buy it. I guess people who buy that type can have good feedback on scalability.

We migrated from an on-premise solution that we had for about three years. We saw cost efficiency when we went from on-premise to the cloud, but I do not manage the budget.

We are using Dynatrace in parallel. We used Splunk as a cybersecurity tool, and we embraced Dynatrace a few years ago. So far, Dynatrace does a great job. Splunk is closing the gap. With today's announcement at the Splunk Conference, they are catching up. We are also using Microsoft SCOM, so it is a trio. It helps us do a better job.

I was not involved with the setup of the on-prem one, but I was involved with the migration to the cloud. My experience was interesting because I started from zero, but with the help of Splunk's professional teams, we could achieve our project. On a personal side, it helped me to gather the knowledge that brought me here at the Splunk conference.

The setup is always challenging. We had four or five people involved in the migration. We also involved a lot of key players in application migration. We had 20 to 30 people involved at some point in the migration path.

We used professional services.

We have, for sure, seen an ROI with Splunk. Our DevOps team is able to gather faster answers to their questions. Obviously, it brings value, whether it is Splunk or any other tool.

We could see the ROI in a few months. We gave time to our DevOps specialists to embrace the solution and get used to it. From there, as they made their own usage and use cases of the tool, it gave them speed to achieve what they were looking for.

I would rate Splunk Cloud Platform a seven out of ten.

We use it for IT security and observability.

We did not have anything prior to this that could perform the same function. Previously, if we needed to trace a security event, we had to search across logs on multiple systems to figure it out. Since Splunk, we have got it all in one place, and we can dashboard that out and save searches.

It has reduced the time for root cause analysis. It gets us to the logs quicker, so it has reduced our mean time to resolve (MTTR). The time saved is entirely dependent on what the problem is, but it shaves a good hour or two off the initial investigation per incident.

It would improve our company's resilience if it was used effectively. It has helped the technology teams that do use it improve their business resiliency. It needs either evangelizing or being made more accessible to the front-end teams or departments that do not use it today. That is largely on us. We can do that in Splunk, but there is a never-ending list of things to do, and a part of that is building Splunk outs so that we can provide that centralized logging, and then give users access to it while maintaining the privacy of their data within our organization.

We have probably not seen any cost efficiencies. The benefit of any cloud platform such as Splunk, AWS, or Azure is that you do not have to look after it, but you pay a premium for that. For example, for VMware, you pay a premium for vCenter, vSphere, etc. You can do the exact same thing with OpenStack, but you need to hire five people to look after it versus two people for VMware. You pay for Splunk Cloud, but you run into other challenges. You do not own your data anymore because it is now stuck there, and you have to export to AWS, and then rehydrate into a different Splunk instance if you want to get access to it, or you pay through the nose for the data or retention history. It is horses for courses.

Do you want to host it yourself and save money on the OpEx but spend more on headcount and CapEx, or give it Splunk Cloud and spend more CapEx, but save money on CapEx and headcount? I prefer to have it on-prem. I prefer to go down the CapEx and headcount route because it gives me more control over my data, and it gives me more flexibility of my data. It gives me easier access to troubleshooting when something is wrong. It gives me easier access to scaling when we are seeing performance issues. I can bulk my hardware. It does not lock me into Splunk Cloud Platform. I know that Victoria promises some improvements around that with being able to manage my own applications and being able to have auto-scaling on search heads, but I will believe that when I see it, and I have not seen that yet, so I would personally prefer to put money in somebody pocket and food on their table than to give money out to a cloud provider.

I do not really like it, but being able to correlate events across platforms in a single place is valuable. I can trace an event back to its root cause. I can find the root cause instead of just looking at the symptoms across different things.

Its stability and performance can be better. Very rarely does a day go by when we do not see an error in the console, such as a health check error. Because it is cloud-hosted, we do not have access to the backend to figure it out ourselves. We are reliant on their support to figure it out, and a couple of days later, the error comes back or it is a different error. It is a never-ending cycle of support tickets. Their support is also not great.

In terms of performance, we are on the classic version of Splunk. We are not yet on Victoria or the new version, so we do not get auto-scaling. Therefore, we are limited. 90% of the time, Splunk is not doing anything. It is just reading logs, and 10% of the time is when we need to use it, but when we actually need to use it, there are five or six different teams trying to use it at the same time, and there are speed issues with search.

I have been using this solution for about eight years.

I could not interact with them very much, but I have people who do. It is not often a pretty experience. From what I understand or from the complaints that I hear, you are often told that this is not a problem or you have done something wrong, and then magically, it manages to fix itself an hour later.

Before Splunk, we used distributed instances of Elasticsearch, Logstash, Grafana, and Graphite. This was ten years ago. Splunk was in its early days. Everybody had heard of it, but it had not become apparent why people need something like Splunk, so people had been building their own little instances. A lot of that still exists today in the organization because of the Splunk pricing model, the performance issues that we have on Splunk Cloud, and the stability. People want access to their data, but they also want to own their data. They do not want it to go into the black hole that is Splunk Cloud, so they keep it on-premises. They keep it in their own systems, such as Elasticsearch or Logstash, mostly because they can maintain sovereignty over data.

When compared to not having anything, we have seen an ROI. If we were going into it today, and that today was ten years ago, I do not think I would be at this Splunk conference. I would probably be at an Elastic conference and an Open Compute conference.

The value is definitely there, but it needs more performance around it. It needs to be more responsive. The value is definitely there in terms of a centralized point of visibility, but this value is provided by Splunk, as well as all of its competitors. Splunk potentially suffers from the same problems as ServiceNow, which is, if you want to do something clever with your data, you need a Ph.D. in data sciences to figure out how it works. It is hard to put in front of end-users who do not necessarily want to do something clever with their data. They want to be able to link it to the tools that they are familiar with.

It is a touchy subject because we are locked into it. That goes back to the rehydrating data. We cannot have the retention that we want to store for legal and compliance purposes because that is seven years' worth of data for some of the indexes, so we ship them off into S3 buckets and install them there, at which point they are invisible to Splunk, so we have to rehydrate them, but we cannot rehydrate those pockets into Splunk Cloud. We have to rehydrate them into a self-hosted version of Splunk, which can take days to set up and get going. I would not call Splunk's licensing and pricing predatory, but they have made it very difficult to maintain the independence of your own data.

There are a few solutions out there that are similar to Splunk. You can get something similar with CloudWatch, BigQuery, Azure Monitor, and Azure Sentinel. In the cloud, Azure Monitor for the analytics platform and Azure Sentinel for the SIEM platform are the biggest competitors of Splunk. When you put dollars next to them, they all cost about the same at the end of the day. I probably would not trade Splunk for another cloud provider or another cloud-hosted solution.

We are heavily AWS compared to every other cloud. If that was not true and we were heavily Azure, I would probably move everything to Azure Monitor and Azure Sentinel to get that single ecosystem, but we are not going to live in that world. I also do not like AWS CloudWatch, so we are not doing that. On the cloud-hosted side of things, Splunk does not really have a competitor out there. Despite being very mature, Grafana is not as convenient as Splunk, but Splunk definitely has on-prem competition. Ten years ago, everybody was itching to get to the cloud. Everybody was pushing everything to AWS. It was like, "We have got to go to the cloud. We have got to be the first. We have got to be hybrid." Now, everyone is like, "I can do this cheaper in my own data center and have more control over it and not go offline every Friday when AWS East goes down." The competition for Splunk Cloud is with Splunk on-prem and probably Elastic on-prem, which is significantly cheaper and offers 99% of the same functionality.

In terms of Splunk's ability to predict, identify, and solve problems in real time, if this capability exists, I have not seen it.

We monitor multiple cloud environments with it. We also have the on-prem environment and a lot of SaaS providers. We are largely dependent on the people who are deploying to the cloud. They are configuring their services and their platforms to talk to Splunk. We provide Splunk as a centralized service, but it is largely up to them whether they consume it or not. Some departments are eager to get in there so they can get visibility. Some want to build their own little greenfield internally, and some have not reached the maturity of realizing why they want it.

I would rate it a six out of ten. We have frequently run into many performance problems with it. The search is slow. We cannot scale it. We cannot troubleshoot it. We cannot get access to some of the functionality that we wanted, which is changing because we are moving to the new version. We also want to be able to manage our own applications. We are just locked into this parted sandbox, and we send our data off to it, and all of a sudden, it is no longer our data because it is trapped in the Splunk cloud. If we wanna get it out, it is going to cost us money. Their support is also not great, but it does provide single-pane access to data from a whole bunch of different places.

On Splunk Cloud, I mainly look for errors in applications or issues that come up with our internal applications. I have also used it to create dashboards and display customer data to customers in an effective way so that they have insights into their data.

There is less overhead now for infrastructure management. There are fewer issues that we have to worry about on the infrastructure side. This has freed up more of our resources' time to work toward initiatives on the Splunk platform itself. It is hard to measure the time savings. If one resource was working on it, that resource could save anywhere between 15 to 20 hours a week.

It must have reduced our MTTR, but I have been with Splunk for as long as I have been in my current environment, so I do not have anything to compare it with.

It helped improve our organization’s business resilience. The solution helps us find where errors are and potentially where threats are a lot faster. We can more effectively push out alerts not only to our team but also to the teams across the enterprise. It is nice to have on hand.

It is quite effective at helping us identify problems very quickly. We do not participate in real-time searches within our Splunk environment, but close to real-time is possible, and it is quite effective.

Not having to manage Splunk Cloud's infrastructure is valuable. Being able to deploy within the cloud and not having to manually manage our configs on the infrastructure side and set up our own architectures has been the biggest help.

Other than that, the new Dashboard Studio has been a pretty big win, but I do not know whether that is more cloud-specific or not. Dashboard Studio has a cleaner look for customers that want to see their data but not necessarily search. For the customers that want to see their data, having an easy and effective way to drag and drop to see where things are going to be if they want to change them has been pretty beneficial.

They can streamline the process of creating custom apps. I do not have a lot of experience with it. It was not very difficult for me to do so, but there is probably a better way to present the ability for people to push their own custom apps to the platform and go through Splunk's manual and automatic reviewing process.

I have been using this solution for about three years.

I have not seen any downsides when it comes to uptime and availability. Being in the cloud reduces downtime, especially compared to being on-prem where if something goes wrong, you will have to go in and fix that infrastructure yourself. I have not necessarily seen significant downtime with Splunk Cloud or on-prem at this time.

I quite enjoy the fact that if we need more indexes or search heads, it is very easy to plug and play with Splunk Cloud. With the infrastructure model that we had before, we would have to go in, set up a new search head out to the cluster, and add a new indexer to the cluster if we needed it. It will have more benefits going forward as we move more and more into the cloud.

I have worked with Splunk support, and I would rate them an eight out of ten. It depends on where you are and what project you are working on at the time. It would be quite beneficial to work with them if you have a specific project that you are working on, and they have some insight into it. I do not work with support too often myself. Usually, one of our Splunk Infrastructure managers works with them, but there is always room for improvement. Availability in terms of making the time to gain insight into specific projects and problems that we are having is an area that can be improved.

My company has been with Splunk for quite some time now. We are well integrated at this point, and we are in the process of migrating over to Splunk Cloud specifically. We used Splunk on-prem for a while. We are currently in a hybrid situation, and we are making our way toward being completely on the cloud.

I help from time to time with the migration process, but I am not necessarily in charge of the total migration functions that we currently have today. The most I have done in terms of deploying to the cloud was creating a custom alert action for the cloud environment, which is one of my biggest contributions so far. I am not completely in charge of it, but from time to time, I will assist in the migration process. It is a bit of a learning curve, but once you get more and more familiarized with the cloud and how to benefit from it by using features like federated search, it becomes easier. It is somewhere in between in terms of complexity.

We would have seen an ROI. I do not have a specific number, but assuming that we did not have Splunk Cloud, we would have to manage our own infrastructure. Not having to manage nearly as much infrastructure and not having to have the personnel to manage that infrastructure on a regular basis, frees up that time for them to do what they are really designed to do. This has definitely added value.

I am a little bit familiar with the pricing and licensing model. I am not sure about the particular pieces of the actual price that we have, but I do like the idea of going towards a more CPU-based approach rather than the ingesting approach. This CPU-based approach gives us the ability to ingest more data if we need it.

The biggest value that I get from attending Splunk conferences is the insights from everybody here. You have people from many different companies doing very different things and deploying very different models within their different Splunk instances. You get an idea of where everybody lands and maybe grab some ideas that you would not necessarily have thought of by looking at it from the inside of someone who is in a completely different field than you are.

There is definitely a big difference between Splunk Cloud and on-prem. For me, one of Splunk on-prem's biggest features is being able to deploy my own custom applications internally, which is something that is a bit of a process with Splunk Cloud. So, given the information that I have, I would rate it a seven out of ten.