Was ist OpenTelemetry und wie kann es Ihre Backend-Qualität verbessern?

Wenn wir früher vom Backend sprachen, meinten wir damit normalerweise eine große Anwendung mit einer einzigen großen Datenbank, und für die Überwachung reichte die Protokollierung aus. Heute sind dank Technologien wie Kubernetes Microservices zum Standard geworden. Die Anwendungen sind zahlreicher und verteilter, und für die Fehlerbehebung und Problemdiagnose in unseren Anwendungen reicht die herkömmliche Protokollierung nicht mehr aus.

Eine hervorragende Lösung zum Organisieren der Überwachung ist OpenTelemetry – ein modernes Toolkit, das zum Debuggen und zur Leistungsanalyse verteilter Systeme verwendet werden kann.

Dieser Artikel richtet sich an IT-Experten, die ihr Wissen im Bereich Backend-Optimierung erweitern möchten. Im Folgenden erläutern wir im Detail, was OpenTelemetry ist, welche Schlüsselkonzepte es hat und welche Probleme es löst. Wenn Sie wissen möchten, wie OpenTelemetry Ihren Ansatz zur Überwachung und Fehlerbehebung von Backend-Systemen ändern und deren Zuverlässigkeit und Effizienz verbessern kann, lesen Sie weiter.

Eine kurze Geschichte von OpenTelemetry

Große Technologieunternehmen standen Ende der 2000er Jahre erstmals vor der Herausforderung der verteilten Protokollierung und Nachverfolgung. Im Jahr 2010 veröffentlichte Google ein Papier, Dapper, eine groß angelegte Infrastruktur zur Ablaufverfolgung verteilter Systeme , das den Grundstein für Twitters 2012 veröffentlichtes Tracing-Tool Zipkin legte.

Im Jahr 2014 kam Kubernetes auf den Markt, das die Entwicklung von Microservices und anderen Cloud-verteilten Systemen erheblich vereinfachte. Dies führte dazu, dass viele Unternehmen Probleme mit der verteilten Protokollierung und Nachverfolgung in Microservices hatten. Um die verteilte Nachverfolgung zu standardisieren, wurden der von der CNCF übernommene OpenTracing-Standard und das OpenCensus-Projekt von Google erstellt.

Im Jahr 2019 kündigten die Projekte OpenTracing und OpenCensus ihre Fusion unter dem Namen OpenTelemetry an. Diese Plattform vereint die über viele Jahre gesammelten Best Practices und ermöglicht die nahtlose Integration von Tracing, Protokollierung und Metriken in jedes System, unabhängig von seiner Komplexität.

Heute ist OpenTelemetry nicht nur ein Projekt, sondern ein Industriestandard für die Erfassung und Übertragung von Telemetriedaten. Es wird von einer Community aus Spezialisten und marktführenden Unternehmen wie Google und Microsoft entwickelt und unterstützt. Das Projekt entwickelt sich ständig weiter und erhält neue Funktionen, um den Integrations- und Nutzungsprozess zu vereinfachen.

Was ist da drin?

OpenTelemetry ist ein umfassender Satz von Verfahren und Tools, die definieren, welche Signale eine Anwendung generieren kann, um mit der Außenwelt zu interagieren, und wie diese Signale gesammelt und visualisiert werden können, um den Zustand von Anwendungen und des Systems als Ganzes zu überwachen. Die drei wichtigsten Signaltypen sind Ablaufverfolgung, Protokollierung und Metrikerfassung .

**Schauen wir uns die einzelnen Komponenten genauer an: \

Kontexte

OpenTelemetry führt das Konzept von Operationskontexten ein. Ein Kontext umfasst in erster Linie Attribute wie `trace_id` (Kennung für die aktuelle Operation) und `span_id` (Kennung für eine Unteranforderung, wobei jeder Wiederholungsversuch einer Unteranforderung eine eindeutige `span_id` hat).

Darüber hinaus kann ein Kontext statische Informationen enthalten, wie etwa den Knotennamen, auf dem die Anwendung bereitgestellt wird, oder den Umgebungsnamen (prod/qa). Diese Felder, die in der OpenTelemetry-Terminologie als Ressourcen bezeichnet werden, werden jedem Protokoll, jeder Metrik oder jedem Trace zur einfacheren Suche beigefügt. Kontexte können auch dynamische Daten enthalten, wie etwa die Kennung des aktuellen Endpunkts ( `http_path: "GET /user/:id/info"` ), die selektiv an Gruppen von Protokollen, Metriken oder Traces angefügt werden können.

