Explore metrics

After your metrics are in Elastic, query them, visualize them in Kibana, and act on them with Observability rules. Use Elasticsearch Query Language (ES|QL) or PromQL depending on how you ingested the data. Chart the results in Discover, the Infrastructure UI, and dashboards, or keep Grafana pointed at Elasticsearch as a Prometheus data source.

Elastic gives you two ways to query metrics: ES|QL, including its time-series (TS) mode, and PromQL. Use ES|QL for new analysis and Kibana dashboards. Use PromQL to reuse existing Prometheus query expressions and Grafana dashboards.

Pick a language based on what you ingested and what you want to do:

If you want to Use
Run time-series queries over OpenTelemetry (OTel) or Prometheus remote write metrics, including counters, rates, and time buckets ES|QL with time-series (TS) mode
Reuse existing Prometheus query expressions or Grafana dashboards PromQL

ES|QL is the recommended choice for ad hoc analysis, time-series aggregations, and dashboards in Kibana.

For metrics stored as a time series data stream (TSDS), use ES|QL time-series mode. The TS command operates on TSDS columnar storage and computes rates, averages, and other per-series aggregations over time windows, which makes it more efficient than the equivalent aggregations on regular indices and correct for per-series data.

Use TS mode when:

  • Your metrics are stored as a TSDS, which is the default for OTLP and Prometheus remote write ingestion.
  • You need to compute rates, averages, or other time-window aggregations.
  • You're aggregating time-series metrics in Kibana.

For example, the following query returns the 80th percentile of request duration per endpoint in one-minute buckets:

TS my-metrics
| STATS PERCENTILE(request_duration, 80) BY endpoint, TBUCKET(1m)

For commands, functions, and syntax, refer to the ES|QL overview.

When a TSDS is downsampled, keep using the TS command. It's the optimized way to query downsampled data, and the time series aggregation functions apply to downsampled data with the same semantics as for raw data. For how those queries behave, refer to Query downsampled data.

Elasticsearch supports PromQL for any metrics stored in a TSDS, whichever ingest path filled it: Prometheus remote write, OTLP, or the bulk API. You can reuse existing Prometheus query expressions as long as they use supported PromQL. Metric names reflect the ingest path you used.

Elasticsearch runs PromQL in two ways:

  • A Prometheus-compatible HTTP API under the /_prometheus/ prefix, for Grafana and other Prometheus clients. Refer to PromQL HTTP API for the endpoints.
  • The PROMQL source command inside ES|QL, so you can post-process PromQL results with ES|QL commands. Refer to PROMQL command for the syntax.

Metrics ingested with Prometheus remote write are stored as metrics.<metric_name> with Prometheus labels as labels.<label_name>. PromQL uses the original Prometheus metric and label names. ES|QL uses the Elasticsearch field names. For the mapping table, refer to Data mapping.

Elasticsearch implements a subset of PromQL functions for rates, range aggregations, and math. Unsupported constructs return a client error. For the function list, refer to PromQL functions. For unsupported constructs and differences from upstream Prometheus, refer to PromQL limitations.

If you use Grafana, point its built-in Prometheus data source at the Elasticsearch /_prometheus/ API. Grafana treats Elasticsearch like any other Prometheus backend: dashboard panels, autocompletion, and template variables run PromQL against metrics in Elasticsearch. For the data source URL and authentication, refer to Use Elasticsearch as a Prometheus data source in Grafana.

The UI you use to explore time-series metrics depends on your deployment and Elastic Stack version.

Use Discover in Kibana to explore time-series metrics data, apply filters, and run ES|QL queries. In Discover, run a TS query in ES|QL mode to open a chart grid of available metrics. You can search, filter, break metrics down by dimension, and add charts to a dashboard. For the Discover metrics workflow, refer to Explore metrics data with Discover in Kibana.

Use Metrics Explorer to create time-series visualizations of your metrics, chart them against related metrics, and break them down by the field of your choice. For the Metrics Explorer workflow, refer to Explore infrastructure metrics over time.

These views give you a resource-centric perspective on your infrastructure, with metrics-driven health and performance indicators:

View infrastructure metrics by resource type
Use the Infrastructure inventory page, organized by resource groupings.
Analyze and compare hosts
Open the Hosts page to compare host metrics side by side.
Detect metric anomalies
Use anomaly detection powered by machine learning for memory usage and network traffic. Not available for hosts monitored with OpenTelemetry.

Build dashboards in Kibana Lens to track metrics over time, compare resources, and share views with your team. Metrics stored as a time series data stream (TSDS) support efficient time-series aggregations in Lens visualizations. Start with Create a dashboard, then add charts using Visualize data with Lens.

After you can see the time series you care about, create a rule so a threshold notifies you. Select a rule type from the following list. Each page has the conditions, filters, and action setup.

Create a custom threshold rule
Alert when a metric in a data view crosses a threshold. Use this rule for OpenTelemetry and Prometheus remote write metrics on every deployment type.
Create an inventory rule
Alert on infrastructure resources from the Infrastructure inventory page.
Create a metric threshold rule

Alert on metrics in the Infrastructure metrics indices. Create this rule from the Rules page.

You can also create this rule from Metrics Explorer.

For the full list of Observability rule types, refer to Create and manage rules.

As your metrics volume grows, learn how to control storage costs and retention with Manage metrics storage.