OpenTelemetry Support

What OpenTelemetry is, and where Datadog receives it

OpenTelemetry is a framework that defines, in a form independent of any particular vendor, the SDKs and APIs for extracting traces / metrics / logs from applications, and a protocol called OTLP for transporting them. As of September 2026, Datadog's official documentation lists 2 instrumentation options, "a vendor-neutral configuration using OpenTelemetry SDKs and APIs" and "a configuration using the OpenTelemetry API with Datadog's SDK implementation," and explains that the available features are determined by this choice and by the choice of Collector that processes and forwards the data (source: OpenTelemetry in Datadog). To state the conclusion first, Datadog can receive OTel data at 4 places, and the officially recommended one is via the DDOT Collector bundled with the Datadog Agent. Without this intake, the only way to view assets instrumented with OTel in Datadog would be to rewrite the instrumentation to the dd-trace family of SDKs for APM, giving up instrumentation neutrality. Thanks to the intake, the division of labor "keep instrumentation on the standard, use each tool's strengths for analysis" holds. However, not all features are the same across all routes. The purpose of this article is to write down that difference without hiding it.

There are 4 ingestion routes, and the official recommendation is the DDOT Collector

As of September 2026, the "Send OpenTelemetry Data to Datadog" page places the DDOT Collector as the recommended route, and lists 3 other options: a standalone OpenTelemetry Collector, OTLP Ingest in the Agent, and Direct OTLP Ingest (source: Send OpenTelemetry Data to Datadog).

OTLP receiving in the Agent is disabled by default and is enabled in datadog.yaml or via environment variables. Once enabled, metrics and traces are received by default, but OTLP logs must be explicitly enabled with a separate switch "to avoid unexpected billing" (same source). Also, because the official documentation asks you not to run the Datadog Agent and a separate OpenTelemetry Collector on the same host (source: Datadog and OpenTelemetry Compatibility), the premise is 1 route per host.

How the DDOT Collector differs from the traditional Collector + Exporter

The DDOT Collector (Datadog Distribution of OpenTelemetry Collector) is an open source distribution that selects and bundles the OpenTelemetry Collector components that have been verified in combination with Datadog. It is combined with the Datadog Agent's data collection features and remote management via Fleet Automation (as of September 2026, source: Datadog Distribution of OpenTelemetry Collector). Since it is included in the standard Agent package, there is no need to distribute a separate binary. The bundled components include the otlp, prometheus, filelog, and hostmetrics receivers and a set of exporters including datadogexporter (same source). There are 3 differences from the traditional "standalone Collector + Datadog Exporter." First, there are Datadog-specific components: the Infrastructure Attribute Processor, which automatically adds Kubernetes tags to OTLP data emitted from Pods and containers; the Converter, which corrects known configuration mistakes; and the DD Flare Extension, which gathers diagnostic information from both the Collector and the Agent. Second, the support level is stated explicitly per component. Datadog-made components are maintained by Datadog, community components bundled by default have their compatibility verified by Datadog, and components not in the default set are drawn with the line "guidance is provided but not directly supported" (source: Datadog and OpenTelemetry Compatibility). Third, because the Agent-side features run in the same set of processes, more items in the next section's compatibility table become "available with DDOT." Remote Configuration for remotely distributing configuration is treated as a preview as of September 2026.

Feature compatibility in practice - what you can and cannot use

It is not the case that "with OTel, all features are equivalent." As of September 2026, the official compatibility page tabulates feature support for each of 4 configurations (source: Datadog and OpenTelemetry Compatibility). Organized by tier, it is as follows.

The explainer page for OTLP receiving in the Agent also states explicitly that data instrumented with OpenTelemetry SDKs cannot be used with App and API Protection, Continuous Profiler, or Ingestion Rules (source: OTLP Ingestion by the Datadog Agent). What matters in practice is the last row: experiences such as chasing hotspots with the profiler or descending from a RUM session into a backend trace remain on the Datadog SDK side. Conversely, the core of trace and span visualization and correlation with logs is available even with Direct OTLP Ingest, so a staged approach of "bring data in with OTel first, confirm correlation, then switch to the SDK starting from the features you need" is realistic.