OpenTelemetry-Kontexte können mithilfe von Kontextweiterleitungsprotokollen zwischen verschiedenen Anwendungen weitergegeben werden. Diese Protokolle bestehen aus Header-Sets, die jeder HTTP- oder gRPC-Anforderung oder den Headern von Nachrichten für Warteschlangen hinzugefügt werden. Auf diese Weise können nachgelagerte Anwendungen den Operationskontext aus diesen Headern rekonstruieren.

Hier sind einige Beispiele für die Kontextausbreitung:

1. B3-Propagation Dies ist ein Satz von Headern ( x-b3-* ), der ursprünglich für das Zipkin-Tracing-System entwickelt wurde. Er wurde in OpenTracing übernommen und von vielen Tools und Bibliotheken verwendet. B3-Propagation enthält trace_id / span_id und ein Flag, das angibt, ob eine Stichprobennahme erforderlich ist.

   
   

2. W3C Trace Context Dieser von der W3C-Arbeitsgruppe entwickelte Standard vereint verschiedene Kontextausbreitungsansätze in einem einzigen Standard und ist der Standard in OpenTelemetry. Ein gutes Beispiel für die Anwendung dieser Standards ist die Verfolgung der Ausführung einer Anfrage, die durch mit unterschiedlichen Technologien implementierte Microservices läuft, ohne die Genauigkeit von Überwachung und Debugging zu beeinträchtigen.

Ablaufverfolgung

Beim Tracing handelt es sich um den Vorgang, den zeitlichen Verlauf einer Anfrage durch mehrere Microservices aufzuzeichnen und anschließend zu visualisieren.

In der Visualisierung wird jeder Balken als „Span“ bezeichnet und hat eine eindeutige „span_id“ . Der Stamm-Span wird als „Trace“ bezeichnet und hat eine „Trace_id“ , die als Kennung für die gesamte Anfrage dient.

Mit dieser Art der Visualisierung können Sie:

• Analysieren Sie die Ausführungszeit von Anfragen über verschiedene Systeme und Datenbanken hinweg, um Engpässe zu identifizieren, die optimiert werden müssen.
• Erkennen Sie zyklische Abhängigkeiten zwischen Diensten.
• Suchen Sie nach doppelten Anfragen. Mithilfe von Ablaufverfolgungsdaten können Sie auch zusätzliche Analysen erstellen, z. B. eine Microservices-Karte erstellen oder die Zeit während der Vorgangsverarbeitung auf verschiedene Systeme verteilen. Auch wenn Sie keine Ablaufverfolgungsdaten zur Visualisierung von Zeitleisten verwenden, generiert OpenTelemetry dennoch trace_id und span_id zur Verwendung in anderen Signalen.

Protokolle

Trotz seiner scheinbaren Einfachheit bleibt die Protokollierung eines der leistungsstärksten Tools zur Problemdiagnose. OpenTelemetry erweitert die herkömmliche Protokollierung durch Hinzufügen kontextbezogener Informationen. Insbesondere wenn eine aktive Ablaufverfolgung vorhanden ist, werden den Protokollen automatisch die Attribute „trace_id“ und „span_id“ hinzugefügt, die sie mit der Ablaufverfolgungszeitleiste verknüpfen. Darüber hinaus können Protokollattribute statische Informationen aus dem OpenTelemetry-Kontext enthalten, z. B. die Knotenkennung, sowie dynamische Informationen, z. B. die aktuelle HTTP-Endpunktkennung („http_path: "GET /user/:id"“).

Mithilfe der „trace_id“ können Sie Protokolle aller mit der aktuellen Anfrage verknüpften Microservices finden, während Sie mit der „span_id“ zwischen Unteranfragen unterscheiden können. Bei Wiederholungsversuchen beispielsweise haben Protokolle verschiedener Versuche unterschiedliche „span_ids“. Die Verwendung dieser Kennungen ermöglicht eine schnelle Analyse des Verhaltens des gesamten Systems in Echtzeit, was die Problemdiagnose beschleunigt und die Stabilität und Zuverlässigkeit verbessert.

Metriken

