Elastic Search Reviews

We save credentials, new account information, logs from Palantir Panorama, Firefox logs, traffic logs, GlobalProtect logs from our servers, and Active Directory new users. We're still improving this, but not very fast.

I appreciate that Elastic Enterprise Search is easy to use and that we have people on our team who are able to manage it effectively.

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. 

 I have been using this solution for five years now.

I would rate the stability a seven out of ten. We faced a few issues. 

I would rate the scalability a seven out of ten. 

We don't use the support because we use the free version.

We were able to handle the deployment ourselves. We have one administrator and three users for this solution. So, there are four people in total. 

I use the free version. We use the free version for some logs, but not extensive use.

Overall, I would rate the solution a seven out of ten. The free version is not very useful.

On-premises

I use the solution to store historical data and logs to find anomalies within the logs. That is about it. I don't create dashboards from it.

I find the solution to be fast. Aggregation is faster than querying directly from a database, like Postgres or Vertica. It's much faster if I want to do aggregation. These features allow me to store logs and find anomalies effectively.

I found an issue with Elasticsearch in terms of aggregation. They are good, yet the rules written for this are not really good. 

There is a maximum of 10,000 entries, so the limitation means that if I wanted to analyze certain IP addresses more than 10,000 times, I wouldn't be able to dump or print that information. I need to use paging or something similar as a workaround. That's what the limitation is all about.

I have probably used it for three or four years, maybe longer.

The solution is very good with no issues or glitches.

In terms of scalability, I have multiple Search instances. I can actually add more storage and memory because I host it in the cloud. It's much easier in terms of scalability, and I have no complaints about it.

I have never talked to technical support.

Neutral

I am using Elasticsearch.

The initial setup is very easy.

I did not use any outside assistance.

I don't know about pricing. That is dealt with by the sales team and our account team. I was not involved with that.

I am evaluating InfluxDB as well. Timescub is a kind of database.

I would rate Elasticsearch at eight out of ten.

Public Cloud

Other

For me, the primary use case of Elasticsearch is log analysis, as it is a text-based search tool. To explain how it works, let's consider its role at the backend. Elasticsearch operates on keywords used to fetch data. This is in contrast to some databases, where operations might be based on a key order or a primary key, allowing for various maintenance and analysis tasks.

Many people use Elasticsearch to store their application logs in JSON format. These logs are indexed, facilitating efficient search and analysis. Additionally, Elasticsearch integrates well with tools like Grafana and Kibana, enabling users to create diverse dashboards for data visualization.

There's also the text-based search scenario. For instance, if a user wants to search for something using a specific keyword, Elasticsearch excels in this area by creating multiple indices. 

Elasticsearch is a versatile tool that can store and retrieve information effectively, making it suitable for various applications across different industries.

Elasticsearch is a quick search engine tool. A good use case is saving metadata of your systems for data cataloging. Various systems, like those opened in metadata and similar applications, use Elasticsearch to store their text data. However, the major use case for many is to store application logs and build different dashboards on top of it.

The use of Elasticsearch is very specific. It is not helpful for storing your OLTP data. Elasticsearch's specific use is when you need to provide text-based search functionality. That's when Elasticsearch becomes relevant. 

For instance, for log analysis or searching values, Elasticsearch performs very well. However, there are challenges with performance management and scalability, particularly how developers manage these aspects. 

For example, Kubernetes is a popular choice as it offers the needed features to run your application and allows performance optimization in response to increased system load, and managing itself. If you plan to deploy Elasticsearch with limited or predefined resources, it may not be the ideal setup. 

Therefore, it's better to create ultimate commerce capabilities for it. This is the challenge people are facing in the market and the solution for it. So, this answer combines two aspects: the challenge and its solution.

I have been using Elasticsearch for almost a year now. I'm comfortable working with it and understand its functionalities. 

In our organization, it's not so much about the number of people as it is about the number of products utilizing it. Currently, we use Elasticsearch in more than 12 products. 

