Dynatrace → OpenTelemetry

Dynatraces Versprechen ist Tiefe: Installieren Sie den OneAgent, und er auto-instrumentiert alles – Hosts, Prozesse, JVMs, Datenbankaufrufe, Real-User-Sessions – mit sehr geringem Aufwand. Diese Tiefe ist real, und sie ist zugleich die Quelle des Lock-ins. Der OneAgent ist ein einzelnes proprietäres Binary, das Discovery, Instrumentierung und Collection auf einmal erledigt, und es füttert genau einen Ort: Dynatrace. Die Preisgestaltung folgt derselben Form – Host Units, DDUs (Davis Data Units) und Verbrauchszähler, die die Rechnung schwer vorhersehbar und noch schwerer deckelbar machen.

Der Wegzug fühlte sich früher genau deshalb unmöglich an, weil der OneAgent so viel leistete. OpenTelemetry ändert das, indem es diese Aufgaben in offene Standards entbündelt, die Ihnen gehören – und Ihnen erlaubt, beide Stacks parallel zu betreiben, bis Sie dem neuen vertrauen. Dieser Leitfaden ist das Dynatrace-spezifische Playbook; für die allgemeine Argumentation siehe Vendor-Lock-in mit OpenTelemetry reduzieren.

Was der OneAgent leistet, was OTel (noch) nicht ersetzt

Der OneAgent ist nicht nur ein Collector – er ist eine tiefe, auto-injizierende APM-Plattform. Ehrlich über die Lücke zu sein, ist es, was diese Migration davor bewahrt, auf halbem Weg zu scheitern:

Dynatrace-Fähigkeit	OTel-Äquivalent?	Realität
Host-/Prozess-/Container-Metriken	Ja	hostmetrics + kubeletstats decken den Standardsatz ab.
Distributed Traces	Ja	OTel-SDKs / Auto-Instrumentierung emittieren OTLP-Spans.
Log-Collection	Ja	filelog- / journald-Receiver.
Tiefe Code-Auto-Injection (ohne Codeänderung)	Teilweise	OTel-Auto-Instrumentierung ist gut, aber nicht so unsichtbar wie die Bytecode-Injection des OneAgent; einige Sprachen brauchen mehr Setup.
PurePath (End-to-End-Traces auf Code-Ebene)	Teilweise	OTLP-Distributed-Traces decken die Hops ab; die Method-Level-Tiefe von PurePath ist nicht vollständig äquivalent.
Smartscape-Topologie (auto-erkannt)	Nein	Aus Traces/Attributen ableitbar, aber Dynatraces Live-Dependency-Map überträgt sich nicht 1:1.
Davis AI (automatische Root-Cause)	Nein	Hersteller-Analytics; das Backend, zu dem Sie wechseln, liefert – falls überhaupt – eigene.
Real User Monitoring (RUM)	Meist nicht	OTel hat Browser-/Mobile-Signale, aber keine RUM-/Session-Feature-Parität.
Synthetic Monitoring	Nein	Separate Fähigkeit; behalten Sie sie oder ersetzen Sie sie durch ein dediziertes Tool.
Metadaten-Anreicherung (Auto-Tags, Entities)	Teilweise	Mit resource-/k8sattributes-Processors nachbauen; das Entity-Modell unterscheidet sich.

Das Fazit: OTel ersetzt die Collection- und Standard-Telemetrie-Ebene bequem und gibt Ihnen portable Traces, Metriken und Logs. Es ersetzt nicht pauschal Dynatraces Analytics und Auto-Magie – RUM, Synthetics, Smartscape und Davis werden behalten, durch andere Tools ersetzt oder bewusst aufgegeben, nicht migriert. Entscheiden Sie, worauf Sie tatsächlich angewiesen sind, bevor Sie irgendetwas anfassen. (Siehe was OpenTelemetry ersetzen kann und was nicht für die allgemeine Version.)

Die mentale Verschiebung: den OneAgent entbündeln

Die Stärke des OneAgent – ein Binary, das alles tut – ist genau das, was Sie rückgängig machen. In der OpenTelemetry-Welt sind diese Zuständigkeiten getrennt, offen und einzeln ersetzbar:

Dynatrace OneAgent leistet…	…OpenTelemetry teilt es auf in
Tracing auf Code-Ebene (Auto-Instrumentierung)	OTel-SDKs + Zero-Code-Auto-Instrumentierungs-Agents
Host- & Prozessmetriken	hostmetrics-Receiver auf einem OTel Collector
Log-Collection	filelog- / journald-Receiver
Datenweiterleitung an den Hersteller	OTLP-Exporter an ein beliebiges Backend
PurePath / Service-Topologie	Distributed Traces (OTLP), gerendert von Ihrem Backend
Flotten-Konfiguration	OpAMP-Control-Plane

