Skip to main content

OpenTelemetry with Datadog

Send OpenTelemetry traces, metrics and logs to Datadog through a controlled Collector or Agent pipeline with deliberate sampling and attribute governance.

Integration boundary

OpenTelemetry provides vendor-neutral instrumentation and transport; a Collector or Datadog Agent receives OTLP data and exports it to the Datadog backend.

Supported approaches

OpenTelemetry Collector

Use receivers, processors and a Datadog exporter in a central or gateway deployment.

Datadog Agent OTLP ingest

Send OTLP directly to an Agent configured to receive supported signals.

Prerequisites

  • Instrumented applications or auto-instrumentation
  • An OTLP endpoint reachable from workloads
  • Datadog API/site configuration
  • Attribute, sampling and cost policy

Implementation

1

Choose pipeline topology

Decide between per-node/sidecar agents and gateway collectors based on failure and scaling boundaries.

2

Normalise resource attributes

Set stable service.name, environment and version values before export.

3

Protect the exporter

Keep API credentials server-side and add queues, retries and memory limiting appropriate to the deployment.

Verification

1

Inspect Collector health

Check receiver, processor, exporter and dropped-telemetry metrics.

2

Send a known trace

Follow a controlled request from application span creation to the Datadog service view.

3

Audit cardinality

Identify unbounded attributes before scaling traffic or enabling additional signals.

Boundary failures

Common failure modes

  • Missing service.name fragments telemetry
  • Tail sampling configured without suitable collector topology
  • Unbounded attributes increase cost
  • Collector retries exhaust memory during backend interruption
Engineering signal

Follow OpenTelemetry and Datadog failures and fixes

One useful weekly email with new error references, tools, integration notes and production lessons. No daily noise.