Elastic Search Reviews

At Shopee, I worked with numerous database schemas to find out which table columns belonged to which schema. We utilized Elastic Search to manage metadata for millions of tables, allowing us to search efficiently. Besides that, we used Logstash to put all the log files in Elastic Search for easy searchability.

Elastic Search significantly improved my work. Previously, when searching for text that appears in the middle of strings, the process was time-consuming. Elastic Search enables efficient searching, enhancing system performance and responsiveness. I can also collect logs through Kafka, send them to Elastic Search, and create indices, thus managing logs and customizing searches easily.

Elastic Search provides features such as stemming and range-based queries to search log files efficiently. It allows filtering data easily by searching for specific words based on created indexes. This made searches very efficient, and it also allows for log collection through Kafka and helps with managing logs and customizing searches according to needs, such as grouping by dates or user IDs.

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 is stable as many companies already use Elastic Search. In cloud scenarios, it manages well by scaling up or down based on peak traffic. Otherwise, similar functionality needs to be replicated in a private cloud, including backups.

Elastic Search requires enhancements for handling huge amounts of data and updates. Segmenting or sharding data and complexities regarding the cluster can be issues. Updating in Elastic Search involves index computations and user dependencies. There might be issues regarding data size and scaling, but these can be tuned and improved.

I remember Apache Solr, which is generally used for much larger scale data compared to Elastic Search. Apache Solr is used by most companies, and while Elastic Search is very common, there are technologies similar to Elastic Search, though I'm not familiar with all the names.

I have used Elastic Search, but I might not be aware of many internal details; I just used the API to create an index, manage data, and search. It's very useful. On a scale of 1-10, I rate it an eight.

Private Cloud

Other

It is basically for the banking and non-banking sectors. We use it for the APM perspective and application performance monitoring, but not in a holistic way; it is just layer seven, layer five, and six that are there.

In analytics, people use it for search patterns. I've also used Elasticsearch for indexing, where we can have content and do these things. But from an analytics perspective, I have never used Elasticsearch. I have used it in one project

It's a good tool because if you compare it with MongoDB, MongoDB is better. It has a very good data warehouse and search pattern. Elasticsearch cannot be made into a data warehouse. You can use it for smaller-scale analytics, but if you are looking at anything over 30-40 TB, it's not a data lake or big data solution. 

It's a normal database, and any Oracle database or enterprise DB like MSSQL or PostgreSQL can do these things. I've never used it for unstructured data. I have used MongoDB, but not for this.  

All features are almost the same as other observability tools. The best part I like is that it becomes a MOM aka monitoring of monitors. It can capture data from all other sources. It's not a unique feature of Elasticsearch itself because other tools like Dynatrace do do the same thing. But from an ROI perspective and a user-friendly perspective, it is a good tool.

Even at level four to level seven of the OSI model, it does monitoring very well. There are a lot of AI-embedded tools or prediction tools, and numerous default reports are available, which get populated easily. 

So, the quality features are there. There are about 60  to 70 odd reports available. When you deploy the tool and the logs come in, they can capture those logs and automate field mapping and other things. That's the feature—by default, a few reports are available.

The data indexing capability of Elasticsearch is very good. It does the indexing correctly. It's not over-indexing, so it's perfect. It's very good. But how it works depends on the customization of the application and the search pattern you want. The log can be easily viewed, and based on that, you can easily tag things.

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 have been using it for more than four to five years. 

I would rate the stability a nine out of ten. It is a good product. It is a stable product. 

Elasticsearch has horizontal scalability. The users can scale up to any level. The only problem is related to disaster recovery. After some time, it becomes very difficult to do the DC/DR mapping because observability is a critical tool for event alerts. It becomes difficult to manage real-time events if the primary data center goes down and the disaster recovery site needs to take over. This is an issue for large projects like those at tier-one organizations like Ford or big banks. For mid-level and lower-level tier-two or tier-three organizations, it is good.

Another thing to consider is that Elasticsearch has high resource utilization on both the vertical and horizontal levels. But it's a good product for tier-two organizations.

All my clients are enterprise businesses. 

