Datadog → OpenTelemetry

Datadog ist die Observability-Plattform, die Teams lieben – bis die Rechnung kommt. Das Produkt ist ausgezeichnet; das Problem ist die Preisgestaltung – Infrastruktur-Abrechnung pro Host, Log-Ingestion pro GB plus Indexierung pro Event, Mehrkosten für Custom Metrics und ein Stapel von SKUs pro Signal, die die Gesamtsumme wirklich schwer prognostizierbar machen. Und das, was Sie an all das bindet, ist der Datadog Agent: ein herstellerspezifischer Collector, der Datadog spricht und Datadog füttert.

OpenTelemetry ist der Ausweg, und die gute Nachricht ist, dass Datadog selbst OTLP-Ingestion unterstützt – Sie können OpenTelemetry also einführen, ohne Datadog am ersten Tag zu verlassen, und dann über das Backend entscheiden, sobald Sie nicht mehr an den Agent gebunden sind. Dies ist das Datadog-spezifische Playbook; die umfassendere Argumentation finden Sie in Vendor-Lock-in mit OpenTelemetry reduzieren.

Was zu OpenTelemetry migriert – und was nicht

OTel ersetzt den Agent und das Wire-Format von Datadog. Es ersetzt nicht das Backend von Datadog, dessen Query-Modell oder die darauf aufsetzenden Analytics-Funktionen – die werden beibehalten, anderswo neu aufgebaut oder aufgegeben:

Datadog-Fähigkeit	Zu OTel migrieren?	Anmerkungen
Host-/Infra-Metriken	Ja	hostmetrics (+ kubeletstats) ersetzen die Core-Checks des Agents.
APM / Distributed Tracing	Meist	OTel-SDKs, oder dd-trace behalten und mit dem datadog-Receiver des Collectors empfangen; Span-/Service-Benennung validieren.
Logs	Ja	filelog- / journald-Receiver; Log-Pipeline-Parsing als Processors nachbauen.
DogStatsD Custom Metrics	Grösstenteils	Der statsd-Receiver nimmt Metriken im DogStatsD-Format auf; Events und Service Checks lassen sich nicht portieren.
Agent-Integrationen (Checks)	Oft	Viele lassen sich auf den prometheus-Receiver oder OTel-Receiver abbilden; einige sind Datadog-spezifisch.
Unified Service Tagging (env/service/version)	Ja	Abbildung auf die Resource-Attribute deployment.environment.name, service.name, service.version.
Dashboards	Nein	Im neuen Backend neu aufbauen, oder Datadog dafür behalten.
Monitors / Alerts	Nein	Separat zum Alerting des neuen Backends migrieren.
Live Processes / Live Containers	Teilweise	Prozess-/Container-Metriken portieren; die Live-View-UX ist Datadog-spezifisch.
Network Performance Monitoring (NPM)	Meist nicht	eBPF-basiert, Datadog-spezifisch; keine OTel-native Fähigkeit.
Watchdog / Analytics	Nein	Hersteller-Analytics; das Backend, zu dem Sie wechseln, liefert – falls überhaupt – eigene.
Backend-Speicherung & -Query	Nein	OTel ist kein Backend – hier lebt das verbleibende Lock-in.

Die Faustregel: OTel bewältigt Collection (Metriken, Traces, Logs, DogStatsD) und Unified Service Tagging sauber. Datadog-spezifische Produkte – NPM, Live Processes, Watchdog, die Dashboards und Monitors – sind nichts, was Sie „migrieren”; Sie behalten sie, ersetzen sie oder legen sie bewusst still. (Für die allgemeine Version siehe was OpenTelemetry ersetzen kann und was nicht.)

Den Datadog Agent auf OTel abbilden

Die Migration ist grösstenteils ein Komponente-für-Komponente-Austausch. Alles, was der Datadog Agent tut, hat ein Äquivalent nach offenem Standard:

