--- title: Elastic OpenTelemetry compared to upstream description: How {{edot}} compare to upstream OpenTelemetry components, including Collector, SDKs, Kubernetes Operator, and more. url: https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/compatibility/edot-vs-upstream products: - Elastic Cloud Serverless - Elastic Distribution of OpenTelemetry Collector - Elastic Distribution of OpenTelemetry SDK - Elastic Observability applies_to: - Serverless Observability projects: Generally available - Elastic Stack: Generally available --- # Elastic OpenTelemetry compared to upstream [Elastic OpenTelemetry](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference) are a set of [OpenTelemetry distributions](https://opentelemetry.io/docs/concepts/distributions/) curated, tested, and supported by Elastic. Each Elastic OpenTelemetry component builds on its upstream counterpart, adding production-ready defaults, Elastic-specific capabilities, and official support backed by [Elastic's Support Policy](https://www.elastic.co/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 Elastic OpenTelemetry ahead of upstream when there are strong reasons to do so. Elastic OpenTelemetry 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](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/compatibility/nomenclature) but receive community support only. Elastic OpenTelemetry 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 | Elastic OpenTelemetry | 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](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/central-configuration), 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 | Elastic Agent releases align with Elastic Stack. Elastic OTel SDKs follow the upstream OpenTelemetry release cycle. | Follows the upstream OpenTelemetry release cycle. | The following sections describe how this general comparison applies to each Elastic OpenTelemetry component. ## Elastic Agent 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](https://opentelemetry.io/docs/collector/). Assembling a production-ready Collector from these components requires careful selection, configuration, and testing. Elastic Agent 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. Elastic Agent ships with [default configurations](https://docs-v3-preview.elastic.dev/elastic/elastic-agent/tree/main/reference/edot-collector/config/default-config-standalone) for common deployment scenarios, including [standalone](https://docs-v3-preview.elastic.dev/elastic/elastic-agent/tree/main/reference/edot-collector/config/default-config-standalone) and [Kubernetes](https://docs-v3-preview.elastic.dev/elastic/elastic-agent/tree/main/reference/edot-collector/config/default-config-k8s). In self-managed Elastic Stack deployments, the Elastic Agent running in [gateway mode](https://docs-v3-preview.elastic.dev/elastic/elastic-agent/tree/main/reference/edot-collector/modes) 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 Elastic Agent can follow the [custom Collector guide](https://docs-v3-preview.elastic.dev/elastic/elastic-agent/tree/main/reference/edot-collector/custom-collector), which describes the required components and preprocessing pipelines for Elastic compatibility. For the full list of components included in Elastic Agent, refer to the [Elastic Agent components](https://docs-v3-preview.elastic.dev/elastic/elastic-agent/tree/main/reference/edot-collector/components) page. ## Elastic OTel SDKs 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](https://opentelemetry.io/docs/concepts/distributions/) that add defaults, extensions, or vendor-specific improvements. Elastic OTel SDKs are such distributions. They maintain full compatibility with the OpenTelemetry specification and come with preselected instrumentations that enable [zero-code instrumentation](https://opentelemetry.io/docs/concepts/instrumentation/zero-code/) by default. The following Elastic OTel SDKs are available: - [Elastic OTel .NET](https://docs-v3-preview.elastic.dev/elastic/elastic-otel-dotnet/tree/main/reference/edot-dotnet) - [Elastic OTel Java](https://docs-v3-preview.elastic.dev/elastic/elastic-otel-java/tree/main/reference/edot-java) - [Elastic OTel Node.js](https://docs-v3-preview.elastic.dev/elastic/elastic-otel-node/tree/main/reference/edot-node) - [Elastic OTel PHP](https://docs-v3-preview.elastic.dev/elastic/elastic-otel-php/tree/main/reference/edot-php) - [Elastic OTel Python](https://docs-v3-preview.elastic.dev/elastic/elastic-otel-python/tree/main/reference/edot-python) - [Elastic OTel Android](https://docs-v3-preview.elastic.dev/elastic/apm-agent-android/tree/main/reference/edot-android) - [Elastic OTel iOS](https://docs-v3-preview.elastic.dev/elastic/apm-agent-ios/tree/main/reference/edot-ios) Due to current upstream limitations, some capabilities are temporarily available only in Elastic OTel SDKs. Elastic is actively working to contribute these upstream so that they become part of the standard OpenTelemetry SDKs. Refer to the [Elastic OTel SDKs overview](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/edot-sdks) for the full feature matrix across languages. | Capability | Status | |-----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Inferred spans | Available in Elastic OpenTelemetry only. Generates spans from profiling data without manual instrumentation, closing visibility gaps that auto-instrumentation does not cover. | | Central configuration | Available in Elastic OpenTelemetry only. Manages SDK settings from Kibana through the Elastic Agent using [OpAMP](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/central-configuration). Most SDKs apply configuration changes dynamically, without restarting or redeploying applications. | | Profiling integration | Available in Elastic OTel Java only. Correlates traces with continuous profiling data for deeper performance analysis. | | Crash reporting | Available in Elastic OpenTelemetry only. Captures native crash data on mobile platforms for post-mortem analysis. | Upstream OTel SDKs are technically [Compatible](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/compatibility/nomenclature) 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](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/compatibility/sdks) for version-level details. Elastic OTel SDKs are designed to export telemetry through the [Elastic Agent](https://docs-v3-preview.elastic.dev/elastic/elastic-agent/tree/main/reference/edot-collector) or the [Elastic Cloud Managed OTLP Endpoint](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/managed-inputs/managed-otlp-endpoint). Using Elastic OTel SDKs directly with APM Server's OpenTelemetry intake is not supported — attribute mapping, enrichment, and processing pipelines are not guaranteed on that path. ## Kubernetes Operator Elastic OpenTelemetry does not ship its own Kubernetes operator. Instead, Elastic OpenTelemetry deployments on Kubernetes rely on the upstream [OpenTelemetry Operator](https://opentelemetry.io/docs/platforms/kubernetes/operator/), which manages Collector deployments and auto-instrumentation of workloads through Kubernetes custom resource definitions (CRDs). In an Elastic OpenTelemetry-based Kubernetes setup, the operator's `OpenTelemetryCollector` CRD deploys Elastic Agent images as DaemonSets, Deployments, or StatefulSets, and the `Instrumentation` CRD is configured to inject Elastic OTel 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 Elastic OpenTelemetry 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 Elastic Agent 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 Elastic OpenTelemetry component behavior (Elastic support). On platforms that provide their own OpenTelemetry distributions, such as [Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/red_hat_build_of_opentelemetry/index) or [AWS Lambda (ADOT)](https://aws-otel.github.io/docs/getting-started/lambda), those platform-native distributions can be used [at the edge](/elastic/opentelemetry/pull/640/reference/architecture#understanding-edge-deployment) instead. Elastic does not provide support for third-party distributions, but they remain [Compatible](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/compatibility/nomenclature) as long as they export data over OTLP. Refer to the [Kubernetes architecture page](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/architecture/k8s) and the [Kubernetes use case guide](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/solutions/observability/get-started/opentelemetry/use-cases/kubernetes) for deployment details. ## Elastic Cloud Forwarder The [Elastic Cloud Forwarder](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/edot-cloud-forwarder) are Elastic-specific components with no upstream equivalent. They package the Elastic Agent 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](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/managed-inputs/managed-otlp-endpoint). Because there is no upstream counterpart, the Elastic OpenTelemetry-versus-upstream comparison does not apply to Cloud Forwarders. Refer to the [Elastic Cloud Forwarder documentation](https://docs-v3-preview.elastic.dev/elastic/opentelemetry/pull/640/reference/edot-cloud-forwarder) for setup guides and supported cloud services. ## OTel Demo The upstream [OpenTelemetry Demo](https://opentelemetry.io/docs/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](https://github.com/elastic/opentelemetry-demo) that replaces these default backends with an Elastic Stack deployment. The fork ships Elastic Agent configurations for both Kubernetes and host scenarios, allowing teams to see how Elastic OpenTelemetry components work together in a near-production environment before rolling them out. The Elastic OpenTelemetry demo is a learning and showcase tool, not a production artifact. Elastic does not provide support for the demo application itself, but the Elastic OpenTelemetry components running within it follow the same support terms as their standalone releases.