---
title: OpenTelemetry limitations in Elastic APM
description: 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...
url: https://www.elastic.co/elastic/docs-builder/docs/4572/solutions/observability/apm/opentelemetry/limitations
products:
- APM
- Elastic Cloud Serverless
- Elastic Documentation
- Elastic Observability
applies_to:
- Elastic Cloud Serverless: Generally available
- Elastic Stack: Generally available
---
# 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.
## Data format and compatibility with the `.apm` OTLP intake
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](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4572/reference/opentelemetry/compatibility/data-streams#ingest-path-data-format).
## OpenTelemetry traces
- 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](https://github.com/elastic/apm-server/issues/7001)).
- Inability to see Stack traces in spans.
- Inability in APM views to view the "Time Spent by Span Type" (see issue [#5747](https://github.com/elastic/apm-server/issues/5747)).
## OpenTelemetry logs
- The OpenTelemetry logs intake through the [APM Server](/elastic/docs-builder/docs/4572/solutions/observability/apm/opentelemetry/upstream-opentelemetry-collectors-language-sdks#apm-open-telemetry-proxy-apm) is in technical preview. : 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](https://github.com/elastic/apm-server/issues/9093)).
Logs ingest through [Elastic Agent](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4572/reference/edot-collector) is fully supported.
## OpenTelemetry Line Protocol (OTLP)
Elastic supports both the [OTLP/gRPC](https://opentelemetry.io/docs/specs/otlp/#otlpgrpc) and [OTLP/HTTP](https://opentelemetry.io/docs/specs/otlp/#otlphttp) protocol with ProtoBuf payload. Elastic does not yet support JSON Encoding for OTLP/HTTP.
## EDOT SDKs with APM Server OTel intake
EDOT SDKs are tested and supported only with [Elastic Agent Gateway](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4572/reference/edot-collector/modes#edot-collector-as-gateway) or [Managed OTel intake](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4572/reference/opentelemetry/managed-inputs/managed-otlp-endpoint). Using EDOT SDKs directly with APM Server's OTel intake is not supported.
## OpenTelemetry Collector exporter for Elastic
The [OpenTelemetry Collector exporter for Elastic](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.57.2/exporter/elasticexporter) has been deprecated and replaced by the native support of the OpenTelemetry Line Protocol in Elastic Observability (OTLP).
The [OpenTelemetry Collector exporter for Elastic](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/elasticsearchexporter) (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](https://www.elastic.co/elastic/docs-builder/docs/4572/solutions/observability/apm/opentelemetry/upstream-opentelemetry-collectors-language-sdks) instead.
## OpenTelemetry’s tail-based sampling
- Elastic Stack: Generally available
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:
- Tail-based sampling using the [tailsamplingprocessor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/tailsamplingprocessor) in the OpenTelemetry Collector
- Native [tail-based sampling in the Elastic APM backend](/elastic/docs-builder/docs/4572/solutions/observability/apm/transaction-sampling#apm-tail-based-sampling)
Using the [tailsamplingprocessor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/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](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4572/reference/edot-collector/config/configure-tracing-collection) instead of sending data directly to APM Server. Elastic Agent provides native support for tail-based sampling that properly handles metric extrapolation.