Beobachtbarkeit über Protokolle hinaus: Was OpenTelemetry in der Praxis verändert

Zu überwachen, ob ein System betriebsbereit ist, ist nicht dasselbe wie zu verstehen, warum es sich so verhält – und die Verwechslung dieser beiden Dinge ist der teuerste Fehler, den Ingenieurteams bei der Skalierung einer verteilten Architektur machen. Ein grünes Dashboard bedeutet nicht, dass der Benutzer eine gute Erfahrung macht. Es bedeutet lediglich, dass die Dienste auf Pings reagieren. Der Abstand zwischen diesen beiden Aussagen ist genau dort, wo die am schwersten zu findenden Fehler, stillen Beeinträchtigungen und Vorfälle, deren Diagnose Stunden dauert, live auftreten.

Was unterscheidet Überwachung von Beobachtbarkeit?

Die Überwachung beginnt mit im Voraus bekannten Fragen: Reagiert der Server? Wächst die Warteschlange? Hat die Fehlerquote den Schwellenwert überschritten? Sie definieren die Metriken, konfigurieren die Warnungen und warten darauf, dass etwas einen Schwellenwert überschreitet. Es funktioniert gut, wenn das System einfach ist und Fehlermodi vorhersehbar sind.

Beobachtbarkeit ist anders. Der aus der Kontrolltheorie entlehnte Begriff beschreibt die Fähigkeit, aus seinen Ausgängen auf den internen Zustand eines Systems zu schließen. In der Praxis bedeutet das, dass Sie Fragen beantworten können, von denen Sie beim Aufbau des Systems nicht wussten, dass Sie sie stellen würden. Warum erhält dieser bestimmte Benutzer 503, die anderen jedoch nicht? Warum stieg die Checkout-Latenz nur für Kunden in São Paulo um 40 %? Warum verbraucht dieser Dienst dienstags nach 14 Uhr doppelt so viel CPU?

Für diese Fragen sind keine Warnungen vorkonfiguriert. Sie benötigen umfangreiche, korrelierte Daten mit genügend Kontext, um eine echte Untersuchung durchzuführen.

Warum Protokolle allein keine Lösung bringen

Jahrelang lautete die Standardantwort auf die Frage „Debuggen in der Produktion“ „Weitere Protokolle hinzufügen“. Protokolle sind nützlich – zeichnen Sie einzelne Ereignisse auf, erfassen Sie Fehlermeldungen und ermöglichen Sie die Überwachung. In verteilten Architekturen reichen sie jedoch aus strukturellen Gründen nicht mehr aus.

Eine Anfrage, die zehn Dienste durchläuft, generiert Protokolle an zehn verschiedenen Orten. Ohne eine korrekt in der Kette weitergegebene Korrelationskennung ist es unmöglich, den Pfad zu rekonstruieren, den die Anfrage genommen hat. Selbst mit Korrelations-IDs fassen Sie verstreute Textfragmente zusammen und versuchen, manuell eine zusammenhängende Erzählung zusammenzusetzen. Die dafür benötigte Zeit bei einem aktiven Vorfall ist die Zeit, die der Benutzer ohne Service verbringt.

Metriken lösen einen Teil des Problems – sie zeigen aggregierte Trends an und ermöglichen schnelle Warnungen – aber sie verlieren konstruktionsbedingt den Kontext. Sie wissen, dass die durchschnittliche Latenz gestiegen ist, aber Sie wissen nicht, welcher konkrete Vorgang, welche Datenbank, welcher externe Aufruf dafür verantwortlich war.

Spuren schließen diese Lücke. Ein Trace folgt einer Anfrage von Anfang bis Ende und durchläuft jeden Dienst, jeden Bankanruf, jede externe Integration sowie die Aufzeichnungsdauer und Attribute bei jedem Schritt. Mit Traces erfordert die Untersuchung, die stundenlanges Grep in Protokolldateien erfordern würde, jetzt Minuten der visuellen Analyse der Zeit, die jeder Span aufwendet.

Das Problem, das OpenTelemetry lösen wollte

