Elastic Observability Reviews

I use this product in projects that we do for other companies. We use the most updated version of the solution.

We're using Elastic to get information for several points of observability and several projects and solutions. We're using it broadly in lots of systems. For each solution, we're defining the observability points and the data we want to capture in each point. We're deploying Elastic as the tool to capture the data in each of these points in these transactions, and then putting that in the database. It allows us to analyze not only the number of transactions and quantities, but also the business content of each payload of the transactions in order to have business KPIs, not just technical KPIs. We have more than 300 data capture points in several systems.

This has been used by an IO monitoring team. We have two types of users: technical guys that are monitoring the stability of the systems where this tool is used, to see if we are having issues on the operation. This is the IO management team, and there are around 40 users. The second category is people related to business that are actually using this to capture business information, like the amount of transactions, credit sales, the average value of each operation, and things like that. In that sense, there are about 100 people looking at business dashboards. 

The use is much heavier with the first group. They are tuning systems and deploying new data capture points, etc. Although there are more people in the second group, they are using it more to get the information and use it for tech and business decisions, but they are not heavy users in that sense.

It's easy to deploy, and it's very flexible. We have been able to easily deploy it in the data capture points that we want. After you capture the data payload of each transaction, it's also easy to do the search in the database.

It could come with more detailed or sophisticated dashboards that are pre-defined and that could speed up when you start looking at the data of the transactions. If we had some pre-defined templates for observability that we could start using right away after deploying it – instead of having to build or to change some of the dashboards – that would be helpful.

I would like to see an automated deploy tool, like Dynatrace has, that would allow you to have the parts of the system where you want to do the observability and they would deploy very quickly and kind of outer connect with the systems.

I've been using this solution for 12 months.

The stability is good. We didn't have trouble installing and getting the data from it. There haven't been any major incidents, just the normal tuning that you doing as part of the deployment.

We are still increasing the number of data capture points, but so far it's quite stable.

We have plans to increase usage in two dimensions: Horizontally because we are getting the same data points expanded to other instances of the same systems. We're not creating anything new. We are just deploying the same data capture point in different instances of the same solution. 

We're also expanding vertically. We are creating new data capture points. When we start monitoring the solution, we kind of start having ideas of how to better view the operation. It's a little bit of a learning process when you start monitoring and seeing new opportunities.

The available documentation and the skill level that we have in the team has been enough. So far, we haven't used technical support yet.

Setup was straightforward to start getting the data and doing the searches that we want. I would rate setup 4 out of 5.

In comparison, Dynatrace is more automatic in terms of the deployment.

The implementation strategy was to deploy it system by system, point by point. We started looking at the systems that could have the best result for starting using this as observability tool. The idea was to deploy gradually and start getting results ASAP with the most critical transactions, instead of doing a major design of everything and deploying all at once with a bunch of transactions at the same time. It was gradual to start getting results as fast as possible.

Our technical team was about six to seven people. There were development guys because they are the ones that knew the systems and where to include the data capture points and then insert the API from Elastic that would be used to capture the data. The other guys were the IO management team and were monitoring the setup and building the database and dashboards.

Deployment was done internally with our team.

It's quite cost effective depending on your objective. I would rate the ROI 4 out of 5 because it really reached the objectives and at a lower price.

I would rate the pricing 4 out of 5.

So far, there are just the standard licensing fees. Several of the components are embedded in the license or are even open source. They're even free depending on what you use, which makes it even more appealing.

I have also used Dynatrace. Although Dynatrace is a great solution, it's becoming very expensive. They have increased the value of the licenses and the way they license, especially when we moved from on-premise to cloud. Because of the way they count the agents in the cloud for Dynatrace, it becomes really expensive. But Dynatrace is more ready as a solution. With Elastic, you need to code and program more things compared to Dynatrace. 

Dynatrace is very well positioned in the market. I think they are becoming a little too confident in that differentiation, and are reflecting this in the license price, which is becoming prohibitive. I'm in Brazil, and our currency isn't in dollars, but the license is in dollars and is becoming more expensive. The exchange rate hasn't been favorable in the last few years.

