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.

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.

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.

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.

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.

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.

At Shopee, I worked with numerous database schemas to find out which table columns belonged to which schema. We utilized Elastic Search to manage metadata for millions of tables, allowing us to search efficiently. Besides that, we used Logstash to put all the log files in Elastic Search for easy searchability.

Elastic Search significantly improved my work. Previously, when searching for text that appears in the middle of strings, the process was time-consuming. Elastic Search enables efficient searching, enhancing system performance and responsiveness. I can also collect logs through Kafka, send them to Elastic Search, and create indices, thus managing logs and customizing searches easily.

Elastic Search provides features such as stemming and range-based queries to search log files efficiently. It allows filtering data easily by searching for specific words based on created indexes. This made searches very efficient, and it also allows for log collection through Kafka and helps with managing logs and customizing searches according to needs, such as grouping by dates or user IDs.

Elastic Search could improve in areas such as search criteria and query processes, as search times were longer prior to implementing Elastic Search. Elastic Search has limitations for handling huge amounts of data and updates, especially if updates are frequent. It doesn't handle big data scale efficiently, especially regarding data size and scale, compared to Apache Solr. It doesn't support real-time search effectively, as it refreshes the indexes every few seconds.

It is stable as many companies already use Elastic Search. In cloud scenarios, it manages well by scaling up or down based on peak traffic. Otherwise, similar functionality needs to be replicated in a private cloud, including backups.

Elastic Search requires enhancements for handling huge amounts of data and updates. Segmenting or sharding data and complexities regarding the cluster can be issues. Updating in Elastic Search involves index computations and user dependencies. There might be issues regarding data size and scaling, but these can be tuned and improved.

I remember Apache Solr, which is generally used for much larger scale data compared to Elastic Search. Apache Solr is used by most companies, and while Elastic Search is very common, there are technologies similar to Elastic Search, though I'm not familiar with all the names.

I have used Elastic Search, but I might not be aware of many internal details; I just used the API to create an index, manage data, and search. It's very useful. On a scale of 1-10, I rate it an eight.

I have been using it for a year. The main use cases involved implementing search functionality.

When discussing the features of Elastic Search, the full text search capabilities are particularly beneficial for handling large volumes of data.

The full text search capabilities in Elastic Search have proven to be extremely valuable for our operations.

Regarding AI integration, we have not yet implemented any AI-driven projects or initiatives using Elastic Search.

There are some features and functionality that could be enhanced in Elastic Search to improve its overall capabilities.

I have been using Elastic Search for a year.

In terms of performance and stability, Elastic Search has proven to be a reliable solution.

The environment includes multiple users utilizing Elastic Search across different locations.

Before implementing Elastic Search, I had experience working with other search engines from different vendors.

The implementation strategy involved specific steps during the setup process to ensure proper configuration.

The main benefits observed from using Elastic Search include improvements in operational efficiency, along with cost, time, and resource savings.

I previously used Graylog.

I am currently working with Elastic Search as the primary solution.

My role is Senior DevOps engineer at UVIK Digital.

On a scale of 1 to 10, with 10 being the highest, I would rate Elastic Search as an 8 overall as a product and solution.

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.

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.

I use the solution to store historical data and logs to find anomalies within the logs. That is about it. I don't create dashboards from it.

I find the solution to be fast. Aggregation is faster than querying directly from a database, like Postgres or Vertica. It's much faster if I want to do aggregation. These features allow me to store logs and find anomalies effectively.

I found an issue with Elasticsearch in terms of aggregation. They are good, yet the rules written for this are not really good.

There is a maximum of 10,000 entries, so the limitation means that if I wanted to analyze certain IP addresses more than 10,000 times, I wouldn't be able to dump or print that information. I need to use paging or something similar as a workaround. That's what the limitation is all about.

I have probably used it for three or four years, maybe longer.

The solution is very good with no issues or glitches.

In terms of scalability, I have multiple Search instances. I can actually add more storage and memory because I host it in the cloud. It's much easier in terms of scalability, and I have no complaints about it.

I have never talked to technical support.

I am using Elasticsearch.

The initial setup is very easy.

I did not use any outside assistance.

I don't know about pricing. That is dealt with by the sales team and our account team. I was not involved with that.

I am evaluating InfluxDB as well. Timescub is a kind of database.

I would rate Elasticsearch at eight out of ten.

We are using Elastic Search for free text search. We scan cache files and convert them into OCR. This allows our end users to search for any judgment given in the 1980s or 1990s based on their criteria.

Elastic Search is very quick when handling a large volume of data. The facet search is particularly valuable. It is scalable. Elastic Search makes handling large data volumes efficient and supports complex search operations.

There should be more stability. When we started learning it, new versions came out frequently in one quarter with extended features. This can create problems for new developers because they have to quickly switch to another version. Stability could be improved, as it sometimes requires quick adaptation to new versions.

We have been using Elastic Search for two years.

Elastic Search is generally stable, however, the frequent release of new versions can cause challenges for stability. If asked to rate stability, I would give it an eight out of ten.

Elastic Search is scalable. Our supreme court uses it for the whole nation across all judgments, so it must be scalable.

We have not contacted customer service. We rely on documentation for solutions.

We are using Elastic Search for free text search in our project.

The documentation for Elastic Search is very well structured. It provides easy-to-follow steps for installation, making it a straightforward process.

One person can install Elastic Search by following the documentation steps.

Our organization prioritizes open-source tools. We have not purchased any licensed products, and our use of Elastic Search is purely open-source, contributing positively to our ROI. We adopt open-source tools due to the organization's policy.

Our experience has been positive, finding solutions in documentation without needing customer support. We also use supporting technologies like PostgreSQL, Spring Boot, and Subversion for seamless integration.

I rate Elastic Search nine out of ten.