What is EDOT (Elastic Distributions of OpenTelemetry)?

EDOT (Elastic Distributions of OpenTelemetry) is Elastic's family of production-ready OpenTelemetry distributions tailored for Elastic Observability. It includes Elastic Agent (which packages OpenTelemetry Collector capabilities), EDOT language SDKs for seven supported languages, and Elastic Cloud Forwarders for serverless cloud environments. Every GA distribution is backed by Elastic support under defined Service Level Agreements (SLAs).

EDOT consists of three component families: Elastic Agent (the collector component), EDOT language SDKs, and Elastic Cloud Forwarders. Each family covers a different part of the telemetry pipeline: collection and processing at the host or cluster level, instrumentation at the application code level, and collection from managed cloud services.

When an application runs with an EDOT SDK, the SDK instruments the code and emits telemetry over OTLP to Elastic Agent. Elastic Agent then processes the data and writes it to Elasticsearch.

The EDOT SDK auto-instruments the application process, capturing traces, metrics, and logs from recognized frameworks and libraries without requiring code changes. The SDK batches the telemetry it collects and exports it over OTLP, using gRPC or HTTP/protobuf transport. Elastic Agent receives the OTLP stream and acts as the collection and processing layer. It applies processors for batching, enrichment, and resource attribution and then runs any configured transformations before forwarding data downstream. Processed data lands in Elasticsearch, where Kibana renders it as service maps, dashboards, and alerts.

Teams without an EDOT SDK can still send data over plain OTLP using any upstream-compatible instrumentation. Elastic's ingestion endpoints are vendor-agnostic and preserve OpenTelemetry semantic conventions. Elastic Cloud users who prefer not to manage a collector can send OTLP telemetry directly to the Managed OTLP Endpoint.

Platform and site-reliability teams adopt EDOT when they need a standardized, vendor-neutral telemetry layer. EDOT spans applications, infrastructure, and cloud services without requiring each team to maintain their own OpenTelemetry configuration.

Greenfield applications are a natural starting point. New services are instrumented with EDOT SDKs at the start, so every language in the stack emits a uniform signal format. Teams working in different languages each get a distribution with preconfigured defaults, rather than assembling their own OpenTelemetry setup from scratch.

Kubernetes cluster monitoring is another common pattern. The upstream OpenTelemetry Operator deploys Elastic Agent as a DaemonSet for node-level collection and as a gateway Deployment for cluster aggregation. This collects host, pod, and application telemetry from an entire cluster without custom configuration.

Teams building large language model (LLM)-powered features use EDOT's semantic-convention-aligned instrumentation to capture inference latency, token usage, and error rates from large language model integrations. They can then correlate LLM performance with downstream service traces in application performance monitoring.

Cloud telemetry forwarding serves teams running fully serverless architectures. Cloud Forwarders collect logs and metrics from managed cloud services without a persistent collector host, filling a coverage gap that standard collector deployments cannot reach.

Teams currently on classic Elastic APM agents can adopt EDOT SDKs as the designated migration path to OTel-standard instrumentation.

OpenTelemetry is a Cloud Native Computing Foundation (CNCF)-hosted, vendor-neutral framework for collecting, processing, and exporting telemetry as traces, metrics, and logs. EDOT and upstream OpenTelemetry both speak OTLP and can send data to any compatible back end. EDOT removes the component-selection, configuration, and production-testing work that a reliable upstream setup requires.

Five dimensions separate a production EDOT setup from a hand-assembled upstream configuration: configuration defaults, support, bundled components, central management, and Elastic Stack compatibility.

EDOT is always optional. Any upstream or third-party OpenTelemetry component that exports OTLP can send data to Elastic's ingestion endpoints. Upstream components are technically compatible but receive community support only.

On vendor portability: Elastic contributes EDOT improvements to the upstream OpenTelemetry project before shipping them in EDOT wherever possible. Telemetry data lands in Elasticsearch using OTel semantic conventions, preserving the ability to re-export it to any OTLP-compatible backend.

For a detailed breakdown of compatibility at the component level, see how EDOT compares to upstream OpenTelemetry. 

EDOT's main benefits are reduced configuration work, enterprise-grade support, observability capabilities that upstream OpenTelemetry does not yet provide, and full portability of the telemetry data it produces.

1. Zero-code instrumentation: EDOT SDKs ship with preselected, tested instrumentation libraries. An application emits traces, metrics, and logs after adding the SDK and configuring an endpoint — no instrumentation code to write or maintain. The SDK handles recognized frameworks automatically, so teams get signal coverage at the start.
2. SLA-backed support: GA distributions are covered by Elastic support under the same terms as the Elastic Stack, giving teams a single support relationship for the full observability pipeline. Technical Preview distributions — EDOT Browser, and the Azure and GCP forwarders — carry best-effort support and fall outside standard SLAs.
3. Capabilities not yet in upstream OpenTelemetry: Inferred spans generate code-level visibility from continuous profiling data without manual instrumentation, closing gaps that auto-instrumentation cannot reach. Central configuration lets you update SDK and collector settings from Kibana via OpAMP without redeploying applications. Crash reporting captures native crash data on mobile distributions. Elastic is actively contributing all three upstream.
4. No vendor lock-in: Elastic contributes improvements back to the upstream OpenTelemetry project before shipping them in EDOT wherever possible. Telemetry data lands in Elasticsearch using OTel semantic conventions, so it can be re-exported to any OTLP-compatible backend without reformatting.

Elastic Observability — Elastic's unified solution for APM, infrastructure monitoring, and log management — uses EDOT as its official mechanism for ingesting OpenTelemetry telemetry into Elasticsearch and visualizing it within Kibana.

For application-level instrumentation, simply integrate the appropriate EDOT language SDK for your runtime, configure your endpoint along with authentication credentials, and let the SDK handle telemetry collection automatically. For host-level or Kubernetes telemetry, deploy Elastic Agent to act as a standalone collector.

If your current setup relies on legacy Elastic APM agents, transition to EDOT SDKs, which serve as the primary migration path toward OpenTelemetry-compliant instrumentation.