Wie man die Beobachtbarkeit in der Landschaft der Mikroservices durch OpenTelemetry am Leben erhält

Das Konzept der Beobachtbarkeit ist zu einem Grundpfeiler für die Sicherstellung der Zuverlässigkeit und Effizienz von Systemen im modernen Software-Engineering und Betrieb geworden. Beobachtbarkeit, über ihren traditionellen Rahmen von Logging, Überwachung und Tracing hinaus, lässt sich durch das Prisma der Effizienz der Incident-Response definieren – insbesondere durch die Untersuchung der Zeit, die Teams benötigen, um den vollständigen Kontext und Hintergrund eines technischen Vorfalls zu verstehen.

Optimierung der Zeit bis zum Verständnis

Diese differenzierte Sichtweise führt die kritische Metrik der Zeit bis zum Verständnis (Time to Understanding, TTU) ein, eine Dimension, die als entscheidendes Glied in der Kette von Incident-Management-Metriken dient, einschließlich der Zeit bis zur Anerkennung (Time to Acknowledge, TTA) und der Zeit bis zur Lösung (Time to Resolve, TTR). TTU etabliert sich als Metrik, indem sie die Dauer von dem Moment, in dem ein Alarm empfangen wird, bis zu dem Punkt, an dem ein Team den Umfang, die Auswirkungen und die zugrundeliegenden Ursachen eines Vorfalls vollständig versteht, quantifiziert. Im komplexen Kontext der Alarmierung überbrückt TTU nicht nur das Intervall zwischen der anfänglichen Alarmierung (TTA) und dem Beginn der Lösungsbemühungen (TTR), sondern spielt auch eine transformative Rolle bei der Verfeinerung von Alarmmanagementstrategien. Durch die Optimierung von TTU können Organisationen ihre operationelle Resilienz signifikant erhöhen, Ausfallzeiten minimieren und ihren Weg zur Incident-Lösung effizienter gestalten. Es ist jedoch wichtig zu verstehen, dass die Optimierung von TTU völlig abhängig von der zugrundeliegenden Infrastruktur und Architektur des gepflegten Softwareprodukts ist.

Die Auswirkungen von Mikroservice-Architekturen auf die Zeit bis zum Verständnis

Softwarebereitstellungen bevorzugen oft monolithische Architekturen aufgrund ihrer Einfachheit, bei denen die Anwendung als eine einzige, einheitliche Einheit gebaut wird. Dieser Ansatz vereinfachte das Verständnis der Funktionsweise des Systems und das Debugging von Problemen, da alle Komponenten innerhalb eines einzigen Codebasis- und Laufzeitumfelds operierten. Wenn jedoch Entwicklungsteams und die Komplexität der Anwendung wachsen, stoßen die Grenzen monolithischer Architekturen, wie Skalierbarkeit und Geschwindigkeit der Bereitstellung, Organisationen zur Umstellung auf Mikroservice-Architekturen. Mikroservices, die die Anwendung in kleinere, unabhängig einsetzbare Dienste aufteilen, bieten größere Flexibilität und Skalierbarkeit. Doch diese Fragmentierung führt zu einem chaotischen Verständnis des Systems, da die Interdependenzen und Interaktionen über zahlreiche Dienste hinweg das Gesamtbild verschleiern können, was es selbst für große Entwicklungsteams herausfordernd—fast unmöglich—macht, das volle Ausmaß des Zusammenspiels zu erfassen.

Wo OpenTelemetry ins Spiel kommt

Mikroservice-Architekturen können die Beobachtbarkeit erheblich behindern und das Management sowie die Fehlersuche bei Diensten zu einer entmutigenden Aufgabe machen. OpenTelemetry tritt als Entwurf auf, um diesen Herausforderungen zu begegnen, indem es einen einheitlichen und standardisierten Rahmen für das Sammeln, Verarbeiten und Versenden von Telemetriedaten (Metriken, Logs und Traces) von jedem Mikroservice bereitstellt. Durch die Implementierung von OpenTelemetry können Organisationen eine umfassende Sicht auf ihre Mikroservice-Landschaft gewinnen, die es ihnen ermöglicht, den Fluss von Anfragen über Dienstgrenzen hinweg zu verfolgen, die Interaktionen und Abhängigkeiten zwischen den verschiedenen Diensten zu verstehen und Leistungsengpässe oder Ausfallpunkte präzise zu identifizieren. Diese verbesserte Ebene der Beobachtbarkeit durchbricht die chaotische Natur von Mikroservice-Architekturen und erleichtert ein tieferes Verständnis der Systemverhaltensweisen und betrieblichen Dynamiken.

