I have been using Elastic Search for the last five years.

I have a couple of use cases. First, I use it for logging purposes and observability logging of our product. In Azure, Elastic Search has good support. Whenever I deploy any application, it automatically detects the application and tags the elastic log with it. This provides proper logging and observability to our application. That is my main use case. Another use case is making AI agents. In AI agents, I use it for vector search. Vector search means whenever I am searching anything in Elastic Search, which is a database, I can perform vector search on whatever I store in the database. Vector search is similarity search. For example, if I ask what are the petrol prices today, it will try to find similar items such as petrol, diesel, or similar things. If I ask about petrol, it will not only search for petrol but can also search for diesel because they are both liquid forms. Elastic Search has this search capability. I take the similarity search and after that add some of my algorithms to create the AI agent using that.

In traditional search, I get some log file and have to manually find information in it. For example, with text search, I type some keyword and manually have to open it in Notepad++ or any other similar tool. With Elastic Search, it is much better. I can search based on date ranges. For example, if I want to check the last one hour of data, I give the time frame and my application data appears there. If I want to search history, such as what happened one week ago with this application, and some customer provided some issue saying that one week back they received this issue, I can search the logs from one week back and go through those logs. Elastic Search has more search criteria. With different search criteria I can search it. I can also search based on context, where if I select the search in that time frame, it will search just before and after some context for me. That is also available in Elastic Search.

Hybrid search can be used programmatically as well. In Elastic Search, there is one user interface where I can provide a lot of things. That is one part of search. Hybrid search means if I want to search programmatically, I can search and get some data from Elastic Search and use it in my application. For example, if I am developing one agent, I definitely have to write some code and search some data using my program in Elastic Search. In that way, hybrid search is very useful. I can directly connect with Elastic Search database where I store all the data and get the data and use it in my application, wherever I want to use it. For example, if I am developing the AI agent, that is fine. If I want to just apply similarity search, I can also use it in my application.

Observability is one part when I am deploying my application. When I deploy my application on the server in Azure, observability comes into the picture. Whenever I deploy my application, I need the log. Logging means observability, how my application is going on, whether I am getting any issues or whether I am getting any exception in the backend. That comes into the observability bucket. That is one use case of observability. The second is whenever I am developing RAG or AI agent. Whenever I am working on RAG, hybrid search comes into the picture, vector search, hybrid search. For security purposes, whenever it is deployed on Azure, it automatically handles security. I have worked with the cloud only, so I cannot tell much about security on this.

Regarding how I use Elastic Search in generative AI, I mostly use it for observability and RAG. Whenever I am deploying or creating the AI agent, I use RAG. Vector similarity search has been very helpful for me. I have different search criteria based on KNN or cosine similarity that I can use to search on Elastic Search database. The second is observability, which is also very good because most people are using Elastic Search because it is easy to use. As I explained before, I can give criteria by providing a date and time, and I can also see the graphs as well. Whenever I deploy the application, I can see usability graphs. It also shows the flow of data. Flow of data means if much data or some more operations are performed in this time frame, that graph will show as darker. I can easily see this because of small user interface presentations that are very good. I find it very useful in observability, log observability, and RAG development and AI agent development.

Hybrid search will be valuable.

Elastic Search is easy to use in Azure cloud. Mostly, my full company uses Azure cloud, so it is easy to use. Cost-wise, my company found Elastic Search is good. Cost matters. Based on cost and use cases, I found Elastic Search is good. Even compared to Splunk, Elastic Search has good easy-to-use user interface. Even non-technical people can easily search and easily observe the logs and easily track the applications. With Splunk, I found I have to be a little more technical in that area. There are key-based searches and some criteria that I have to remember. I found that difference between Splunk and Elastic Search.

Support-wise, it is good because I did not get much support work. Mostly my DevOps team handles it, but one or two times I did get support. There is a ticket creation option. Within the available time zone, somebody will be there to support me. Within two to three hours, somebody can help and try to resolve the issue.

