Elastic Search Reviews

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.

We try to detect malicious files by the logs. The logs are all centralized including all our PCs, our callers, our servers, Linux, windows, Polaris names. We scan everything. Then we have pre-defined specific use cases that allow us to identify if there is an attack on the machine or indirectly by the endpoint. On top of that, we can check with users as we're not directly dealing with the configuration, so we can follow up on the alerts we receive. On top of that, we have the systems in place that allow us to detect if certain inexcusable items are on the system, such as malicious files. We can do this because we also retrieve the log files of the identifiers.

The fact that you can dump any type of format in the database without any specific reformatting is fantastic. It makes it very flexible in collecting information and that saves us a lot of time because otherwise, we would really need to define specifically what we're looking for and reformat everything. With this solution, that's not necessary. We can directly, and in a really standard raw format, dump the data into the database. Only afterwards do we need to define what specifically we're looking for, however, at that point, it's not a big deal to actually add an additional log and to collect additional information. 

The solution is very scalable. 

There's lots of processing power. You can actually just add machines to get more performance if you need to. It's pretty flexible and very easy to add another log. It's not like 'oh, no, it's going to be so much extra data'. That's not a problem for the machine. It can handle it.

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.

This solution has been used for at least five years at the company.

It's very stable. The only thing that might happen is that sometimes when you do a search it will stress the machine a bit too much. If that happens, then it's a matter of, if you do it the wrong way, the machine gets stressed and then it slows down. However, it will not crash. It almost never crashes. You'll simply figure out that the machine is overwhelmed and take the stress off. 

The problem, occasionally, is that it may become unresponsive, but it isn't really unresponsive, it's just that the system is overloaded. That can only happen if you do your database search in the wrong way. That's why, especially when you have a lot of data and are really concentrating a lot of data on a few machines, you have to be careful of what you're doing. 

It's a very nice tool but you have to be a bit aware of how to deal with this, especially when you have a lot of data and you have limited processing capacity. If you have unlimited processing capacity you can do whatever you want with it. I personally can say that I've never seen a machine crash.

The scalability of the product is good. It's our key system that generates alerts and does surveillance on a security level. This product is extensively used in our organization.

We have people of course, from the server team that makes sure that the logs get collected. And then we have the people that actually deal with the configuration of the ELK as well. That is a team of five or six people that we use now. Then, of course, we have all the teams that follow up on the alerts, and there, I would say, we have two or three different teams, which is between 10 and 20 people. That's just part of the people that work with the solution.

I work on part of the team that deals with technical support issues. There's a good community around the solution. This is because the product is actually open-source. With a lot of typical issues, you can simply Google questions and you will find the answer. Of course, we do have a support contract with the company. I don't deal directly with that, however. We contact them directly if we really need to and we have maintenance contracts with them. Unfortunately, I can't really speak to how good or bad they are because I've never called them myself.

Before we switched over to this, we used it in combination with an end product called QRadar, but both of them together were time-consuming. 

It's easy to install the servers, that's not really the problem. The difficulty is afterward. Users need to understand how to explore the data.

The server setup is the easy part. Even, let's say, moving the log into the machine or into the database is no problem. However, then you have all this data and you will really struggle to understand the information. That is sometimes not always obvious at the outset. In order to do that in an effective way, it requires a little bit of manipulating.

To install the servers, a minimum installation takes me a day or more. It's for the most part usually pretty fast.

I myself have already had quite a lot of experience with the product. Therefore, I can set it up myself.  Most customers or most IT departments will struggle to set it up due to the difficult learning curve in the beginning. 

I would definitely recommend most users or companies, at least for the beginning, to get help troubleshooting problems. It will help them understand a little bit more about the steep learning curve. It really makes things much easier, and much more effective. 

I have used different products myself due to the nature of my work. I'm a security consultant. I have been working with different customers who use different solutions, which means that I have used other things and can evaluate and compare them for clients.

I've worked with Splunk, for example. Splunk, for instance, on the level of data mining and inquiring, might be easier. It's a bit more intuitive. The downside of it is as soon as you start collecting a lot of data, it becomes extremely expensive to use Splunk. It's a very good product. However, typically, with the need to collect as many logs and as much data as possible, Splunk becomes expensive, and you can't put it in a budget easily. It's simply out of budget for many as soon as they start clicking. Also, the purpose of a security system is not the same.

With Splunk, some will not add additional logs because they don't often have the budget, especially when it immediately means that you're going to need to increase your costs enormously. That's not the purpose of a security system. For the system to be effective you must be able to have good surveillance and that means that you should not hesitate in adding your logs. Still, when the costs double, people hesitate and if they don't have the budget and cut the logs, things can get through. Fortunately, with ELK, you don't have that issue. With ELK you don't pay for gigabytes, or terabytes or the data that you use. That's the main advantage compared to Splunk. But Splunk, it has a less steep learning curve.

I'm just using it as a customer

We tend to use the latest versions of the solution. We try to upgrade it on a regular basis.

I'd advise other companies considering implementing the solution to get a team in that knows the product and try to take advantage of their knowledge. It will help reduce the pain of the learning curve.

I'd rate the solution eight out of ten.

I would not give it a ten because of the steep learning curve. I know what the product is, but many do not, and for them it will be quite difficult to get started without becoming very frustrated in the process. 

Elastic Search is added advantage for us because we normally use it for our uptime monitoring and our log analysis. When we merge it with Splunk, it helps us correlate and do security monitoring. 

