OpenTelemetry-Protokollierung: Eine Einführung

OTel-Protokollierung bietet IT-Teams eine einheitliche, eindeutige Mapping-Struktur zur Konvertierung von Logdaten aus verschiedenen Quellen, Systemen und Formaten in ein einziges, sprachneutrales Modell, wobei die ursprüngliche semantische Bedeutung erhalten bleibt.

Mit einem anbieterunabhängigen, strukturierten Datenmodell können Observability-Tools Protokolle einfacher und zuverlässiger analysieren, Metadaten anhängen und Protokolle mit Metriken und Traces korrelieren, um eine umfassende, durchgängige Transparenz zu gewährleisten.

Die OTel-Protokollierung ermöglicht es Unternehmen, Observability-Backends zu wechseln und zu kombinieren, ohne die gesamte IT-Architektur neu instrumentieren zu müssen. Deshalb hat sie sich zum Branchenstandard für die Instrumentierung in modernen, cloudnativen Systemen entwickelt. Diese Funktionen helfen IT-Teams und Site Reliability Engineers (SREs), die Observability-Lücken und Datenfragmentierungsprobleme zu vermeiden, die auftreten, wenn jeder Anbieter, Stack und jedes Gerät sein eigenes Protokollierungsschema und seine eigenen Übertragungsprotokolle hat.

Die OTel-Protokollierung erleichtert außerdem die automatische Cross-Signal-Korrelation, was das Debugging erheblich verbessert und die Observability-Anbieterbindung reduziert.

OpenTelemetry-Protokolle sind eine wichtige Komponente von OpenTelemetry. OpenTelemetry ist ein Open-Source-Observability-Framework, der eine Sammlung von Software Development Kits (SDKs), anbieterunabhängigen Programmierschnittstellen (APIs) und anderen Tools für die Anwendungs-, System- und Geräteinstrumentierung umfasst.

Früher gab es sehr unterschiedliche Instrumentierungslösungen, und kein einziger kommerzieller Anbieter bot ein Tool an, mit dem sich Daten von allen Apps und Diensten in einem Netzwerk erfassen ließen. Diese Funktionslücke machte es für Teams schwierig (und oft sogar unmöglich), Daten aus verschiedenen Programmiersprachen, Formaten und Laufzeitumgebungen zu erfassen.

Auch die traditionellen Observability-Ansätze machten die Änderung der Backend-Infrastruktur und -Komponenten zu einem zeitaufwändigen und arbeitsintensiven Prozess.

Wenn beispielsweise ein Entwicklungsteam die Backend-Tools austauschen möchte, muss es seinen Code komplett neu instrumentieren und neue Agenten (Softwarekomponenten, die automatisierte Build- und Release-Aufgaben ausführen) konfigurieren, um Telemetriedaten an die neuen Server zu senden. Fragmentierte Ansätze führten zu Datensilos und Verwirrung, was es schwierig machte, Leistungsprobleme effektiv zu lösen.

OpenTelemetry stellt einen bedeutenden Fortschritt bei der Observability dar, da es die Art und Weise standardisiert hat, wie Telemetriedaten erfasst, analysiert und an Backend-Plattformen übertragen werden. Es bot eine Open-Source-Lösung – basierend auf von der Community entwickelten Standards – zur Erfassung von Daten über Systemverhalten und Sicherheit und half Teams damit, die Überwachung und Observability in verteilten Ökosystemen zu optimieren.

Die OpenTelemetry-Protokollierung basiert auf mehreren kooperierenden Komponenten, die Protokolldatensätze im Rahmen einer einheitlichen Observability-Pipeline erstellen, strukturieren, transportieren und bereitstellen. Dazu gehören:

Ein Protokolldatensatz ist eine zentrale Datenstruktur, die ein einzelnes Protokollereignis in OpenTelemetry darstellt. Er folgt einem Standard-Datenmodell, das Felder und Semantik definiert, so dass Protokolle aus verschiedenen Sprachen und Systemen von Backends einheitlich interpretiert werden können.

Protokolldatensätze erscheinen wie strukturierte Zeilen in einer Tabelle, die ein Ereignis beschreiben und grundlegende Fragen beantworten, wie z. B. „Was ist passiert“, „Wann ist das passiert“, „Wie wichtig ist es“ und „Woher kam es?“

Das Protokolldatenmodell ist die gemeinsame Vorlage, der jeder Datensatz in allen Sprachen und Systemen folgt. Es definiert, welche Felder der obersten Ebene existieren und was jedes einzelne davon bedeutet.