I've never heard anything wrong from the delivery side, but it's an international company with a very good product. So, the support system should be good.

Positive

I tried to sell Kibana twice, but in terms of deployment, we've used it in two or three places. However, I don't have hands-on experience with Kibana. 

To be very honest, we faced some setbacks with Kibana, particularly with network-level monitoring. This issue occurred a few weeks ago when I tried to sell one of our products. We have used Kibana for APM purposes, as well as the Elasticsearch ELK stack.

From an application perspective, it’s one of the tools we use. I can share a lot of insights, but I haven't seen all their reports or dashboards. So, my experience is from a presales perspective rather than a deployment perspective.

If I compare it with other auxiliary tools like Dynatrace, SolarWinds, or Relay, Elasticsearch is very competitive and user-friendly. 

One thing about Elasticsearch is the way they sell licenses for their database, which can be a bit hidden. Many people think Elasticsearch is entirely open-source, but there are charges involved. It's an MPP-based NoSQL database with some limitations on certain datasets.

I would rate my experience with the initial setup a nine out of ten, with ten being easy. It is easy, not that difficult. 

It can be deployed both on the cloud and on-premises. I've seen on-premises deployments. This is especially true in other parts of the world where governments don't want to use the private cloud and have their own private cloud. I have mostly worked with on-premises deployments.

The mapping can take three months on average. However, the deployment time depends on the project. If you have a hundred servers, it will take two or three weeks. With three or four thousand servers, it will take longer. It's the same with any tool, like Dynatrace or SolarWinds. We have to map services and events, set thresholds, and configure event triggering and notifications. There's a lot to consider, so it depends on the project scope, the number of servers, the data captured, and whether it's agent or agentless. It's difficult to calculate an average about how many days it will take.

I would rate the pricing an eight out of ten, with one being cheap and ten being expensive. It is not very costly, but it is not cheap either. 

I would rate it to others. Elasticsearch can be used for many things. It has a good indexing parameter and can be used for search patterns and more. 

If it's for observability, I would give it a nine out of ten. The only issue I have is with APM (Application Performance Monitoring).

Elasticsearch as a product is different than Elasticsearch as a search engine. Elasticsearch is also different as an analytics tool. It depends on the analytical solution and how they want to fetch data from Elasticsearch as a database. As a search engine, it is one of the best. 90% of people use either Solar or Elasticsearch for web portals and other things. Nobody can challenge Elasticsearch in that area. So, out of ten, I would give it a ten.

But for analytics, I'd give it an eight. It depends on my database and in-memory tools. If I use QlikView or other tools, I'll just use Elasticsearch as a database. It's just like any other database they are using for in-memory analytics. 

For observability, Elasticsearch, Logstash, and other things, it is a good component. It's good for tier-two enterprises. But when you define "enterprise," you must be specific. If you mean more than 2000 servers, then 90% of people won't consider it. There are other observability tools on the market. So, be specific in your query.

I can describe a project where we use Elasticsearch, Logstash, and Kibana (ELK stack) for our archiving objectives. I work in the security department of a Fintech company in the payment industry. We use the ELK stack to connect our internal systems with the bank's systems and we used Beats for data collection. We then store and forward this data to Elasticsearch for indexing and analysis, visualize and create alerts using Kibana based on categorized access logs, identifying and blocking malicious traffic or payloads.

Logsign provides us with the capability to execute multiple queries according to our requirements. The indexing is very high, making it effective for storing and retrieving logs. The real-time analytics with Elastic benefits us due to the huge traffic volume in our organization, which reaches up to 60,000 requests per second. With logs of approximately 25 GB per day, manually analyzing traffic behavior, payloads, headers, user agents, and other details is impractical.

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.

I have been using Elastic Search for the past year.

We subscribed to NGINX for technical support, and they were helpful during the installation phase. There is a lack of community support for GRPC, which needs improvement. 

we are using a licensed version of the product. 

We are fully satisfied with the usage and support, rating it 8 out of 10. I recommend NGINX for managing traffic due to its multiple functionalities like load balancing, proxy management, and caching.

The main use case for Elastic Search is mainly for log management.

