Elastic Search Reviews

There are a lot of good things about this solution. First, it is an extremely fast search. We have quite an extensive number of logs, and we can search through billions of documents in just a few minutes, and get the results we're looking for.

The second is easy indexing. We can index almost anything that comes from a log. Anything produced in the system can be ingested in Elastic Search.

I want the solution to improve the graph feature because it is a little bit poor. Both the graph feature and the reporting feature are a little bit lacking. The alerting also needs to be improved.

As for new features, I would like to see more on the network monitoring side. I can see that a lot has been done in server management, security, and application. However, I would love to see the same attention given to network management. If we could go and harvest the network information and bring it into Elastic Search, it would be the perfect solution for achieving a NOC and SOC environment.

I have been using this solution for five years.

We haven't had any stability issues at all. You just have to make sure that you are ingesting the right amount of data and maintaining your cluster by clearing up all of the data regularly. We input some script that tells the solution to drop any data it sees that is older than three months. It's as simple as that, and we're very happy with it. 

If you size your nodes properly, and a node drops or there is a problem, the product will still function. Last night, one of the nodes in my cluster crashed. I went in to check it and restarted the node, and the data appeared and everything was fine. I cannot say the same for a lot of other solutions.

The solution has great scalability. We started with one node, then went to three nodes, as recommended by Elastic. We then found ourselves with seven nodes, and eventually 11 nodes. Then we said, "Wait a minute, this is not going well because we keep adding data and running out of storage." That's when we decided to start dropping data after three months. 

I've seen a lot of improvement over the last five years. Five years ago, there was a little bit of tech support but it was not great. Recently, I opened some cases and the team gave me answers that included exactly what to do to resolve the problems. This shows that the support team has knowledge. It's not just someone who is sitting in the office and try to figure out the problem. When you give them a problem, they know exactly what's wrong and they'll offer the precise solution that will solve the problem. We have seen a lot of improvements in the last six months. I would rate the technical support as a four out of five because they are very knowledgeable. 

Positive

I would rate the initial setup process as a five out of five because it's the easiest product I've ever dealt with. When it needs to be upgraded, you just tell it to upgrade and the solution does it for you. 

We started with the open-source version and the price increases as you add nodes because it's node-based. The price kept increasing, so we decided to buy a license to get all the features and manage the clusters more efficiently. The price of Elastic Enterprise is very, very competitive. I think it was around $700. It was very cheap for our budget. We have other solutions from other vendors that are way more expensive.

The beauty of Elastic Search is that it's based on an open-source solution, so even if you don't want to keep your license, you can just switch it off and go back to the open-source version. You'll lose some of the features, but your data will still be there, and you'll still be able to manipulate it.

You can scale the pricing up and down, which is great flexibility for us because we are a government organization. When it comes to invoicing and payment, the government is a little slow. For example, we found that our license expired on December 31st, but the vendor still hadn't been paid, so they would not issue us a new license. We switched our license off and went back to open source mode until we were able to get our license again and switch back to Enterprise.

One time, we had a remote customer who was complaining about response time, and we couldn't figure out where the problem was located. We created a small setup, just one node of Elastic Search, and we started using it to ingest the network traffic that was going from that customer to our main site. Once we started ingesting the network traffic, we saw exactly what the problem was. We were able to solve the problem, and it only took us an hour.

What sets this solution apart from its competitors is the innovation. For example, look at the number of releases they're doing. About every three to six months, you have a new release with new features, and it's great. The good thing is that even if you don't like the innovation, you still follow an upgrade line, which means you don't lose anything from the past. You just keep getting new stuff pumped into Elastic Search. As a result, it's becoming more like an overall operational solution, when before, it was just a place where you dumped your logs.

My advice to new users of this solution is to start with a specific use case that's a simple or complicated problem that you want to address. Start with that use case, address it straight away, and keep expanding. For example, we started with a network traffic use case, then expanded into Syslog management of a network device. Next, we expanded to an event management server, and then we went into application management. Now we are in security logs, and it keeps expanding.

I would rate this solution as a seven out of ten because there is still a lot missing regarding network management. Also, machine learning is still not clear to me. A lot of the things in machine learning can be addressed straight away with other features, like a watcher or alerting. At this point, I don't see the benefit of machine learning when it comes to IT infrastructure.

We use the product for log analytics and metrics features. 

We can easily collect all the data and view historical trends using the product. We can view the applications and identify the issues effectively.

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.

We have been using Elastic Search for about a year.

I rate the stability a ten out of ten.

It is a highly scalable application. We have 15 users in our management team. I rate the scalability an eight out of ten.

I have experience working with Splunk in the past.

The initial setup for the SaaS platform is quite easy. We took assistance from an engineer for the onboarding. Thus, it was straightforward for us. However, there could be a better integration with AWS.

I rate the process a seven out of ten.

I rate Elastic Search's pricing an eight out of ten.

By integrating Deepgram insights with the product, we've gained visibility into logging, service behavior, and cost optimization.

I rate Elastic Search a nine out of ten.

We are primarily using it for monitoring. It is used for server monitoring.

I really like the visualization that you can do within it. That's really handy. Product-wise, it is a very good and stable product.

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.

I have been using this solution for one year.

Stability-wise, it is very good. Once the data starts coming in, it is very stable. I didn't find any big glitches in it.

We contacted their technical support once. I didn't find them very good. They are there just to provide documentation and stuff. They don't help you much with the customized stuff. They could improve that. I would rate them a two out of five.

It is complex because it is not Windows-based. It is Linux-based, so one must know Linux to deploy it properly. It is not a product that you can install with just multiple clicks. You need to understand it.