Ein typisches Protokolldatenmodell erfordert, dass die Datensätze Folgendes enthalten:

• Ein Zeitstempel und ein beobachteter Zeitstempel (wann das Ereignis stattfand und wann es beobachtet wurde)

• Schweregradzahlen und Schweregradtext (auch Protokollierungsstufe genannt) ,die den Schweregrad eines Ereignisses beschreiben

• Der Hauptteil (die eigentliche Protokollmeldung, oft eine kurze Zeichenfolge oder ein JSON-Objekt)

• Attribute, die detailliertere Informationen zu jedem Ereignis hinzufügen (z. B. Benutzer- oder HTTP-Details)

• Ressourceninformationen, die den aussendenden Dienst und die Bereitstellungsumgebung identifizieren

• Trace-IDs und Span-IDs, die das Ereignis mit einer bestimmten Anfrage verknüpfen (vereinfacht die Datenkorrelation)

Die Strukturdatenmodelle wandeln Protokolle aus verschiedenen Diensten und Technologien in umfangreiche, abfragbare Telemetrie-Entitäten um, die bei der Einbindung in die Observability-Pipeline einheitlich aussehen und sich einheitlich verhalten. Mithilfe von Protokolldatenmodellen können IT-Teams Protokolle mit Traces in Beziehung setzen, sie nach Diensten oder Benutzern gruppieren und einheitliche Abfragen in der gesamten IT-Umgebung durchführen, anstatt sich mit einer Vielzahl inkompatibler Protokollformate auseinandersetzen zu müssen.

Und da das Protokollmodell offen und gemeinschaftsorientiert ist, sind die Instrumentierungs- und Protokollpipelines von OTel portabel (sie sind nicht an ein einzelnes Software-as-a-Service-Produkt (SaaS) oder einen proprietären Agenten gebunden). Sie funktionieren framework- und plattformübergreifend, was insbesondere in polyglotten Microservice- Umgebungen von großem Wert ist.

Ein Logger ist das Objekt, das Protokolleinträge schreibt, ähnlich wie Logger-Instanzen in anderen Protokollierungsframeworks (wie Java und Python). Wenn eine Observability-Plattform einen Befehl wie „Diesen Fehler protokollieren“ oder „Diese Infomeldung protokollieren“ sendet, wird die Nachricht an einen Logger gesendet.

Verschiedene Teile einer Anwendung oder eines Systems können ihre eigenen Logger benötigen (zum Beispiel einen für „Checkout“ und einen für „Zahlungen“), aber sie alle folgen den gleichen Regeln für die Generierung von Protokollen.

Logger werden von einem Logger-Provider bereitgestellt, der für die Erstellung von Loggern und deren Konfiguration mit der richtigen Pipeline, den richtigen Attributen und den richtigen Exportern zuständig ist​ Wenn der Softwarecode einen Logger anfordert, stellt der Provider einen bereit, der bereits entsprechend konfiguriert ist.

Dieses Design ermöglicht es, dass verschiedene Teile eines Systems unterschiedliche Logger verwenden, die dennoch eine gemeinsame Konfiguration nutzen und alle zentral vom Logger-Provider verwaltet werden. Außerdem erleichtert es IT-Teams, Implementierungen auszutauschen und das Protokollierungsverhalten global anzupassen, ohne jede Aufrufstelle ändern zu müssen.

Der OTel Collector ist ein separater Dienst, der Telemetriedaten – einschließlich Protokolldatensätzen – aus vielen Quellen empfängt, verarbeitet und exportiert. Anwendungen senden ihre Protokolle (sowie Traces und Metriken) an den Collector, der Daten in verschiedenen Formaten empfangen, standardisieren und dann an ein oder mehrere Backends senden kann.

Collectors unterstützen spezielle Protokoll-Pipelines, die auf drei Hauptkomponenten basieren: Empfänger, Prozessoren und Exporter.

Receiver nehmen Protokolle von verschiedenen Eingaben auf, z. B. OTLP-Streams (OpenTelemtetry Protocol) und Protokolldateien von File-Tailing-Receivern. Prozessoren führen Vorgänge wie Batching, Änderung von Attributen, Kontextanreicherung (beispielsweise das Hinzufügen von Kubernetes-Pod-Metadaten), Filterung und Stichprobenahme an Protokolldatensätzen durch. Die Exporters innerhalb des Collectors leiten die verarbeiteten Protokolle anschließend an einen oder mehrere Ziele weiter.