Datadog	OpenTelemetry-Äquivalent
Datadog Agent (Metriken, datadog-agent)	OTel Collector mit hostmetrics- + prometheus-Receivern
Trace Agent / APM-Bibliotheken (dd-trace)	OTLP-Receiver + OTel-SDK, oder dd-trace behalten und mit dem datadog-Receiver aufnehmen
Log-Collection (logs_config)	filelog- / journald-Receiver
DogStatsD	statsd-Receiver
Agent-Integrationen / Checks	prometheus-Receiver (Scrape) + OTel-Receiver
Unified Service Tagging (env/service/version)	resource-Processor → deployment.environment.name, service.name, service.version
Datadog-Backend	datadog-Exporter – oder ein beliebiges OTLP-Backend

Die letzte Zeile ist das Schlupfloch. Der datadog-Exporter des OTel Collectors schreibt direkt nach Datadog, Sie können OpenTelemetry also unter Ihre gesamte Pipeline legen, während Datadog genau wie zuvor weiterläuft. Zuerst die Einführung; die Backend-Entscheidung später.

Zwei Datadog-spezifische Details werden Ihnen schaden, wenn Sie sie überspringen. APM-Bibliotheken: Datadogs Tracer (dd-trace) emittieren Datadogs eigenes Span-Format, nicht OTLP – wechseln Sie entweder zu OTel-SDKs, oder behalten Sie dd-trace und lassen Sie den datadog-Receiver des Collectors dessen Traffic aufnehmen (DD_TRACE_OTEL_ENABLED schaltet nur die In-Process-API auf OpenTelemetry um; der Export bleibt im Datadog-Format). So oder so: Prüfen Sie, dass Service-, Operation- und Resource-Namen weiterhin dem entsprechen, worauf Ihre Dashboards aufsetzen. Metrik-Benennung: Datadog-Metriknamen (system.cpu.user) unterscheiden sich von den OTel Semantic Conventions (system.cpu.utilization mit Attributen). Der datadog-Exporter bildet viele ab, aber Custom-Dashboards und Monitors, die exakte Metriknamen referenzieren, müssen eventuell angepasst werden – auditieren Sie Ihre wichtigsten Monitors vor dem Cutover, nicht danach.

Schritt 1 – Den Agent durch einen Collector ersetzen, weiterhin Datadog füttern

Stellen Sie einen OTel Collector neben (oder anstelle) des Datadog Agents bereit, konfiguriert für den Export nach Datadog. Nutzer bemerken keinen Unterschied; die Collection-Ebene ist jetzt offen.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  hostmetrics:
    collection_interval: 30s
    scrapers: { cpu: , memory: , disk: , network: , load: }

exporters:
  datadog:
    api:
      key: "${DD_API_KEY}"

service:
  pipelines:
    metrics:
      receivers: [otlp, hostmetrics]
      exporters: [datadog]
    traces:
      receivers: [otlp]
      exporters: [datadog]

Schritt 2 – Dual-Shipping zu Datadog und einem Kandidaten

Fügen Sie einen zweiten Exporter hinzu und senden Sie dieselbe Telemetrie an ein Kandidaten-OTLP-Backend. Jetzt können Sie Dashboards, Monitors und APM-Traces auf Live-Daten vergleichen, wobei Datadog weiterhin das System of Record ist. Das ist der Parallelbetrieb, der die Migration sicher macht.

exporters:
  datadog:
    api:
      key: "${DD_API_KEY}"
  otlphttp/candidate:
    endpoint: "https://backend.internal:4318"

service:
  pipelines:
    metrics:
      receivers: [otlp, hostmetrics]
      exporters: [datadog, otlphttp/candidate]

Das Topology-Canvas unten zeigt genau diese Form – ein Stream, der auf mehrere Backends aufgefächert wird, mit Live-Durchsatz pro Kante, sodass Sie sehen, was jedes Ziel tatsächlich empfängt:

Schritt 3 – Die Rechnung dort angreifen, wo sie tatsächlich wächst

Datadogs Kosten haben drei Haupttreiber, und ein OTel Collector gibt Ihnen einen Hebel für jeden:

• Log-Ingestion (pro GB) & Indexierung (pro Event). Filtern Sie Debug-Logs, Health-Check-Spam und geschwätzige Erfolgs-Events am Collector, bevor sie ingestet werden. Das ist der grösste, sicherste Schnitt – oft mehr als die Hälfte des Log-Volumens.
• Custom Metrics (Abrechnung pro Serie). Metrik-Kosten sind ein Kardinalitäts-Spiel: jede eindeutige Tag-Kombination ist eine abrechenbare Zeitreihe, und ein einziges Tag mit hoher Kardinalität (eine User-ID, eine Request-ID, eine rohe URL) kann Ihre Rechnung explodieren lassen. Verwerfen oder aggregieren Sie ausufernde Labels am Collector, bevor sie sich vervielfachen.
• Infra pro Host. Die Konsolidierung der Collection und das Routing nur dessen, was jedes Backend benötigt, reduziert, was Sie pro Host senden.

processors:
  # Drop sub-INFO logs before they're ingested
  # (also matches logs with UNSET severity — parse severity first, or add
  # 'severity_number != SEVERITY_NUMBER_UNSPECIFIED' to keep unparsed logs)
  filter/drop_debug:
    logs:
      log_record:
        - 'severity_number < SEVERITY_NUMBER_INFO'
  # Strip a high-cardinality tag that explodes custom-metric series
  attributes/drop_cardinality:
    actions:
      - key: request_id
        action: delete

Jeder verworfene Record und jede beschnittene ausufernde Serie ist Geld, das nie den Zähler erreicht. Die vollständige Methode – messen, filtern, samplen, routen – finden Sie in wie Sie Observability-Kosten senken. Sie können ausserdem PII vor dem Egress maskieren, was Payloads verkleinert und sensible Felder gleichzeitig aus einem Drittanbieter-Backend heraushält.

Schritt 4 – Die Flotte verwalten und die Einsparungen sehen

Den Datadog Agent durch rohe OTel Collectors zu ersetzen bedeutet, Datadogs Flottenmanagement und Fleet Automation zu verlieren. Machen Sie dort keinen Rückschritt. Verwalten Sie die Collectors von einer Control Plane, die auf OpAMP aufbaut: LinkMesh ist eine selbstgehostete, mit der Sie Sources, Processors und Routes in einer visuellen UI aufbauen, die Config validieren und an die richtigen Nodes ausrollen – mit Durchsatz pro Kante, sodass das gerade eingesparte Volumen eine Zahl ist, auf die Sie zeigen können, keine Hoffnung.

Und die Wirtschaftlichkeit muss stimmen: Ein Tool, das Sie einführen, um der Volumen-Preisgestaltung zu entkommen, sollte nicht selbst nach Volumen abrechnen. LinkMesh wird pro verwaltetem Collector abgerechnet, nicht pro Host oder Gigabyte – jedes Gigabyte, das Sie nicht mehr senden, ist also reine Ersparnis auf der Backend-Rechnung und erhöht nie die Kosten der Pipeline. Die Telemetrie fliesst direkt von Ihren Collectors zu Ihrem Backend und bleibt auf Ihrer Infrastruktur; die Control Plane verwaltet nur die Config.

Parität validieren – und das Doppelabrechnungs-Fenster im Blick behalten

Dual-Shipping zu Datadog und einem Kandidaten bedeutet, dass Sie während der Überlappung für beide zahlen – validieren Sie also zügig und halten Sie das Fenster kurz. Die Checkliste:

• Metriken – vergleichen Sie Schlüsselmetriken und, entscheidend, die Custom-Metric-Zählungen zwischen Agent und OTel. Ein Kardinalitätsunterschied verändert, wofür Sie abgerechnet werden.
• Traces – bestätigen Sie, dass Service-Namen, Operation-/Resource-Namen und Span-Struktur dem entsprechen, worauf Ihre APM-Dashboards und Monitors aufsetzen (hier treten die Benennungsunterschiede zwischen dd-trace und OTel-SDK zutage).
• Logs – prüfen Sie, dass Parsing, env-/service-Tags und Log-zu-Trace-Korrelation den Umzug von Datadog-Log-Pipelines zu Collector-Processors überstanden haben.
• Unified Service Tagging – kontrollieren Sie, dass env, service und version als Resource-Attribute vorhanden sind, damit das Filtern sich wie zuvor verhält.
• Monitors – richten Sie Ihre höchstpriorisierten Monitors auf die OTel-gespeisten Daten neu aus und bestätigen Sie, dass sie weiterhin auslösen; achten Sie auf Monitors, die exakte Datadog-Metriknamen referenzieren.
• Verworfene Telemetrie – prüfen Sie die internen Metriken des Collectors auf abgelehnte/verworfene Daten, damit ein Filter nicht stillschweigend Signal verschluckt.
• Kosten – bestätigen Sie, dass der reduzierte Stream das ingestete Volumen und die Custom-Serien tatsächlich gesenkt hat und dass Sie nicht versehentlich die Host-Zählungen verdoppeln, indem Sie Agent und Collector während der Überlappung auf denselben Hosts betreiben.

Einen Rollback-Plan haben

• Behalten Sie den Datadog Agent (oder den datadog-Exporter-Pfad) aktiv, bis der Kandidat die Validierung für einen vereinbarten Zeitraum besteht.
• Unabhängige Exporter – Datadog und der Kandidat sind separate Blöcke; verwerfen oder stellen Sie einen wieder her, ohne den anderen anzufassen.
• Definieren Sie Erfolgsschwellen – Metrik-/Trace-Parität, auslösende Prioritäts-Monitors, Volumen um den erwarteten Betrag gesenkt – bevor Sie irgendetwas entfernen.
• Achten Sie während der Überlappung auf den Zähler – Dual-Shipping zu Datadog kostet Geld; setzen Sie eine Frist für den Vergleich, damit das Doppelabrechnungs-Fenster nicht ausufert.
• Stilllegen nach einem Beobachtungszeitraum, nicht beim ersten grünen Ergebnis.

Schritt 5 – Über Datadog zu Ihren Bedingungen entscheiden

Hier ist der wichtige Teil: Sobald Sie auf OTel sind, müssen Sie Datadog überhaupt nicht verlassen. Viele Teams behalten Datadog für APM oder eine Teilmenge kritischer Services und routen den Rest – günstig zu speichernde Logs, archivierte Telemetrie – an ein OTLP-Backend oder Object Storage. Der Sinn der Migration ist nicht zwingend „Datadog aufgeben”; es geht darum, Bleiben oder Gehen zu einer Wahl statt einer Gefangenschaft zu machen.

Wenn Sie doch umsteigen, ist es eine Exporter-Änderung, kein Re-Instrumentierungsprojekt. Ihre Daten sind OTLP, Ihre Flotte läuft auf OpAMP, und die nächste Backend-Entscheidung ist einen Config-Block entfernt.

Die Migration in fünf Schritten

1. Den Agent ersetzen – OTel Collectors bereitstellen, die über den datadog-Exporter nach Datadog exportieren. Für Nutzer ändert sich nichts.
2. Dual-Shipping – ein Kandidaten-OTLP-Backend hinzufügen und auf Live-Daten vergleichen.
3. Volumen kürzen – Logs filtern, Metriken mit hoher Kardinalität beschneiden und am Collector samplen, um die drei Kostentreiber direkt anzugreifen.
4. Validieren & Rollback behalten – die Checkliste abarbeiten, das Doppelabrechnungs-Fenster beobachten, den Agent als Sicherheitsnetz behalten.
5. Entscheiden – Datadog für das behalten, was es Ihnen wert ist, den Rest anderswohin routen oder vollständig umsteigen. Auf OTLP ist es Ihre Entscheidung.

Der Datadog Agent war das Lock-in auf der Collection-Ebene und die Rechnung war das Symptom. Verlagern Sie die Collection zu OpenTelemetry, und beides wird zu etwas, das Sie kontrollieren – während Sie in Datadog alles behalten, was analytisch noch seinen Platz verdient.