EDOT data streams

Serverless Observability Stack

Elastic Distribution of OpenTelemetry writes telemetry data to two types of data stream schemas in Elasticsearch:

• OTel-native data streams (default)
• ECS-compatible data streams (for backwards compatibility with APM)

This page provides a practical reference for which data streams EDOT uses, exporter behavior, and storage engines. For a detailed comparison of OTel data streams with classic APM and ECS-based integrations, see OTel data streams compared to classic APM.

To learn how to route OpenTelemetry (OTel) signals to custom data streams, see Data stream routing.

EDOT may use two Elasticsearch exporters:

• otel: sends data to OTel-native data streams
• ecs: sends data to ECS-compatible data streams

The ecs exporter ensures compatibility with legacy APM data formats.

When EDOT runs as a local gateway or Collector, it writes telemetry data to different data streams depending on the storage mode and exporter configuration:

This is the default mode. When ingesting standard OTel signals, EDOT writes to:

These streams follow OTel naming conventions and field structures.

When the ecs exporter is enabled, or when ingesting data from APM agents using elasticapmintake, EDOT writes to:

• traces-apm-*
• traces-apm.sampled-*
• metrics-apm.internal-*
• metrics-apm.*-*
• metrics-apm.service_destination.[interval]-*
• logs-apm.error-*
• logs-apm.app.*-*

These match legacy APM Server behavior.

The Elastic Cloud Managed OTLP Endpoint follows the same stream selection logic as local EDOT deployments:

• OTel-native streams for standard OTel telemetry
• ECS-compatible streams for APM-formatted events

The main difference is that Elastic Cloud Managed OTLP Endpoint is a managed cloud service that handles ingestion and storage, whereas local EDOT deployments require you to manage the Collector infrastructure yourself. Ingest and storage behavior remain consistent between both approaches.

You may notice fields like:

• resource.attributes.service.name
• service.name

These are not true duplicates. Here's why:

• OTel defines attributes at multiple levels (for example: resource, span).
• EDOT stores resource attributes under resource.attributes.*, according to OTel specifications.
• Kibana dashboards and APM UI rely on ECS-style top-level fields like service.name.

To bridge these models, EDOT aliases or copies key fields so that:

• Dashboards continue to function
• Filters and searches behave consistently
• OTel structure remains intact for downstream compatibility

This duplication is intentional.

EDOT uses the same index templates and mappings as the rest of the Observability solution.