OpenTelemetry: einmal instrumentieren, das Backend frei wählen

Drei Jahre lang lief jeder Trace durch den Agenten eines einzigen Anbieters, bequem und teuer. Dann zog die Rechnung an, das Team wollte zu einem anderen Backend wechseln, und merkte: jede einzelne Span klebt am SDK des Herstellers. Wer die Observability wechseln will, baut sie neu. Genau diese Sackgasse löst OpenTelemetry auf, indem es das Messen vom Auswerten trennt.

Das Wichtigste in Kürze

• Instrumentierung und Backend werden entkoppelt: Wer einmal mit OpenTelemetry misst, kann das Auswerte-Tool später frei tauschen, von Jaeger über Prometheus und Grafana bis Datadog. Der Code bleibt gleich, das Ziel ändert sich per Konfiguration.
• Breit getragener De-facto-Standard: OpenTelemetry ist ein graduiertes Projekt der Cloud Native Computing Foundation und nach Kubernetes eines der aktivsten dort. Die großen Observability-Anbieter unterstützen das Protokoll inzwischen selbst.
• Der schnelle Start hat eine Rückseite: Auto-Instrumentierung läuft in Minuten, die eigentliche Arbeit beginnt beim Collector, beim Sampling und bei der Frage, welche Daten man überhaupt behalten will.

Verwandt:OpenTofu vs. Terraform: welches IaC-Tool wirklich trägt  /  Coolify im Test: Self-Hosting statt Vercel und Heroku

Warum die Observability-Rechnung irgendwann zur Geiselnahme wird

Das Muster wiederholt sich in fast jedem Stack, den ich in den letzten Jahren von innen gesehen habe. Am Anfang steht ein Agent. Man installiert ihn, ein paar Zeilen Config, und plötzlich sind Traces, Metriken und Logs in einem hübschen Dashboard. Der Anbieter macht es bewusst leicht, denn jeder instrumentierte Service ist ein Service, der sein Backend so schnell nicht mehr verlässt.

Die Reibung kommt später. Das Datenvolumen wächst schneller als geplant, die Rechnung folgt dem Volumen, und irgendwann steht die Frage im Raum, ob ein anderes Tool nicht günstiger oder schlicht besser wäre. Dann erst zeigt sich, wie tief der Haken sitzt. Die Spans tragen die Klassennamen aus dem SDK des Anbieters, die Metriken folgen seinem Namensschema, die Sampling-Logik steckt in seinem Agenten. Ein Wechsel ist kein Konfigurations-Job, sondern ein Refactoring quer durch die Codebasis.

Das ist kein Vorwurf an einen bestimmten Hersteller. Es ist die logische Konsequenz, wenn Messung und Auswertung im selben proprietären Paket stecken. OpenTelemetry zieht genau hier die Trennlinie ein.

Was OpenTelemetry tut, wenn man die Folien weglässt

Was ist OpenTelemetry? OpenTelemetry ist ein offener Standard für das Erzeugen und Transportieren von Telemetriedaten in verteilten Systemen. Er definiert herstellerneutrale Schnittstellen und Bibliotheken für die drei stabilen Signaltypen Traces, Metriken und Logs sowie ein einheitliches Protokoll namens OTLP, über das diese Daten an ein beliebiges Backend gehen.

Der praktische Kern ist diese Entkopplung. Die Instrumentierung lebt im Code und im Standard, nicht im Agenten eines Anbieters. Eine Span heißt so, wie das Team sie benennt, und nicht so, wie ein SDK sie vorgibt. Wohin die Daten am Ende fließen, entscheidet eine Konfigurationszeile, kein Code-Eingriff.

Entstanden ist das Projekt aus der Fusion zweier älterer Ansätze, OpenTracing und OpenCensus, die jahrelang nebeneinander dasselbe Problem lösten. Heute ist OpenTelemetry ein graduiertes Projekt der Cloud Native Computing Foundation und nach Kubernetes das Projekt mit der zweithöchsten Aktivität dort. Selbst die kommerziellen Anbieter, deren Lock-in der Standard aufbricht, nehmen OTLP heute direkt entgegen. Herstellerneutrale Instrumentierung ist damit zum Normalfall geworden.

Auto oder Manual: wo der schnelle Start seine Grenze findet

