What needs improvement with Elastic Observability?

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.

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.

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

It doesn't work as a completely full hundred percent monitoring tool since certain applications are different. We did have some issues at the beginning, but we managed by using agents, bits, and metrics. We had a specialist who learned and gained experience, which helped us a lot.

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.

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

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

There is room for improvement regarding its APM capabilities.

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 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’s price could be improved.

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.

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.

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.

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 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.

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.