Elastic Search is not specifically being used for certain purposes. I deploy Elastic Search database on the cloud and use cloud services so that nobody can attack. However, I do not use Elastic Search to resolve attack issues.

The basic main purpose of Elastic Search, as of now, I feel it can do more in the AI area. Sometime I saw that when I am developing RAG and have to generate the embeddings, which I call metadata, sometimes it tries to fail. That durability or issue handling should be improved, but apart from that, I did not find anything as of now. As per my use case, whatever I am using seems pretty good. Apart from that, some definitely improvement will be there. One improvement is that it should be faster. Whenever I am searching any logs, it takes much time. For example, if I open my log in Notepad or a similar tool, I can search the text within a second. With Elastic Search, it takes a little bit of time, ten to fifteen seconds. That can be improved. Sometimes, engineers take time to assign when I create a ticket.

Till now, I did not face any issue with the stability and availability of Elastic Search. It is not that the server is down. I faced issues such as some slowness. Whenever heavyweight logging will be there or heavyweight operations are performed, at that time, it will be a little slow. That sometimes also depends on cloud connectivity. Sometimes the cloud is only down, so it is very hard to perform my application better. I did not face any issue related to availability and other things. It is pretty good till now. The slowness is the one part, otherwise it is good.

Definitely, because I have very big applications in my company. It auto-scales up. Whenever I am deploying multiple instances of my application on a server, as I told, no need to give any configurations. For example, if I have five instances of my application I am deploying, automatically it will configure the five Elastic Search logs. Automatically it will create five Elastic Search configurations. Every application will have their own Elastic Search log. Auto-scaling wise, it is pretty good.

Support-wise, it is good because I did not get much support work. Mostly my DevOps team handles it, but one or two times I did get support. There is a ticket creation option. Within the available time zone, somebody will be there to support me. Within two to three hours, somebody can help and try to resolve the issue.

Sometimes, engineers take time to assign when I create a ticket.

I used Splunk. I have Splunk. Kibana, I think, merged with Elastic Search. I used Splunk and Kibana before. I am using pure Elastic Search now. For the last four to five years, I have been using pure Elastic Search. Before that, I was using Kibana and Splunk.

I am not aware of licensing and cost because I am not from the DevOps team. From a usability point of view, it is very easy to use and easy to plug with my application. I do not need extra configuration. Whenever I deploy my application on the server, I have to give the path of any observability tool such as Splunk or Kibana. Initially, I have to provide some extra configuration so that my log will appear on Elastic Search or Splunk. But nowadays, whenever I deploy my application, whatever logging I am doing is it will automatically connect with Elastic Search because Elastic Search has the capability to track. Whatever logging I am doing, whether it is SLF logging in Java, or in Python, whatever logging I am doing, basic logging is easily tracked by Elastic Search. No extra configuration is needed. It is just easy to plugin. I just deploy my application, and that is it. Automatically Elastic Search will track my log. No extra configuration is needed. I just have to make sure that I have Elastic Search services in my cloud and it should be enabled. That is all. Otherwise, it is easy to plugin.

Elastic Search is easy to use in Azure cloud. Mostly, my full company uses Azure cloud, so it is easy to use. Cost-wise, my company found Elastic Search is good. Cost matters. Based on cost and use cases, I found Elastic Search is good.

Elastic Search is easy to use in Azure cloud. Mostly, my full company uses Azure cloud, so it is easy to use. Cost-wise, my company found Elastic Search is good. Cost matters. Based on cost and use cases, I found Elastic Search is good. Even compared to Splunk, Elastic Search has a good easy-to-use user interface. Even non-technical people can easily search and easily observe the logs and easily track the applications. With Splunk, I found I have to be a little more technical in that area. There are key-based searches and some criteria that I have to remember. I found that difference between Splunk and Elastic Search.