It seems good in terms of return on investment. It is a monitoring solution, and it triggers alerts before something happens. For example, it triggers an alert when the space in Windows reaches an 80% limit. I would say it is a good investment. We are able to fix things before they go wrong. If we didn't have Elasticsearch, things would go wrong, and we would be spending more time fixing them later on.

I would advise others to first know Linux because it would most probably be on Linux. If you're good at Linux, you will be good at this as well.

I would rate ELK Elasticsearch an eight out of ten.

The primary use case of this solution is to search large amounts of data across multiple systems.

The solution has improved our organization by allowing us to quickly search data from multiple systems saving valuable time.

The most valuable features are full-text search, the ability to index large amounts of data, map data in areas that are not fully structured, and scaling out.

The one area that can use improvement is the automapping of fields.

This may have been improved in the latest version.

I have been using the solution for a year.

The solution is stable. 

The solution is easily scalable.

There has not been a need to use customer service or support because of the vast amount of reliable forums available online.

The initial setup is straightforward. If you understand Linux you can deploy in a couple of days.

The implementation was completed in-house.

To access all the features available you require both the open source license and the production license.

I rate the solution seven out of ten.

In cases where the memory of the nodes is exceeded, you will need to manually step in to delete some data, otherwise, the solution maintains itself automatically with little need for human intervention.

The forced merge and forced resonate features reduce the data size, increasing reliability.

The open source license is not enough when dealing with a large amount of data. The production license is required when you have larger requirements.

I recommend the solution to anyone who needs to integrate a lot of old systems into a data lake.

We are mainly using it for analytics reports for the data taken from our call center. We are using the entire stack. We are using Kibana and Elasticsearch. Kibana is the front end for dashboards, reports, etc.  

The flexibility and the support for diverse languages that it provides for searching the database are most valuable. We can use different languages to query the database. 

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.

We have been using it for about one year, but it is not yet in our production environment.

It is reliable.

If you use a cloud platform or a cloud environment, it is easy to scale. 

For on-premises, we are using OpenShift. We are using a cluster on OpenShift, and we are facing some issues, but they are not related to Elastic. They are related to our infrastructure of OpenShift because OpenShift is deployed on VMware, and the storage of VMware doesn't allow us to take backup snapshots in a secure way. We are thinking of migrating this cluster of OpenShift to another platform.

Currently, we have a few users of this product because we have been using it only for one year, and we are the first ones in our company. In the future, we will have more people involved with the product.

We have only used their community support from the discuss.elastic.co site.

There is a free version, and there is also a hosted version for which you have to pay.

We're currently using the free version. If things go well, we might go for the paid version.

It is a good choice, but you have to take your time to learn it. Its learning curve can be hard. 

I would rate it an eight out of 10.

I run the function to review the usage for the team and for the organization itself.

We use this product internally and then some of our business relationships with the other businesses that we have, they get their data from our data. It's more for collaborative data reporting that we have with them.

The most valuable feature is the out of the box Kibana. You plug it in and start the basic analysis on the data out of the box. This also gives a quick way to check the data and the models to figure out what fits the needs.

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.

I have been familiar with this product for approximately four years.

ELK Elasticsearch is stable.

It's scalable, but there are some limitations.

If you are scaling a bit too quickly, you tend to break the applications into different indexes. 

The limitations come in when getting the correlation between the applications or the logs.

It is difficult to get the correlations once the indexes have been split.

We are using the open-source version, that is installed on-premises.

We have not worried about technical support, but the community is good.

Before ELK, we used another solution for internal usage, and also, we used Splunk for different use cases in a different organization altogether.

It wasn't a switch per se, it was a different organization with a different use case.

The initial setup is simple, not too difficult. 

Getting the index, doing your models, and putting the data in, correctly, is done more on a trial and error basis. You have to start early and plan it well to get it right.

We are using the open-source version. 

We are not looking into the subscription because it's on-premises in-house.

For anyone who is looking into implementing this solution, the only tip is to get your models for the type of actual use that you are looking at upfront in order to have a good run.

I would rate ELK Elasticsearch a seven out of ten.

Our primary use case of this solution is for monitoring our logs and infrastructure. We are customers of ELK and I'm a system administrator. 

A positive feature of ELK is that it directly interacts with Elasticsearch. The UI is very nice, and performance wise it's quite good too. A key feature is that this is a reasonably priced monitoring solution.

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.

I've been using this solution for six months. 

This solution is stable. 

This is a scalable solution, we have eight to 10 users. We had initially planned to expand use of ELK because of its cheap price and the services that are included, but given the difficulty with implementation we've decided to go with Nagios instead. 

The technical support people are very knowledgeable but the response time is quite slow which is not very good. 

The initial setup of ELK is more difficult than the setup of other monitoring applications. I was able to carry out the deployment alone. 

For anyone looking to implement a monitoring product with almost no cost or at a cheaper price, I would suggest the ELK stack. However, it does require a high skill set because of the difficulty with implementation. 

I would rate this solution a six out of 10. 

Elasticsearch is one of the NoSQL databases available. My application is a microservices application where the data gets published on a Kafka cube. It allows us to connect to Kafka and get this data in a document format very easily. I'm using Elasticsearch as my backend processing database, where I'm building and reporting using Kibana.

I like how it allows us to connect to Kafka and get this data in a document format very easily. Elasticsearch is very fast when you do text-based searches of documents. That area is very good, and the search is very good.

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.

I have been using ELK Elasticsearch over the last two years.

The price could be better.

I would tell potential users that they have to locate the data source and understand the data. They will have to decide on whether they have to go for a NoSQL or a relational database. 

If it's NoSQL, then what kind of data are you seeing? If it's more textual data, then you're going to read more. So, I would recommend Elasticsearch. Otherwise, you have other databases like MongoDB and Cassandra.

On a scale from one to ten, I would give ELK Elasticsearch a seven.