I appreciate the indexing capabilities and the speed of indexing in their product, which demonstrates how quickly logs are collected and stored. The search capabilities are also valuable.

The architecture of Elastic Search could be improved as it is complicated for most general users to build up the environment and maintain the cluster.

Currently, I do not have suggestions for additional functions that could be added to the product.

I have been working with Elastic Search for about two years.

I usually use Elastic Search on-premises, which introduces complexity in deployment. Using the cloud version would reduce the complexity of setting up.

I would rate the stability for Elastic Search as eight out of ten.

I would rate the scalability as eight.

I would rate technical support from Elastic Search as three out of ten.

The main issue is a general sum of all factors. Being based in Hong Kong means I can only assess the service in my region and cannot speak for other regions based on my experience.

Negative

I am currently working with multiple solutions including Elastic Search, Splunk, and Graylog.

The initial setup for Elastic Search is complex.

The real-time analytics capabilities depend on whether you use the paid version or open-source version.

I work with SME users of Elastic Search, though the solution can technically support enterprise customers.

I have not extensively used AI technology with Elastic Search.

I can recommend Elastic Search to other users.

The pricing for Elastic Search rates as four out of ten. Overall, I would rate Elastic Search as seven out of ten.

On-premises

We use Elastic Enterprise Search to develop robust and competitive projects. 

We provide clients with a chance to upload a file. They have all the accounts and transactions that they want to do and we have a limit of 10,000. In two minutes, they can have the 10,000 transactions in their accounts.

I would like to see Elastic Enterprise Search focus on interbank transfers, maybe in another way of payments. We have a feature focused on online interbank transfers. But, it would be good to see current payments for workers. They could also provide this same product to the retail clients. The price support could be improved as well. 

We have been using Elastic Enterprise Search for about a year and a half.

Elastic Enterprise Search is stable. On a scale of one to 10, with one being not very stable and 10 being very stable, I give Elastic Enterprise Search a nine. 

Elastic Enterprise Search is scalable. On a scale of one to 10, with one being not scalable and 10 being very scalable, I give Elastic Enterprise Search a 10. 

Elastic Enterprise Search's tech support is good but it could be improved. 

Positive

The initial setup is difficult. On a scale of one to 10, with one being very difficult and 10 being very easy, I would rate Elastic Enterprise Search a two. 

We are continuously integrating new features. Everything we added this month took about a day each to deploy. We have 22 software engineers on the project, along with two tech leads and one solution architect.

The price we pay for Elastic Enterprise Search is very high. We have a complicated banking project with a lot of components, developers, and features. 

On a scale of one to 10, with one being very cheap and 10 being very expensive, I would rate this solution an nine. Their pricing system is highly complex. 

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

We have a distributed login environment. We have logs in databases and some in files. We use the solution to centralize everything. It's good for monitoring. 

The solution is useful for observing logs. The observability is good. 

It's good for collecting various types of logs. The metrics on offer are great.

We also collect logs from VMs, and we can look at the CPU and RAM situation to see what is being used. 

The APM for our ITSM tools is helpful. It provides good visibility.

It is scalable.

The solution offers good stability.

The initial setup is easy.

We'd like to see more integration in the future, especially around service desks or other ITSM tools. 

I've been using the solution for two or three years. 

The solution is stable and reliable. There are no bugs or glitches. It doesn't crash or freeze. 

It is scalable. It's not a problem if you need to expand it. 

We have about 20 people using the solution right now. We're using it in a test environment right now. Once we deploy to production, 300 to 400 people will use it. 

We have never used technical support. 

Our help desk also uses Grafana. We'll use this solution more widely eventually. 

The initial setup is very easy.

We took about a month to deploy the solution. 

We might need about ten people to handle the deployment and maintenance. We're still in the test environment right now. 

We handled the setup ourselves. We did not need outside assistance. 

I'm not sure of the exact licensing costs. I don't deal with that aspect of the solution. 

I'm using the latest version of the solution. I started with version 7.1, and now I use 8.6.

I'd recommend the solution to other users. 

I'd rate the solution nine out of ten. The features and tools are overall very good. 

On-premises

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.