Elastic Search Reviews

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

I use Elastic Search for fast search of products in our database. With Elastic Search, we use full-text search with keywords and different rules from the Elastic Search documentation. I do not have cases when a search request is four sentences long. I typically use three, four, or five words for searches.

I think the best feature of Elastic Search is the speed. It is very fast and comfortable to use in requests with transpositions rather than full requests. It has a smart engine inside.

In Elastic Search, the improvements I would like to see require many resources.

I have used Elastic Search for two or three years, though I do not remember exactly which it is.

Maintenance of Elastic Search is easy because we do not have problems. I would rate the stability of Elastic Search at an eight.

I would rate the scalability of Elastic Search at an eight.

I did not have a situation where I needed to ask something in technical support for Elastic Search.

Positive

I used a different solution before using Elastic Search. It was Sphinx.

I do not know if the deployment was easy or complex, and it is also not my responsibility.

I do not know how it was purchased as it is our DevOps responsibility. I know that it is in AWS, but I do not know the details of how it is deployed there.

I do not know about features such as Agentic AI, RAG, or Semantic Search in Elastic Search. I did not know that there are AI search features available.

I would recommend Elastic Search to other people who want to have fast search in their applications. It is comfortable, it is fast, and it is very interesting to work with it. I gave this product a rating of eight out of ten.

Our primary use case was primarily for data storage and quick searching. We focused on getting objects from the database and filtering them efficiently. This involved getting and searching through objects.

Our productivity was consistently maintained while using this database. Its consistent performance allowed us to maintain steady productivity levels.

The most valuable feature of Elasticsearch was the quick search capability, allowing us to search by any criteria needed. The searches were executed very quickly, which made the process reliable. Additionally, full-text queries were integral to our usage. Our productivity was consistently maintained with this database. Its consistent performance allowed us to maintain steady productivity levels.

It would be useful if a feature for renaming indices could be added without affecting the performance of other features. However, overall, the consistency and stability of Elasticsearch are already commendable, and they should keep up the good work.

I have been using Elasticsearch for two and a half years while at this company.

The stability of Elasticsearch was very high, and I would rate it a ten. It was consistent and reliable in our usage.

Elasticsearch was decently scalable, matching our data growth. I would rate its scalability a ten.

I was not involved in the initial setup. However, the setup process for smaller projects was straightforward.

One person from our DevOps team was responsible for the maintenance of Elasticsearch.

We used the open-source version of Elasticsearch, which was free.

If a feature for renaming indices could be added without affecting the performance of all other features, it would be nice to have. Overall, I rate Elasticsearch a ten out of ten.

Public Cloud

Amazon Web Services (AWS)

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.

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.

Positive

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.

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.

Neutral

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.

Public Cloud

Other

It is basically for the banking and non-banking sectors. We use it for the APM perspective and application performance monitoring, but not in a holistic way; it is just layer seven, layer five, and six that are there.

In analytics, people use it for search patterns. I've also used Elasticsearch for indexing, where we can have content and do these things. But from an analytics perspective, I have never used Elasticsearch. I have used it in one project

It's a good tool because if you compare it with MongoDB, MongoDB is better. It has a very good data warehouse and search pattern. Elasticsearch cannot be made into a data warehouse. You can use it for smaller-scale analytics, but if you are looking at anything over 30-40 TB, it's not a data lake or big data solution. 

It's a normal database, and any Oracle database or enterprise DB like MSSQL or PostgreSQL can do these things. I've never used it for unstructured data. I have used MongoDB, but not for this.  

All features are almost the same as other observability tools. The best part I like is that it becomes a MOM aka monitoring of monitors. It can capture data from all other sources. It's not a unique feature of Elasticsearch itself because other tools like Dynatrace do do the same thing. But from an ROI perspective and a user-friendly perspective, it is a good tool.

Even at level four to level seven of the OSI model, it does monitoring very well. There are a lot of AI-embedded tools or prediction tools, and numerous default reports are available, which get populated easily. 

So, the quality features are there. There are about 60  to 70 odd reports available. When you deploy the tool and the logs come in, they can capture those logs and automate field mapping and other things. That's the feature—by default, a few reports are available.

The data indexing capability of Elasticsearch is very good. It does the indexing correctly. It's not over-indexing, so it's perfect. It's very good. But how it works depends on the customization of the application and the search pattern you want. The log can be easily viewed, and based on that, you can easily tag things.

Scalability and ROI are the areas they have to improve. Their license terms are based on the number of cores. If you increase the number of cores, it becomes very difficult to manage at a large scale. For example, if I have a $3 million project, I won't sell it because if we're dealing with a 10 TB or 50 TB system, there are a lot of systems and applications to monitor, and I have to make an MOM (Mean of Max) for everything. This is because of the cost impact. 

Also, when you have horizontal scaling, it's like a multi-story building with only one elevator. You have to run around, and it's not efficient. Even the smallest task becomes difficult. That's the problem with horizontal scaling. They need to improve this because if they increase the cores and adjust the licensing accordingly, it would make more sense.