Stack discovery is something I did not use till now. Whenever I am deploying my application on the cloud, and any attacks happen, I have some monitoring services in the cloud. Whenever something happens, if any attack happens to my Elastic Search database, it can happen through log injection. Something attackers can do a direct attack on my Elastic Search database and change some logs. This kind of scenario can come into the picture. I have some monitoring services deployed on the cloud. Whenever outside my company, outside of my company IP is trying to access my database or my data, that time automatically that monitoring alerts will be triggered and it will go to whoever is tagged into the mail. It will go to my higher manager and that mail will go to them. Regarding generative AI and how it will protect, nowadays, what is happening is that if I want to monitor this kind of attack, for that also, cloud is providing GenAI solutions. If this kind of attack comes, how automatically this GenAI resolves my problem, or how it suggests me to resolve the problem. That kind of solution I have already deployed on cloud.

I did not see much or connect with the support people much, but based on my experience, I would rate customer service as a four out of ten.

My overall rating for Elastic Search is eight out of ten.

I am a customer, and I use Elastic Search to enhance our search capabilities in our applications.

Elastic Search has excellent features, particularly its scalability and speed. What I appreciate most about Elastic Search is the ability to handle complex queries efficiently. I assess the relevancy of the search results by comparing it to hybrid search methods, such as vector and text searches, which helps ensure the accuracy of the results.

I see that there are areas in Elastic Search that have room for improvement, such as user documentation and onboarding processes.

Regarding the stability of Elastic Search, I find it to be quite robust, and I rate it a 9.

Regarding technical support, I would rate it an 8 because they are responsive and helpful.

The deployment took about two weeks, as we needed to ensure everything was configured correctly.

I compare Elastic Search with other solutions, such as OpenSearch or Algolia, in terms of features and performance, which are quite impressive.

Elastic Search requires regular maintenance, including updates and patching to keep it running smoothly, and upgrades are straightforward to implement.

I have used Elastic Stream for log investigation, which has been very helpful in diagnosing issues. We have about 50 active users in our organization.

As a developer, I use Elastic Search in developing one of my applications, basically integrating the back-end with Elastic Search.

Our main use case for Elastic Search is for Logstash, which is a subset of Elastic Search that allows us to store logs and enables searching between logs with specific keywords in specific time ranges. Apart from that, we have our data stored in an index, and since Elastic Search is a NoSQL database, that's how we store the files in our databases.

The main objective of integrating Elastic Search is to transition from normal SQL databases to have faster searches and dynamic queries built around it, which makes the search much quicker. Since not all data is structured, we also need to handle unstructured data, and that's how Elastic Search has replaced our previous system.

The positive impact I've seen from using Elastic Search includes replacing conventional databases and being able to store much more unstructured data. In the future, if we need to include data not present in earlier systems, we can implement semantic or flyway changes with Elastic Search in place, allowing us to store unstructured data as is.

The most valuable feature of Elastic Search that I appreciate is the dynamic query building and the speed of result fetching, especially since we have an open-source version called OpenSearch that we use in specific places due to the cost of storing data with Elastic Search.

Dynamic query building and result fetching are valuable because there are specific use cases where we need to build queries based on environment variables rather than having a generic query. This dynamic building helps address various business scenarios, especially considering customer product types and flags that may need inclusion or exclusion in the query. It allows me to create one query to accommodate multiple business cases and ensures that user-specific scenarios are included, with results already fetched for each.

Elastic Search has many features, including Kibana and Logstash, which we regularly use. However, one downside in our product is cost, as it can be expensive when maintaining multiple shards and indexes. Failures of shards or nodes can occur, and I can mention that cost and the upscaling of nodes or shards are areas needing improvement.

We haven't explored the hybrid search feature of Elastic Search, which combines vector and text searches, yet.

Scalability of Elastic Search presents disadvantages, particularly when handling minimal or production-level data. It manages high volumes of unstructured data well, but during performance tests involving one million requests at once, we encountered issues with shards and nodes not upscaling as needed, leading to crashes and minimal data loss, which isn't typical in real-world scenarios.

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

Elastic Search is quite reliable for us, and despite identifying some very minute limitations, we still rely on Elastic Search.