Es gibt zwei Wege in OpenTelemetry hinein, und beide haben ihre Berechtigung. Die Auto-Instrumentierung hängt sich über einen Agenten oder eine Bibliothek an gängige Frameworks und Treiber und liefert ohne Code-Änderung Traces für HTTP-Aufrufe, Datenbankzugriffe und Message-Queues. Das ist der Weg, mit dem man in einer Mittagspause ein erstes Trace-Bild bekommt.

Das Manual-Instrumentieren ist mehr Arbeit, liefert aber den Kontext, der wirklich zählt. Ein Aufruf wie tracer.start_as_current_span(…) markiert genau den Geschäftsvorgang, der bei einem Incident interessiert, also den Checkout, die Risikoprüfung, den Batch-Lauf. Auto sagt, dass die Datenbank langsam war. Manual sagt, dass die Datenbank langsam war, während der dritte Wiederholungsversuch einer Zahlungsfreigabe lief. Das ist der Unterschied zwischen einer Zahl und einer Erklärung.

In der Praxis kombiniert man beides. Auto-Instrumentierung als Grundrauschen, manuelle Spans dort, wo Geld, Risiko oder Kundenfrust hängen. Baut man alles manuell, wird man nie fertig. Überlässt man alles dem Agenten, hat man am Ende viele Daten und wenig Antworten.

Der Collector ist der Teil, den die meisten unterschätzen

Die Bibliotheken bekommen die Aufmerksamkeit, der OpenTelemetry Collector macht die eigentliche Arbeit. Er ist ein eigenständiger Prozess, der Telemetrie von den Services entgegennimmt, sie verarbeitet und an ein oder mehrere Backends weiterreicht. Genau dieser Baustein macht aus der Theorie der Austauschbarkeit eine betriebliche Realität, denn das Routing der Daten passiert hier, nicht im Anwendungscode.

Diese knappe Config zeigt das Prinzip. Ein Receiver nimmt OTLP entgegen, ein Batch-Prozessor bündelt die Daten, und zwei getrennte Pipelines schicken Traces und Metriken an unterschiedliche Ziele. Will das Team morgen das Trace-Backend wechseln, ändert sich genau eine Exporter-Zeile, kein Service muss neu deployt werden.

Die Reibung versteckt sich im Sampling. Bei moderatem Volumen kann man alles behalten, bei ernsthaftem Verkehr wird das schnell teuer und unübersichtlich. Tail-Based-Sampling, also die Entscheidung erst nach Abschluss eines Traces, behält gezielt die langsamen und die fehlerhaften Vorgänge und wirft den gleichförmigen Erfolgsfall weg. Das ist mächtig, kostet aber Speicher im Collector und ein paar Iterationen, bis die Regeln sitzen. Diese Disziplin habe ich selbst öfter zu spät ernst genommen, als mir lieb ist.

Was der Wechsel bringt, und wo er nichts rettet

Der konkrete Gewinn von OpenTelemetry ist Optionsfreiheit. Die Instrumentierung wird zur dauerhaften Investition statt zu einer Wette auf einen Anbieter. Backends lassen sich vergleichen, kombinieren oder wechseln, ohne dass jedes Mal der Code aufgemacht wird. Für Teams, die mit ihren Telemetriekosten oder mit der Bindung an ein Tool hadern, ist das der entscheidende Hebel.

OpenTelemetry ist kein fertiges Observability-Produkt. Der Standard erzeugt und transportiert Daten, er speichert, visualisiert und alarmiert nicht. Das Backend bleibt eine eigene Entscheidung mit eigenen Kosten, ob selbst betrieben mit Grafana und Prometheus oder als gekaufter Dienst. Und der Collector ist Infrastruktur, die jemand betreiben, skalieren und überwachen muss. Observability, die selbst beobachtet werden will.

Für ein kleines Team mit einem überschaubaren Monolithen und einem Tool, das passt, ist die sofortige Migration kein Selbstzweck. Richtig lohnend wird OpenTelemetry erst, wenn mehrere Services, mehrere Sprachen oder ein handfester Frust mit Kosten und Lock-in zusammenkommen. Dann ist die Frage nicht mehr, ob man wechselt, sondern nur noch, wie schnell die alte Instrumentierung ausläuft.

Häufige Fragen

Bildquelle: Rashed Paykary / Pexels