I have been using it for more than four to five years. 

I would rate the stability a nine out of ten. It is a good product. It is a stable product. 

Elasticsearch has horizontal scalability. The users can scale up to any level. The only problem is related to disaster recovery. After some time, it becomes very difficult to do the DC/DR mapping because observability is a critical tool for event alerts. It becomes difficult to manage real-time events if the primary data center goes down and the disaster recovery site needs to take over. This is an issue for large projects like those at tier-one organizations like Ford or big banks. For mid-level and lower-level tier-two or tier-three organizations, it is good.

Another thing to consider is that Elasticsearch has high resource utilization on both the vertical and horizontal levels. But it's a good product for tier-two organizations.

All my clients are enterprise businesses. 

I've never heard anything wrong from the delivery side, but it's an international company with a very good product. So, the support system should be good.

Positive

I tried to sell Kibana twice, but in terms of deployment, we've used it in two or three places. However, I don't have hands-on experience with Kibana. 

To be very honest, we faced some setbacks with Kibana, particularly with network-level monitoring. This issue occurred a few weeks ago when I tried to sell one of our products. We have used Kibana for APM purposes, as well as the Elasticsearch ELK stack.

From an application perspective, it’s one of the tools we use. I can share a lot of insights, but I haven't seen all their reports or dashboards. So, my experience is from a presales perspective rather than a deployment perspective.

If I compare it with other auxiliary tools like Dynatrace, SolarWinds, or Relay, Elasticsearch is very competitive and user-friendly. 

One thing about Elasticsearch is the way they sell licenses for their database, which can be a bit hidden. Many people think Elasticsearch is entirely open-source, but there are charges involved. It's an MPP-based NoSQL database with some limitations on certain datasets.

I would rate my experience with the initial setup a nine out of ten, with ten being easy. It is easy, not that difficult. 

It can be deployed both on the cloud and on-premises. I've seen on-premises deployments. This is especially true in other parts of the world where governments don't want to use the private cloud and have their own private cloud. I have mostly worked with on-premises deployments.

The mapping can take three months on average. However, the deployment time depends on the project. If you have a hundred servers, it will take two or three weeks. With three or four thousand servers, it will take longer. It's the same with any tool, like Dynatrace or SolarWinds. We have to map services and events, set thresholds, and configure event triggering and notifications. There's a lot to consider, so it depends on the project scope, the number of servers, the data captured, and whether it's agent or agentless. It's difficult to calculate an average about how many days it will take.

I would rate the pricing an eight out of ten, with one being cheap and ten being expensive. It is not very costly, but it is not cheap either. 

I would rate it to others. Elasticsearch can be used for many things. It has a good indexing parameter and can be used for search patterns and more. 

If it's for observability, I would give it a nine out of ten. The only issue I have is with APM (Application Performance Monitoring).

Elasticsearch as a product is different than Elasticsearch as a search engine. Elasticsearch is also different as an analytics tool. It depends on the analytical solution and how they want to fetch data from Elasticsearch as a database. As a search engine, it is one of the best. 90% of people use either Solar or Elasticsearch for web portals and other things. Nobody can challenge Elasticsearch in that area. So, out of ten, I would give it a ten.

But for analytics, I'd give it an eight. It depends on my database and in-memory tools. If I use QlikView or other tools, I'll just use Elasticsearch as a database. It's just like any other database they are using for in-memory analytics. 

For observability, Elasticsearch, Logstash, and other things, it is a good component. It's good for tier-two enterprises. But when you define "enterprise," you must be specific. If you mean more than 2000 servers, then 90% of people won't consider it. There are other observability tools on the market. So, be specific in your query.

I can describe a project where we use Elasticsearch, Logstash, and Kibana (ELK stack) for our archiving objectives. I work in the security department of a Fintech company in the payment industry. We use the ELK stack to connect our internal systems with the bank's systems and we used Beats for data collection. We then store and forward this data to Elasticsearch for indexing and analysis, visualize and create alerts using Kibana based on categorized access logs, identifying and blocking malicious traffic or payloads.

Logsign provides us with the capability to execute multiple queries according to our requirements. The indexing is very high, making it effective for storing and retrieving logs. The real-time analytics with Elastic benefits us due to the huge traffic volume in our organization, which reaches up to 60,000 requests per second. With logs of approximately 25 GB per day, manually analyzing traffic behavior, payloads, headers, user agents, and other details is impractical.

I don't see improvements at the moment. The current setup is working well for me, and I'm satisfied with it. Integrating with different platforms is also fine, and I'm not recommending any changes or enhancements right now.

I have been using Elastic Search for the past year.

We subscribed to NGINX for technical support, and they were helpful during the installation phase. There is a lack of community support for GRPC, which needs improvement. 

we are using a licensed version of the product. 

We are fully satisfied with the usage and support, rating it 8 out of 10. I recommend NGINX for managing traffic due to its multiple functionalities like load balancing, proxy management, and caching.