What is data brought in via OTLP counted under?

There is no OTel-specific pricing; the question is which existing SKU the arriving data is counted under. For logs, it is stated explicitly that OTLP log receiving in the Agent is disabled by default "to avoid unexpected billing" (as of September 2026, source: OTLP Ingestion by the Datadog Agent), and it is designed on the premise that once enabled, the data is counted as Log Management ingestion volume. For metrics, since the official definition of custom metrics includes "metrics sent from sources other than the more than 1,000 Datadog integrations" (source: Custom Metrics), metrics that your app emits on its own via the OTel SDK are counted within the custom metrics allotment. The allotment as of August 2026 is 100 per host for Infrastructure Monitoring Pro and 200 for Enterprise (source: Datadog Pricing). Traces fall under the APM billing structure, decided by ingested span volume and the number of indexed spans in addition to the APM host unit price. The ingestion allotment as of August 2026 is 150 GB per APM host per month, and the indexed span allotment is 1 million spans per host per month (15-day retention), both pooled across all APM hosts (same source). The pricing page as of September 2026 also lists a category called "OTLP APM Ingest," but because the unit price could not be confirmed from a primary source, this article does not state a figure. Narrow the spans you retain with ingestion controls. As a caution, the compatibility page states that the combination of AWS EKS Fargate and the OpenTelemetry Collector is not supported and that infrastructure host billing will not be calculated correctly (source: Compatibility, cited above). The overall pricing structure is covered in the pricing guide. Prices in this article are examples at each point in time and do not reflect price revisions after writing.

If you want to reduce vendor dependence, is the division of labor "instrument with OTel, analyze with Datadog" worth it?

Most of the motivation for choosing OTel is "we want to be in a position to switch monitoring tools in the future." What you gain is neutrality of instrumentation code: you can swap the backend just by changing the Collector's destination. What you lose is the last row of the previous section's table, the features that exist only in the Datadog SDK such as Continuous Profiler and RUM correlation. Narrow the decision criteria to 3.

The middle ground the official documentation provides is the "OpenTelemetry API + Datadog SDK" configuration. Because the app code is written against the OTel API with Datadog's SDK as the implementation, it falls in the column where all features are available in the compatibility table (as of September 2026, source: Datadog and OpenTelemetry Compatibility). Since this configuration keeps code neutrality while using Datadog's features, it is the least costly choice for organizations that "use Datadog fully now but do not want the code to be locked in." A configuration to avoid is also shown: mixing the Datadog SDK and the OpenTelemetry SDK in the same application results in undefined behavior (some languages such as Python are exceptions that require both) (same source). Once you have decided the division of labor, simply holding 2 lines, 1 kind of SDK and 1 route per host, avoids many problems.

Steps for the first service - try OTLP receiving in the Agent, then move to DDOT

Even if the production configuration will be DDOT, trying the first service with OTLP receiving in the Agent is quick, and on a host where the Datadog Agent is already running, no additional binary is needed. There are 3 steps. First, enable receiving on the Agent side. The official documentation notes that when specifying via environment variables, they must be passed to both the core Agent and trace Agent processes (as of September 2026, source: OTLP Ingestion by the Datadog Agent).

DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT=0.0.0.0:4318

In container environments, specify 0.0.0.0 rather than localhost and expose the corresponding port. Next, point the app's destination at the Agent, using the OpenTelemetry SDK's standard environment variable.

OTEL_EXPORTER_OTLP_ENDPOINT=http://<datadog-agent>:4318

Finally, confirm that the service appears on Datadog's APM screen and that traces and spans are visible under the expected service name. If you also send logs, additionally enable the 2 settings DD_LOGS_ENABLED=true and DD_OTLP_CONFIG_LOGS_ENABLED=true (same source). What makes things easier later if checked at this stage is whether container tags are attached (the official guidance is to attach resource attributes such as container.id to OTLP metrics). Once you have the correlation experience, expanding in the order of switching to the DDOT Collector at the point you want Kubernetes monitoring or Live Processes, and moving only the services that need the profiler or RUM correlation to the Datadog SDK, avoids waste.