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.

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.

We use Elastic Observability for APM, basically. Right now, it is used only for application performance monitoring. In short, it is only the APM module that Observability is looked upon for by all our customers.

We use the solution to collect logs. It also helps us with application performance monitoring. We use it for centralized logs and visualizing them with Grafana.

It offers end-to-end observability, the capability of monitoring and analyzing the entire stack, from the user experience to the low-level infrastructure. It enables troubleshooting and debugging by allowing us to trace issues through the entire system.

We are using Elastic Observability for monitoring.

We use it to handle significant volumes of data sourced from various network monitoring protocols like NetFlow and SNMP.

As we have access to all the features offered by Elastic Observability, we utilize it for APM, to provide support and manage our infrastructure, and even leverage it for our CRM needs. 

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.

We use the product to monitor various data pipelines.

We use the product to monitor our infrastructure. 

We usually use the solution in our production environment to monitor production on Rancher. I'm a DevOps engineer.

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

We use it for monitoring the application performance and development.

Our clients use the product for monitoring and alerting.

The primary use case for our organization is handling login events. We also utilize it for some big data use cases.

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. 

We are using Elastic APM primarily for central logging.