Vor OpenTelemetry bedeutete die Instrumentierung eines Systems für Beobachtbarkeit die Auswahl eines Anbieters – Datadog, New Relic, Jaeger, Zipkin – und die Implementierung des proprietären SDK jedes einzelnen Anbieters. Der Wechsel des Anbieters bedeutete, die Instrumentierung in der gesamten Codebasis neu zu schreiben. Die gleichzeitige Verwendung mehrerer Tools bedeutete die Verwaltung mehrerer SDKs mit unterschiedlicher Semantik und doppeltem Overhead.

OpenTelemetry, ein CNCF-Absolventenprojekt mit Beiträgen von Google, Microsoft, Splunk und Dutzenden anderen Organisationen, beendete dieses Modell auf zwei Arten. Zunächst wurde eine einheitliche Spezifikation für die drei Säulen – Metriken, Protokolle und Traces – mit konsistenter Semantik zwischen ihnen definiert. Zweitens wurde diese Spezifikation in SDKs für praktisch alle relevanten Sprachen implementiert, mit Selbstinstrumentierung für die gängigsten Frameworks.

Das praktische Ergebnis besteht darin, dass die Instrumentierung einmal im Code enthalten ist und das Datenziel im Kollektor konfiguriert wird. Sie können Traces während der Entwicklung an Jaeger, in der Produktion an Tempo senden und Honeycomb parallel testen, ohne eine Zeile Anwendungscode zu berühren. Die Lieferantenbindung als technische Einschränkung entfällt.

So implementieren Sie, ohne das Team zu stoppen

Die häufigste Gefahr bei der Einführung von OpenTelemetry besteht darin, alles auf einmal zu instrumentieren. Der intelligente Pfad ist inkrementell und beginnt mit den Punkten mit dem größten diagnostischen Wert.

Der erste Schritt besteht darin, das SDK zu installieren und die Selbstinstrumentierung für das HTTP-Framework zu aktivieren, das der Dienst verwendet. In Node.js, Go, Python und Java deckt dies automatisch eingehende Anrufe, ausgehende Anrufe und Datenbankverbindungen ab, ohne dass Änderungen am Geschäftscode erforderlich sind. In weniger als einer Stunde Arbeit erhalten Sie Spuren mit nützlichem Kontext.

Der zweite Schritt besteht darin, den OpenTelemetry Collector als Vermittler zwischen den Anwendungen und den Observability-Backends zu konfigurieren. Der Collector empfängt Daten, kann sie umwandeln, filtern und an mehrere Ziele senden. Dies entkoppelt die Anwendung von jeglicher Entscheidung darüber, wo die Daten gespeichert werden.

Der dritte Schritt, den die meisten Teams unterschätzen, ist die Definition einer Attributstrategie. Traces ohne Kontextattribute – Benutzer-ID, Mandanten-ID, Bereitstellungsversion, Region – sind schwer zu filtern, wenn Sie nach einem bestimmten Muster suchen. Die Standardisierung der Attribute, die jeder Dienst weitergeben muss, ist eine architektonische Entscheidung, keine Implementierungsentscheidung.

Welche Änderungen im Debug-Prozess in der Produktion

Mit der Implementierung echter Beobachtbarkeit ändert sich die Dynamik der Vorfalluntersuchung auf konkrete Weise. Anstatt einen Vorfall zu starten, indem es Infrastruktur-Dashboards konsultiert und versucht, CPU-Warnungen mit Latenzspitzen in Zusammenhang zu bringen, beginnt das Team mit der betroffenen Benutzererfahrung.

Ein Trace des Benutzers, der das Problem gemeldet hat, zeigt genau, wo sich die Latenz konzentrierte, welcher Dienst einen Fehler zurückgab und welche Bankabfrage dreimal länger als normal dauerte. Die Hypothese basiert auf den Daten und nicht auf Annahmen darüber, was sich hätte ändern können.

Dies verkürzt den Abstand zwischen „etwas stimmt nicht“ und „Hier ist die Ursache und die verantwortliche Codezeile“. Teams, die mit ausgereifter Observability arbeiten, kommen bei der Obduktion mit Beweisen an, nicht mit groben Rekonstruktionen auf der Grundlage fragmentierter Protokolle.