Elastic Enterprise Search comes embedded within a solution that we have developed for our clients. It's a payment solution. We've recently shipped it with Elastic Enterprise Search embedded. All the logs and all the internal communications get captured by Elastic Enterprise Search. It makes it easy for the IT teams who are doing uptime monitoring and troubleshooting to have a look at it. We have the security teams develop their own monitoring metrics and logs, if they wish, based on their deployment. 

The beauty of Elastic Enterprise Search is if they also have their own third-party tools, there's the ability to integrate and read off Elastic Enterprise Search and have any third-party tool process the logs as well. It is highly extensible.

The most valuable features of Elastic Enterprise Search are it's cloud-ready and we do a lot of infrastructure as code. By using ELK, we're able to deploy the solution as part of our ISC deployment. 

The extensibility and configurability of the solution are great. Having the ability to mine for anything is useful. It's extensible and useful in terms of digesting any type of information. Since we do a lot of consulting, it means we are able to apply it to diverse environments without having to suffer the overhead of integration.

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.

I have been using Elastic Enterprise Search for approximately four years.

I have no complaints in terms of stability. However, you have to make sure you give Elastic Enterprise Search the minimum resources it requires. We have not seen any major issues that we would send back to the vendor or the solution maker. If there was an issue it most likely would be from the environment, depending on how it was deployed and how it was configured.

Elastic Enterprise Search is scalable. In our environment, we deploy it in a containerized environment. For us, we've experienced the scalability of the solution because as we grow and expand, we spin up more containers that are interconnected. I don't see any issues with Elastic Enterprise Search from a scalability perspective. 

There's a lot of material available online. We tend to look online before we reach out for technical support. We have not needed to contact the support and this is a testament to how much information is available online. 

The solution is not expensive because users have the option of choosing the managed or the subscription model. 

Elastic Enterprise Search is a very good solution and they should keep doing good work.

I'm a very satisfied customer because almost everything I need comes out of the book. You already have machine learning, alerts, the ability to search, APIs, inbuilt security, and integration to third-party authentication.

I rate Elastic Enterprise Search a ten out of ten.

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.

We use ELK primarily for enterprise monitoring and analytics through log ingestion. The data collected in Elasticsearch will be used for near real-time monitoring, analytics, and machine learning.

All new applications have been onboarded and used by the application teams. The initial feedback has been positive, and its capabilities seem to be a descent fit for our needs.

ELK being an open source certainly provided a platform for our organization to get involved. 

X-Pack provides good features, like authorization and alerts. An X-Pack license is more affordable than Splunk.

Logstash has been a challenge and needs improvements in data ingestion reconciliation. The Kibana Cross Cluster feature is long awaited and I hope 6.0 will address it without issues.

ELK has been considered as an alternative to Splunk to reduce licensing costs.

We use the product for log management. 

The products comes with REST APIs. 

Elastic Search needs to improve authentication. It also needs to work on the Kibana visualization dashboard. 

I have been using the product for six years. 

I rate the product's stability a nine out of ten. 

I rate Elastic Search's scalability a ten out of ten. 

The technical team needs to improve their response time. 

Positive

The tool's deployment is easy. It took us one day to deploy a seven-node Elastic Search cluster. 

Elastic Search is open-source, but you need to pay for support, which is expensive. 

The solution suits medium to large companies better. I rate it a nine out of ten. 

ELK provides 

• good end to end log monitoring
• Logstash grok pattern
• elasticserach indexing
• easily configurable Kibana dashboards
• feature rich and appealing Kibana UI, as its USP.

The product offers a powerful, cost effective solution for proprietary log management and is easy to understand and start with. This saves cost as well as enhances usability.

The open source version should ship basic security versions with it. Alerting is an important feature which is not available in the open source stack.

About two years.

Stability issues can be seen with Logstash and can be addressed using Kafka. Also, data collections may not be 100% optimal using Filebeat and could be further improved.

The product is highly scalable, especially on the database side (elasticserach).

Have worked on the open source version and, hence, I don't have much information about tech support.

I have not worked with another solution.

The setup is straightforward for PoC, but becomes complex while scaling it or deploying it for production.

Yes, I evaluated GrayLog and Fluentd, but ELK was more feature rich.

The ELK open source stack is rich in features but lacks the essential security features.

ELK is one of the best open source alternatives for log management. If alerting and security features can be built by the team internally, on top of the stack, then the product is for sure going to add a lot of value to business.

We are internal integrators. We are in the bigger group as of now, but other groups, our clients, are affiliates from our group. They are our internal clients. 

The solution is currently on-premises.

I was mostly responsible for the SOC team, and I helped them create the detection rules for the production. I wanted to know how it could be implemented in different kinds of products, like Sentinel.

The most valuable features are the detection and correlation features.

Something that could be improved is better integrations with Cortex and QRadar, for example. 

I have been using this solution for no more than one year. 

Not really, because I'm not the engineer and so most problems appear during the installations or maintenance and I'm not in developing infrastructure operations.

The price of Elasticsearch is fair. It is a more expensive solution, like QRadar. The price for Elasticsearch is not much more than other solutions we have.

I would say that Elasticsearch is better than all the other solutions. QRadar is getting better, but it is still behind Elasticsearch in my opinion.

I would rate this solution 8 out of 10.

I would recommend Elasticsearch if you don't have bigger budget limitations to use other enterprise solutions or if you want to avoid the vendor lock-in.