Elastic Search Reviews

I have implemented Elastic Search in my organization. My experience has been really good with Elastic Search regarding the dashboards and alerts. They have integrated AI/ML capabilities in it. The Attack Discovery feature helps to dig into incidents from where they occurred to determine how the incident originated and its source. It gives an entire path of attack propagation, showing when it started, what happened, and all events that took place to connect the entire cyber incident.

Another feature is image vector analysis, which can authenticate images to prevent impersonation frauds in the ecosystem. This is a major use case in personal information and identifiable information portfolio.

I'm using Elastic Search as an observability tool and a SIEM tool. The indexing, searching, fast indexing, alert mechanisms, and BCDR compatibility are pretty smooth with Elastic Search.

On the resourcing part, I have cut off a good amount. While I don't have a concrete percentage to mention precisely, it has reduced resources to some extent.

Attack Discovery is the first feature that I appreciate. It is truly an amazing feature for any SIEM to have inbuilt. The image vector analysis is another feature that identifies any manipulation done to images. It can authenticate and identify authenticated images. If there are 10 duplicate and forged images, it can identify them through vector-based searching capabilities. These two features are prominent in terms of SIEM capabilities that Elastic Search has.

I can share feedback from the SIEM perspective about Elastic Search, as I had evaluated Elastic Search, LogRhythm, QRadar, and Microsoft.

More AI would be beneficial. I would also appreciate more simplicity in dashboards. A comprehensive dashboard is something I could expect.

I have been using Elastic Search for a year now.

There are no limited parameters to search from the events perspective. When you put one keyword, everything related to that keyword in your ecosystem will showcase all the results. This helps to get into the granularity of any events happening across the system.

It has gained significant visibility. Comparing alert statistics from other SIEMs where they could trigger 50 alerts on average weekly, Elastic Search has given me alerting statistics of roughly 90 plus for a week's time. All those alerts are mapped to MITRE ATT&CK framework. Though it could result in false positives in the earlier stage until you fine-tune and streamline the use cases in your SIEM, which is common with all SIEM tools, the visibility that Elastic Search has given us is amazing.

It was a direct purchase.

Positive

We previously used an on-premises solution.

The setup complexity depends upon the engineering team doing the implementation and the kind of infrastructure you have where logs will be ingested into the solution. For us, it was time-consuming in the earlier stages, but it was manageable and not overly complex.

We have seen moderate returns on investment.

As a CISO, I review and do the governance part. I receive alert notifications, but I don't work directly with the tool. None of my team members have complained or proposed any feature changes or modifications to the existing solution.

It totally depends upon the nature of business you are in. For my organization, it was imperative to have image scanning in place and identifying frauds happening with PII. From that perspective, Elastic Search has played a vital role. It has good inbuilt EDR capabilities as well, making it a good-to-go tool.

I rate Elastic Search eight out of ten.

On-premises

Other

I work in a gaming company where we handle a lot of microservices, observability, monitoring, and metrics. We aggregate all our logs to Elastic Search for troubleshooting across different environments including production, staging, and dev. We use Elastic Search to give us insights and to conduct a lot of troubleshooting.

We decided to go with Elastic Search because of the ability to aggregate everything into one portal where we have access to our entire infrastructure and the correlation about observability and traces. I have used competitors, but we are not using them in the production environment; perhaps on lower environments, but for production, we use Elastic Search.

One thing I appreciate about Elastic Search is the ability to aggregate everything into one dashboard, so I can have monitoring, logs, and traces in one portal instead of having multiple different tools to do the same.

Normally, if you were to use Prometheus, you need to know the Prometheus query language, but with Elastic Search, it gives us the ability to use normal human language for queries. It is very intelligent when it comes to querying. Unless you want to search something in depth, I find it very user-friendly.

I think hybrid search, which combines vector and text searches, is very effective because a developer or platform engineer does not need to spend time learning how to do a query. They can log in and use the standard query language to query a specific log, for example.

