I think they are working on the AI-based features, which are currently in technical preview. The only challenging aspect for new users is often writing the query language. Basic searching is very easy, but creating graphs or writing custom aggregations or histograms for daily averages requires some familiarity. There is currently no out-of-the-box integration for these tasks, and someone usually needs to write a simple query.

Recently, I tested their AI feature that connects to OpenAPI and anonymizes your data. You just ask a question, and it writes a query for you. For instance, if you have many error logs and want to create a rule with a custom query, such as triggering an alert for five errors in the last hour, all you need to do is open the AI bot, type this question, and it generates an Elastic query for you to use in your alert rules. Overall, they are going beyond just what the tool can do by incorporating features akin to Copilot functionalities.

One example is the inability to monitor very old databases with the newest version. Also, when opening tickets, we cannot use our team mailbox. It would be easier if tickets could be opened with the team mailbox.

Elastic Observability could improve asset discovery as the current requirement to push the agent is not ideal. Simplifying the parsing of logs and manual efforts would also be beneficial.

I don't know how Elastic can improve. The integration feature I am using is very easy to implement.

Of course, maintenance is necessary, as with any software, requiring updates with the latest features and security enhancements.

It lacked some capabilities when handling on-prem devices, like network observability, package flow analysis, and device performance data on the infrastructure side.

Elastic Observability needs to improve the retrieval of logs and metrics from all the instances. In an on-premise environment, the solution's data scrappers should be more flexible and simple to configure.

I would love to have the stack trace of the requests. For example, I want to track a request across all the environments and all the services we have.

Right now, I don't have any comments on what needs to be improved because I handle the delivery unit at a CEO's level. So, it's my team who works hands-on and on a day-to-day basis. Hence, they may be the right people to comment on this.

The price of the solution can make a 100 percent difference. I think the licensing model may not have major issues because it's only a node-based one or something. However, the customers should first consume the existing features completely because quite a few customers do not use the complete capacity of Elastic's enterprise version. So that's how things are in India right now.

The price is the only issue in the solution. It can be made better and cheaper.

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.

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.

Elastic Observability needs to have better standardization, logging, and schema. 

Improving code insight related to infrastructure and network, particularly focusing on aspects such as firewalls, switches, routers, and testing would be beneficial.

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.

The interface could be improved. Currently, the aspect that impresses me the most is the AI functionality. However, the pricing for the AI-powered APM feature is quite steep.

There could be more low-code features included in the product. They should improve the machine learning system. Additionally, more features should be related to LLM. 

There could be on-site support services available in the Middle Eastern region. Also, more web features could be added to the product.

Elastic Observability is reactive rather than proactive. It should act as an ITSM tool and be able to create tickets and alerts on Jira. 

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. 

Using this solution is quite complex and there's a steep learning curve if you've never used it before. 

The auto-discovery isn't nearly as good. That's a big portion of it. When you drop the agent onto the JVM and you're trying to figure things out, having to go through and manually do all that is cumbersome. 

Elastic Observability’s price could be improved.

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.

Our licensing model isn't a full one. We are in a less interesting model, so we do not have intelligence on it. We don't get system intelligence and machine learning models, however, I don't know if it is relevant to what we use the solution for. 

We don't have the platinum version. We are on the gold version. Our system intelligence and machine learning, and the other things regarding the competencies of everything, we have to build ourselves. It's not easy, as we are in West Africa and sometimes we do not have the relevant competencies. It takes time to get the skills we need to use the solution effectively.

The solution would be better if it was capable of more automation, especially in a monitoring capacity or for the response to abnormalities.

The tool's scalability involves a more complex implementation process. It requires careful calculations to determine the number of nodes needed, the specifications of each node, and the configuration of hot, warm, and cold zones for data storage. Additionally, managing log retention policies adds further complexity. The solution's pricing also needs to be cheaper. 

There is room for improvement regarding its APM capabilities.

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.

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.

The cost must be made more transparent. Sometimes, we create a cost plan, but it doesn’t match.