It's become essential for any component that requires text-based functionality. Besides that, it's also used for logging to analyze application performance, peak times, etc. Elasticsearch is a basic component of the architecture for each of these products.

Most of our deployments are not exposed to the Internet or public networks; they're restricted to closed networks. We don’t frequently upgrade from previous versions unless a specific use case arises. 

In such cases, we usually turn to the developer community for support. 

Another scenario is when running the application in a careful mode, where the main requirement is to change the image name in the configuration. Then, we check for any changes or incompatibilities with previous versions. Upgrades can sometimes introduce issues if they’re not compatible with existing configuration files, but it's generally not too problematic to handle.

Deploying in Kubernetes is not complex. There are many resources in the market, like DevOps guys and guides, which make the process straightforward. The deployment can be done in a matter of minutes. You basically run a configuration file to set up your application, define replicas, and so on. It shouldn't take much time; even with an expert, it's a matter of a few hours. 

However, the key lies in following best practices and configuring your files properly. If you follow the best practices, you'll likely face fewer issues. But if not, problems are inevitable. 

It’s crucial to analyze these practices, considering factors like bandwidth, data volume, user interaction, and how it's read by different applications. These considerations help in managing resources and scalability, including scaling up and down your Elasticsearch container. These points are vital for running Elasticsearch efficiently, especially for text-based search applications.

You can deploy it as required. Elasticsearch is versatile; you can run it on Kubernetes, in the cloud, or on-premises. There is no limitation in terms of deployment options.

The cost varies based on factors like usage volume, network load, data storage size, and service utilization. If your usage isn't too extensive, the cost will be lower. 

However, if you're dealing with high volumes, you'll need to reconsider the cost-effectiveness. If there are no challenges or bottlenecks in buying a service from a cloud service provider, that might be a viable option. 

But if you're concerned about price or issues like exposing your data to the public cloud, then deploying on-premises and conducting stress testing becomes important. It’s a part of the learning and development process, not just a deployment for production. 

You need to pass through testing processes in the development environment and then move to staging and production. This involves various tests to understand user access patterns, data push, and performance assessment. Deploying on your own requires considering all these factors. On the other hand, if you use a cloud service, many of these concerns aren't your responsibility.

If you're interested in using Elasticsearch as a search tool and for cloud data integration, comparing it with alternatives like Amazon Cloud Search or Azure Search is valid. Many cloud service providers that offer text-search services are utilizing Elasticsearch. They've implemented best practices and resolved a myriad of issues experienced by companies using Azure, AWS, or GCP. 

These providers have integrated Elasticsearch into their cloud offerings effectively. Choosing their services might be preferable due to lower operational costs on your side. 

In case of any disaster or issue, their development and DevOps teams are available to support you. However, if you face limitations, like client requirements prohibiting data storage in public or private clouds, then deploying Elasticsearch on-premises would be your alternative.

I would definitely rate it an eight out of ten,  which is very good. The reason is the active community continuously working on it, and the support from contributors and the support team is notable. Because Elasticsearch is very specific in its use cases. 

It excels in text-based search and creating dashboards for application logs. It provides results and functionality that are hard to find in alternative tools. So, if you have a use case that fits, Elasticsearch is a great service without any direct alternatives.

We use the solution mainly for logs today. There are other teams that use it for other use cases. We just use it for logging and logging search and these kinds of things.

The search capabilities are the best that we could find. It's great for searching for any text with wild cards inside the logs. It's very good. We have a very good performance, even with billions of registries.

The solution is stable and reliable. 

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.

We've been using the solution for three or four years. We've used it since 2019.

This is a very stable solution. It's reliable. There are no bugs or glitches. It doesn't crash or freeze.

It's scalable in the sense of pods or quantity or numbers of requests, yet not so scalable when considering persistence. We can't handle too much long-term data.

We have at least 500 people using the solution right now.