Protokolldaten-Exporters befinden sich in einem OTEL Collector oder einem Anwendungs-SDK und definieren, wo und wie Telemetriedaten an Backend-Systeme geliefert werden.

Nachdem das Protokoll-SDK einen Protokollsatz erstellt und verarbeitet hat, kodiert der Exporter das Protokoll-Datenmodell in ein bestimmtes Protokoll oder Format und sendet den Datensatz an einen nachgelagerten „Verbraucher“. Zu den Verbrauchern können beispielsweise OTel Collectors, Observability-Lösungen oder Open-Source-Stores gehören.

Exporters können entweder auf Push- oder auf Pull-Basis arbeiten und lassen sich austauschen und kombinieren, um dieselben Protokolleinträge gleichzeitig an verschiedene Backends zu übertragen, ohne den Anwendungscode ändern zu müssen. Die Flexibilität, die Exporters bieten, erleichtert es Unternehmen, ihre Observability-Architektur an sich ändernde Anforderungen anzupassen.

Die Protokoll-API und das Protokoll-SDK funktionieren wie eine Steckdose an einer Steckdosenleiste: Die API ist der Steckdosentyp, und das SDK ist die Steckdosenleiste, über die der Strom fließt.

Die OpenTelemetry-APIs umfassen eine Reihe von Funktionen, die von Programmier- und Protokollierungsbibliotheken aufgerufen werden, um einheitliche Protokolleinträge zu erstellen. Im Wesentlichen legt die Protokoll-API die „Form“ fest, die ein Protokoll haben muss, um in OTel integriert zu werden. Die Protokoll-API trägt dazu bei, dass dieselben API-Aufrufe funktionieren, unabhängig davon, für welches Observability-Backend oder welchen Anbieter sich das IT-Team später entscheidet.

Die API ist jedoch lediglich eine Schnittstelle. Sie kann nicht entscheiden, wohin die Protokolle gesendet werden oder wie sie gesendet werden. Hier kommt das OpenTelemetry SDK – oder Protokoll-SDK – ins Spiel.

Das Protokoll-SDK übernimmt die Protokolle vom API-Endgerät und führt die eigentliche Verarbeitung durch. Es empfängt Protokolleinträge, ergänzt sie (beispielsweise um den Namen des Dienstes oder die Umgebung), fasst sie zu Batches zusammen und bereitet sie für den Versand vor. Anschließend werden mithilfe von Exportern die verarbeiteten Protokolle an einen Collector oder eine Protokollplattform gesendet.

Protokoll-Appender – auch als Protokoll-Brücken bezeichnet – verbinden bestehende Protokollierungsbibliotheken (wie Log4j, SLF4J oder ähnliche Frameworks) mit dem OpenTelemetry-Protokolldatenmodell.

Anstatt die Protokoll-API direkt aufzurufen, können Softwareentwickler ihr bestehendes Protokollierungs-Framework so konfigurieren, dass ein Appender verwendet wird, der jedes herkömmliche Protokollereignis in einen OTel-Protokollsatz umwandelt.

Protokoll-Brücken können auch Span- und Trace-Kontext in Protokolleinträge einfügen, wodurch eine Korrelation zwischen Protokollen und Traces ermöglicht wird, selbst wenn der Anwendungscode selbst keine Kenntnis von den Trace-Details hat.

Mechanismen zur Kontextweitergabe und -korrelation sind wesentliche Komponenten der OpenTelemetry-Protokollierung. Wenn ein Trace-Span aktiv ist, kann eine Protokollierungs-Brücke oder ein SDK automatisch die aktuelle Trace-ID und Span-ID an jeden ausgegebenen Protokollsatz anhängen.

Mithilfe von Korrelationen können Observability-Backends Protokolle mit verteilten Traces verknüpfen, die dieselbe Anfrage oder denselben Workflow darstellen. Über diese Verknüpfungen können Teams von einem problematischen Protokolleintrag direkt zu einem Trace navigieren, der den gesamten Verlauf der Anfrage anzeigt. Außerdem wird die signalübergreifende Analyse von Metriken, Traces und Protokollen erleichtert, die gemeinsame Ressourcen- und Kontextfelder aufweisen.

OTel unterscheidet verschiedene „Arten“ von Protokollen: nach Struktur, nach Quelle und nach Kodierung oder Übertragungsprotokoll.