Der Handel ist ehrlich: Sie geben etwas von der schlüsselfertigen Auto-Magie des OneAgent auf und erhalten im Gegenzug eine Instrumentierungsebene, die portabel, inspizierbar und Ihr Eigentum ist – eine, die kein Hersteller widerrufen oder neu bepreisen kann. Für viele Teams ist der entscheidende Faktor, dass OTLP-Traces und -Metriken mit jedem Backend funktionieren, sodass dies die letzte Agent-Migration ist, die sie je durchführen müssen.

Schritt 1 – Mit OTel neben dem OneAgent instrumentieren

Sie müssen den OneAgent nicht entfernen, um zu beginnen. Fügen Sie OpenTelemetry-Instrumentierung parallel hinzu:

• Neue Services: Verwenden Sie das OTel-SDK oder einen Zero-Code-Auto-Instrumentierungs-Agent (Java, .NET, Node, Python – Go über die eBPF-basierte Zero-Code-Option, noch reifend), um OTLP-Traces und -Metriken zu emittieren.
• Hosts: Stellen Sie einen OTel Collector mit den hostmetrics- und filelog-Receivern für Infrastruktur- und Log-Coverage bereit.

Richten Sie dieses OTLP auf einen Collector, nicht direkt auf ein Backend – der Collector ist der neutrale Broker, der alles nach diesem Schritt möglich macht.

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:

exporters:
  otlphttp/backend:
    endpoint: "https://backend.internal:4318"

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/backend]
    metrics:
      receivers: [otlp, hostmetrics]
      exporters: [otlphttp/backend]

Schritt 2 – Beide Stacks betreiben und Parität validieren

Dies ist der Schritt, der eine Dynatrace-Migration entrisikt. Lassen Sie den OneAgent weiterhin an Dynatrace reporten, und betreiben Sie zugleich den OTel-Stack in ein Kandidaten-Backend. Erledigen Sie dann die langweilige, essenzielle Arbeit, die Signalparität gegen eine Checkliste zu bestätigen:

• Metriken – stimmen Host-, Prozess- und Container-Metriken mit dem überein, was Dynatrace zeigt, innerhalb einer Toleranz? Achten Sie auf herstellerspezifische Metriken ohne direktes OTel-Äquivalent.
• Traces – überspannen Distributed Traces dieselben Service-Hops? Akzeptieren Sie, dass die Method-Level-Tiefe von PurePath nicht vollständig äquivalent sein mag, und entscheiden Sie, ob das für die betreffenden Services relevant ist.
• Resource-Attribute – sind service.name, deployment.environment.name, Host und Ownership-Tags vorhanden, sodass Entities so zuordenbar sind, wie Smartscape sie gemacht hat?
• Logs – werden Severities und Timestamps korrekt geparst, und sind Logs über Trace-/Span-IDs mit Traces korreliert?
• Verworfene Telemetrie – prüfen Sie die internen Metriken des Collectors auf abgelehnte/verworfene Daten; ein stiller Exporter-Fehler liest sich wie „sauberere Daten”, bis ein Incident kommt.
• Sampling – bestätigen Sie, dass Fehler und langsame Requests zu 100 % behalten werden; samplen Sie nur den hochvolumigen Happy Path.
• Alerts & Dashboards – bauen Sie die Alerts, auf die Sie tatsächlich alarmiert werden, gegen das Kandidaten-Backend neu auf und bestätigen Sie, dass sie bei denselben Bedingungen auslösen.
• Fehlerverhalten – starten Sie einen Collector neu, kappen Sie eine Backend-Verbindung; bestätigen Sie, dass er puffert und ohne Datenverlust fortsetzt.

Weil beide Stacks gleichzeitig laufen, können Sie diese auf Live-Produktionsdaten beantworten, wobei Dynatrace als Sicherheitsnetz weiterhin vollständig in Betrieb ist. Nichts wird abgeschaltet, bevor der neue Stack es sich verdient hat.

Schritt 3 – Die Collector-Flotte von einem Ort aus verwalten

Den OneAgent zu entfernen bedeutet, sein zentrales Management aufzugeben – Dynatrace deployt und aktualisiert Agents von der Plattform aus. Ersetzen Sie ihn durch handgepflegtes OTel-Collector-YAML, haben Sie eine verwaltete Flotte gegen eine unverwaltete eingetauscht, und das ist ein Rückschritt, den Ihr Ops-Team sofort spürt.

Die Lösung ist eine Control Plane, die auf OpAMP aufbaut, dem offenen Standard zur Verwaltung von Collector-Flotten. LinkMesh ist eine selbstgehostete: Jeder Collector meldet sich mit seinem Status, seiner Version und seinem OpAMP-Modus, und Sie konfigurieren die gesamte Flotte von einem visuellen Builder aus, statt Dateien pro Node zu bearbeiten. Sie rendert und validiert die Config zentral und rollt sie aus – die Flottenmanagement-Erfahrung des OneAgent, aber für Collectors nach offenem Standard, die Ihnen gehören.

Entscheidend ist: Die Telemetrie wird niemals durch die Control Plane geroutet – sie fliesst direkt von Ihren Collectors zu Ihrem Backend und bleibt auf Ihrer Infrastruktur. LinkMesh verwaltet nur die Konfiguration.