The initial deployment of Elastic Search was very easy for our instance because we just needed to enable some annotations for it to start getting the logs. We only needed to do a very minimal deployment on our side. The advantage we had is we had already deployed templates, so we did not need to configure each and every microservice. Once Elastic Search was there and we were able to push the annotations to our deployment, everything came alive.

I think the biggest issue we had with Elastic Search was regarding integrations with our multi-factor authentication tool. We had a challenge with the types of protocols that it allows. Sometimes you find it only supports one or two, and maybe we have a third-party tool for our MFA, so we are limited in how we can do integrations and in terms of audit. Since we are in an environment where we need to be compliant and have all our audits done, it is very hard to audit access logs for Elastic Search. I do not know if that has changed; perhaps we are still on an older version, but that has been the major issue we have experienced.

When it comes to updates for Elastic Search, we might need to push updates, for example, when they have a security patch that we need to enhance or add into our deployments. We do this in the lower environments for staging and then promote it into production. There is not much ongoing maintenance that requires any sort of downtime.

Elastic Search gives you quotas, so you are able to monitor your quotas and know when you are about to fill them up and maybe expand or tighten on your logs. Internally, we try not to have alert fatigue, so we only do important logs and queries, and we rarely have any sort of lag.

Elastic Search is very flexible when it comes to scalability. Being on the enterprise license, it is not really a big issue for us because we can increase the number of quotas we need depending on the logs we want.

For Elastic Search, we have never contacted any support. I appreciate the way they do their documentation and blogs. As a technical professional, before I reach out to support, I have to do my own troubleshooting and research; unless it is something that I cannot resolve, that is when I will probably raise a ticket. In the recent past, we have not raised any specific ticket for Elastic Search.

Before we migrated to Elastic Search, we were using the open-source tools Grafana and Prometheus for logs, but we had to have another third-party tool to do tracing such as Jaeger, or have Sentry to do database logs.

The initial deployment of Elastic Search was very easy for our instance because we just needed to enable some annotations for it to start getting the logs. We only needed to do a very minimal deployment on our side. The advantage we had is we had already deployed templates, so we did not need to configure each and every microservice. Once Elastic Search was there and we were able to push the annotations to our deployment, everything came alive.

The deployment of Elastic Search was done by our DevOps team, because I am part of the DevOps team. Our technical lead was mostly involved in terms of authentications and API key setup. From my side, it was easy for me to enable the annotations on the deployment and commit into the repository and push the changes to it. It was a team effort at different levels.

I would give Elastic Search probably an eight because there is always room for improvement. In IT, everything keeps evolving, and AI is here, and probably tomorrow something else will come, so they will need to elevate their game. I give it a general rating of eight, which for me means it is working perfectly, but it can always get better; there is always something to improve. My overall review rating for Elastic Search is eight out of ten.

I use Elastic Search, and from time to time I use it, but most of the time I am a system administrator. I deployed it more than using it. At the beginning, I was a system administrator, responsible for the deployment and maintenance of Elastic Search clusters. For a few years now, I have started to use it more because the end users are rookie users. They need a lot of help to be able to use Elastic Search effectively. I started to be a user approximately five years ago.

Today, at least, we provide a global, unique Elastic Search cluster for the whole company, and all teams store their logs inside, their traces, and their APM traces. Teams use Kibana to display information. We also use Prometheus exporters to collect metrics from the logs. We execute some query DSL over Elastic Search to collect metrics, which will be injected in a time series database like Prometheus. This is the main usage. We store metrics, logs, and APM traces.

The deployment of Elastic Search is excellent. I like Elastic Search very much for that. I say regularly to the team that Elastic is elastic. It is really difficult to break. This was not the case a few years ago when I worked with Elastic Search version one and version two. Starting with version six of Elastic Search, it started to be really strong. Today, in the past, the main issue was about the data and the volume.