Strukturierte Protokolle weisen ein einheitliches Schema auf – dieselben Felder mit festen Namen und Datentypen –, sodass Observability-Tools sie zuverlässig analysieren und abfragen können. Die Protokolle können im JSON-Format oder einem anderen Format kodiert sein, aber ihre Struktur entsteht durch die vorhersehbare Menge an Datenfeldern.

Halbstrukturierte Protokolle weisen eine gewisse erkennbare Struktur auf (beispielsweise Schlüssel-Wert-Paare oder JSON-ähnliche Blobs), doch das Schema bleibt im Laufe der Zeit nicht konsistent. Sie sind maschinenlesbarer als freier Text, benötigen aber zusätzliches Parsing und Normalisierung, bevor Teams sie effektiv analysieren können.

Unstrukturierte Protokolle sind frei formatierte Textnachrichten ohne festes Schema (wie beispielsweise Ad-hoc-Ausgabebefehle oder Serverprotokolle im Klartext). Sie sind für Menschen leicht zu schreiben und zu lesen, für automatisierte Systeme jedoch schwieriger zu durchsuchen, zu korrelieren und zu aggregieren, ohne dass ein erheblicher zusätzlicher Analyseaufwand erforderlich ist. 

System- und Infrastruktur -Protokolle werden von Betriebssystemen, Netzwerkgeräten, Cloud-Infrastrukturservices und anderen Plattformkomponenten erstellt, nicht vom Anwendungscode. Sie erfassen Ereignisse – wie Betriebssystemfehler, Netzwerkprobleme und den Status der Infrastruktur –, um Teams dabei zu helfen, den Zustand und die Leistung der zugrunde liegenden Umgebung zu verstehen.

First-Party-Anwendungsprotokolle stammen aus internen Diensten und Anwendungen, in der Regel über ein OTel-SDK, eine Protokollierungsbibliothek, einen Sidecar (einen zweiten App-Container, der parallel zum primären Container läuft und dieselben Ressourcen nutzt) oder einen Agenten. Sie beschreiben Geschäftsereignisse, die Bearbeitung von Anfragen, Benutzeraktionen und interne Fehler. Sie können mit Ressourcenattributen und Instrumentierungsbereich (der den Ursprung des Protokolls innerhalb der Entität beschreibt, die es generiert hat) angereichert werden, um ein vollständigeres Bild des Anwendungsverhaltens zu liefern.

Third-Party-Protokolle werden von externen Diensten, verwalteten Komponenten und SaaS-Produkten erzeugt, von denen viele IT-Umgebungen von Unternehmen abhängen (z. B. externe APIs und Datenbanken). OTel kann diese Protokolle zusammen mit internen Protokollen aufnehmen, sodass IT-Teams sehen können, wie sich externe Abhängigkeiten auf das Ökosystem auswirken.

OTLP-Protokolle werden im nativen OTLP-Datenmodell dargestellt und über OTLP gRPC oder HTTP übertragen. Jedes Protokoll ist standardisiert, um Anbieterneutralität zu gewährleisten und eine schnelle Korrelation mit Traces und Metriken zu ermöglichen.

Dateibasierte Protokolle werden in Dateien geschrieben (Anwendungsprotokolldateien oder Webserver-Zugriffsprotokolle), und Protokolle im Syslog-Stil sind Meldungen, die mithilfe des Syslog-Protokolls ausgegeben werden. OTel erfasst diese Protokolle in der Regel mithilfe von Receivern, die Dateien überwachen oder auf Syslog-Meldungen warten, und wandelt sie anschließend zur einheitlichen Verarbeitung in OTel-Protokollsätze um.

HTTP- und JSON-Protokolle werden über HTTP in JSON bereitgestellt. OpenTelemetry unterstützt CSV, Common Log Format (CLF), LTSV sowie Schlüssel-Wert-Paare. Diese Formate werden vom Collector in das gemeinsame OTel-Protokoll-Datenmodell konvertiert, sodass sie auf dieselbe Weise wie native OTLP-Protokolle abgefragt und korreliert werden können.

Angenommen, die SREs stellen auf den Observability-Dashboards für einen Checkout-Microservice einen Anstieg der Fehlermeldungen „Checkout fehlgeschlagen“ fest. Sie könnten die Fehlerbehebung damit beginnen, die OTel-Protokolle zu überprüfen, die bereits standardisiert sind und für jeden Protokolleintrag zum Thema „aufgegebene Bestellung“ strukturierte Attribute (einschließlich Bestellwert, Stückzahl und Sendungsverfolgungsnummer) enthalten.