As a bank, we have some constraints around using and adding new tools. It's very difficult to change stacks. Therefore, we have no plans to stop using the solution anytime soon. 

I've never directly worked with technical support. We have our own support comprised of our own employees. I do not deal with external support services.

We did no previously use a different solution. 

I can't speak to the initial setup. The infrastructure team handled the setup. I did not implement it directly.

It is my understanding we needed three or four engineers to handle the deployment and maintenance process. 

I do not have any details about the cost or licensing. That said, the cost is public, and likely, someone can search for the approximate costs online. 

We are a customer.

I'm not sure which version we're using. I'm from the development team. The people who are doing the configuring work would know the version.

I'd rate the solution seven out of ten. It is a good solution, yet not quite perfect.

Elastic Enterprise Search is the repository for time series and data from the onsite instrument that monitors variables in our mining infrastructure called tailing dams. We monitor the tailing dams' physical stability and take the information from the sales force and manual data introduced by the operators. The system captures the information in the Elastic Enterprise Searchtime series, and we make calculations and trigger events and alerts based on those calculations. We save them as well as the events and alert times.

Elastic Enterprise Search is a nonstructured database that can manage large amounts of nonstructured data. We also use a structured SQL database. I am unsure why our technical people selected Elastic Enterprise Search. The people that started the project selected open-source software and recommended the ETC component required in the system architecture. The Elastic Enterprise Search has been defined from the beginning of the project and fulfills the project's requirements. However, there is a lack of technical people to develop, implement and optimize equipment operation and web queries. This may be a problem with the provider, and they currently lack the resource to optimize the performance of the database.

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.

It is fairly stable.

It is a scalable solution. 70 people are working with this solution in the project, 35 on the development team and 20 backend people. We are working on the development, but it's part of the service that the Indian company has to provide. There are about 50 people on their development team who deal with all the development, infrastructure implementation, architecture definition and implementation of the software stack. We are the counterpart of that company.

Since it is open-source, we don't pay licensing fees. In the development and QA environment, we don't pay anything. We, however, have to pay for all the software, subscription, pre-protection and protection.

I rate this solution a seven out of ten. Because it is open-source, there is no technical support provided by the vendor, so we are moving to enterprise subscriptions for each of these products. We are allowed free licenses and implement enterprise or commercial licenses and the production of protections.

An original criterion selects the software stack because they have to be good tools, but they all have to be open-source. Nobody considers it because the original team that started the project worked in an investigation organization and was closer to open-source software.

They are not clear regarding the support of their solution when they go into production. That's why we are updating the licenses to interpret license subscriptions and assume their support for each software component.

Using real-time search functionality to support operational decisions has been helpful. However, it is not functioning correctly, as the real-time search consumes significant system resources.

The search feature is one of the valuable features of Elasticsearch.

There are areas for improvement in Elasticsearch.

The real-time search functionality is not operational due to its impact on system resources. There are some stability issues.

My overall experience with support was positive.

Neutral

The initial setup is complex.

I do not have specific details about the implementation team. The process might require certain expertise.

The pricing is not cheap and is expensive.

I compared the differences between Elastic and other SIEM solutions.

I am more like an implementer than a customer.

I'd rate the solution seven out of ten.

Other

The primary use case for Elasticsearch is to serve as a non-SQL database platform to replace traditional SQL processes. It is used in situations where unstructured data needs to be studied and searched.

Elasticsearch has been helpful due to its ability to handle unstructured data effectively compared to SQL. It provides a fast and interesting search capability which is advantageous for our needs.

The most valuable feature of Elasticsearch is its convenience in handling unstructured data, making it easy to use.

Elasticsearch could be improved in terms of scalability. If the database becomes too large, its efficiency is not as good as SQL. Additionally, the initial setup could be a little easier.

We have been using Elasticsearch for about two to three years.

We have faced shutdown issues, but these are mostly related to problems with our own machines and not due to Elasticsearch itself.

