Using Datadog with OpenTelemetry: 3 integration paths

If you have services already instrumented with OpenTelemetry and a Datadog account on the other end, this post is for you. Datadog accepts OTLP data through three different integration paths, each with different trade-offs. Picking the right one matters because the choice quietly determines which Datadog features keep working, which features break, and how portable your instrumentation stays.

We make Telemtra, a pure-OpenTelemetry backend. So we have an obvious bias when it comes to "go pure OTel" recommendations. We've written this anyway because most of the integration content for OTel + Datadog is sales-pitched from one side or the other, and the practical answer for many teams is "use Datadog with OTel for a while, decide later." That's a defensible choice.

The three integration paths

1. OTel Collector with the `datadog` exporter

The most flexible path. Run a standard OpenTelemetry Collector and configure the datadog exporter to forward traces, metrics, and logs to Datadog's intake API. Your applications speak OTLP to the Collector; the Collector speaks Datadog's wire format to Datadog.

exporters:
  datadog:
    api:
      key: ${env:DD_API_KEY}
      site: datadoghq.com
    hostname_source: config_or_system

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]

Pros: applications stay vendor-neutral; they only know OTLP. Backend switches are an exporter change, not an instrumentation rewrite. You can fan out to two backends (Datadog and another) simultaneously with two exporters, which is useful for migrations.

Cons: some Datadog features that depend on the native agent (Continuous Profiler, Database Monitoring, certain RUM integrations) don't activate via this path. You're trading feature breadth for portability.

2. Datadog Agent with the OTLP receiver

Install the Datadog Agent as normal. Enable the agent's OTLP receiver in datadog.yaml. Applications send OTLP to the agent (on the same host or a sidecar), and the agent forwards to Datadog.

# /etc/datadog-agent/datadog.yaml
otlp_config:
  receiver:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

Pros: all Datadog Agent features stay available (profiling, security signals, network performance monitoring, host integrations) because the agent is still in the pipeline. You get OTel-instrumented apps with Datadog-agent-level coverage of the host.

Cons: you still run the Datadog Agent everywhere. The vendor footprint hasn't shrunk; you've just added OTel as an input format. The portability story is weaker because the agent is doing host-level data collection that doesn't go anywhere else.

3. DDOT Collector (Datadog's OTel Collector distribution)

Datadog ships a customized OpenTelemetry Collector distribution called DDOT (Datadog Distribution of OpenTelemetry Collector). It's a standard Collector plus Datadog-maintained components and processors that activate more Datadog features than the vanilla Collector path can.

Pros: closer to feature parity with the Datadog Agent path, but with the OTel data model preserved end-to-end inside the Collector pipeline. Newer than the other two options; the maturity curve is improving.

Cons: binary specific to Datadog; you can't reuse the same Collector to send to another backend without rebuilding the pipeline. You've adopted a Datadog distribution of an OSS tool, which feels OTel-native but reintroduces a vendor binary into the stack.

What works the same vs differently

Three categories of behaviour to understand:

Works the same on every path

OTel-instrumented HTTP server and client spans
OTel-instrumented database client spans (with the right semantic conventions)
OTLP log records, with trace ID correlation when the SDK log bridge is in use
Most OTel metrics (counter, gauge, histogram, observable)
W3C tracecontext propagation between services

Works differently or partially

Semantic conventions. Datadog has its own attribute model (tags, service tag, env tag). The conversion from OTel's service.name, deployment.environment, and resource attributes to Datadog's tag namespace is mostly automatic but not lossless. Custom OTel attributes can land under unexpected tag names.
Span linking and exemplars. OTel supports span links and metric exemplars. Datadog renders them, but with some translation; the UX is not identical to native OTel backends.
Trace ID encoding. OTel uses 128-bit trace IDs; Datadog originally used 64-bit. Modern Datadog supports 128-bit; older configurations may truncate. Verify with your Datadog Agent version.
Sampling decisions. Tail sampling in the OTel Collector can conflict with head sampling configured on the Datadog side. Pick one or the other; running both produces over-sampled data and confusing rate calculations.

Requires the Datadog agent or DD library, doesn't work on the pure Collector path

Continuous Profiler. OTel does not yet have a stable profiling signal. Datadog's profiler is its own library.
Database Monitoring (DBM). Datadog DBM uses its own agent components to sample queries and collect database metadata.
Cloud Network Monitoring. Network flow data is collected by the Datadog Agent, not by OTel.
Some RUM features. Datadog RUM uses its own browser SDK; OTel's browser tracing is less mature.
LLM Observability. Datadog's LLM features depend on their tracer libraries; OTel's LLM semantic conventions are evolving but not yet at parity.

A decision matrix

If you are deciding between the three paths, the practical filter:

Future-flexibility matters most to you → OTel Collector + datadog exporter. You can leave whenever.
You need Datadog feature breadth (profiling, DBM, RUM, NPM) right now → Datadog Agent + OTLP receiver. Apps stay OTel-instrumented, agent stays Datadog.
You want the hybrid (OTel Collector pipeline operationally, but more Datadog feature activation than the vanilla exporter gives) → DDOT Collector. Newer and Datadog-specific, but increasingly capable.

The case for going pure OpenTelemetry instead

If your reason for adopting OTel is portability, the path that maximises that property is exporting OTLP to an OTel-native backend rather than to Datadog. The integration paths above are useful, but the underlying tension doesn't go away: any Datadog-specific feature you depend on becomes a switching cost.

The honest decision criterion: if you would migrate off Datadog tomorrow if a credible alternative existed, the cost of staying compounds the longer you depend on Datadog-only features. If you'd happily stay regardless, the OTel + Datadog combination is a fine destination.

Pure-OTel backends in 2026 include Telemtra, SigNoz, Honeycomb (events-first), and the self-hosted Prometheus + Tempo + Loki + Grafana stack. We've written a longer comparison: Datadog alternatives in 2026.

A migration on-ramp that doesn't burn bridges

If you want to keep options open, the OTel Collector's multi-exporter pattern lets you fan out to Datadog and a second backend in parallel during evaluation. Cost goes up by the second backend's per-GB rate; risk goes down because you can compare cost and queries before committing.

exporters:
  datadog:
    api:
      key: ${env:DD_API_KEY}
  otlphttp/telemtra:
    endpoint: https://ingest.telemtra.io
    headers:
      x-api-key: ${env:TELEMTRA_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog, otlphttp/telemtra]

The same pattern works for any OTLP-capable second backend; substitute the exporter block for whichever candidate you're evaluating.

Using Datadog with
OpenTelemetry.

The three integration paths

1. OTel Collector with the `datadog` exporter

2. Datadog Agent with the OTLP receiver

3. DDOT Collector (Datadog's OTel Collector distribution)

What works the same vs differently

Works the same on every path

Works differently or partially

Requires the Datadog agent or DD library, doesn't work on the pure Collector path

A decision matrix

The case for going pure OpenTelemetry instead

A migration on-ramp that doesn't burn bridges

Further reading

Using Datadog withOpenTelemetry.

The three integration paths

1. OTel Collector with the datadog exporter

2. Datadog Agent with the OTLP receiver

3. DDOT Collector (Datadog's OTel Collector distribution)

What works the same vs differently

Works the same on every path

Works differently or partially

Requires the Datadog agent or DD library, doesn't work on the pure Collector path

A decision matrix

The case for going pure OpenTelemetry instead

A migration on-ramp that doesn't burn bridges

Further reading

Using Datadog with
OpenTelemetry.

1. OTel Collector with the `datadog` exporter