Scalability of Elastic Search presents disadvantages, particularly when handling minimal or production-level data. It manages high volumes of unstructured data well, but during performance tests involving one million requests at once, we encountered issues with shards and nodes not upscaling as needed, leading to crashes and minimal data loss, which isn't typical in real-world scenarios.

I have not communicated with the technical support of Elastic Search at all up to this point.

Before Elastic Search, we used Couchbase, which is also a NoSQL database. Initially, it was free software integrated into our applications, but with its commercialization, we explored alternatives and found that Elastic Search would be a better fit than Couchbase.

We conducted some preliminary research to find a potential replacement for Couchbase while searching for NoSQL databases. The good documentation for Elastic Search on various websites helped us conclude that it would be an ideal fit. Although we considered the open-source version known as OpenSearch, we decided to integrate Elastic Search to explore its features, eventually determining it had much more powerful features, such as the Kibana dashboard and Logstash.

With respect to performance, we have seen a return on investment from Elastic Search. For example, the API response time has improved significantly, cutting the time down from about one or two minutes to around 50% faster, benefiting our downstream applications.

Elastic Search use cases for us involve maintaining a huge amount of data per day, around millions of transactions for each record. We are maintaining all this data with Elastic, and Elastic is doing a fantastic job by doing the indexing. The algorithm is very good, enabling us to process the data very fast.

We are conducting searches with Elastic Search because the data volume is too high. With a couple of indexing configurations, we are able to achieve our goal.

A good feature of Elastic Search is that they have something called policies, which we can make hot and cold, all related to data retention, and that is what I appreciate the most.

From the UI point of view, we are using most probably Kibana, and I think they can do much better than that. That is something they can fine-tune a little bit, and then it will definitely be a good product.

Maintenance in terms of Elastic is that they can improve the UI and UX, and if they fine-tune it a little bit, then it will be much better.

I have used Elastic Search for the last two years in my career.

So far I haven't noticed any lagging, crashing, or downtime with Elastic Search.

The scalability of Elastic Search is good, and I am satisfied with that as of now, and the performance is good.

I don't think I have ever had to contact technical support.

I find the initial deployment of Elastic Search easy; it is quite straightforward.

Approximately, I am able to deploy Elastic Search within two to three hours for the first time.

To deploy, one or two people will be enough because you need Logstash to be configured to bring the data to Elastic Search for indexing.

We tried to implement big data pipelines and all, and we tried to use Spark as well for analytics and data cleaning, but I think Elastic is better in that field. I didn't find anything better than that.

My use case has evolved over time with Elastic Search. Initially, we started with it as a searching solution. Before Elastic Search, our primary source of truth was SQL databases, the traditional RDBMS. We thought about taking the data from the traditional RDBMS because they were not able to cater to the scale that we wanted to achieve, so we migrated the data from MySQL, keeping it as the primary source of truth, but for the searching mechanism and wildcard searches, we migrated to Elastic Search.

My experience with the relevancy of search results in Elastic Search includes both traditional keywords and full-text search. In the supply chain industry, with millions of orders and customers such as CMA CGM, Maersk, or Kuehne+Nagel, filtering out those orders was essential, using a shipment number, transportation order number, or an origin or destination number. In the gaming industry at FDJ United, full-text searches make more sense to understand gaming intent. For example, when a user searches for 'I really want to play action games', we break down that full-text query, use custom text analyzers, and derive the intent behind the user's query in combination with a vector database alongside Elastic Search.

My assessment of the effectiveness of hybrid search, combining vector and text searches, shows that Elastic Search is remarkable for text-based searches. I have explored other solutions, but none can beat Elastic Search in that area. When I combine hybrid searches with vector databases, they store the mathematical representation of the data. For instance, to find the top 10 closest proximity based on a query, the vector database uses cosine similarity on the available data and suggests the top 10 results while Elastic Search can keep the metadata, enabling quick access to the entire database based on derived intent.

