Elastic 9.4 for metrics: managed OTLP endpoint and PromQL

Elastic 9.4 was released on 5 May 2026. In the announcement the vendor puts clear emphasis on metrics: it wants Elasticsearch to store them as well as it stores logs. For teams that keep metrics in Prometheus, Grafana or a SaaS service, three things are of interest: a managed OTLP endpoint in Elastic Cloud, native PromQL support and changes to time series indices. Below we describe each of them together with its status, because some of the features are still technical previews.

What in 9.4 concerns metrics

Feature	Status in 9.4	Notes
Managed OTLP endpoint	GA	Elastic Cloud Hosted (version 9.0 or later) and Serverless
Native Prometheus and PromQL support	Technical preview	Writing through remote write and PromQL queries in Kibana
Time series support in ES|QL (the TS command, rate, changes and other functions)	GA	Complemented by filtering across the whole time range
TSDB performance improvements	GA	Vendor figures, not our measurements

The statuses come from the Elastic 9.4 announcement and the documentation. The announcement says that metrics take 2.6 times less space than in Prometheus and that queries are up to 30 times faster than in Prometheus and Mimir. These are results from the vendor’s benchmarks. With your own volume and your own queries the result may differ, so test a sample before you decide on a migration.

The managed OTLP endpoint: data without your own collector

OpenTelemetry Protocol (OTLP) is an open protocol for sending logs, metrics and traces. In Elastic Cloud you can point applications at the address of a managed endpoint and send data without running your own collector for basic ingestion. The documentation says the endpoint handles logs, metrics and traces. You will find the address in the Elastic Cloud console under Application endpoints.

Authentication uses an API key with the event:write privilege on the apm application. A key created in Kibana has no scheme prefix, so add it yourself. A configuration for the OpenTelemetry Collector looks like this:

exporters:
  otlp:
    endpoint: https://<otlp-endpoint-address>
    headers:
      Authorization: ApiKey <api-key>

And for applications using SDK environment variables:

export OTEL_EXPORTER_OTLP_ENDPOINT="https://<otlp-endpoint-address>"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=ApiKey <api-key>"

Three things the documentation states outright, and which are worth taking into account:

• Restricting a key to particular indices is not yet supported. Keys with custom index-level privileges fail with PermissionDenied.
• Data is stored in the native OpenTelemetry format, without translation to ECS. Custom attributes go to attributes.* with the dots preserved. The older way of ingesting data through APM Server translates it to ECS and stores attributes in labels.*, so existing dashboards and rules may need their fields corrected.
• This is a managed endpoint in the cloud. For clusters on your own infrastructure you still need a collector or an Elastic Agent working as a gateway.

We describe how to build an architecture with a collector, and why OpenTelemetry pays off whichever backend you choose, in the article on OpenTelemetry alongside Elastic and Grafana.

PromQL in Elasticsearch: a preview, but worth knowing

Elastic is adding native Prometheus support: you can send data with remote write and run PromQL queries in Kibana. In 9.4 this has the status of a technical preview. The documentation describes a default write path, /_prometheus/api/v1/write, and the configuration on the Prometheus side is a few lines:

remote_write:
  - url: "https://<elasticsearch-address>/_prometheus/api/v1/write"
    authorization:
      type: ApiKey
      credentials: "<api-key>"

By default data goes to the metrics-generic.prometheus-default data stream. The key must have write access to the target data stream. PromQL works on metrics stored in time series data streams (TSDS), and Elasticsearch translates the query into an ES|QL plan and runs it with the same engine as the TS command.

A technical preview means that details may change and not every PromQL function is supported. Compatibility is described on a separate documentation page. In our view this is a good moment for a parallel test: keep Prometheus as the source of truth, attach Elastic as a second write target and compare the results of a few important queries. At this stage do not plan to switch off your existing monitoring.

ES|QL and time series

Time series support in ES|QL has GA status in 9.4. It adds the rate, changes, cumulative, trange and clamp functions and full time-range filtering. For a team building alerts and dashboards on metrics, this means typical expressions (the rate of change of a counter, detecting changes) can be written natively, without workarounds.

Who this makes sense for

The managed OTLP endpoint makes the most sense for companies that already use Elastic Cloud and are introducing OpenTelemetry in their applications: in simple scenarios you save the upkeep of a collector, but you can still add one where you need to process data before it is sent. PromQL is for teams with Prometheus who want to assess Elastic as a single place for logs and metrics. If your metrics come from Elastic agents and you are not planning changes, 9.4 is mainly a performance upgrade, and the most important task is to review the breaking changes.

Changes to watch when upgrading

The release notes for 9.4 describe three breaking changes that concern metrics:

1. Exponential histograms are the default for OTLP data. If your queries assume classic histograms, check them after the upgrade.
2. Time series indices have sequence numbers disabled. Operations with if_seq_no fail, and update_by_query and delete_by_query run without conflict detection. The index.disable_sequence_numbers setting set to false restores the previous behaviour.
3. Downsampling in ILM no longer runs a force merge by default. If you depend on it, add a force merge action to the policy or set force_merge_index to true.

Before upgrading, review the breaking changes for every version between your current one and the target.

Where to start

If you use Elastic Cloud, start with one application that already sends OpenTelemetry data and point its output at the managed endpoint. If you use Prometheus, set up a parallel write to Elastic in a test environment. In both cases, review your alert rules for changes in field names.

We deploy monitoring of metrics, logs and traces on Elastic as part of application monitoring, including a comparison with existing tools.