My main use case is for security, specifically for the SIEM aspect, as I work as a cybersecurity engineer.

We specifically use this system for security-related topics. We have a dedicated environment for Large Language Models (LLMs). We have connected our LLM, but our primary focus remains on security. When we encounter any incidents or need to gather information about connected IPs, we rely on established rules and alerts. We utilize the chat functionality of this LLM to generate queries in Kibana language.

My favorite feature is the ease of use, particularly in how you integrate the agent. I've been using it since version 7, and we're on version 9 now, and I've seen the progress from using Beats to using the agent, making it so simple today to enroll a server with the Elastic Agent.

Deploying the Elastic Agent internally is relatively straightforward; it only requires a few commands to be run on the server. However, to manage this deployment at scale, we needed to develop a solution using Ansible. This involved creating scripts to install, restart, and uninstall the agent. While I would have preferred if Elastic had provided an official solution for these tasks, they haven't yet developed one that addresses all the necessary aspects. As a result, we've taken it upon ourselves to create these tools internally.

There are two areas in which it could improve. One is the smoother enrollment process for 1,000 or 2,000 servers at the same time, rather than having to develop something internal.

The second topic is the actual support of YARA rules—it's Y-A-R-A, which is specific for security. As of today, this is not supported, and I've been asking for a while now; I'm unsure if they will ever release it.

I have been using this solution for at least four years.

I haven't seen any downtime.

It is really scalable. Since we're on the cloud, whenever we need to upgrade or add resources, they handle everything. It takes a couple of hours due to the amount of data we have, and I've never faced any issues during upgrades.

I have contacted technical support because we encountered issues when we started using the Elastic integrations, some of which were not finalized on their side. I had countless meetings with engineers from Elastic, including product managers and support engineers, to work on and fix the integrations we wanted to use. They have always been really responsible and responsive to my requests. Once, we had an issue with GCP, Google Cloud Platform, and they even sent us a complimentary five or six hours with an Elastic consultant to help set things up.

I would give them a nine out of ten because they are very responsive. They clearly know what they are talking about. I never encountered a situation where the support team didn’t understand what we needed.

The initial setup process took around a month.

What they need is to be more transparent about the actual setup of the cluster and the deployment process. When using Elastic out of the box, there is information that is not readily available, requiring users to dig deep into the documentation to truly understand how it works. If you're looking to set up the cluster automatically, it works well for testing purposes. However, when installing two thousand servers at once, if your deployment isn't large enough, it can lead to crashes. Occasionally, we have to delete the logs just to access the interface. Therefore, I believe they should provide clearer guidance on using the deployment manager effectively.

We started four years ago with 200-300 servers, and now we are at around 2,000 servers. The learning curve involved understanding how it works, doing labs, and the difference between Elastic Search and competitors. Elastic really helped with support; we had weekly sessions with engineers from their side to assist us in setting up.

Maintenance on my end is limited to updates. Since we are using Elastic Cloud, they take care of the infrastructure.

I am familiar with the pricing, as we negotiated it last year. Compared to other tools, it's fair. However, if we are talking with full transparency, Elastic pushes clients to buy the Enterprise edition instead of the Premium edition, and we don't see the value in that other than to spend more money more quickly. So, while pricing is good and what we expect to pay for this type of product, I'd love to finalize this concern.

We've tested multiple open-source tools based on Elastic before signing with them, including one tool called Wazuh that is built on top of Elastic. We've also tested the open-source edition of Elasticsearch where we manage the cluster and Splunk. Overall, I believe Elastic Cloud is still one of the best products out there.

I would rate this solution an eight out of ten.

We use Elastic Cloud (Elasticsearch Service), Kibana, Enterprise Search, and on-premise as in a cloud environment within our Bosch environment, and we have different customers using the search, ML, and other services.

One of our customers uses Elastic Cloud (Elasticsearch Service) Agents out of the box when their server is installed, and this captures the metrics from the different servers within their environment, giving a unified Kibana view in the form of dashboards and helping us to understand the different key metrics which are relevant for them. They also use Elastic Cloud (Elasticsearch Service) for their search and indexing operations, and they also use agents and Fleet as different integration options, and finally, they also use the MLOps for their Elastic Cloud (Elasticsearch Service) ML for their AIOps purposes.

We've got close to about 50-plus customers and we've got three huge clusters of Elastic Cloud (Elasticsearch Service) on three different environments, and customers are happy.

One of the best features that Elastic Cloud (Elasticsearch Service) offers is their wonderful documentation as the technical support is very helpful. Every time I have a doubt, it's very easy to go through the Elastic articles, and if I have any questions and raise a support case, the technical support team provides valuable insights and recommendations. Even if I'm not aware of them, it really helps to make the product experience much better.

The integrations and features of Elastic Cloud (Elasticsearch Service) are very much kept up to date, and there's at least one or more use cases suiting every single need. There's also good room for customization, as Elastic Cloud (Elasticsearch Service) understands that different customers can have different needs, allowing customers to add their own integrations and edit or update them as they wish.

There have been quite a lot of good outcomes since using Elastic Cloud (Elasticsearch Service); customers have been able to use their data much faster and more effectively, and it definitely stands as one of the best observability platforms. We are also looking at integrating Elastic Cloud (Elasticsearch Service) along with certain other observability tools and CI/CD tools to give an overall comprehensive experience to our customers.

Elastic Cloud (Elasticsearch Service) is highly scalable, giving great options to scale the solution for the customer as at the cluster level. I've seen customers being able to deliver their results or web pages to their end users in a much faster way, increasing overall productivity and usage of their respective products, therefore leading to more profits. Using other conventional methods have been costly, so Elastic Cloud (Elasticsearch Service) has been a very cost-effective solution, and most importantly, the scalability meaning that you can upscale or downscale or even auto-scale the solutions as per the need has really reduced unnecessary waste, helping in cost reduction.

