OpenTelemetry data streams compared to classic APM

Stack Serverless Observability

The Elastic Distribution of OpenTelemetry (EDOT) stores telemetry data using a storage model optimized for OpenTelemetry signals. When mapping_mode: otel is enabled on the Elasticsearch exporter (which is the default setting), EDOT writes logs, traces, and metrics to specialized data streams aligned with OpenTelemetry semantics.

This architecture is designed for scalable observability workloads. It supports dynamic attributes, reduces mapping complexity, and avoids issues like mapping explosions or manual dimension setup.

EDOT uses Elasticsearch’s Logs data stream (LogsDB) and Time Series Data Streams (TSDS) as storage backends. These are purpose-built to handle the scale and variety of observability data and improve the storage efficiency.

Log and trace data is stored in LogsDB, a storage engine optimized for high-ingest, semi-structured observability data. Benefits include:

• Storage efficiency
• Optimized field handling for dynamic fields (for example, attributes)

Metric data is stored using Elasticsearch’s TSDS. Benefits include:

• Efficient storage using columnar compression
• Fast aggregations
• Automatic detection of metric dimensions (no need to manually define time_series_dimension in field mappings)

EDOT is designed to make OpenTelemetry data queryable using many of the same field names as classic APM (ECS-based) data streams. This helps preserve compatibility with existing dashboards, saved searches, and queries.

Query compatibility is achieved through:

• passthrough fields: Make nested OpenTelemetry fields available at the top level so they can be queried. For example, while the service name is stored at resource.attributes.service.name, you can query it as service.name (the same field name as the one used in the classic APM data stream).
• Field aliases: Map fields with different names in ECS and OpenTelemetry semantic conventions to a common query name to make migration easier.

Query compatibility is not complete:

• Not all ECS fields have aliases. Some integration-specific fields may require query changes.
• Custom attributes and labels are stored differently.

These differences may require updates to certain queries or visualizations.

Refer to ECS & OpenTelemetry for details on the available aliases and field mappings.

This table highlights key differences between classic Elastic APM data streams and EDOT with mapping_mode: otel:

"@timestamp": "2025-08-14T05:29:43.922Z"
data_stream:
  type: logs
  dataset: apm.app.cart-service
  namespace: default
service:
  name: "cart-service"
host:
  ip: ["127.0.0.1", "0.0.0.0"]
kubernetes:
  namespace: "ecommerce"
labels:
  customer_id: "fc2d1b03-b307-4ae3-a19e-df2804c49fc2"
numeric_labels:
  order_id: 4711
  cart_items: 42
  cart_total_amount: 42.0
message: "Order was successfully created"
log:
  level: INFO

"@timestamp": "2025-08-14T05:29:43.922Z"
data_stream:
  type: logs
  dataset: generic.otel
  namespace: default
resource:
  attributes:
    service.name: "cart-service"
    host.ip: ["127.0.0.1", "0.0.0.0"]
    k8s.namespace.name: "ecommerce"
attributes:
  customer.id: "fc2d1b03-b307-4ae3-a19e-df2804c49fc2"
  order.id: 4711
  cart.items: 42
  cart.total_amount: 42.0
body:
  text: "Order was successfully created"
severity_text: INFO