What needs improvement with ELK Elasticsearch?

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.