Die drei Säulen von OpenTelemetry

Metriken, die erste Säule von OpenTelemetry, stellen eine entscheidende Komponente für das Monitoring und Verständnis der Systemleistung im großen Maßstab dar. Sie sind so konzipiert, dass sie leichtgewichtig und einfach zu speichern sind, auch bei hohem Volumen, was sie ideal macht, um einen Überblick über die Gesundheit und das Verhalten des Systems im Zeitverlauf zu erfassen. Durch die Aggregation numerischer Datenpunkte – wie Anfragenzahlen, Fehlerquoten und Ressourcennutzung – bieten Metriken eine vereinfachte, aber dennoch umfassende Momentaufnahme des betrieblichen Zustands. Der Prozess der Aggregation, obwohl vorteilhaft für Skalierbarkeit und Verwaltbarkeit, kann jedoch detaillierte Informationen über seltene oder außergewöhnliche Ereignisse versehentlich verdecken und potenzielle Probleme im System verbergen.

‍

Logs, obwohl sie im OpenTelemetry Protocol (OTLP)-Framework noch als "jung" gelten, spielen eine kritische Rolle bei der Diagnose und dem Verständnis von Problemen innerhalb von Mikroservice-Architekturen. Logs bieten eine sehr detaillierte Erklärung von Problemen, indem sie Ereignisse in einem strukturierten oder unstrukturierten Format erfassen, das Entwickler analysieren können, um die Wurzelursachen von Problemen zu ermitteln. Die Nützlichkeit von Logs bringt jedoch ihre Herausforderungen mit sich; aufgrund des potenziell hohen Volumens an Logs, insbesondere in komplexen und verteilten Systemen, kann deren Speicherung und Verwaltung schwierig werden. Diese Herausforderungen erfordern effiziente Lösungen für die Log-Aggregation und -Verwaltung, um sicherzustellen, dass Logs zugänglich und nützlich für die Fehlersuche bleiben, ohne die Ressourcen des Systems zu überfordern.

‍

Tracing, die dritte Säule von OpenTelemetry, dient als Hybrid zwischen Metriken und Logs und bietet einen einzigartig reichen und detaillierten Einblick in das Verhalten des Systems, indem es sehr dichte Informationen erfasst, noch mehr als traditionelle Logs. Ein Trace umfasst die Reise einer einzelnen Anfrage durch das System, aufgeteilt in mehrere Spans, wobei jeder Span eine distinkte "Arbeitseinheit" oder Operation innerhalb der Servicearchitektur darstellt. Diese Spans bilden gemeinsam eine detaillierte Zeitleiste des Weges der Anfrage, die aufzeigt, wo Zeit verbracht und wo Fehler auftreten können. Trotz der Fülle an Daten, die Traces liefern, ist es bemerkenswert, dass der überwiegende Teil (99,9%) dieser Daten nie aktiv betrachtet wird, was die selektive Natur des Tracing-Datenkonsums unterstreicht.

Das Herzstück von OpenTelemetry: Der Collector

Neben den OpenTelemetry-Instrumenten, wie Bibliotheken und SDKs, die Entwickler dabei unterstützen, OTLP-Daten aus dem Anwendungscode zu veröffentlichen – wie in den drei oben genannten Säulen erwähnt –, markiert der OpenTelemetry Collector (OTelC) das Herzstück des Frameworks.

‍

Der Collector (OTelC) ist nicht nur ein Datenexporteur; er führt fortgeschrittene Fähigkeiten ein, die für die effiziente Verwaltung von Telemetriedaten in verteilten Systemen kritisch sind. Er bewältigt geschickt die Kardinalität, ein wesentliches Merkmal zur Aufrechterhaltung der Datenbenutzbarkeit, während er die Überlastung in Überwachungssystemen durch die Reduzierung der Dimensionalität bei Bedarf verhindert. Diese Flexibilität erlaubt es, OTelC-Instanzen zu verketten und bietet eine skalierbare Lösung für die Vorverarbeitung von Telemetriedaten – durch Filterung, Sampling und Verarbeitung – bevor diese das Backend erreichen. Durch das intelligente Management der zu übertragenden Daten, einschließlich der Entfernung von lärmenden, sensiblen oder sonst unnötigen Informationen, stellt OTelC sicher, dass nur relevante, hochwertige Daten weitergeleitet werden, wodurch Leistung und Compliance optimiert werden.