I have utilized trusted GenAI experiences related to semantic search and text-based search in my current project using Elastic Search. My go-to solution for text-based searches will always be Elastic Search, but for semantic search, I am trying to build a solution that emphasizes system-level understanding agents. For example, if a new engineer queries the agent for a system explanation, it scans all the relevant data and provides a comprehensive analysis of the service, contextualizing inputs to reduce hallucination, controlled temperatures for the LLM model, and reducing nucleus sampling. As for knowledge preservation, I use a vector database to store significant outputs generated by the LLM, depending on user preferences regarding the gravity of the analyses performed.

The best features of Elastic Search that I appreciate include its capability for eventual consistent systems where you do not need hard consistency, and it scales very smoothly. For wildcard searches and regex patterns, it really scales massively. It offers ILM, indexation lifecycle management, which allows you to enable a search for a span of six months for the data fed into the system while moving the rest to a new cluster. The structure of the inverted index document facilitates its core features, and I find how Elastic Search understands, indexes, and creates mappings for your data to be remarkable.

While Elastic Search is a good product, I see areas for improvement, particularly regarding the misconception that any amount of data can simply be dumped into Elastic Search. When creating an index, careful consideration of data massaging is essential. Elastic Search stores mappings for various data types, which must remain below a certain threshold to maintain functionality. Users need to throttle the number of fields for searching to avoid overloading the system and ensure that the design of the document is efficient for the Elastic Search index. Additionally, I suggest utilizing ILM periodically throughout the year to manage data shuffling between clusters, preventing hotspots in the distribution of requests across nodes.

I have been using Elastic Search for more than six years.

In terms of stability, I would rate it eight out of ten regarding downtime, bugs, and glitches.

For scalability, I assign it a ten out of ten.

I would rate Elastic Search's technical support as nine out of ten.

Before Elastic Search, our primary source of truth was SQL databases, the traditional RDBMS.

Estimating the return on investment from Elastic Search is nuanced; however, I can share that initially, search times from traditional RDBMS were around two to three seconds, and with Elastic Search, we reduced that to 50 milliseconds, indicating a significant improvement.

Assessing the complexity of deploying Elastic Search, I have a gray area because a separate DevOps team handles that aspect, but from my experience writing code and utilizing its features, I find it not complex at all.

Estimating the return on investment from Elastic Search is nuanced; however, I can share that initially, search times from traditional RDBMS were around two to three seconds, and with Elastic Search, we reduced that to 50 milliseconds, indicating a significant improvement.

On the subject of pricing, Elastic Search is very cost-efficient. You can host it on-premises, which would incur zero cost, or take it as a SaaS-based service, where the expenses remain minimal.

When comparing Elastic Search to other vendors and products, I have recently explored Algolia, which is also a fully managed service. Elastic Search offers a choice between hosting on-premises or as a fully managed service, which has been beneficial compared to other solutions.

In my company's relationship with the vendor, I have always worked in product-based companies using Elastic Search, often as part of solutions from companies such as Manhattan Associates and in the gaming sector. For B2B industries, they sold to large clients such as Maersk and CMA CGM while my current company, Agoda, operates in the B2C space.

Elastic Search does require some maintenance, especially when considering features such as ILM if you want to enjoy its capabilities. Maintenance tasks depend on the established data pipeline and may introduce some friction.

Currently, we are not using Elastic streams for log ingestion; previously, we utilized the ELK and EFK stacks with Logstash for log ingestion and Kibana for visualization. I also observe a trend where companies migrate to Grafana Loki instead of ELK.

Regarding integration aspects, Elastic Search has exposed REST APIs for all its services, making it easy to integrate with third-party models or endpoints regardless of the underlying infrastructure, as any modern development language can interact with these REST services.

I have not used the attack discovery feature.

My deployment of Elastic Search is on-premises.

At Agoda, we handle over 1.2 billion searches daily, facilitated by Elastic Search.

While I have been at my current company for four months, I am still getting to know my colleagues; however, I know there is a dedicated team focused on Elastic Search. This team exposes a service that acts as an intermediary for communication between Elastic Search and other services.

In my department, there are more than 100 people, whereas the overall organization consists of thousands, exceeding 10,000.