At the moment they integrated lifecycle policy for indices, ILM, Index Life Cycle Management. When it was created, additionally to the data stream, it started to be really easy to have all the same index volume. It is really easy to administrate and to balance data between data centers and between data nodes, and to keep the same everywhere. It is very nice. It is my favorite feature of Elastic Search. It is so easy to manage. Also, maybe because we used it for a long time, we started to be comfortable with all the setup and the node type, and how we should manage our cluster to make it resilient. I think it is really easy to maintain comparatively to some other databases.

To be honest, there is only one downside of Elastic Search that makes sense because we use a basic license, which is a free license. We do not have some features available because of the free license. Except for that, I do not have any complaint. It works perfectly. It is pretty easy to administrate and to use. I do not have complaints, to be honest, except the fact that we do not have all features available such as the APM service map or alerting.

We are not able to use a provider like Sentry, Slack, or PagerDuty. We are forced at some point to generate metrics from the logs in order to use our alerting stack in Prometheus, which works. It is an open-source project which allows us to generate alerts to Slack, PagerDuty, and some third-party tools without any license. However, it is not doable with Elastic Search in the open-source version. The alerting part is the most complicated part to manage because of the license.

From time to time we have some JVM, Java Virtual Machine issues with Elastic Search. However, it is more linked to users' requests. From time to time, people ask Elastic Search to search inside one year of logs without a nice query and without any filters. This is clearly not doable and some nodes will crash. This makes sense. However, Elastic Search is really stable when we do not have this kind of request.

Elastic Search is the perfect tool for scalability. You just need to deploy new nodes. They will be able to join and reach the cluster really easily. I appreciate it for that as well because today at VP, we use Terraform to deploy our infrastructure. All Elastic Search nodes are managed through Terraform. If I need to extend my data node or my ingest node or whatever, I just need to deploy new nodes with the same setup, and the node will join my cluster, and it will scale horizontally really easily.

I have never had to contact the technical support of Elastic Search.

For logs management, I have not used any alternatives or something similar to Elastic Search. For APM as well, there was a plan in the past to try to migrate to Grafana, the Grafana open-source platform for APM traces using Tempo. Tempo is a Grafana Labs project. However, we decided to keep Elastic Search for that, so we do not have any other tool or similar tool to accomplish that.

Maybe just one, it is about error tracking. We can track errors with APM inside an application, and currently we use Sentry, which is not just an error tracking platform, but also about performance management. However, we use it only for error tracking. It is more useful for developers at the beginning of a new project. Most of the time, they prefer to be connected to Sentry more than APM in order to track errors. When the project will be in production, they will be more focused on the performance than the errors. At this moment they will start to use APM, Elastic Search APM more than Sentry. We do not provide any performance indicators. Sentry is also able to manage performance metrics, but we use it only for errors and everything related to performance has been disabled.

I think the pricing of Elastic Search is really, really expensive. The main point is that we do not get any license. I tried in the past, a few times, to contact the Elastic Search team to get a quote, and it was so complicated each time to get a quote because of the volume and the number of nodes. We are a big company at VP, so we have a lot of nodes, more than one hundred. For sure it was so expensive. They tried to tell me about the enterprise mode and about the new license way to manage cost based on CPU and memory usage. It was really expensive because at this moment, we do not use any cloud services. Our Elastic Search cluster is on-premises.

Everything is self-hosted at VP tech, at VP. We do not have any limit. People using AWS or GCP have limits because the volume of data is really expensive in cloud services and cloud platforms. Because we self-hosted everything around our services such as Elastic Search or Sentry, the idea is to let the user be able to store a lot of data and a lot of metrics. We try to train the team to have a good log level. We do not have such limitation in terms of volume. We have a really big cluster, and at the end, the price is so huge. I gave this review a rating of ten out of ten.

On-premises

Other

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.

Positive

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.

Elastic Search is used as an observability tool and logging analyzer for solutions that already exist in the company, mainly in FinTech products and financial products.

Elastic Search's main advantages are the visuals that represent and visualize all entities and system components in a simplified diagram, which provides the ability to identify which component in the system has an issue.

The main benefits include having one centralized place that gathers and aggregates all logs related to different or distributed systems.