Die Metrikerfassung liefert quantitative Daten zur Systemleistung, wie etwa Latenz, Fehlerraten, Ressourcennutzung und mehr. Durch die Echtzeitüberwachung von Metriken können Sie umgehend auf Leistungsänderungen reagieren, Ausfälle und Ressourcenerschöpfung verhindern und eine hohe Verfügbarkeit und Zuverlässigkeit der Anwendung für Benutzer sicherstellen.

Die Integration mit Messspeicher- und Visualisierungssystemen wie Prometheus und Grafana erleichtert die Visualisierung dieser Daten und vereinfacht die Überwachung erheblich.

Metrische Sammler

Die Metriksammler von OpenTelemetry sind mit den Standards Prometheus und OpenMetrics kompatibel und ermöglichen einen einfachen Übergang zu OpenTelemetry-Lösungen ohne wesentliche Änderungen. Das OpenTelemetry SDK ermöglicht den Export von trace_id-Beispielen zusammen mit Metriken, sodass Metriken mit Protokollbeispielen und Traces korreliert werden können.

Signalkorrelation

Protokolle, Metriken und Ablaufverfolgung ergeben zusammen eine umfassende Ansicht des Systemzustands:

• Protokolle liefern Informationen zu Systemereignissen und ermöglichen so eine schnelle Identifizierung und Behebung von Fehlern.
• Metriken spiegeln qualitative und quantitative Leistungsindikatoren des Systems wider, wie etwa Reaktionszeiten oder Fehlerraten.
• Tracing ergänzt diese Ansicht, indem es den Pfad der Anforderungsausführung durch verschiedene Systemkomponenten anzeigt und so hilft, deren Wechselwirkungen zu verstehen. Die klare Korrelation zwischen Protokollen, Traces und Metriken ist ein besonderes Merkmal von OpenTelemetry. Beispielsweise ermöglicht Grafana Benutzern, beim Anzeigen eines Protokolls die entsprechenden Trace- und Anforderungsmetriken anzuzeigen, was die Benutzerfreundlichkeit und Effizienz der Plattform erheblich verbessert.

Zusätzlich zu den drei Kernkomponenten umfasst OpenTelemetry die Konzepte Sampling, Baggage und Operationskontextverwaltung.

Probenahme

In Systemen mit hoher Auslastung wird das Volumen an Protokollen und Traces enorm und erfordert erhebliche Ressourcen für Infrastruktur und Datenspeicherung. Um dieses Problem zu lösen, umfassen die OpenTelemetry-Standards Signal-Sampling – die Möglichkeit, nur einen Teil der Traces und Protokolle zu exportieren. Sie können beispielsweise detaillierte Signale aus einem Prozentsatz von Anfragen, lang laufenden Anfragen oder Fehleranfragen exportieren. Dieser Ansatz ermöglicht ausreichendes Sampling zum Erstellen von Statistiken und spart gleichzeitig erhebliche Ressourcen.

Wenn jedoch jedes System unabhängig entscheidet, welche Anfragen im Detail überwacht werden sollen, erhalten wir eine fragmentierte Ansicht jeder Anfrage. Einige Systeme exportieren möglicherweise detaillierte Daten, während andere diese nur teilweise oder überhaupt nicht exportieren.

Um dieses Problem zu lösen, übertragen die Kontextausbreitungsmechanismen von OpenTelemetry ein Sampling-Flag zusammen mit der `trace_id`/`span_id`. Dadurch wird sichergestellt, dass alle anderen Systeme dem Beispiel folgen, wenn der erste Dienst, der die Benutzeranforderung empfängt, entscheidet, dass die Anforderung detailliert überwacht werden soll. Andernfalls sollten alle Systeme Signale teilweise oder gar nicht exportieren, um Ressourcen zu sparen. Dieser Ansatz wird als „Head Sampling“ bezeichnet – eine Entscheidung, die zu Beginn der Anforderungsverarbeitung entweder zufällig oder basierend auf einigen Eingabeattributen getroffen wird.

Darüber hinaus unterstützt OpenTelemetry „Tail Sampling“, bei dem alle Anwendungen immer alle Signale im Detail exportieren, aber ein Zwischenpuffer vorhanden ist. Nach dem Sammeln aller Daten entscheidet dieser Puffer, ob die vollständigen Daten oder nur eine Teilprobe aufbewahrt werden. Diese Methode ermöglicht eine repräsentativere Stichprobe jeder Anforderungskategorie (erfolgreich/lang/Fehler), erfordert jedoch die Einrichtung einer zusätzlichen Infrastruktur.

