OpenTelemetry limitations in Elastic APM

Using OpenTelemetry with APM has limitations that depend on how you send data and which signals you collect. These limitations affect how data is stored and displayed, and which protocols, SDKs, collectors, and sampling setups you can use.

The APM Server or managed inputs OTLP intake (the .apm endpoint) is a legacy ingest path. When you send OTLP data to it, your data is translated to ECS format before storage. This differs from the Elastic Cloud Managed OTLP Endpoint and Elastic Agent configured as an OTel Collector, which store data in OTel-native format. For new users, Elastic recommends those paths instead.

Consequences of the ECS translation:

  • Unmapped span and transaction attributes are stored under labels.* (strings) or numeric_labels.* (numbers), with dots replaced by underscores. For example, order.id becomes labels.order_id. On OTel-native paths, they are stored under attributes.order.id, with dots preserved.
  • OpenTelemetry content packages, which provide OTel-compatible dashboards, are not applicable to ECS-translated data. Use prebuilt ECS-based integrations and dashboards, or the classic APM UI.
  • ECS-translated data passes through Elasticsearch ingest pipelines in the usual way. OTel-native data bypasses ingest pipelines.
  • EDOT SDKs are not supported with the APM Server or managed inputs OTLP intake. Use the Elastic Cloud Managed OTLP Endpoint or Elastic Agent configured as an OTel Collector instead.

For a detailed comparison and guidance on choosing your ingest path, refer to How your ingest path determines the data format.

  • Traces of applications using messaging semantics might be wrongly displayed as transactions in the Applications UI, while they should be considered spans (see issue #7001).
  • Inability to see Stack traces in spans.
  • Inability in APM views to view the "Time Spent by Span Type" (see issue #5747).
  • The OpenTelemetry logs intake through the APM Server is in technical preview.
  • The application logs data stream (app_logs) has dynamic mapping disabled. This means the automatic detection and mapping of new fields is disabled (see issue #9093).
Note

Logs ingest through Elastic Agent is fully supported.

Elastic supports both the OTLP/gRPC and OTLP/HTTP protocol with ProtoBuf payload. Elastic does not yet support JSON Encoding for OTLP/HTTP.

EDOT SDKs are tested and supported only with Elastic Agent Gateway or Managed OTel intake. Using EDOT SDKs directly with APM Server's OTel intake is not supported.

The OpenTelemetry Collector exporter for Elastic has been deprecated and replaced by the native support of the OpenTelemetry Line Protocol in Elastic Observability (OTLP).

The OpenTelemetry Collector exporter for Elastic (which is different from the legacy exporter mentioned above) is not intended to be used with Elastic APM and Elastic Observability. Use Elastic’s native OTLP support instead.

Tail-based sampling allows to make sampling decisions after all spans of a trace have been completed. This allows for more powerful and informed sampling rules.

When using OpenTelemetry with Elastic APM, there are two different implementations available for tail-based sampling:

Using the tailsamplingprocessor in the OpenTelemetry Collector comes with an important limitation when used with APM Server. Elastic’s APM backend calculates span and transaction metrics based on the incoming span events. These metrics are accurate for 100% sampling scenarios. In scenarios with probabilistic sampling, Elastic’s APM backend is being informed about the sampling rate of spans and can extrapolate throughput metrics based on the incoming, partial data. However, with tail-based sampling there’s no clear probability for sampling decisions as the rules can be more complex and the OpenTelemetry Collector does not provide sampling probability information to the Elastic backend that could be used for extrapolation of data. Therefore, there’s no way for APM Server to properly extrapolate throughput and count metrics that are derived from span events that have been tail-based sampled in the OpenTelemetry Collector. In these scenarios, derived throughput and count metrics are likely to be inaccurate.

Use Elastic Agent tail-based sampling instead of sending data directly to APM Server. Elastic Agent provides native support for tail-based sampling that properly handles metric extrapolation.