I would rate this solution 7 out of 10. 

The very positive features are the cost effectiveness and the range of things that you can implement. An improvement would be the ability to speed up the deployment, like Dynatrace. In that case, Elastic would have the cost effectiveness and would be easier to implement.

My advice is that you should first understand what kind of observability objectives you have in managing your environment. See if what you want to do is really being covered by each solution. If you're doing something that isn't that sophisticated, you don't need to pay the price of Dynatrace or Datadog. You can reach your objectives with something much more cost effective. Sometimes you don't need to buy a really expensive, sophisticated solution. 

Understand your system landscape and what you want to do and what your objectives are before jumping into a specific tool. We put a lot of research into what we wanted to do and what was the best tool for our objectives.

You should also understand what you need to implement the selected solution: what sort of skills, how many people, if you have them or not in your team, and see if you need professional services before putting together the full business case to implement. If you don't have people that really know middleware and APMs properly, they tend to be quite expensive in the market. If you don't consider this properly, you may end with a big issue in fulfilling your business case. Human resource costs are not small in this sort of project.

Elastic APM is a kind of log aggregation tool and we're using it for that purpose. 

Elastic APM is very new so we haven't explored much on it, but it's quite interesting. It comes with a free offering included in the same license. So we are looking to explore more. It is still not as mature as other tools like Kibana, AppDynamics or New Relic products related to application performance monitoring. Elastic APM is still evolving, but it's quite interesting to be able to get all the similar options and features in Elastic APM.

In terms of what could be improved, Elastic APM's visualization is not that great compared to other tools. It's number of metrics is very low. Their JVM metrics are much less while running on CPU memory and on top of that you get a thread usage. They're not giving much on application performance metrics. In that respect, they have to improve a little bit. If you compare that with other tools, such as New Relic, which is also not giving many insights, it would be good to get internal calls or to see backend calls. We are not getting this kind of metric.

On the other hand, if you go to the trace view, it gives you a good backend calls view. That backend call view is also capturing everything, and we need some kind of control over it, which it does not have. For example, if I don't want some of the sequence selected, there should be controls for that. Moreover you need to do all these things manually. Nowadays, just imagine any product opted to do conservation manually, that would be really disastrous. We don't want to do that manually. For now this needs to be either by API or some kind of automated procedure. If you want to install the APM Agent, because it is manual we would need to tune it so that the APIs are available for the APM site. That's one drawback.

Additionally, the synthetic monitoring and real user monitoring services are not available here. Whereas in New Relic the user does get such services.

The third drawback I see is the control site. For now, only one role is defined for this APM. So if I want to restrict the user domain, for example, if in your organization you have two or three domains, domain A, domain B, domain C, but you want to give access to the specific domain or a specific application, I am not sure how to do that here.

Both the synthetic and process monitoring should be improved. For the JVM, Java Process Monitoring, and any process monitoring, they have to have more metrics and a breakdown of the TCP/IP, and the tools are giving me - they don't provide many metrics in size. You get everything, but you fail to visualize it. The New Relic only focuses on transactions, and Elastic APM also focuses on similar stuff, but I am still looking for other options like thread usage, backend calls, front end calls, or how many front end and backend calls. This kind of metric is definitely required.

We don't have much control. For example, some backend calls trigger thousands of prepared statements, update statements, or select statements, and we don't have any control. If I only want select statement, not update statements, this kind of control should be there and properly supplied. The property file is very big and it is still manual, so if you want control agent properties you need UI control or API control. Nowadays, the world is looking for the API site so they'll be able to develop more smartly. They are looking for these kinds of options to enrich their dashboard creation and management.

I'm new to Elastic APM, but I do have very good APM knowledge since I have been using APM almost 10 years and Elastic APM for just two years. I see that Elastic APM is still evolving.