Schritt 4 – Dem Preismodell entkommen, nicht nur dem Agent

Der Grund, aus dem viele Teams diese Migration starten, ist die Rechnung. Host Units und DDUs messen Sie danach, wie viel Sie überwachen und wie viele Daten Davis berührt – die Kosten steigen also mit Ihrem Bestand und Ihrer Nutzung, oft unvorhersehbar. OpenTelemetry durchbricht das auf zwei Arten:

• Das Backend wird zur Wahl. OTLP-Daten können an ein kostengerechtes Backend gehen – selbstgehostet, Open Source oder ein günstigerer verwalteter OTLP-Store – statt an den Verbrauchszähler eines Herstellers.
• Die Pipeline kürzt Volumen, bevor es abgerechnet wird. Filtern Sie Rauschen, samplen Sie hochvolumige Streams und verwerfen Sie ungenutzte Attribute am Collector, sodass Sie nur für die Speicherung dessen zahlen, was Sie nutzen. Das ist das Kostsenkungs-Playbook, angewandt auf einen Dynatrace-Ausstieg.

Und das Tool, das die Pipeline verwaltet, sollte nicht seinen eigenen Verbrauchszähler wieder einführen. LinkMesh wird pro verwaltetem Collector abgerechnet, nicht pro Host Unit, DDU oder Gigabyte – eine flache, vorhersehbare Linie statt einer Kurve, die Ihrem Wachstum folgt.

Einen Rollback-Plan durch die gesamte Migration behalten

Progressive Entkopplung bleibt nur dann sicher, wenn Sie jeden Schritt umkehren können:

• Behalten Sie den OneAgent installiert auf einer Host-Klasse, bis diese Klasse die Validierung für einen vereinbarten Beobachtungszeitraum bestanden hat – deinstallieren Sie nicht beim ersten Erfolg.
• Entkoppeln Sie die Exporter. Der OTel-Pfad und der OneAgent sind unabhängig, sodass Sie eine Host-Klasse zurück auf Dynatrace ziehen können, ohne den Rest zu stören.
• Definieren Sie Erfolgsschwellen – Metrik-Toleranz, Trace-Coverage, auslösende Prioritäts-Alerts – sodass „den OneAgent hier stilllegen” eine Entscheidung anhand von Kriterien ist, keine Ahnung.
• Behalten Sie die Fähigkeit umzuleiten. Einen otlphttp-Exporter, der auf Dynatraces OTLP-Ingest-API (/api/v2/otlp – nur HTTP, kein gRPC) als Fallback-Route gerichtet ist, bereitzuhalten, bedeutet, dass Sie OTel-Daten zurück an Dynatrace senden können, falls mitten in der Migration eine Backend-Lücke auftaucht.

Schritt 5 – Den OneAgent stilllegen, wo OTel ihn abdeckt

Steigen Sie bewusst um. Sobald jeder Service oder jede Host-Klasse im neuen Stack Parität erreicht – und Sie bestätigt haben, dass Sie keine OneAgent-only-Fähigkeit verlieren, auf die Sie tatsächlich angewiesen sind – entfernen Sie den OneAgent davon und lassen Sie den OTel-Stack allein stehen. Tun Sie es in Wellen, unkritische Services zuerst, damit das Sicherheitsnetz am längsten unter den Teilen bleibt, die zählen. Wo Sie weiterhin RUM, Synthetics oder Smartscape brauchen, behalten Sie den OneAgent (oder einen Ersatz) für genau das und lassen Sie OTel die Standard-Telemetrie besitzen – Entkopplung muss nicht Alles-oder-Nichts sein.

Während der OneAgent-Fussabdruck schrumpft, haben Sie die Kategorie geändert, nicht nur den Hersteller: Ihre Instrumentierung ist OTLP, Ihre Flotte wird auf OpAMP verwaltet, und Ihr Backend ist ein Posten, den Sie neu verhandeln oder ersetzen können, ohne einen einzigen Host neu zu instrumentieren.

Die Migration in fünf Schritten

1. Ehrlich scopen – entscheiden Sie, welche OneAgent-only-Fähigkeiten (RUM, Synthetics, Smartscape, tiefe PurePath) Sie behalten, ersetzen oder aufgeben.
2. Parallel instrumentieren – OTel-SDKs und Collectors neben dem OneAgent hinzufügen.
3. Parität validieren – beide Stacks betreiben, die Checkliste abarbeiten, Rollback bereithalten.
4. Die Flotte verwalten – eine OpAMP-Control-Plane über die Collectors legen, damit Sie bei der Verwaltbarkeit keinen Rückschritt machen.
5. Den OneAgent stilllegen, wo OTel ihn abdeckt – in Wellen umsteigen und für die verlagerte Telemetrie vom Host-Unit-/DDU-Zähler herunterkommen.

Das Bündel des OneAgent war das Lock-in auf der Collection-Ebene. Es in offene Standards zu entbündeln, ist der Ausweg – ehrlich vollzogen, Fähigkeit für Fähigkeit.