Migrate from Datadog
Elastic endpoints don't accept the Datadog Agent's native metrics protocol. You migrate by sending OpenTelemetry data to Elastic, or by replacing Datadog Agent collection with {edot} or {agent} integrations. Keep Datadog running until the Elastic queries and alerts match what you need, then stop the duplicate stream.
You need:
- An Elastic deployment that can ingest metrics.
- An API key for the ingest path you use. Managed inputs, the Managed OTLP and Managed Prometheus Remote Write endpoints that Elastic Cloud runs for you, authenticate with the
event:writeprivilege for theapmapplication. The Elasticsearch remote write endpoint authenticates with an API key that can ingest metrics. - Your existing pipeline left running. Send data to both systems until you have rebuilt the queries, dashboards, and alerts you rely on.
-
Send your metrics to Elastic
Pick the path that matches how you collect metrics:
If your services already export OTLP, retarget those exporters at Elastic. Change
OTEL_EXPORTER_OTLP_ENDPOINT(and the authentication headers) to the Managed OTLP Endpoint or to Elastic Agent configured as an OTel Collector gateway, using the same settings as any other OTLP client.The Datadog Agent can receive OTLP from your applications and forward it to Datadog. That ingest path doesn't forward the same telemetry to Elastic. Point the applications, or a collector in front of them, at Elastic.
For the endpoint and gateway options by deployment type, refer to Ingest metrics.
If a collector already receives your metrics and exports them to Datadog, add Elastic as a second exporter and send the same metrics to both backends. Keep the Datadog exporter until you have validated Elastic queries and alerts.
Any OpenTelemetry Collector distribution can do this, including vendor distributions. On Elastic Cloud, add an
otlpexporter that points at the Managed OTLP Endpoint. On self-managed Elastic Stack, forward OTLP to Elastic Agent configured as an OTel Collector gateway.For the Elastic OTLP destination, refer to Ingest metrics. For the self-managed gateway pattern, refer to Send data from an upstream OpenTelemetry Collector.
Checks that the Datadog Agent scrapes itself, such as host CPU and memory or Kubernetes state, are Datadog-native, not OTLP. To bring those metrics into Elastic, collect them with Elastic instead of forwarding data from the Datadog Agent.
For the OpenTelemetry schema, follow an Elastic OpenTelemetry quickstart for your hosts or cluster: Get started with metrics.
For Elastic Common Schema (ECS) field names and existing Elastic integrations, use Elastic Agent integrations: Ingest with Elastic Agent integrations.
-
Recreate dashboards and monitors
Elastic has no built-in import for Datadog dashboards and monitors. After metrics are in Elastic, rebuild the views and alerts you still need:
- Explore and chart the new field names. Refer to Explore metrics for how to query and chart them.
- Recreate monitors with a custom threshold rule, or with an inventory rule for resource-centric checks.
Metric names and tags from Datadog don't match OpenTelemetry semantic conventions or ECS one-for-one. Confirm each chart and rule against the fields you ingested before you stop Datadog.