Elastic APM's technical support is pretty good and we have a platinum license for log aggregation. They respond very quickly and they follow a very good strategy. They have one dedicated resource especially for us. I'm not sure if that is common for other customers, but they assigned a very dedicated resource. So for any technical issue a dedicated resource will respond. Then, if that resource is busy or not available someone will attend that call or respond with support. In that way, Elastic support fully understands your environment.

Otherwise, if you go with the global support model, they have to understand your environment first and keep asking the same question again and again. How many clusters do you have, what nodes do you have, these kind of questions. Then you need to supply that diagnosis. This is a challenge. If they have a dedicated or a support resource they usually don't ask these questions because they'll understand your environment very well because they have worked with you on previous cases. In that sense they provide very good support and answer the question immediately.

They provide immediate support. Usually they get back you the same or the next day. I think it's pretty good compared to any other support. It was even very good compared to New Relic.

There are two advantages to Elastic APM. It is open source and if somebody wants to try it out in their administration it's free to use. Also, it has full stack observability. For full stack observability, Elastic is the best tool compared with any other tool like New Relic or AppDynamics or Dynatrace. I'm not sure about Dynatrace, since I never worked with it, but I have worked with AppDynamics and New Relic. However, with their log aggregation side, there is still a lot to get implemented here.

I'd like bigger flexibility. That means we would get all the system logs, all the cloud logs, all the kinds of logs aggregated in a single location. On top of that, if they could have better metrics for handling data together it would give a greater advantage for observability. The Observability platform is pretty good because you already have logged data and information like that. If you just add APM data and visualize, you will get much needed information. How are you are going to visualize and how are you going to identify the issues?

For this purpose, Elastic is best. If you are really looking for an observability platform, Elastic provides both of these two options, APM plus log aggregation. But still they have to improve or they have to provide APIs for synthetic monitoring, internet monitoring, etc... If I think about synthetic monitoring, you can't compare New Relic with Elastic today. Elastic is much better.

These are the improvements they have to look at. They support similar functionalities of synthetic monitoring, so it's not a hundred percent APM friendly, but if you look at their observability platform, their full stack observability together with their log aggregation, Elastic APM is a greater advantage.

On a scale of one to ten, I would rate Elastic APM an eight out of 10.

Elastic Observability can address multiple use cases, including monitoring, visibility, and reporting. It is integrated with a visualization product called Kibana. It's called ELK, which stands for Elasticsearch, Logstash and Kibana. Kibana provides visualization, and the others are security modules. SIEM module is there. 

We use it extensively for reporting, pulling metrics, logs, traces, events, etc. from different systems. Everything is aggregated in Elastic and visualized in Kibana. We use Logstash for ETL — extract, transform and load. We extract the data from the source, transform it—data massaging, data mixing, filters, etc. —and send it to Elasticsearch in the format we need.

The Elastic User Interface framework lets us do custom development when needed. You need to have some Javascript knowledge. We need that knowledge to develop new custom tests.

Elastic Observability is an excellent product for monitoring and visibility, but it lacks predictive analytics. Most solutions are aligned with the AIOps requirements, but this piece is missing in Elastic and should be included.

I've used Elastic Observability for two years.

Elastic Observability is highly stable. There is no problem. We tested performance, including load testing. We ingested nearly 170 million records in the system and we have tested it. It's great performance-wise. You get your reports and dashboards within a few seconds. So it doesn't take much time. Yeah. 

Elastic Observability is scalable. You can attach additional nodes as your data size grows. It's a simple process. In a three-node cluster, you already have two replicas of your data.

Okay. From a technical support perspective, yes, it is good. I have mostly, since I'm basically from the engineering and R&D. So I'm leading the engineering and R&D services basically. So we maximum for our development purpose. So we use Elastic open source. So in the platinum and the enterprise versions of Elastic, the support technical support is good. That's what I have seen.

So Elastic is basically clusters, right? Basically three, we can go with the basic cluster is a three note cluster. So the implementation is quite simple. It's not very complex. So we have to architect the solution in such a way that we have the right number of replicas and right number of charts and all those to hold the data. So basically we have to architect based on the data ingestion, how much data we are going to ingest in the cluster. So this setup is pretty simple, but we have to have the right inputs, right decisions in place before we even implement it.

