EDOT compared to upstream OpenTelemetry
Elastic Distributions of OpenTelemetry (EDOT) are a set of OpenTelemetry distributions curated, tested, and supported by Elastic. Each EDOT component builds on its upstream counterpart, adding production-ready defaults, Elastic-specific capabilities, and official support backed by Elastic's Support Policy and SLAs.
Elastic is also an active contributor to the upstream OpenTelemetry project, working to stabilize components, advance semantic conventions, and move capabilities upstream so that the broader community benefits. Elastic contributes bug fixes and improvements upstream first, and only ships fixes in EDOT ahead of upstream when there are strong reasons to do so.
EDOT is always optional. Elastic's OTLP ingestion APIs are vendor-agnostic and preserve OpenTelemetry semantic conventions, so any upstream or third-party OpenTelemetry component that speaks OTLP can send data to the Elastic Stack. Upstream components are technically Compatible but receive community support only. EDOT is for teams that want a supported, production-grade experience that can be a drop-in replacement for upstream OpenTelemetry components.
The following table summarizes the key differences:
| Aspect | EDOT | Upstream |
|---|---|---|
| Configuration | Pre-configured defaults for Elastic Observability. | Requires manual component selection and configuration. |
| Support | Official Elastic support with SLAs. | Community support. |
| Integration | Seamless integration with Elastic Stack components. | Requires additional configuration for Elastic. |
| Components | Curated, production-tested components optimized for Elastic, including preselected instrumentations for zero-code setup. | Broad ecosystem. Component maturity levels vary. Instrumentations must be selected and configured manually. |
| Deployment | Same deployment methods as upstream, with ready-to-use default configurations. | Users provide their own configuration. |
| Central management | Central configuration of SDKs and Collectors through OpAMP, including a managed OpAMP server. | OpAMP protocol is supported, but no managed server is provided. |
| Compatibility | Fully tested with Elastic Stack components. | Compatible, but not tested or supported by Elastic. |
| Updates | EDOT Collector releases align with Elastic Stack. EDOT SDKs follow the upstream OpenTelemetry release cycle. | Follows the upstream OpenTelemetry release cycle. |
The following sections describe how this general comparison applies to each EDOT component.
The upstream OpenTelemetry project does not ship a single, recommended Collector distribution for production use. Instead, it offers a core Collector and a contrib Collector whose components have mixed stability levels. Assembling a production-ready Collector from these components requires careful selection, configuration, and testing.
EDOT Collector is a curated distribution that eliminates this assembly step. It includes specific components and configurations optimized for Elastic Observability, and it ships with Elastic-specific components that are not available in contrib, such as the elasticsearchexporter for native ingestion into Elasticsearch and the elasticapmintakereceiver for backward-compatible APM intake. These components are developed by Elastic with the intent of contributing them upstream over time.
EDOT Collector ships with default configurations for common deployment scenarios, including standalone and Kubernetes. In self-managed Elastic Stack deployments, the EDOT Collector running in gateway mode replaces APM Server for OTel-native data ingestion, handling metrics aggregation and format conversion before writing to Elasticsearch.
Users who need a Collector build that differs from the standard EDOT Collector can follow the custom Collector guide, which describes the required components and preprocessing pipelines for Elastic compatibility. For the full list of components included in EDOT Collector, refer to the EDOT Collector components page.
OpenTelemetry language SDKs provide the instrumentation libraries that applications use to generate traces, metrics, and logs. The upstream project publishes reference SDKs for each supported language. Vendors can wrap these into distributions that add defaults, extensions, or vendor-specific improvements.
EDOT SDKs are such distributions. They maintain full compatibility with the OpenTelemetry specification and come with preselected instrumentations that enable zero-code instrumentation by default.
The following EDOT SDKs are available:
Due to current upstream limitations, some capabilities are temporarily available only in EDOT SDKs. Elastic is actively working to contribute these upstream so that they become part of the standard OpenTelemetry SDKs. Refer to the EDOT SDKs overview for the full feature matrix across languages.
| Capability | Status |
|---|---|
| Inferred spans | Available in EDOT only. Generates spans from profiling data without manual instrumentation, closing visibility gaps that auto-instrumentation does not cover. |
| Central configuration | Available in EDOT only. Manages SDK settings from Kibana through the EDOT Collector using OpAMP. Most SDKs apply configuration changes dynamically, without restarting or redeploying applications. |
| Profiling integration | Available in EDOT Java only. Correlates traces with continuous profiling data for deeper performance analysis. |
| Crash reporting | Available in EDOT only. Captures native crash data on mobile platforms for post-mortem analysis. |
Upstream OTel SDKs are technically Compatible with Elastic and can send data through the same ingestion paths, but Elastic does not provide official support or troubleshooting assistance for them. Refer to the SDK compatibility table for version-level details.
EDOT SDKs are designed to export telemetry through the EDOT Collector or the Elastic Cloud Managed OTLP Endpoint. Using EDOT SDKs directly with APM Server's OpenTelemetry intake is not supported — attribute mapping, enrichment, and processing pipelines are not guaranteed on that path.
EDOT does not ship its own Kubernetes operator. Instead, EDOT deployments on Kubernetes rely on the upstream OpenTelemetry Operator, which manages Collector deployments and auto-instrumentation of workloads through Kubernetes custom resource definitions (CRDs).
In an EDOT-based Kubernetes setup, the operator's OpenTelemetryCollector CRD deploys EDOT Collector images as DaemonSets, Deployments, or StatefulSets, and the Instrumentation CRD is configured to inject EDOT SDK images (for example, docker.elastic.co/observability/elastic-otel-javaagent) instead of the default upstream images. The operator handles the mechanics of admission webhooks and init container injection, while EDOT provides the container images and configurations that the operator deploys.
This creates a dual support model. The operator itself is an upstream community project and receives community support. The EDOT Collector and SDK images that the operator deploys are covered by Elastic support under the same terms as their standalone counterparts. When filing issues, distinguish between operator behavior (community support) and EDOT component behavior (Elastic support).
On platforms that provide their own OpenTelemetry distributions, such as Red Hat OpenShift or AWS Lambda (ADOT), those platform-native distributions can be used at the edge instead. Elastic does not provide support for third-party distributions, but they remain Compatible as long as they export data over OTLP. Refer to the Kubernetes architecture page and the Kubernetes use case guide for deployment details.
The EDOT Cloud Forwarders are Elastic-specific components with no upstream equivalent. They package the EDOT Collector as a cloud function — AWS Lambda, Azure Function, or GCP Cloud Run — to collect telemetry from cloud provider services such as S3, CloudWatch, Blob Storage, Event Hub, GCS, and GCP Operations, and forward it to the Elastic Cloud Managed OTLP Endpoint.
Because there is no upstream counterpart, the EDOT-versus-upstream comparison does not apply to Cloud Forwarders. Refer to the EDOT Cloud Forwarder documentation for setup guides and supported cloud services.
The upstream OpenTelemetry Demo is a multi-service reference application instrumented in over a dozen languages. It demonstrates distributed tracing, metrics collection, and log correlation across a realistic microservices architecture, using Jaeger and Prometheus as backends.
Elastic maintains a fork of the demo that replaces these default backends with an Elastic Stack deployment. The fork ships EDOT Collector configurations for both Kubernetes and host scenarios, allowing teams to see how EDOT components work together in a near-production environment before rolling them out.
The EDOT demo is a learning and showcase tool, not a production artifact. Elastic does not provide support for the demo application itself, but the EDOT components running within it follow the same support terms as their standalone releases.