The datadog receiver speaks the Datadog Agent's own protocol, so no host has to be reinstrumented before data reaches Elastic: re-point each agent's dd_url, apm_config.apm_dd_url, and logs_config.logs_dd_url at this collector. The otlp receiver takes the services already moved to OTel SDKs, so hosts on either side of the migration run through one pipeline.
Metrics split into two pipelines because Datadog's intake expects delta temporality: only metrics/datadog runs cumulativetodelta, so Elastic keeps the original cumulative series. Traces and logs fan out to both exporters from a single pipeline. Each exporter has its own file_storage-backed queue, so an outage on one backend does not block delivery to the other.
Set DD_API_KEY and DD_SITE for the current backend, and ELASTIC_OTLP_ENDPOINT and ELASTIC_API_KEY for the Elastic Cloud managed OTLP endpoint. Both backends receive identical data for as long as the bridge runs; removing the datadog exporter from the pipelines completes the cutover.
Use this flow
Open the config in Telflo and it becomes a working pipeline on the canvas: adapt what's specific to you, test it against recorded traffic, and push it to your fleet over OpAMP. Free account, no card.
Components
What's in it, and why
Liveness endpoint on :13133 so an orchestrator can tell whether the collector is up.
Backs each exporter queue with disk, so a restart does not drop buffered telemetry. Creates its own directory on first start.
Accepts traces, metrics, and logs from the Datadog Agents already installed on your hosts, so no host has to be reinstrumented before data reaches Elastic.
Entry point for the services you have already moved to OTel SDKs, over gRPC and HTTP.
First in every pipeline so overload becomes backpressure at the receiver rather than an OOM kill of the bridge.
Maps the Datadog env tag onto the semconv deployment.environment.name so both backends group the same data the same way.
Datadog's intake counts in delta temporality; this runs on the Datadog metrics path only, leaving Elastic the original cumulative series.
Last processor before the fan-out, sized under Datadog's 3.2 MB trace-intake limit so both exporters receive the same batches.
Continues delivery to Datadog for the length of the migration, with its own disk-backed queue.
Sends an identical copy to Elastic Cloud's managed OTLP endpoint, authenticated with an Elasticsearch API key.
Notes
Gotchas
- 1
The
datadogreceiver is an alpha component and implements no/api/v1/validateroute, so re-pointed agents log API-key validation errors on startup while their data still flows. Replay recorded agent traffic through the bridge before rolling it out to a fleet. - 2
Only traces, metrics, and logs have an intake here. Live Process, Network Performance Monitoring, and orchestrator traffic have nowhere to land, so leave those agents pointed at Datadog until you stop paying for them.
- 3
Datadog Agent logs only reach this receiver over HTTP; set
logs_config.force_use_http: trueon the agent or the log stream silently stays on the old path. - 4
At this collector version the
datadogexporter retries logs only, so a long Datadog outage can drop queued traces and metrics even though the queue is disk-backed. Elastic delivery is unaffected because each exporter owns its own queue. - 5
Metrics are split across two pipelines purely for temporality. Elastic accepts cumulative on Serverless and Hosted 9.5+, but on Hosted 9.0 through 9.4 you must route
metrics/elasticthroughcumulativetodeltaas well or the series will not land. - 6
Both backends receive a full copy of everything, so egress and any per-GB ingest cost roughly double for as long as the bridge runs.
- 7
The
otlp_httpexporter id wasotlphttpbefore collector core v0.144.0. On an older collector, rename it or the config will not load.
Sources and references (5)ShowHide
Everything consulted while researching and fact-checking this flow, including the README of every component it uses.
- github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/datadogreceiver
- github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/datadogexporter
- github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/cumulativetodeltaprocessor
- github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/storage/filestorage
- www.elastic.co/observability/opentelemetry
More flows
Related flows
Ship OTel data to ClickHouse
Parses JSON log bodies into queryable attributes, coalesces msg/log and lvl/level field variants, maps severity text onto the OTel severity fields, and masks PII in attributes and bodies.
Dual-ship to two backends during a migration
Fans every trace, metric, and log out to both the legacy agent and the new OTLP/HTTP backend so the two can be compared side by side during a migration.
Replace vendor agents on your VM fleet
Scrapes CPU, memory, load, disk, filesystem, and network metrics plus system and application logs on every VM.
Test it before your fleet runs it
Free account, no card. Open this flow in the editor, adapt it, and see what it does to real data before anything ships.