We have used multiple APM solutions, which we evaluate using the metric MTTR or so meantime-to-resolution. We also have the detect-to-correct lifecycle implemented where Elastic is used to monitor multiple services and automate fixes for any issues. We reduced the number of incidents because you already have automated runbooks that run and fix the issues.

And second thing is we are monitoring an observability, which provides you the complete visibility, and it helps you to figure out the root cause quickly. So these are some of the return on investments that we can see. And also, in terms of reducing the number of incidents, reducing the number of overheads, right? So all those kind of things. And also from a data perspective, you can compress the data very easily and you can manage the data very easily. You have hot, cold retention policies, which allow you to manage your data very well. You can also ensure that your cluster is not getting full. So a lot of good returns are there, some are directly related to, I mean, dollar and some are not.

There are two types: cloud and SaaS. They charge based on data ingestion, ingest rate, hard retention, and warm retention. I believe it costs around $25,000 annually to ingest 30GB of data daily. That is the SaaS version. 

There is also a self-managed license where the customer manages their own infrastructure on-prem. In such cases, there are three license tiers that respectively cost $5,000 annually per node, $7,000 per node, and $12,500 per node.

I rate Elastic Observability eight out of 10. I deduct a couple of points because it lacks predictive analytics and root cause analysis. 

Machine learning is the most valuable feature of this solution.

Because it is an open, enhanced APR, no custom integrations are required. They're open, so it's an open-wear product that's simple to use and evaluate.

They need more skills in the market. There are not enough skills in the market.

It is not pervasive enough on the market, in my opinion. In other words, there isn't a big enough user base. 

The development of new features, functions, and releases, is not necessarily based on market demand. Which is why I can't rate it a 10 because of that. 

In my opinion, because there are not enough skills, the skills are still expensive. The software and the platform may be affordable, but the skills to deploy and manage it are expensive.

I have been managing teams that use Elastic Observability for 36 months.

It's an AWS platform as a service, so it's obviously as stable as AWS.

Elastic Observability is a scalable solution.

We have approximately 500 users in our organization.

I have contacted technical support and I would rate them a five out of five.

It is a Platform As A Service (PaaS). It's challenging because, in a platform world, you have to have your own abilities. You don't rely on the vendor for help unless something goes wrong.

I have not personally used but I have led teams that used App Dynamics, Dynatrace, Elastic, Splunk, ServiceNow, DXAPM, and Tivoli.

We implemented it in a complex environment, so whether the tool was simple or complicated was irrelevant. Because we worked in a complicated environment in a bank, if I say it was difficult, you will think the tool was complex, which isn't the case. But if I claim it was easy, it wasn't.

I would rate the initial setup a three out of five.

Our organization achieved the ROI.

Pricing is one of those situations where the more you use it, the more you pay. However, the cost is variable. And, if used properly, I believe it is rather inexpensive. If you use it badly, you must pay.

If one is very cheap, and five is very expensive, I would rate the pricing a two out of five.

We had many others and did a replacement. We decided on Elastic Observability because it was the most cost-effective.

My recommendation is to start small and gradually expand. Don't attempt to implement or distribute over a vast estate all at once. Begin small. 

Use Agile methodology. Basically, don't go large at first. Take a little bit and then grow.

I would rate Elastic Observability an eight out of ten.

We basically use Elastic APM for our metrics to look at our performance. Whenever people say that there's a latency of more than a certain amount, then we just open this APM and see why exactly the latency is high. We can choose that data set, and then we can go deeper. 

The solution allows us to track performance via metrics.

We're able to see where latency is happening. 

The solution allows us to dig deep into data.

There needs to be less boiler code. That's where I see a solution such as Dynatrace as being very good. We need to just deploy the Dynatrace and then it just uses all the TCP packages et cetera, to figure out what the endpoint to endpoint mapping is. It can give more insight into performance.

