Moving from Datadog.

One Collector (the OpenTelemetry contrib distribution) takes what your services already send, writes it to Sondar and keeps a copy going to Datadog. This is the configuration we ran, cut to the parts that matter:

receivers:
  statsd:                        # DogStatsD clients point here (UDP 8125)
    endpoint: 0.0.0.0:8125
  datadog:                       # dd-trace libraries point here (8126)
    endpoint: 0.0.0.0:8126
  file_log:
    include: [/var/log/app/*.log]

exporters:
  otlp_http/sondar:
    endpoint: http://sondar.internal:9200
    headers:
      authorization: "Bearer ${env:SONDAR_TOKEN}"
  datadog:                       # keep Datadog fed during the overlap
    api: { key: "${env:DD_API_KEY}" }

service:
  pipelines:
    logs:    { receivers: [file_log], exporters: [otlp_http/sondar, datadog] }
    metrics: { receivers: [statsd],   exporters: [otlp_http/sondar, datadog] }
    traces:  { receivers: [datadog],  exporters: [otlp_http/sondar, datadog] }

Component maturity, from each one's own documentation: the statsd receiver is beta, the datadog receiver is alpha, and the datadog exporter is beta. Plan the alpha piece as a bridge, not a destination.

The biggest line item and the easiest to redirect. The Collector's file receiver reads what the Agent was tailing; we sent 12 lines through it and found all 12 in Sondar by keyword. OpenTelemetry logs land in the tracing_logs index with the source type otlp_logs. Datadog's log pipelines do not come across: each becomes an extraction rule, and regex and JSON rules apply at search time, so they reach data you have already stored.

Your DogStatsD clients keep their code and change their destination. We sent a gauge and a counter with service, env and region tags; both arrived with every tag, and the counter summed correctly. One thing changes shape: Sondar stores checkout.latency as checkout_latency, so dashboard queries use the underscored name.

What does not come across: DogStatsD events and service checks, which are not metrics, and the Datadog Agent's own integration checks. For the systems those watched, install the matching Sondar integration app or an OpenTelemetry receiver.

The bridge. Services instrumented with Datadog's tracing libraries can send to the Collector's datadog receiver instead of the Agent, by changing the agent address they already read. We sent a span in Datadog's trace format through it and found it in Sondar under its own service. That buys time, on an alpha component.

The destination. Re-instrument with OpenTelemetry SDKs or OpenTelemetry auto-instrumentation. That is the part that takes weeks, service by service, and it is what makes the rest of your stack portable. Anything Datadog builds on its own libraries beyond traces does not move by configuration; check each one against what Sondar offers before planning around it.

There is no importer for Datadog dashboards or monitors. Each is rebuilt on a SonQL search or an mstats metrics query, then retired in Datadog once the Sondar one has run through a real incident.

Dashboards · Alerts and notifications