Engineers können durch einfache Abfrage der Protokollattribute schnell überprüfen, ob die Fehler mit hohen Auftragsvolumina, einer bestimmten Versandart oder einer bestimmten Region zusammenhängen. Sie können auch das Zeitfenster über Protokolle, Traces und Metriken hinweg angleichen, da OTel konsistente Zeitstempel und Ressourcen-Metadaten über alle Telemetriesignale hinweg verwendet.

Die Engineers bestätigen, dass nur Aufträge, die an einen bestimmten Zahlungsanbieter weitergeleitet werden, fehlschlagen. Sie verfolgen einen Trace zurück zu allen Protokollen, die dieses Anbieterattribut teilen, wo sie wiederholte Session-Timeouts finden. Anhand dieser Informationen kann das IT-Team den Vorfall umgehend an den zuständigen Verantwortlichen weiterleiten und eine Abhilfemaßnahme einleiten (beispielsweise die Umstellung auf einen anderen Provider).

Die OTel-Protokollierung unterscheidet sich wesentlich von der herkömmlichen Protokollierung in Bezug auf die Datenerfassung, Standardisierung, Korrelation und Protokollübertragung.  

Traditionelle Protokollierungssysteme konzentrieren sich auf Protokollaggregation, Indexierung, Suche und Warnmeldungen auf der Grundlage von Protokollmustern. Sie sind leistungsstarke Tools für Textsuche und historische Analysen, untersuchen Protokolle jedoch meist isoliert von anderen Telemetriedaten.

Bei traditionellen Protokollierungsansätzen geht es primär um die lokale Aufzeichnung von Textnachrichten, damit Entwickler Probleme in einer einzelnen Anwendung oder auf einem einzelnen Host debuggen können. Sie gehen davon aus, dass die Benutzer die Dateien lesen, filtern und sie gegebenenfalls zu einem späteren Zeitpunkt an einen Protokoll-Aggregator senden. Sie verwenden außerdem in der Regel Ad-hoc-Formate wie einfache Textzeilen, lose strukturiertes JSON oder frameworkspezifische Muster ohne dienstübergreifenden Standard.

Und da jedes Entwicklungsteam seine eigenen Felder und Bezeichnungen festlegen kann, gestaltet sich die systemübergreifende Analyse als mühsamer Prozess.

Traditionelle Protokollierungstools verfügen oft nicht über integrierte Korrelations- oder Migrationsfunktionen, sodass die Datenkorrelation und Integration mit Observability-Backends manuelle Prozesse und zusätzliche Schritte erfordert. IT-Teams müssen benutzerdefinierte Konventionen und Parsing-Regeln erstellen, um Ereignisse über verschiedene Dienste hinweg zusammenzuführen, und die Integration von Protokolldaten in den Observability-Stack erfordert in der Regel benutzerdefinierte Shipper oder Formatadapter.

Die OpenTelemetry-Protokollierung ist Teil eines einheitlichen Observability-Frameworks, das Protokolle, Metriken und Traces als erstklassige, interoperable Signale behandelt, die durch gemeinsame semantische Konventionen geregelt werden. Sie ist von Anfang an darauf ausgelegt, Protokolle über verteilte Systeme hinweg zu korrelieren und zu analysieren, denn das Ziel ist es, das Systemverhalten von Anfang bis Ende zu verstehen.

Während die traditionelle Protokollierung Stack- und Backend-spezifisch ist, ist die OTel-Protokollierung bewusst agnostisch. Sie stellt Brücken und Appender bereit, sodass bestehende Protokollierungs-Frameworks Daten im OTel-Format ausgeben können, ohne dass jeder Protokoll-Aufruf neu geschrieben werden muss.

Dieser einheitliche Umfang und Ansatz ermöglicht es IT-Teams, einen ganzheitlichen Workflow zur Fehlerbehebung zu erstellen, in dem sie nahtlos zwischen Dashboards und Datentypen wechseln können, um komplexe, verteilte Fehler zu verstehen.

Die OTel-Protokollierung bietet standardisierte, kontextreiche Protokolle, die sich eng mit Traces und Metriken integrieren lassen und so die Fehlersuche und Analyse wesentlich effektiver gestalten als traditionelle Ansätze. Zu den Vorteilen gehören: