OpenTelemetry

Datadog is deeply committed to OpenTelemetry (OTel)—the open source, vendor-neutral observability standard for instrumenting, generating, collecting, and exporting telemetry data. We were there when OTel was formed as a Cloud Native Computing Foundation (CNCF) project in 2019. We contributed our java-agent as one of its founding code donations. Ever since, we have been pushing the project forward: shaping the spec, building first-class OTel support across the Datadog platform, and proposing work like native OTel tracing in Node.js core.

Datadog's built-in support

To support Datadog customers in their adoption of OpenTelemetry, we have made several enhancements to our platform.

Collection & ingestion

Datadog meets you where you are. Whether you're using the OTel Collector or Datadog Agent, or sending data directly via API, we support multiple ingestion paths so you can adopt OTel without changing how you work:

• Datadog Exporter for the OpenTelemetry Collector, which has stable support for OpenTelemetry Protocol (OTLP) traces, metrics, and logs.
• Datadog Connector for the OpenTelemetry Collector, which provides accurate Application Performance Monitoring (APM) statistics in the form of metrics for OTel users.
• OTLP ingestion support in the Datadog Agent, which enables Datadog customers to use OTel SDKs while benefiting from the Datadog Agent’s ecosystem of integrations.
• The Datadog platform's OTLP API endpoints, which allow direct OTLP ingestion of metrics, logs, and traces (currently in Preview) via the Datadog API.

DDOT & Collector management

For teams running OTel Collectors at scale, Datadog provides an enterprise-ready distribution and centralized management tooling to simplify deployment, configuration, and visibility across your data pipelines:

• Datadog Distribution of OpenTelemetry Collector (DDOT), which provides an OTel-native Collector distribution built into the Datadog Agent that lets teams use OTel pipeline configurations without giving up Datadog's advanced capabilities—including Live Container Monitoring, Universal Service Monitoring (USM), and Fleet Automation integration.
• OTel Gateway with DDOT, which allows deploying DDOT as a centralized gateway between node-level Collectors and observability backends—enabling consistent processing policies, tail-based sampling, and schema normalization across all telemetry data before it leaves your infrastructure.
• Fleet Automation for OTel Collectors, which enables centralized management of OTel Collectors at scale.
• Validate and troubleshoot OTel Collector pipeline configurations, which enables teams to visualize and debug their OTel Collector pipeline configurations.

OTel-native powered features

OTel data doesn't just flow into Datadog. It powers native monitoring experiences. From Kubernetes to runtime metrics to GenAI workloads, OTel signals give access to rich, built-in capabilities across the platform:

• Kubernetes monitoring, which delivers the Kubernetes monitoring experience powered by OTel data.
• Host metrics, which provides support for OTel-instrumented infrastructure.
• Runtime metrics, which integrates runtime metrics from OTel-instrumented applications in Java, .NET, and Go without additional configuration.
• GenAI Semantic Convention support, which brings OTel semantic convention support for LLM and GenAI observability.

Interoperability

OTel and Datadog aren't an either/or choice. Datadog bridges vendor-neutral instrumentation with platform-native features so you don't have to trade one for the other:

• Support for the OpenTelemetry API in Datadog SDKs, which allows users to maintain vendor-neutral instrumentation of all their services, while still taking advantage of Datadog’s native implementation, features, and products.
• Integration between Datadog Real User Monitoring (RUM) and OTel-instrumented backend services, which allows teams to correlate frontend sessions with backend traces end-to-end.

Datadog’s contributions

On the code side, Datadog has donated the java-agent, dd-trace-py, dotnet-agent, and orchestrion to OpenTelemetry, and made our auto-instrumentation tracers available as the foundation of OpenTelemetry tracers.

Datadog engineers continue to contribute code, maintain features, and participate in contributor roles (triager, approver, maintainer) across the OTel ecosystem.

Contributing to OpenTelemetry also means shaping what it becomes. Datadog engineers actively propose and drive specifications that extend the project's capabilities. Some examples:

• Process Context: Sharing Resource Attributes with External Readers, proposed by Ivo Anjo, introduces a mechanism for OTel SDKs to publish process-level resource attributes—such as service name and version—to external readers via a standard in-process interface. This allows external tools like profilers or agents to identify which service a process belongs to without requiring manual configuration, improving automatic correlation across observability signals.
• Thread Context: Sharing Thread-Level Information with the OpenTelemetry eBPF Profiler, proposed by Ivo Anjo and Scott Gerring, introduces a mechanism for OTel SDKs to publish thread-level trace context through a standard format based on ELF Thread Local Storage. This allows external readers like the eBPF profiler to correlate profiling samples with request traces—even when the active span wasn’t sampled by the SDK—bridging the gap between distributed tracing and continuous profiling.
• Span Metrics Connector support for extrapolated metrics from tracestate, proposed by Yuanyuan Zhao, which proposes using the tracestate key to derive an adjusted_count from sampled spans. By applying stochastic rounding, the Span Metrics Connector can extrapolate span counts into statistically accurate metrics that represent the full, unsampled traffic.
• Native OpenTelemetry tracing in Node.js, proposed by Bryan English, aims to bring OTel tracing directly into Node.js core as a built-in node:otel module. If adopted, this would make distributed tracing a first-class capability of the Node.js runtime itself, removing the need for third-party instrumentation for common use cases.

Datadog engineers also actively participate in the Special Interest Groups (SIGs) crafting the future of OpenTelemetry, including co-leading:

• contributor-experience: focused on improving the experience of contributing to the OpenTelemetry project, from first commit through the transition to approver, and on overall community health
• developer-experience: focused on improving the experience for developers using OpenTelemetry within their projects

Advancing the community

Datadog promotes OpenTelemetry beyond code. Our engineers have written extensively about OTel in practice:

• How to monitor your Rust applications with OpenTelemetry walks through how to instrument and monitor Rust applications using OpenTelemetry.
• How to select your OpenTelemetry deployment covers OTel Collector deployment patterns.
• Choosing the right OpenTelemetry Collector distribution explores the pros and cons of different Collector distributions.
• Instrument and monitor Boomi integration flows with OpenTelemetry and Datadog shows how to instrument and monitor Boomi Atoms and Molecules with OTel and Datadog.

As part of the Developer Experience SIG, we also document how companies use OTel in production:

• How Mastodon runs OpenTelemetry Collectors in production
• How Adobe uses OTel in production
• How Skyscanner scales OpenTelemetry: managing collectors across 24 production clusters

Datadog is also active in the community, sponsoring events, sharing talks, and keeping the ecosystem informed:

• Datadog is a founding strategic partner of the Observability Summit and has sponsored community events such as OTel Unplugged EU 2026.
• The OTel News newsletter by Juliano Costa highlights updates from across the OTel community.

The playlist below features Datadog and OpenTelemetry conference and event presentations from around the globe:

Our future with OTel

The work continues. Follow the OTel News newsletter to keep up with our latest contributions and community updates.

Ready to use OTel with Datadog? The OpenTelemetry solutions page covers how the two work together, and the OpenTelemetry documentation has the setup guides to get you there.