Elastic Search could be enhanced by incorporating low-code or no-code plugins that permit developers to integrate it with different or distributed systems. This would allow for configurations that already exist but need customization through plugins or simple code that can facilitate user control over parts of the visuals, dashboards, and sensors.

Graphs should be more interactive by importing different graph schemes or visuals from external resources into Elastic Search.

Given that the product has not been used since 2023, the data might be outdated. If Elastic Search is not integrated with any promised LLM, it should have this capability as soon as possible.

Elastic Search has been used since 2018 to the present moment, depending on the different companies that have been worked with.

Elastic Search is a very stable product, especially after obtaining support licenses from Elastic.

The scalability aspect is straightforward. With self-hosting, resources can be expanded vertically, which is managed from the organization's side.

There is no knowledge about general customer service, but there is previous experience in submitting support cases to the Elastic team to get answers and fulfill requirements.

Negative

Elastic Search was installed one time but the work was not completed with it.

Experience exists with Dynatrace observability tool, but Dynatrace is completely different from Elastic Search. Dynatrace is comparable to other observability tools in this category.

Elastic Search has been installed in multiple organizations, including the current employer and previous ones, and used for different purposes.

The setup is somewhat complicated due to multiple dependencies and relations with different systems. However, any engineer should be able to understand and read the documentation well to implement it properly based on business needs and requirements.

The implementation team was involved in the deployment.

Return on investment was achieved more than a year ago.

DataDog might be an equivalent product to Elastic Search, though this requires verification.

Hybrid observability was not used. Enterprise API, whether referring to ESB, API Gateway, or middleware, was not used. Serverless interaction with Kibana was not used. The overall rating for this review is 9 out of 10.

On-premises

I have used the Wazuh SIEM tool, an open-source SIEM tool that uses Elasticsearch for indexing. In this SIEM tool, we have a large amount of logs. Data are converted into alerts, then they are stored in our environment for monitoring and security purposes. For storing that data in Wazuh, we use Elasticsearch indexing.

Configuring Elasticsearch is much easier compared to comprehending other SIEM tools like Splunk. It has a full command-based access that allows you to configure how much data you want to store and set up retention policies. I can easily change the bandwidth for the network to send log data. Elasticsearch is quite user-friendly and offers a hands-on experience for configuring databases.

Elasticsearch should have simpler commands for window filtering. It is primarily based on Unix or Linux-based operating systems and cannot be easily configured in Windows systems. Multi-operating system support would be a great improvement.

I have used it for approximately two years.

It can be installed on cloud and locally, with no issues.

I would rate the stability of Elasticsearch as a seven. There have been multiple instances where I faced errors due to network bandwidth issues. The data transfer sometimes exceeded the bandwidth limits without proper notification, which caused issues.

I would rate the scalability of Elasticsearch as an eight. The high scalability is somewhat limited by its lack of support for different operating systems other than Linux.

I have never used their technical support. I usually resolve issues on my own or with the help of online community forums.

Positive

The complexity of the initial setup depends on the requirements. In an MSSP scenario, where multiple clients use the same software, there is a need to segregate the data. This can make the setup more complex, especially for a single client where you need to adjust network configurations.

For time-saving, Elasticsearch is a good software. It is stable, and we do not encounter critical issues like server downtime, which could result in data loss. There are minor misconfigurations regarding data transfer rates that I have noticed sometimes.

I'm not familiar with the pricing details as it falls under the finance department. My manager handles the costing. However, given that we have been using it for two years, I can suggest that it's priced sensibly for us.

If you can't afford a large SIEM tool like Splunk and QRadar, Elasticsearch is a viable alternative.

Overall, considering key aspects like cost, learning curve, and data indexing architecture, Elasticsearch is a very good tool. I would rate it as a nine.

We use Elastic Search for search purposes and things related to semantic search.

It is not being used for the moment regarding my main use case for Elastic Search.

In my experience, the best features Elastic Search offers are its stability and brand new features that I consider very interesting.

The machine learning features of Elastic Search are very interesting, including the possibility to include models such as ELSER and different multilingual models that let us fine-tune our searches and use them in our search projects.