I can see mistakes in annotations. If a developer uses a different annotation, these performance metrics are not in the portal. When I go to the portal, I do not see many insights on the endpoints or where there could be latencies. I'd like overall fewer mistakes.

The solution needs to use more AI. Once the product onboards AI, users would more effectively be able to track endpoints for specific messages.

I do not have more than six months' experience with this solution. I'm a senior engineer here and I just was looking at a few issues in our system, and then I could see that how we are doing this APM integration.

I may not be able to comment on the stability as that is something DevOps should know. My understanding is that it is stable. That said, in use cases, it lacks insights features. 

I came to this organization from a financial background. In all the major banks, capital markets, they use this ITRS Geneos. I have experience in that tool.

I don't have any details in terms of pricing. It's not an aspect of the solution I am familiar with. 

I see that there are a few features that are not there in that Elastic APM. I have been looking at another APM that we can use in our C systems.

I am looking into Dynatrace and Azure Monitor.

We are just a customer and an end-user.

With so little experience with the solution so far, I do not have any specific advice to share with others. 

I'd rate the solution at a six out of ten.

We are using Elastic Observability for monitoring.

The solution has been stable in our usage.

Elastic Observability is difficult to use. There are only three options for customization but this can be difficult for our use case. We do not have other options to choose the metrics shown, such as CPU or memory usage. 

I have been using Elastic Observability for approximately two years.

I rate the stability of Elastic Observability a ten out of ten.

We have approximately 10 people using the solution in my organization.

We use the solution daily.

I have not used the support from the vendor.

I have not used another similar solution to Elastic Observability.

We have a lot of Kubernetes clusters making the initial setup more difficult. If we only had one cluster of Kubernetes it would be simple. We have to do a lot of the setup manually. 

If someone had a simple environment the setup could be easier but it depends on the environment.

I rate the initial setup of Elastic Observability a five out of ten.

The price of Elastic Observability is expensive.

I rate the price of Elastic Observability an eight out of ten.

I rate Elastic Observability an eight out of ten.

We use Elastic Observability for system monitoring, server monitoring, and application monitoring. I'm working on a project wherein I use the solution for capacity planning.

I have built a mini business intelligence system based on Elastic Observability. We show all the real-time transactions, the transaction type, the transaction amount, and different kinds of metrics based on different transactions. We've built something that helps our different teams working with the same stack make everything visible using Kibana. This helps the compliance team to track some Visa card transactions, etc.

Elastic Observability’s price could be improved.

I have been using Elastic Observability since 2015.

Elastic Observability is a stable solution.

Currently, Elastic Observability is scalable because the client needs to see things working before agreeing to scale the solution.

I am the only guy involved with the solution's deployment.

Users have to pay for some features, like the alerts on different channels, because they are unavailable in different source versions.

The project requires monitoring and tracking everything, including some internal services with the SAP application. The project manager needs the capacity planning dashboard to help him reduce the cost on the cloud.

Overall, I rate Elastic Observability a nine out of ten.

We are using Elastic APM primarily for central logging.

Elastic APM has plenty of features, such as the Elastic server for Kibana and many additional plugins. It's a comprehensive tool when used as a logging platform.

In the future, Elastic APM needs a portfolio iTool. They can provide an easy way to develop the custom UI for Kibana.

Elastic APM needs to focus on improving infrastructure, monitoring, and enriching Kibana features.

I have been using Elastic APM for approximately one year.

Elastic APM is a stable solution if it is configured properly.

The scalability of Elastic APM is good.

The solution is good for small businesses but not good for enterprises or corporations. There are other tools that would be better suited.

The is a comprehensive online community that I have used for support.

The implementation of Elastic APM is highly complex. However, the setup is straightforward for Docker installation or containers. The multiple cluster configuration with the distributed nature of the solution is difficult.

I have evaluated Dynatrace and it's an amazing solution compared to Elastic.

I would advise others to use a different solution than Elastic APM. 

I rate Elastic APM a six out of ten.