I would rate this review overall as a nine out of ten.

I have completed two different Elastic Search implementations, and in both cases, the goal was to speed up very slow Postgres databases. As a platform PM, I am typically responsible for user management and company management. These areas are quite heavy depending on how many users, customers, or companies exist. Before Elastic Search, when we relied solely on Postgres, there were significant delays to user list pages and company list pages. In the other company, there was a lot of data displayed for particular list pages for admins. We combined Postgres with Elastic Search to speed this up, and it certainly does speed it up. We have used it throughout my current job and previous job.

From the customer side, Elastic Search is super fast and very efficient, delivering results quickly. We recently tuned a series of compliance results in the CMS where we would specify that certain results should come up higher by adding keywords and other factors. However, the results were not as good as when we restarted and used Elastic Search out-of-the-box search results. We actually got better results that were more logical.

The most significant issue I find with Elastic Search is that it gets out of sync, and this has happened in both cases where I have implemented it. When Elastic Search gets out of sync, for instance, if I create a company or user, it gets created in Postgres and then sometimes there is a delay for it to appear in Elastic Search. This could be a 15-minute delay depending on how it was implemented. If other significant processes are running on the platform where you are touching a lot of records, such as a million records, that will take a hit on Elastic Search. We have seen differences of 800 records between Postgres and Elastic Search. Proactive tools that would find and adjust any mismatches would be beneficial.

Occasionally, Elastic Search has failed, and when that happens, search results do not come up at all. This has been a rare occurrence, and I am not certain Elastic Search is entirely to blame, as it could have been platform storage or other factors. For the most part, the most common problem is the out-of-sync issue.

I have used Elastic Search since 2019 at the last two companies where I have worked.

I would say Elastic Search is pretty scalable. We have had good results.

Earlier, in the 2019 and 2020 range, we were having a lot of trouble with syncing, and we tried to see if consulting was available. At the time, we could not find what we needed from the knowledge bases, and we could not really get support. There was not a technical support option at that time. That may have changed. Currently, I do not think we have gone to Elastic Search to ask for any significant help.

Google Appliance was a search engine that Google had for a while, and we used that and were pretty happy with it, but then they deprecated it and it is no longer available. After that, I do not remember what we used, something else.

Although I am not an engineer, it seemed easy to medium to set up. It was not complicated.

For the initial rollout, I would say it was maybe two or three people for the initial implementation, and then I have a team of 40 or 50 engineers with somebody always working on updates and other tasks.

We have not yet used anything in combination with Elastic Search, but that is on the roadmap.

I would say Elastic Search's relevancy is okay, and if I were to give it a score, I would give it a B. Elastic Search works best out of the box as much as possible. When you start to overtune or put in other factors that will increase the priority of specific results you want to come up, it gets really complicated and then you do not necessarily get the best results.

Elastic Search works best when used out of the box without excessive tuning. My overall review rating for Elastic Search is seven out of ten.

I use Elastic Search for fast search of products in our database. With Elastic Search, we use full-text search with keywords and different rules from the Elastic Search documentation. I do not have cases when a search request is four sentences long. I typically use three, four, or five words for searches.

I think the best feature of Elastic Search is the speed. It is very fast and comfortable to use in requests with transpositions rather than full requests. It has a smart engine inside.

In Elastic Search, the improvements I would like to see require many resources.

I have used Elastic Search for two or three years, though I do not remember exactly which it is.

Maintenance of Elastic Search is easy because we do not have problems. I would rate the stability of Elastic Search at an eight.

I would rate the scalability of Elastic Search at an eight.

I did not have a situation where I needed to ask something in technical support for Elastic Search.

I used a different solution before using Elastic Search. It was Sphinx.

I do not know if the deployment was easy or complex, and it is also not my responsibility.

I do not know how it was purchased as it is our DevOps responsibility. I know that it is in AWS, but I do not know the details of how it is deployed there.

I do not know about features such as Agentic AI, RAG, or Semantic Search in Elastic Search. I did not know that there are AI search features available.