Elasticsearch is not scalable when dealing with very large databases. The efficiency decreases for huge databases because it deals with unstructured data, which presents an inherent problem.

The initial setup is of medium difficulty since it requires some understanding of the disk and related concepts.

Elasticsearch can be expensive. It requires some support and unlocking of features.

I recommend Elasticsearch for anyone looking to build a simple database, as it should be a top choice.

I'd rate the solution seven out of ten.

Elastic has a lot of products. The one I'm most familiar with is Elastic Observability. It's designed to monitor our applications within an organization. It gives managers visibility into the activity and functionality of applications within the network. I've worked with it both on-premises and in the cloud. It helps us monitor applications and identify any issues. For example, we can see if an application is calling on a database if there are any delays or errors, and what might be causing those problems. It can also give us a proper view of the number of transactions done on the database and other information. It's not just pulling data for us; it's giving us real-time insights into the activities and functionalities of our applications within our network environment.

When users understand the root cause of the problem, they spend less time resolving it. The number one benefit is end-to-end stability. It provides deep visibility into your cloud and distributed applications, from microservices to serverless architectures. It quickly identifies and resolves the root causes of issues, like gaining visibility into all your cloud-based and on-prem applications. It also simplifies issue resolution, leading to faster resolution times and optimized performance. It is achieved through numerous tools, metrics, and application performance fine-tuning systems, ensuring a smooth user experience. That's why many enterprises seek this kind of solution. It provides valuable insights into potential security vulnerabilities, enabling pre-emptive measures and safeguards for your data assets. Then there's data-driven decision-making, which is very important! It breaks down data silos by ingesting all the telemetry data (metrics, logs, etc.) into a single, scalable platform with a contextual data model. This flexibility allows you to collect and visualize any data from any source. Essentially, it pulls data from all sources and guides you in making data-driven decisions for capacity planning, resource allocation, and risk mitigation. Finally, it also fosters collaboration across IT teams.

There are potential improvements based on our client feedback, like unifying the licensing cost structure, which might be helpful for clients. This room for improvement is from my perspective as a salesperson. Because when I give customers the pricing information, they might wonder why there are two different licensing models, unlike competitors like BeyondTrust or Delinea. Delinea also has the same thing with the code.

I have been with this solution for more than six months.

It's very, very stable. Most times, I go through the demo sites, which allows understanding of functionalities and use cases and all of that. I would rate the stability a nine out of ten.

It is a scalable solution. I would rate the scalability a nine out of ten.

The customer service and support are very nice.

Positive

I have experience with Delinea, ManageEngine, BeyondTrust, IBM and WALLIX. But compared to Elastic, they lack the same level of artificial intelligence capabilities. It's like an all-encompassing package with tons of features. One of those features is the ability to pinpoint the root cause of any problem, whether it's code issues (like it was not written properly), developer errors, or anything else. It goes beyond just surface-level troubleshooting and digs deep to give you the real why. That's what sets it apart from the others. Imagine an application is having some issues. Elastic can tell if it's faulty code, a developer mistake, or anything else. It gives you the true root cause, not just the surface-level symptoms. That's its strength and why it stands out as the industry standard.

The initial setup is not complex to me. I've seen it displayed before in a demo presentation with Jakadaz. The solution is not difficult to use. It's very easy. Even as a non-technical person, I could interact with the application.

The deployment doesn't take long because we have experts who can help. It's available both in the cloud and on-premises, so it depends on the customer's choice.

It is a cost-effective solution. It is not expensive.

I would rate it a nine out of ten for now. It has a lot of features compared to other solutions. Its comprehensiveness and range of features are what make it stand out for application monitoring. I highly recommend it. It's very good because it's efficient, highly scalable, and has high availability. Additionally, cost-effectiveness is crucial in Nigeria due to exchange rates. Organizations need solutions that are affordable, and Elasticsearch fits the bill. I would absolutely recommend it to any organization.

Hybrid Cloud