While Elastic Search is a good product, I see areas for improvement, particularly regarding the misconception that any amount of data can simply be dumped into Elastic Search. When creating an index, careful consideration of data massaging is essential. Elastic Search stores mappings for various data types, which must remain below a certain threshold to maintain functionality. Users need to throttle the number of fields for searching to avoid overloading the system and ensure that the design of the document is efficient for the Elastic Search index. Additionally, I suggest utilizing ILM periodically throughout the year to manage data shuffling between clusters, preventing hotspots in the distribution of requests across nodes.
Product Owner Monitoring, Observability & Metrology at a retailer with 1,001-5,000 employees
Real User
Top 20
Dec 29, 2025
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.
Elastic Search has an annoying limitation regarding page size. It has a specific limit for queries on Elastic Search, and the default is ten thousand, and we can increase it. However, after increasing, it can slow down. Pagination in Elastic Search is very slow. If I need to parse one million records saved into Elastic Search, it becomes a nightmare because I need to do the pagination, and it is very problematic in that regard. I need to do ten thousand records and then go to the other page, and when going to the other page, it currently takes much more time than RDS. For specific cases, if we need to do full-text search and searching for one specific word returns less than ten thousand records, it works very well. However, if we go for more than ten thousand, then it creates an issue for us.
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.
I have not explored Elastic Search at the most. Searching from vector DB is available in Elastic Search, and there is one more concept of graph searching or graph database searching. I have not explored it, but if it is not there, that would be an improvement area where Elastic Search can improve.
Software Developer at a media company with 10,001+ employees
Real User
Top 20
Sep 26, 2025
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.
Sr. Consultant at a computer software company with 51-200 employees
Consultant
Top 20
Aug 12, 2025
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 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.
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 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.
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.
Information Security Engineer at a financial services firm with 11-50 employees
Real User
Top 10
Oct 15, 2024
An improvement would be to have an interface that allows easier navigation and tracing of logs. The current system requires manually inputting dates to verify alerts. A visual timeline that pinpoints possible anomalies would be beneficial.
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 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.
Solutions Architect at a recruiting/HR firm with 1-10 employees
Real User
Top 10
Feb 8, 2024
They could improve some of the platform's infrastructure management capabilities. There should be better visualization and insights about the cost of the SaaS services, which are not effective. Additionally, there needs to be more native integrations to merge the data.
Elastic Search could benefit from a more user-friendly onboarding process for beginners. Creating a module or series specifically designed for those new to Elastic Search would be valuable, starting with the basics and gradually introducing the integration of Elastic Search with emerging technologies like AI. Additionally, it would be helpful to see improvements in mailing integration and potentially offer a more accessible pricing tier for individuals or students who are just starting to explore security and monitoring aspects. A tier tailored for the average user, focusing on simplicity and affordability, could attract a broader audience and encourage long-term use.
Head of security of digital systems, electronic databases and networks at Ukreximbank
Real User
Top 10
Oct 23, 2023
We are keeping an eye on other products like QRadar and Splunk in case they offer features that would benefit our company. We currently use the free version of Elastic Search for some of our logs. However, if we were to use it more extensively, we would need to consider the pricing of the paid plans. Another area of improvement is stability.
Dashboards could be more flexible, and it would be nice to provide more drill-down capabilities. Although the discover function offers exploratory capabilities and one can search for various patterns in logs, the ability to do this from the dashboard function would be very useful. It would make the procedure more simple for the end user, and require less training. It would also be pretty much self-explanatory (drill down and explore specific parts of the diagram/dashboard). Also, more predictive analytics would be a nice-to-have feature.
We have an issue with the volume of data that we can handle. When we have a lot of data, like 30 days of logs, the product becomes slow, and we had to reduce it to seven days. Now, we have only seven days of logging. Logging and tracing are different and we have a problem when it comes to tracing things. If we could have some feature related to tracing between microservices or between any sort of logging, that would be nice.
Senior Product Manager at a tech services company with 501-1,000 employees
Real User
Nov 9, 2022
The documentation regarding customization could be better. Other than that, Elasticsearch has very good documentation. We can get a lot of information from forums.
Senior Associate at a consultancy with 10,001+ employees
Real User
Oct 21, 2022
The UI point of view is not very powerful because it is dependent on Kibana. This can be a struggle because it is not clear where observability features such as logging originate. The UI visualization could be more interesting. For example, a centralized login for a strike driver only provides two choices for viewing. You can either view the log for an individual system or view the log at the centralized level. A more granular approach with locations, pods, and servers is preferred. For comparison, Stackdriver is awesome because it includes all information with respect to the UI point of view.
General Manager at Andes Tecnología y Consultoría Ltda.
Real User
Sep 6, 2022
Finding skilled people to work with Elastic Enterprise Search in the project team has been difficult. This may be because the development team has not considered it. It is important to improve the database performance because there is a large amount of data and the optimization of the queries and the system's performance are very important. We also use three other databases, MinIO, PostgreSQL and PostgreSQL. We have a very skilled person on our team that knows how to use all these products. However, he's not responsible for optimization because it's the responsibility of the Indian provider that has to develop the application.
COE Head at a tech services company with 1,001-5,000 employees
Real User
Aug 5, 2022
Maybe Elastic Search could improve the analytics part of the search so it can be more powerful to the user. It could help provide more understanding of what people are searching for. We'd like more user-friendly integrations. It should be easier for non-technical people to understand how to handle them.
Executive VP Operation Aqua + South East Asia at a manufacturing company with 10,001+ employees
Real User
Jul 26, 2022
Elastic Enterprise Search can improve by adding some kind of search that can be used out of the box without too much struggle with configuration. With every kind of search engine, there is some kind of special function that you need to do. A simple out-of-the-box search would be useful. In the next release, they could improve on the scheduling and alert features.
IBM MQ Specialist / Administrator at a financial services firm with 10,001+ employees
Real User
Jun 26, 2022
Elastic Enterprise Search could improve its SSL integration easier. We should not need to go to the back-end servers to do configuration, we should be able to do it on the GUI.
There is another solution I'm testing which has a 500 record limit when you do a search on Elastic Enterprise Search. That's the only area in which I'm not sure whether it's a limitation on our end in terms of knowledge or a technical limitation from Elastic Enterprise Search. There is another solution we are looking at that rides on Elastic Enterprise Search. And the limit is for any sort of records that you're doing or data analysis you're trying to do, you can only extract 500 records at a time. I know the open-source nature has a lot of limitations, Otherwise, Elastic Enterprise Search is a fantastic solution and I'd recommend it to anyone.
It is hard to learn and understand because it is a very big platform. This is the main reason why we still have nothing in production. We have to learn some things before we get there. I have reported and had discussions about several bugs at discuss.elastic.co, but that happens with many products. It is not only with this product.
Elasticsearch includes mechanisms for ingesting data into the cluster. So it would be great if those mechanisms could be simplified. Improving machine learning capabilities would be beneficial.
Senior Consultant at a tech services company with 10,001+ employees
Real User
Sep 15, 2021
They could simplify the Filebeat and Logstash configuration piece. There are a lot of manual steps on the operating system. It could be simplified in the user interface.
Technical Manager at a computer software company with 51-200 employees
Real User
Jul 8, 2021
The price could be better. Kibana has some limitations in terms of the tablet to view event logs. I also have a high volume of data. On the initialization part, if you chose Kibana, you'll have some limitations. Kibana was primarily proposed as a log data reviewer to build applications to the viewer log data using Kibana. Then it became a virtualization tool, but it still has limitations from a developer's point of view.
Senior Analyst at a tech services company with 10,001+ employees
Real User
May 20, 2021
They should improve its documentation. Their official documentation is not very informative. They can also improve their technical support. They don't help you much with the customized stuff. They also need to add more visuals. Currently, they have line charts, bar charts, and things like that, and they can add more types of visuals. They should also improve the alerts. They are not very simple to use and are a bit complex. They could add more options to the alerting system.
Its licensing needs to be improved. They don't offer a perpetual license. They want to know how many nodes you will be using, and they ask for an annual subscription. Otherwise, they don't give you permission to use it. Our customers are generally military or police departments or customers without connection to the internet. Therefore, this model is not suitable for us. This subscription-based model is not the best for OEM vendors. Another annoying thing about Elasticsearch is its roadmap. We are developing something, and then they say, "Okay. We have removed that feature in this release," and when we are adapting to that release, they say, "Okay. We have removed that one as well." We don't know what they will remove in the next version. They are not looking for backward compatibility from the customers' perspective. They just remove a feature and say, "Okay. We've removed this one." In terms of new features, it should have an ODBC driver so that you can search and integrate this product with existing BI tools and reporting tools. Currently, you need to go for third parties, such as CData, in order to achieve this. ODBC driver is the most important feature required. Its Community Edition does not have security features. For example, you cannot authenticate with a username and password. It should have security features. They might have put it in the latest release.
It should be easier to use. It has been getting better because many functions are pre-defined, but it still needs improvement. If you have a large enterprise environment, it is costing a lot of money and it's not a full-blown SIEM. It has SIEM features but a lot is missing. You need to involve other products to make a SIEM out of it. Some of the other products needed were Apache, Kafka, and ticket tools. It was custom made and not what I had expected in the end. I would like to see them get closer to a full-blown orchestrated SIEM, and create predefined modules to bring you to using it as a SIEM faster, and on the fly instead of having to tweak the Grok filter for weeks. I would like to see more pre-defined modules.
I have not been using the solution for many years to know exactly the improvements needed. However, they could simplify how the YML files have to be structured properly. If you want to ingest certain logs, you need to edit the YML file and connect it to your modules to start ingesting and parsing the end-user logs. Doing this is sometimes difficult and could be streamlined.
System Administrator and DevOps Engineer at a tech services company with 10,001+ employees
Real User
Nov 23, 2020
We run this solution on multiple servers. ELK has three lanes which comprise a single package made up of Elasticsearch, Logstash, and Kibana. To my mind, this is not efficient because we have to individually deploy the different applications. In contrast, we're able to deploy Splunk with a singe application. Implementing the dashboards is also quite difficult. With Splunk and Nagios it's much easier to directly interact with Elasticsearch. I'd like to see some additional features in the front end which currently make it a bit difficult to implement and it should be simplified.
Chief Data Scientist at Everlytics Data Science Pte Ltd
Real User
Nov 19, 2020
Enhance the Spaces feature to make it fully multi-tenant by enabling role-based access control (RBAC) at a Space level rather than overall Kibana or stack level like it is currently. Elastic needs to work on their Machine Learning offering because currently they have been trying to make it a black box which doesn't work for a serious user (a Data Scientist) as it doesn't give any control over the underlying algorithm. It's like a point-and-click camera vs a DSLR. The offering started with a single/ univariate anomaly detection on time-series data. Now, they have a multivariate which is good, but beyond this, we cannot build any other Machine Learning models, like traditional supervised models. Anomaly detection uses mostly unsupervised algorithms and also it is a very broad problem space for a black box to solve it fully. Make index’s metadata searchable (or referenceable in search queries).
Head of Technology Operations at a financial services firm with 11-50 employees
Real User
Oct 22, 2020
There are a few things that did not work for us. When doing a search in a bigger setup, with a huge amount of data where there are several things coming in, it has to be on top of the index that we search. There could be a way to do a more distributed kind of search. For example, if I have multiple indexes across my applications and if I want to do a correlation between the searches, it is very difficult. From a usage perspective, this is the primary challenge. I would like to be able to do correlations between multiple indexes. There is a limit on the number of indexes that I can query or do. I can do an all-index search, but it's not theoretically okay on practical terms we cannot do that. In the next release, I would like to have a correlation between multiple indexes and to be able to save the memory to the disk once we have built the index and it's running. Once the system is up, it will start building that in memory. We need to be able to distribute it across or save it to have a faster load time. We don't make many changes to the data that we are creating, but we would like archived reports and to be able to retrieve those reports to see what is going on. That would be helpful. Also, if you provide a customer with a report or some archived queries, that the customer is looking at when they are creating, at first it will be slow while putting up their data or subsequently doing it. I want it to be up and running efficiently. If the memory could be saved and put back into memory as it is, then starts working it would reduce the load time then it will be more efficient from a cost perspective and it will optimize resource usage.
Lead Software Architect at a tech services company with 51-200 employees
Real User
Aug 2, 2020
Kibana should be more friendly, especially when building dashboards. Stability needs improvement. I would like to see the Kibana operating more smoothly, as Grafana does. Also, I would like to see some improvements with the machine learning capability, so that we can rely on it more. It's in the early phases but this would be a great way to start using it. When it comes to aggregation and calculations, I would like to have to have advanced options in the dashboards to be used in a simplified way, such as building formulas and queries between different fields and indexes. Alerting feature should be more flexible with advanced options.
The solution has quite a steep learning curve. The usability and general user-friendliness could be improved. However, that is kind of typical with products that have a lot of flexibility, or a lot of capabilities. Sometimes having more choices makes things more complex. It makes it difficult to configure it, though. It's kind of a bitter pill that you have to swallow in the beginning and you really have to get through it. Once you begin to understand the concepts and how to actually look for data it's a very pleasant solution, but the learning curve is very steep in the beginning, to the point that they could improve it to make it a bit less intimidating to start. There needs to be a bit more intuition behind the architecture and the data search.
Cyber Security Professional at Defensive Cyber Security Center Germany
Real User
May 10, 2020
I would like to see more open source tools and testing as well as a signature analysis in the solution. I think that a lot of times when we go into a corporate environment where it becomes more add on features or an additional service fee, it typically draws away from that product. I think it would be cool if they could provide a couple of licenses that would be test bed licenses so that engineers and people with have their hands on the keyboard could test any new development.
Manager at a tech services company with 11-50 employees
Real User
Dec 15, 2019
I think the GUI part of the solution has the most room for improvement. Actually, we are using the free version. We do not use the plug-ins so we have to do some additional development ourselves to have the necessary access to the controls. We are not a heavy user, we just keep the logs and track data in the system. We use it and there is no problem for our current purposes and level of use.
Data Scientist at a tech vendor with 51-200 employees
Real User
Dec 9, 2019
In terms of product improvement, ratio aggregation is not supported in this solution. I can do aggregations, but taking a ratio of two metrics is not supported. That's a common use case that I have come across. And if I want to do bulk coding then that's something that is not very convenient. I would like those things to be included in the next version.
This is not a robust system, so in terms of resilience, they have to make some improvements. From time to time the system goes down and we have to start again, after adjusting some configuration parameters. Technical support can be improved. The interface would be improved with the inclusion of dashboards to assist in analyzing problems because it is very difficult. Better dashboards or a better configuration system would be very good.
Elasticsearch is useful for different business processes, but there are some problems. We discuss these problems with the vendor and with our in-house team. We see the need for some improvements with Elasticsearch. We would like the Elasticsearch package to include training lessons for our staff.
Elasticsearch is a prominent open-source search and analytics engine known for its scalability, reliability, and straightforward management. It's a favored choice among enterprises for real-time data search, analysis, and visualization. Open-source Elasticsearch is free, offering a comprehensive feature set and scalability. It allows full control over deployments but requires managing and maintaining the infrastructure. On the other hand, Elastic Cloud provides a managed service with features...
While Elastic Search is a good product, I see areas for improvement, particularly regarding the misconception that any amount of data can simply be dumped into Elastic Search. When creating an index, careful consideration of data massaging is essential. Elastic Search stores mappings for various data types, which must remain below a certain threshold to maintain functionality. Users need to throttle the number of fields for searching to avoid overloading the system and ensure that the design of the document is efficient for the Elastic Search index. Additionally, I suggest utilizing ILM periodically throughout the year to manage data shuffling between clusters, preventing hotspots in the distribution of requests across nodes.
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.
Elastic Search has an annoying limitation regarding page size. It has a specific limit for queries on Elastic Search, and the default is ten thousand, and we can increase it. However, after increasing, it can slow down. Pagination in Elastic Search is very slow. If I need to parse one million records saved into Elastic Search, it becomes a nightmare because I need to do the pagination, and it is very problematic in that regard. I need to do ten thousand records and then go to the other page, and when going to the other page, it currently takes much more time than RDS. For specific cases, if we need to do full-text search and searching for one specific word returns less than ten thousand records, it works very well. However, if we go for more than ten thousand, then it creates an issue for us.
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.
I have not explored Elastic Search at the most. Searching from vector DB is available in Elastic Search, and there is one more concept of graph searching or graph database searching. I have not explored it, but if it is not there, that would be an improvement area where Elastic Search can improve.
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.
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 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.
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 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.
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.
An improvement would be to have an interface that allows easier navigation and tracing of logs. The current system requires manually inputting dates to verify alerts. A visual timeline that pinpoints possible anomalies would be beneficial.
Elastic Search needs better guides for developers. Better guides for development.
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 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.
The solution must provide AI integrations. I could direct my data flow to my AI tools if I use Elastic for IoT data.
They could improve some of the platform's infrastructure management capabilities. There should be better visualization and insights about the cost of the SaaS services, which are not effective. Additionally, there needs to be more native integrations to merge the data.
Elastic Search needs to improve authentication. It also needs to work on the Kibana visualization dashboard.
Elastic Search could benefit from a more user-friendly onboarding process for beginners. Creating a module or series specifically designed for those new to Elastic Search would be valuable, starting with the basics and gradually introducing the integration of Elastic Search with emerging technologies like AI. Additionally, it would be helpful to see improvements in mailing integration and potentially offer a more accessible pricing tier for individuals or students who are just starting to explore security and monitoring aspects. A tier tailored for the average user, focusing on simplicity and affordability, could attract a broader audience and encourage long-term use.
We are keeping an eye on other products like QRadar and Splunk in case they offer features that would benefit our company. We currently use the free version of Elastic Search for some of our logs. However, if we were to use it more extensively, we would need to consider the pricing of the paid plans. Another area of improvement is stability.
The solution's integration and configuration are not easy. Not many people know exactly what to do.
It was not possible to use authentication three years back. You needed to buy the product's services for authentication.
Dashboards could be more flexible, and it would be nice to provide more drill-down capabilities. Although the discover function offers exploratory capabilities and one can search for various patterns in logs, the ability to do this from the dashboard function would be very useful. It would make the procedure more simple for the end user, and require less training. It would also be pretty much self-explanatory (drill down and explore specific parts of the diagram/dashboard). Also, more predictive analytics would be a nice-to-have feature.
The cost is too high once you deploy the solution. They're making changes in their architecture too frequently. We'd like less frequent updates.
We have an issue with the volume of data that we can handle. When we have a lot of data, like 30 days of logs, the product becomes slow, and we had to reduce it to seven days. Now, we have only seven days of logging. Logging and tracing are different and we have a problem when it comes to tracing things. If we could have some feature related to tracing between microservices or between any sort of logging, that would be nice.
The documentation regarding customization could be better. Other than that, Elasticsearch has very good documentation. We can get a lot of information from forums.
Elastic Enterprise Search could improve the report templates.
The UI point of view is not very powerful because it is dependent on Kibana. This can be a struggle because it is not clear where observability features such as logging originate. The UI visualization could be more interesting. For example, a centralized login for a strike driver only provides two choices for viewing. You can either view the log for an individual system or view the log at the centralized level. A more granular approach with locations, pods, and servers is preferred. For comparison, Stackdriver is awesome because it includes all information with respect to the UI point of view.
Finding skilled people to work with Elastic Enterprise Search in the project team has been difficult. This may be because the development team has not considered it. It is important to improve the database performance because there is a large amount of data and the optimization of the queries and the system's performance are very important. We also use three other databases, MinIO, PostgreSQL and PostgreSQL. We have a very skilled person on our team that knows how to use all these products. However, he's not responsible for optimization because it's the responsibility of the Indian provider that has to develop the application.
Maybe Elastic Search could improve the analytics part of the search so it can be more powerful to the user. It could help provide more understanding of what people are searching for. We'd like more user-friendly integrations. It should be easier for non-technical people to understand how to handle them.
Elastic Enterprise Search can improve by adding some kind of search that can be used out of the box without too much struggle with configuration. With every kind of search engine, there is some kind of special function that you need to do. A simple out-of-the-box search would be useful. In the next release, they could improve on the scheduling and alert features.
Elastic Enterprise Search could improve its SSL integration easier. We should not need to go to the back-end servers to do configuration, we should be able to do it on the GUI.
There is another solution I'm testing which has a 500 record limit when you do a search on Elastic Enterprise Search. That's the only area in which I'm not sure whether it's a limitation on our end in terms of knowledge or a technical limitation from Elastic Enterprise Search. There is another solution we are looking at that rides on Elastic Enterprise Search. And the limit is for any sort of records that you're doing or data analysis you're trying to do, you can only extract 500 records at a time. I know the open-source nature has a lot of limitations, Otherwise, Elastic Enterprise Search is a fantastic solution and I'd recommend it to anyone.
It is hard to learn and understand because it is a very big platform. This is the main reason why we still have nothing in production. We have to learn some things before we get there. I have reported and had discussions about several bugs at discuss.elastic.co, but that happens with many products. It is not only with this product.
Something that could be improved is better integrations with Cortex and QRadar, for example.
Elasticsearch includes mechanisms for ingesting data into the cluster. So it would be great if those mechanisms could be simplified. Improving machine learning capabilities would be beneficial.
They could simplify the Filebeat and Logstash configuration piece. There are a lot of manual steps on the operating system. It could be simplified in the user interface.
The price could be better. Kibana has some limitations in terms of the tablet to view event logs. I also have a high volume of data. On the initialization part, if you chose Kibana, you'll have some limitations. Kibana was primarily proposed as a log data reviewer to build applications to the viewer log data using Kibana. Then it became a virtualization tool, but it still has limitations from a developer's point of view.
They should improve its documentation. Their official documentation is not very informative. They can also improve their technical support. They don't help you much with the customized stuff. They also need to add more visuals. Currently, they have line charts, bar charts, and things like that, and they can add more types of visuals. They should also improve the alerts. They are not very simple to use and are a bit complex. They could add more options to the alerting system.
Its licensing needs to be improved. They don't offer a perpetual license. They want to know how many nodes you will be using, and they ask for an annual subscription. Otherwise, they don't give you permission to use it. Our customers are generally military or police departments or customers without connection to the internet. Therefore, this model is not suitable for us. This subscription-based model is not the best for OEM vendors. Another annoying thing about Elasticsearch is its roadmap. We are developing something, and then they say, "Okay. We have removed that feature in this release," and when we are adapting to that release, they say, "Okay. We have removed that one as well." We don't know what they will remove in the next version. They are not looking for backward compatibility from the customers' perspective. They just remove a feature and say, "Okay. We've removed this one." In terms of new features, it should have an ODBC driver so that you can search and integrate this product with existing BI tools and reporting tools. Currently, you need to go for third parties, such as CData, in order to achieve this. ODBC driver is the most important feature required. Its Community Edition does not have security features. For example, you cannot authenticate with a username and password. It should have security features. They might have put it in the latest release.
It should be easier to use. It has been getting better because many functions are pre-defined, but it still needs improvement. If you have a large enterprise environment, it is costing a lot of money and it's not a full-blown SIEM. It has SIEM features but a lot is missing. You need to involve other products to make a SIEM out of it. Some of the other products needed were Apache, Kafka, and ticket tools. It was custom made and not what I had expected in the end. I would like to see them get closer to a full-blown orchestrated SIEM, and create predefined modules to bring you to using it as a SIEM faster, and on the fly instead of having to tweak the Grok filter for weeks. I would like to see more pre-defined modules.
I have not been using the solution for many years to know exactly the improvements needed. However, they could simplify how the YML files have to be structured properly. If you want to ingest certain logs, you need to edit the YML file and connect it to your modules to start ingesting and parsing the end-user logs. Doing this is sometimes difficult and could be streamlined.
We run this solution on multiple servers. ELK has three lanes which comprise a single package made up of Elasticsearch, Logstash, and Kibana. To my mind, this is not efficient because we have to individually deploy the different applications. In contrast, we're able to deploy Splunk with a singe application. Implementing the dashboards is also quite difficult. With Splunk and Nagios it's much easier to directly interact with Elasticsearch. I'd like to see some additional features in the front end which currently make it a bit difficult to implement and it should be simplified.
Enhance the Spaces feature to make it fully multi-tenant by enabling role-based access control (RBAC) at a Space level rather than overall Kibana or stack level like it is currently. Elastic needs to work on their Machine Learning offering because currently they have been trying to make it a black box which doesn't work for a serious user (a Data Scientist) as it doesn't give any control over the underlying algorithm. It's like a point-and-click camera vs a DSLR. The offering started with a single/ univariate anomaly detection on time-series data. Now, they have a multivariate which is good, but beyond this, we cannot build any other Machine Learning models, like traditional supervised models. Anomaly detection uses mostly unsupervised algorithms and also it is a very broad problem space for a black box to solve it fully. Make index’s metadata searchable (or referenceable in search queries).
There are a few things that did not work for us. When doing a search in a bigger setup, with a huge amount of data where there are several things coming in, it has to be on top of the index that we search. There could be a way to do a more distributed kind of search. For example, if I have multiple indexes across my applications and if I want to do a correlation between the searches, it is very difficult. From a usage perspective, this is the primary challenge. I would like to be able to do correlations between multiple indexes. There is a limit on the number of indexes that I can query or do. I can do an all-index search, but it's not theoretically okay on practical terms we cannot do that. In the next release, I would like to have a correlation between multiple indexes and to be able to save the memory to the disk once we have built the index and it's running. Once the system is up, it will start building that in memory. We need to be able to distribute it across or save it to have a faster load time. We don't make many changes to the data that we are creating, but we would like archived reports and to be able to retrieve those reports to see what is going on. That would be helpful. Also, if you provide a customer with a report or some archived queries, that the customer is looking at when they are creating, at first it will be slow while putting up their data or subsequently doing it. I want it to be up and running efficiently. If the memory could be saved and put back into memory as it is, then starts working it would reduce the load time then it will be more efficient from a cost perspective and it will optimize resource usage.
Technical support should be faster.
Kibana should be more friendly, especially when building dashboards. Stability needs improvement. I would like to see the Kibana operating more smoothly, as Grafana does. Also, I would like to see some improvements with the machine learning capability, so that we can rely on it more. It's in the early phases but this would be a great way to start using it. When it comes to aggregation and calculations, I would like to have to have advanced options in the dashboards to be used in a simplified way, such as building formulas and queries between different fields and indexes. Alerting feature should be more flexible with advanced options.
The solution has quite a steep learning curve. The usability and general user-friendliness could be improved. However, that is kind of typical with products that have a lot of flexibility, or a lot of capabilities. Sometimes having more choices makes things more complex. It makes it difficult to configure it, though. It's kind of a bitter pill that you have to swallow in the beginning and you really have to get through it. Once you begin to understand the concepts and how to actually look for data it's a very pleasant solution, but the learning curve is very steep in the beginning, to the point that they could improve it to make it a bit less intimidating to start. There needs to be a bit more intuition behind the architecture and the data search.
I would like to see more open source tools and testing as well as a signature analysis in the solution. I think that a lot of times when we go into a corporate environment where it becomes more add on features or an additional service fee, it typically draws away from that product. I think it would be cool if they could provide a couple of licenses that would be test bed licenses so that engineers and people with have their hands on the keyboard could test any new development.
I think the GUI part of the solution has the most room for improvement. Actually, we are using the free version. We do not use the plug-ins so we have to do some additional development ourselves to have the necessary access to the controls. We are not a heavy user, we just keep the logs and track data in the system. We use it and there is no problem for our current purposes and level of use.
In terms of product improvement, ratio aggregation is not supported in this solution. I can do aggregations, but taking a ratio of two metrics is not supported. That's a common use case that I have come across. And if I want to do bulk coding then that's something that is not very convenient. I would like those things to be included in the next version.
The pricing of this product needs to be more clear because I cannot understand it when I review the website.
This is not a robust system, so in terms of resilience, they have to make some improvements. From time to time the system goes down and we have to start again, after adjusting some configuration parameters. Technical support can be improved. The interface would be improved with the inclusion of dashboards to assist in analyzing problems because it is very difficult. Better dashboards or a better configuration system would be very good.
This product could be improved with additional security, and the addition of support for machine learning devices.
Elasticsearch is useful for different business processes, but there are some problems. We discuss these problems with the vendor and with our in-house team. We see the need for some improvements with Elasticsearch. We would like the Elasticsearch package to include training lessons for our staff.