I would recommend Elastic Search to other people who want to have fast search in their applications. It is comfortable, it is fast, and it is very interesting to work with it. I gave this product a rating of eight out of ten.

I work in a gaming company where we handle a lot of microservices, observability, monitoring, and metrics. We aggregate all our logs to Elastic Search for troubleshooting across different environments including production, staging, and dev. We use Elastic Search to give us insights and to conduct a lot of troubleshooting.

We decided to go with Elastic Search because of the ability to aggregate everything into one portal where we have access to our entire infrastructure and the correlation about observability and traces. I have used competitors, but we are not using them in the production environment; perhaps on lower environments, but for production, we use Elastic Search.

One thing I appreciate about Elastic Search is the ability to aggregate everything into one dashboard, so I can have monitoring, logs, and traces in one portal instead of having multiple different tools to do the same.

Normally, if you were to use Prometheus, you need to know the Prometheus query language, but with Elastic Search, it gives us the ability to use normal human language for queries. It is very intelligent when it comes to querying. Unless you want to search something in depth, I find it very user-friendly.

I think hybrid search, which combines vector and text searches, is very effective because a developer or platform engineer does not need to spend time learning how to do a query. They can log in and use the standard query language to query a specific log, for example.

The initial deployment of Elastic Search was very easy for our instance because we just needed to enable some annotations for it to start getting the logs. We only needed to do a very minimal deployment on our side. The advantage we had is we had already deployed templates, so we did not need to configure each and every microservice. Once Elastic Search was there and we were able to push the annotations to our deployment, everything came alive.

I think the biggest issue we had with Elastic Search was regarding integrations with our multi-factor authentication tool. We had a challenge with the types of protocols that it allows. Sometimes you find it only supports one or two, and maybe we have a third-party tool for our MFA, so we are limited in how we can do integrations and in terms of audit. Since we are in an environment where we need to be compliant and have all our audits done, it is very hard to audit access logs for Elastic Search. I do not know if that has changed; perhaps we are still on an older version, but that has been the major issue we have experienced.

When it comes to updates for Elastic Search, we might need to push updates, for example, when they have a security patch that we need to enhance or add into our deployments. We do this in the lower environments for staging and then promote it into production. There is not much ongoing maintenance that requires any sort of downtime.

Elastic Search gives you quotas, so you are able to monitor your quotas and know when you are about to fill them up and maybe expand or tighten on your logs. Internally, we try not to have alert fatigue, so we only do important logs and queries, and we rarely have any sort of lag.

Elastic Search is very flexible when it comes to scalability. Being on the enterprise license, it is not really a big issue for us because we can increase the number of quotas we need depending on the logs we want.

For Elastic Search, we have never contacted any support. I appreciate the way they do their documentation and blogs. As a technical professional, before I reach out to support, I have to do my own troubleshooting and research; unless it is something that I cannot resolve, that is when I will probably raise a ticket. In the recent past, we have not raised any specific ticket for Elastic Search.

Before we migrated to Elastic Search, we were using the open-source tools Grafana and Prometheus for logs, but we had to have another third-party tool to do tracing such as Jaeger, or have Sentry to do database logs.

The initial deployment of Elastic Search was very easy for our instance because we just needed to enable some annotations for it to start getting the logs. We only needed to do a very minimal deployment on our side. The advantage we had is we had already deployed templates, so we did not need to configure each and every microservice. Once Elastic Search was there and we were able to push the annotations to our deployment, everything came alive.

The deployment of Elastic Search was done by our DevOps team, because I am part of the DevOps team. Our technical lead was mostly involved in terms of authentications and API key setup. From my side, it was easy for me to enable the annotations on the deployment and commit into the repository and push the changes to it. It was a team effort at different levels.

I would give Elastic Search probably an eight because there is always room for improvement. In IT, everything keeps evolving, and AI is here, and probably tomorrow something else will come, so they will need to elevate their game. I give it a general rating of eight, which for me means it is working perfectly, but it can always get better; there is always something to improve. My overall review rating for Elastic Search is eight out of ten.