I don't think Elastic Cloud (Elasticsearch Service) has any sort of disadvantages per se; most of the features are pretty good and up to date.

We have some cost-effective indexing as searches with Elastic Cloud (Elasticsearch Service), and there could be other ways where we can probably improve in terms of the design of documentation. Sometimes it gets tricky to navigate through the user manuals because there are different forms of links. For example, we are speaking about ECE 3.x and ECE 4.x, and there are different sets of documentation for 3.x and 4.x. Sometimes it gets tricky to navigate through the documents, and the links can be difficult to catch upon. The content is fantastic, but if there is a better way to navigate through the documentation, that would be really great.

Mostly it's related to some sort of sloppy documentation at times, and we also have operational complexity. For example, we have some cases where the resource consumption due to the JVM could be pretty high; these are design-level issues and have also been discussed in technical topics, and if these could be improved, overall, that would be great.

I have been using Elastic Cloud (Elasticsearch Service) for close to about five to six years.

Mostly Elastic Cloud (Elasticsearch Service) has been stable.

Elastic Cloud (Elasticsearch Service) is highly scalable, giving great options to scale the solution for the customer as at the cluster level.

Customer support for Elastic Cloud (Elasticsearch Service) is great, as I have mentioned in the past; they provide great technical support, and the support articles are great, and the technical team is really brilliant and smart.

Previously, we used Splunk and that's not really effective; it is effective in its own way, but Elastic Cloud (Elasticsearch Service) is more of an integrated solution that has a lot of benefits and provides more features than Splunk does.

One time I was stuck in a technical issue with upgrading our Elastic Cloud (Elasticsearch Service) cluster operator, and it actually happened to be a completely different issue. I was probably misguided thinking that the root cause could have been something else, so Elastic Cloud (Elasticsearch Service) support helped me to deep dive into the case. We've had a couple of calls together, a lot of diagnostics were reviewed, and eventually, we were set on the right path realizing that there could be something else actually wrong and not what I had in mind, and then they set me in the right direction providing the steps to properly fix that; I was quite impressed by the way they and their team handled it.

A lot of money and time have definitely been saved with Elastic Cloud (Elasticsearch Service); I do not have the exact metrics, but overall, we've had pretty good results and outcomes.

We also went through some open-source alternatives OpenSearch, Solr, as DataDog before choosing Elastic Cloud (Elasticsearch Service). We still use a few of the other solutions for different use cases, but predominantly, Elastic Cloud (Elasticsearch Service) has been the main use of our solution.

I've covered pretty much everything regarding Elastic Cloud (Elasticsearch Service) in our previous questions.

It's a great product; it has so many features, great customer support, and it definitely has all rights to fit into every single use case of your applications.

On a scale of one to ten, I would give Elastic Cloud (Elasticsearch Service) a rating of nine.

Our main use case for Elastic Search is primarily for application search and document discovery.

We built an application with APIs that make documents available for search to the enterprise and we store the documents as well. A typical flow would be when an upstream application delivers a document to us, and then a different application or different user looking for some documents comes to our application, enters the metadata for that document, which we use to search in Elastic Search to retrieve the document and then deliver that document to the end user.

The seamless scalability is something I see as among the best features Elastic Search offers.

The speed with which Elastic Search is able to search through all of the documents we place into it is quite remarkable, as we search through 65 billion documents in less than a second in most cases, on a constant consistent basis.

I find configuring relevant searches within Elastic Search platform very straightforward. Elastic Search is easily scalable.

The customer support for Elastic Search is quite good.

I advise others looking into using Elastic Search to think about the future of your platform and where you intend it to be in five years, and based on that, which version of Elastic Search best suits the needs of your platform. Additionally, jump into the AI products first as you're in the planning phase so that as you're filling out your data, the AI products and machine learning products can enrich the data real-time early on in the process, which will save you a lot of time later.

The overall performance of the platform, scalability of the platform and other additional features, especially when it comes to AI, really earn the nine.

The ability to change field types seamlessly would be a huge improvement for Elastic Search, and more seamless upgrades would also be a big improvement, especially with regards to upgrading between major versions.

The upgrade experience and inflexibility with fields keeps Elastic Search from being a perfect 10.

I have been using Elastic Search the whole time I have been at Optum since 2019.

Elastic Search is stable.

The customer support for Elastic Search is quite good.

I would rate the customer support a nine.

We previously used a self-hosted Elastic running on virtual machines, and we switched to Elastic Cloud on Kubernetes at the urging of Elastic Search itself, as well as an internal drive towards cloud-first technologies. The features of Elastic Search Cloud on Kubernetes seemed to mesh well with the overall goals of our organization.

My experience with pricing, setup cost, and licensing for Elastic Search is overall fairly straightforward.

I do not have any specific numbers on a return on investment, but I do have a general sense of the overall improvement of efficiency of the platform as we moved from on-prem hosted to Elastic Cloud on Kubernetes, where the time saved from maintaining the platform itself was significant.

My experience with pricing, setup cost, and licensing for Elastic Search is overall fairly straightforward.

We have tried the hybrid search capability, and we have seen overall fairly positive results, though we have yet to roll it out in production.

We have implemented a proof of concept using Inference APIs in our processes, but we have yet to release it into production.

To be clear, we are not on Elastic Cloud serverless; we are on Elastic Cloud on Kubernetes, running on the Azure platform self-hosted.

We have not utilized Better Binary Quantization, BBQ, in our operations.

On a scale of one to ten, I rate Elastic Search a nine out of ten.