‍

Entscheidend ist, dass mit OTelC in der Nähe der Datenquellen die Menge der Daten, die über das Netzwerk übertragen werden müssen, drastisch reduziert wird, was besonders in Cloud-Umgebungen vorteilhaft ist, wo Datenübertragungskosten anfallen können. Diese Nähe ermöglicht eine effiziente Verkehrsverwaltung und Lastreduktion, um sicherzustellen, dass hochvolumige Telemetriedaten die Netzwerkressourcen nicht sättigen.

‍

Darüber hinaus werden OpenTelemetry-Instrumente (SDKs, Bibliotheken) von der Last der Verkehrs- und Lastüberlegungen befreit, sodass Entwickler sich auf die Instrumentierung konzentrieren können, ohne sich um die Auswirkungen auf das Datentransfervolumen sorgen zu müssen. Mit OTelC wird das Management der OTLP-Kardinalität und die Steigerung der Dateneffizienz nahtlos, wodurch die Notwendigkeit für invasive Änderungen im Anwendungscode selbst entfällt. So wird die Integrität des Codes bewahrt, während eine umfassende Beobachtbarkeit sichergestellt ist.

‍

Letzteres passt auch gut in eine Mikroservice-Umgebung, in der normalerweise die Entwicklerteams selbst für die Bereitstellung und den Betrieb ihrer Dienste verantwortlich sind und ihre eigenen OTel-Collector-Pipelines verwenden können, um ihre OTLP-Datenströme feinabzustimmen, ohne ihre Dienste ändern und neu bereitstellen zu müssen.

Was dem eigenständigen OpenTelemetry fehlt

Während OpenTelemetry im Sammeln und Exportieren von Telemetriedaten in einer verteilten Dienstumgebung hervorragend ist, beinhaltet es keine Funktionalitäten zum Speichern dieser Daten; stattdessen verlässt es sich auf externe Speicherlösungen, um die gesammelten Informationen zu archivieren und zu verwalten.

‍

Zusätzlich bietet OpenTelemetry selbst keine Dashboards, die für die Visualisierung von Datentrends und Einsichten erforderlich sind. Stattdessen benötigt es die Integration mit anderen Tools, um die Daten zu analysieren und anzuzeigen.

‍

Benachrichtigungen, die für die Alarmierung von Teams über Systemprobleme in Echtzeit essenziell sind, gehen ebenfalls über die Fähigkeiten von OpenTelemetry hinaus und erfordern ergänzende Alarmierungsmechanismen.

‍

Schließlich unterstützt OpenTelemetry nicht nativ das proaktive Testen von Anwendungen durch simulierten Verkehr oder Benutzerinteraktionen, einen wichtigen Aspekt zum Verständnis und zur Gewährleistung der Systemleistung und -zuverlässigkeit unter verschiedenen Bedingungen.

‍

Folglich, obwohl OpenTelemetry ein mächtiges Werkzeug für die Beobachtbarkeit ist, muss es mit zusätzlichen Systemen und Strategien ergänzt werden, um diese kritischen Bereiche vollständig abzudecken.

Ein erstklassiger Beobachtbarkeits-Stack mit OpenTelemetry und ilert

Um die Einschränkungen von OpenTelemetry zu adressieren und dadurch einen Spitzen-Beobachtbarkeits-Stack zu schaffen, können seine Fähigkeiten durch die Integration mit spezialisierten Werkzeugen erheblich verbessert werden.

‍

Für die Datenspeicherung und visuell intuitive Dashboards, die eine schnelle Datenanalyse und Einblicke unterstützen, ergänzt Honeycomb.io OpenTelemetry durch das Angebot skalierbarer, leistungsstarker Analysen. Ebenso wird ein Werkzeug wie Checkly integriert, das sich auf proaktives Testen und Validieren von Webdiensten spezialisiert, und schließt damit den Kreis eines umfassenden System-Monitorings. Um die Wirksamkeit von Alarmierungsmechanismen zu verstärken, kann ilert mit Honeycomb und Checkly integriert werden, was sicherstellt, dass Benachrichtigungen zeitnah, handlungsrelevant sind und über die richtigen Kanäle wie Sprachanrufe oder Microsoft Teams-Kanalaktualisierungen eskalieren können.