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
Choose pipeline topology
Decide between per-node/sidecar agents and gateway collectors based on failure and scaling boundaries.
Normalise resource attributes
Set stable service.name, environment and version values before export.
Protect the exporter
Keep API credentials server-side and add queues, retries and memory limiting appropriate to the deployment.
Verification
Inspect Collector health
Check receiver, processor, exporter and dropped-telemetry metrics.
Send a known trace
Follow a controlled request from application span creation to the Datadog service view.
Audit cardinality
Identify unbounded attributes before scaling traffic or enabling additional signals.
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
Follow OpenTelemetry and Datadog failures and fixes
A useful digest about twice a week with new error references, tools, integration notes and production lessons. No daily noise.