Gepäck

Der Baggage-Mechanismus ermöglicht die Übertragung beliebiger Schlüssel-Wert-Paare zusammen mit trace_id / span_id , die während der Anforderungsverarbeitung automatisch zwischen allen Microservices weitergegeben werden. Dies ist nützlich für die Übertragung zusätzlicher Informationen, die im gesamten Anforderungspfad benötigt werden, wie z. B. Benutzerinformationen oder Laufzeitumgebungseinstellungen.

Beispiel für einen Header zur Übertragung von Baggage nach dem W3C-Standard: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Hier sind einige Beispiele zur Gepäcknutzung:

• Übergabe von Geschäftskontextinformationen wie userId , productId oder deviceId kann über alle Microservices weitergegeben werden. Anwendungen können diese Informationen automatisch protokollieren, sodass Protokollsuchen nach Benutzerkontext für die ursprüngliche Anforderung möglich sind.

• Spezifische Konfigurationsparametereinstellungen für SDKs oder Infrastruktur.

• Routing-Flags Flags, die Load Balancern bei Routing-Entscheidungen helfen. Während des Tests müssen einige Anfragen möglicherweise an Mock-Backends weitergeleitet werden. Da Gepäck automatisch über alle Dienste übertragen wird, müssen keine zusätzlichen Protokolle erstellt werden – richten Sie einfach eine Regel für den Load Balancer ein.

  
  

Implementierung der Infrastruktur

Die Implementierung von OpenTelemetry auf Infrastrukturebene umfasst die Integration von OpenTelemetry-Backends in die Anwendungsarchitektur und die Konfiguration der Infrastruktur für die Datenaggregation.

Der Prozess besteht aus vier Phasen:

1. Anwendungsintegration: In der ersten Phase werden OpenTelemetry SDKs direkt in Anwendungen integriert, um Metriken, Protokolle und Traces zu erfassen und so einen kontinuierlichen Datenfluss zur Leistung jeder Systemkomponente sicherzustellen.

   
   

2. Konfigurieren von Exporteuren: Erfasste Daten werden von Anwendungen über Exporteuren an externe Systeme zur weiteren Verarbeitung weitergeleitet, beispielsweise an Protokollierungs-, Überwachungs-, Ablaufverfolgungs- oder Analysesysteme, je nach Bedarf.

   
   

3. Aggregation und Speicherung: In dieser Phase können die Daten normalisiert, mit zusätzlichen Informationen angereichert und Daten aus unterschiedlichen Quellen zusammengeführt werden, um eine einheitliche Ansicht des Systemzustands zu erstellen.

   
   

4. Datenvisualisierung Schließlich werden verarbeitete Daten als Dashboards in Systemen wie Grafana (für Metriken und Traces) oder Kibana (für Protokolle) dargestellt. Auf diese Weise können Teams den Zustand des Systems schnell beurteilen, Probleme und Trends erkennen und auf der Grundlage generierter Signale Warnungen einrichten.

Anwendungsimplementierung

Zur Integration in eine Anwendung müssen Sie das entsprechende OpenTelemetry SDK für die verwendete Programmiersprache verbinden oder Bibliotheken und Frameworks verwenden, die OpenTelemetry direkt unterstützen. OpenTelemetry implementiert häufig weit verbreitete Schnittstellen aus bekannten Bibliotheken und ermöglicht so Drop-in-Ersetzungen. Beispielsweise wird die Micrometer-Bibliothek häufig für die Metrikerfassung im Java-Ökosystem verwendet. Das OpenTelemetry SDK stellt seine Implementierungen von Micrometer-Schnittstellen bereit und ermöglicht den Metrikexport, ohne den Hauptanwendungscode zu ändern. Darüber hinaus bietet OpenTelemetry Implementierungen älterer OpenTracing- und OpenCensus-Schnittstellen und ermöglicht so eine reibungslose Migration zu OpenTelemetry.

Abschluss

In IT-Systemen kann OpenTelemetry der Schlüssel für die Zukunft zuverlässiger und effizienter Backends werden. Dieses Tool vereinfacht das Debuggen und Überwachen und eröffnet zudem Möglichkeiten für ein tieferes Verständnis der Anwendungsleistung und -optimierung auf einer neuen Ebene. Treten Sie der OpenTelemetry-Community bei, um eine Zukunft zu gestalten, in der die Backend-Entwicklung einfacher und effektiver ist!