Shanel Huang
Senior Product Manager
The recent announcement that OpenTelemetry (OTel) has achieved CNCF graduation further reinforces OTel’s credibility as the industry standard for vendor-neutral telemetry. As organizations increasingly adopt the OpenTelemetry Protocol (OTLP), the OTel Collector, and OTel SDKs, they need an observability platform that supports OTel-native data without sacrificing flexibility or portability.
To meet these important customer requirements, Datadog has been significantly expanding its support for OTel-native observability. Whether by enabling you to send OTLP telemetry through vendor-neutral ingestion paths, to investigate issues with OTel-native data, or to manage OpenTelemetry Collectors across a fleet, Datadog supports OTel at every step. Behind the scenes, Datadog is also continuing to make significant contributions to the OpenTelemetry project to further enrich the open source standard with additional powerful features.
Send OTel data to Datadog in a vendor-neutral way
Many teams adopt OTel because they want the flexibility to choose how telemetry is generated, collected, processed, and routed. Using OTel SDKs, the OTel Collector, and OTLP lets teams build pipelines that fit their architecture.
Previously, sending OTel data to Datadog via the OTel Collector required the Datadog Exporter. But now, in a Preview feature, Datadog supports telemetry data ingestion via the standard OTLP HTTP Exporter, a fully vendor-agnostic component included in the standard OTel Collector. With this OTel-native instrumentation, teams can send OTel data to Datadog without relying on any proprietary components like the Datadog Agent, Datadog Exporter, or Datadog Connector. This method allows you to use standards-based telemetry end to end, from instrumentation to ingestion and analysis in Datadog, while supporting your journey toward complete vendor neutrality.
Additionally, for teams that don’t want to run an OTel Collector at all, Datadog’s direct OTLP intake endpoint is now generally available. With this feature, applications can send OTLP metrics, logs, and traces directly to Datadog without any intermediate collection layer, like an OTel Collector or Datadog Agent. This is particularly useful for managed services or serverless environments where running a sidecar or agent adds unnecessary overhead.
Investigate Kubernetes and application issues with OTel-native data
Once data from OTel sources reaches Datadog, it powers the same experience for products like Infrastructure Monitoring and Application Performance Monitoring (APM) that teams already rely on. No transformations, mappings, or Datadog-specific instrumentation are required. Previously, some of these experiences required signals gathered from the Datadog Agent or Datadog SDKs. Now, OTel-native data powers them directly.
For example, the Kubernetes Explorer can now be populated directly with OTel data. Previously, this experience required signals from the Datadog Agent. Now, metrics collected from standard OTel receivers like kubeletstatsreceiver
power the same cluster exploration and troubleshooting workflows, including table views of clusters, nodes, namespaces, and pods.
Datadog also handles semantic normalization automatically, so metrics collected from different receivers with varying units or types are represented across views in a consistent way. This means that, for teams running hybrid environments, the Kubernetes Explorer can join data from OTel pipelines and the Datadog Agent side by side. You can troubleshoot across clusters without worrying about how each signal was collected.
With the OTel-native instrumentation, Datadog APM also now works directly with services instrumented using OTel SDKs. Teams can view and query OTel-native traces in Datadog by using OTel span semantics and attributes, without requiring any translation or re-instrumentation.
Additionally, features like the Internal Developer Portal’s Catalog and each service page are powered by RED metrics generated from OTel trace data via the open source spanmetrics connector component. The connector is configured with dimensions that allow Datadog to compute host tags, peer services, and operation names directly from your traces. Out-of-the-box dashboards featuring runtime metrics from OTel SDKs are also automatically surfaced in Datadog, giving teams visibility into service health without requiring any Datadog-specific instrumentation.
Whether telemetry comes from the Datadog Agent and Datadog SDKs or the OTel Collector and OTel SDKs, teams can adopt OTel incrementally and at their own pace. As a result, they can query OTel-native data in Datadog by using the same span semantics and attributes they’re most familiar with.
Investing in OTel beyond Datadog
Datadog’s commitment to OTel goes beyond supporting its own products. Datadog engineers actively contribute to OTel repositories, participate in special interest groups (SIGs), and help advance standards across areas such as the Collector, semantic conventions, profiling, sampling, real user monitoring, and Open Agent Management Protocol (OpAMP).
In March 2026, Datadog engineers co-authored the alpha release of OTel Profiles alongside contributors from Google, Elastic, and others. The work involved standardizing a unified profiling data format compatible with existing formats like pprof and integrating profiles as a first-class signal in the OTel Collector alongside traces, metrics, and logs.
As OTel’s profiling signal matures, Datadog intends to support it natively in its own profiling products. For example, the Full Host Profiler, now in Preview, is built on the OTel eBPF profiler. It profiles all processes on a host without requiring any code changes or instrumentation, giving teams visibility into every process, runtime, and language.
By investing upstream, Datadog is helping OTel mature as an open standard while making Datadog a stronger destination for teams that choose OTel. Customers can expect continued involvement from Datadog across OTel projects like real user monitoring, OpAMP, and semantic conventions for serverless workloads as the work on these standards continues.
Get started with adopting OpenTelemetry
Whether you’re just beginning to instrument services with OTel or expanding an existing deployment, Datadog can support your team at each step. You can build vendor-neutral pipelines with upstream OTel components; send OTLP metrics, logs, and traces to Datadog; and use Datadog’s infrastructure and APM workflows with OTel-native data.
To get started, request access to the OpenTelemetry Native Instrumentation Preview. To learn more about Datadog’s OTel support, see our Getting Started with OpenTelemetry guide. And if you’re not yet a Datadog customer, sign up for a 14-day free trial.
Facts Only
OpenTelemetry (OTel) has achieved CNCF graduation.
Datadog supports the OpenTelemetry Protocol (OTLP), OTel Collector, and OTel SDKs.
Datadog provides a Preview feature for telemetry ingestion via the standard OTLP HTTP Exporter.
Datadog offers a generally available direct OTLP intake endpoint for metrics, logs, and traces.
The Kubernetes Explorer integrates data from OTel receivers such as kubeletstatsreceiver.
Datadog APM supports services instrumented with OTel SDKs using OTel span semantics and attributes.
RED metrics are generated via the open source spanmetrics connector.
Datadog engineers co-authored the alpha release of OTel Profiles in March 2026.
The Full Host Profiler (Preview) is built on the OTel eBPF profiler.
Datadog participates in OTel special interest groups (SIGs) regarding profiling, sampling, and OpAMP.
Executive Summary
Datadog is expanding its integration with OpenTelemetry (OTel) to allow organizations to maintain vendor-neutral telemetry pipelines while utilizing a centralized observability platform. By supporting the standard OTLP HTTP Exporter and providing a direct OTLP intake endpoint, the platform enables data ingestion without requiring proprietary agents or exporters. This approach is designed to reduce overhead in serverless environments and provide flexibility in how telemetry is routed.
The integration extends to infrastructure and application monitoring, where OTel-native data now directly populates the Kubernetes Explorer and APM workflows without needing transformations or Datadog-specific instrumentation. Beyond product integration, there is an active contribution to the open-source standard, including the co-authorship of OTel Profiles. This dual strategy aims to align the platform's capabilities with the evolving OTel standard, allowing users to adopt open-source instrumentation incrementally.
Full Take
The strongest version of this narrative is that a dominant market player is actively reducing "vendor lock-in" by adopting an open standard, effectively transitioning from a proprietary ecosystem to a supportive role in a neutral one. This represents a strategic shift toward interoperability, ensuring that the platform remains relevant as the industry gravitates toward the CNCF's OpenTelemetry standard.
However, this is a classic vendor advertorial. The persuasion vector relies on the "Authority Game," using the credibility of the CNCF and the OTel project to validate the platform's own product updates. By framing the move as a commitment to "vendor neutrality," the narrative creates a psychological safety net for the user: the promise that they can leave the platform easily (because the data is OTel-native) serves as the primary incentive to join or stay. The load-bearing logic is that the platform is now a "destination" rather than a "cage."
The underlying paradigm is the commoditization of the data plane. When the method of collection becomes a commodity (OTel), the value shifts entirely to the analysis and visualization layer. The benefit is higher flexibility for the engineer; the cost is a continued dependency on the proprietary "brain" that processes the open data.
Patterns detected: ARC-0044 Authority Game
If this were an influence campaign, the playbook would be "The Liberator's Gambit": claim to dismantle your own walls to encourage the target to move deeper into your territory. The actual content aligns with this pattern, as it uses the rhetoric of openness to drive adoption of a specific commercial suite.
Bridge Questions:
1. If the instrumentation is truly vendor-neutral, how much friction actually exists when moving OTel-native data from one backend to another?
2. Does the "semantic normalization" mentioned create a new, hidden form of proprietary lock-in at the analysis layer?
Sentinel — Human
The text reads like a professionally written technical blog post detailing a specific B2B product integration and its implications for an open-source standard, exhibiting high coherence and specificity.