Observability·28. März 2026·9 min

    Von Datadog zu OpenTelemetry in einer Enterprise-Plattform

    Warum wir eine etablierte Datadog-Lösung für 1.000+ Microservices durch einen OpenTelemetry-Stack ersetzt haben — und was wir auf dem Weg dorthin gelernt haben.

    CKR
    CKR Digital

    Datadog ist ein großartiges Produkt. Richtig konfiguriert ist es die schnellste Art, Observability in eine Organisation zu bringen. Falsch konfiguriert ist es die schnellste Art, eine sechsstellige monatliche Rechnung zu produzieren, die niemand mehr hinterfragt.

    In einem Enterprise-Engagement mit über 1.000 Microservices auf AWS/EKS haben wir Datadog durch einen OpenTelemetry-basierten Stack abgelöst. Das Ergebnis: gleiche Signal-Qualität, deutlich niedrigere Kosten, echte Vendor-Neutralität. Hier, was wir gelernt haben.

    Warum ablösen?

    Datadog funktionierte. Das Problem war nicht technisch, es war ökonomisch und strategisch:

    • Custom Metrics explodieren in der Rechnung — Teams legten gutgemeinte Metriken an, die niemand las
    • Host-basierte Pricing-Modelle skalieren schlecht mit Kubernetes (jeder Node zählt, inklusive Spot-Nodes die 5 Minuten leben)
    • Log-Indexing-Kosten waren der größte Einzelposten — und die meisten Logs wurden nie abgefragt
    • Vendor-Lock-in: proprietäre Agents, proprietäre APIs, proprietäre Dashboards
    • OpenTelemetry war 2023/2024 stabil genug für Enterprise-Einsatz — der Moment zum Wechsel war da

    Der Stack, den wir aufgebaut haben

    Keine Magic. Open-Source-Komponenten, die zusammen funktionieren:

    • OpenTelemetry Collector als zentraler Pipeline-Layer (ingestion, transformation, routing)
    • Prometheus für Metrics (mit Mimir/Thanos für langfristige Aufbewahrung)
    • Loki für Logs — deutlich günstiger als Elasticsearch/Datadog Logs bei ähnlicher Query-Qualität
    • Tempo für Traces — native OTLP-Aufnahme, integriert mit Grafana
    • Grafana als einheitliches UI über alle Signal-Typen

    Migration ohne Big Bang

    Niemand schaltet ein Monitoring-System in Produktion mit einem Snap-Finger um. Unser Pfad:

    • Phase 1 — Dual-Ship: OTel-Collector sendet parallel an Datadog UND an den neuen Stack (6 Wochen)
    • Phase 2 — Dashboards migrieren: Team-für-Team neue Grafana-Dashboards erstellen, mit alten Datadog-Dashboards nebeneinander
    • Phase 3 — Alerting migrieren: Alerts in Prometheus/Alertmanager definieren, Datadog-Monitore parallel belassen
    • Phase 4 — Datadog abschalten: erst wenn der neue Stack 30 Tage ohne Incident gelaufen ist

    Was sonst noch wichtig ist

    Kosteneinsparung ist der offensichtliche Benefit. Der versteckte Benefit ist Vendor-Neutralität: mit OpenTelemetry als Datenformat ist jeder Storage-Layer austauschbar. Wer morgen Grafana Cloud nutzen will, wechselt Collectors-Config — nicht den kompletten Instrumentierungs-Stack.

    “Observability-Kosten sind oft ein Zeichen für mangelnde Disziplin, nicht für zu teure Tools. Der Wechsel zu OpenTelemetry zwingt einen, diese Disziplin zu entwickeln.”

    Fazit

    Die Migration von Datadog zu OpenTelemetry ist kein Projekt für jedes Unternehmen. Unter ca. 100 Services ist Datadog oft die ökonomisch richtige Wahl. Ab 500+ Services und sechsstelligen Monatsrechnungen lohnt sich die Analyse. Ab 1.000+ Services ist es fast immer wirtschaftlich — und strategisch sinnvoll.

    Haben Sie ein konkretes Problem?

    Lass uns 30 Minuten sprechen.