The machine learning features of Elastic Search have helped us with many things such as improving our searches and experience for the guests.

We could benefit from refining the machine learning models that we currently use in Elastic Search, along with the possibility to integrate agents, intelligent artificial intelligence, form of agent, and MCP.

It would be useful to include an assistant into Kibana for recommendations, advice, tutorials, or things that can help improve my daily work with Elastic Search.

I have been using Elastic Search and Kibana for about four years.

In my experience, Elastic Search is quite stable.

The scalability of Elastic Search is very good in my opinion. It never has incidents that cause issues in our daily tasks.

The customer support for Elastic Search is one of the best I have ever tried. Whenever I had to create a new incident, I got the responses that I needed.

Positive

I consider Elastic Search a very good project. On a scale of 1-10, I would give it a 10.

The features and capabilities that Elastic Search provides are very easy to use, and the documentation is rich. You can find and understand everything here to use it properly.

I would tell others looking into using Elastic Search that they can try it and see if it fits their use cases.

Elastic Search is a very good product. I really appreciate all the features that it provides, and I hope this product continues its evolution in the way it has been.

Private Cloud

Amazon Web Services (AWS)

My usual use cases for Elastic Search are that we are using APM, Application Performance Monitoring. We are using Real User Monitoring, as a RUM. We mostly are using it for application performance monitoring and troubleshooting in that regard. I think that's the main thing we're using Elastic Search observability for right now. We are considering expanding it also to have some Metric Beats and some other features. When we have more data, we will probably start to try to activate AI within Elastic Search. That's a possibility. The Elastic Search platform that we are using is an on-prem installation. It's not a cloud solution we have. This is because of the criticality and confidentiality of the data we have in Elastic Search.

I don't think there's a specific feature within Elastic Search that I have found the most valuable so far. We are more or less using all the features in one way or the other. Elastic Search has impacted my organization positively as we use it for logging and APM. It's not all systems which are using it yet, but it's gathering momentum because they have more use cases to present to other parts of the organization. They explain how different departments are using it, and then people see that they could also benefit from using it. More departments and their systems start to use Elastic Search as a result.

The documentation for Elastic Search can be challenging if you're not already familiar with the platform. The approach to Elastic Search can be difficult if you haven't been working with it previously. Within the product itself, some features could be more intuitive, where currently you need to know specifically where to find them and how to use them.

I have been working with Elastic Search for more than four years now.

From my perspective, Elastic Search has been very stable. The only thing I'm probably missing is what we call the session replay, some kind of tool within Elastic Search based on the data collected that can make some kind of session replay.

Elastic Search is very scalable. The only issue is some features use a huge amount of storage. You need to be in the forefront to make sure that you have the necessary storage to obtain all the data that you're collecting. They probably have surveillance indicating when storage is running low. The engineering department ensures we have sufficient storage. So far, we don't have any scalability issues regarding hosts sending data or the amount of data we are collecting. The engineering department might say we are over-consuming data, but we haven't received any message saying we have reached the ceiling yet.

I do not often communicate with the technical support of Elastic Search. That's the engineering department's responsibility. If I have an issue, I go to the engineering department, and they have the responsibility to communicate with the supplier of Elastic Search or the producer.

Positive

I work with many technical solutions compared to Elastic Search, specifically on observability. We are also looking into AI, which is in an experimental phase in my area. We haven't chosen any specific technology regarding AI. For Elastic Search as it is now, we are not looking into other technology to replace it. I am a chief consultant in my department, but in this regard, I'm mostly a user. The ones who are responsible for the platform are in another department. My experience with configuring relevant searches within the Elastic Search platform is limited as I don't search much within the platform. If I have specific needs, I reach out to get assistance from specialists because they are more familiarized with the system and know exactly how to search for things. For implementation configuration of the system, they are more capable than I am, as I'm more of a user than an engineer on the platform. I would rate Elastic Search an eight out of ten because there's always room for improvement, though from a functionality and price perspective, it could be considered a ten.

On-premises

Other