Einführung in OpenTelemetry für Anfänger

Lassen Sie uns über OpenTelemetry sprechen – eine herstellerunabhängige und standardisierte Methode, um Telemetriedaten zu erfassen.

Die Verbesserung der Beobachtbarkeit einer Anwendung ist für Entwickler eine große Herausforderung, da sie Telemetriedaten der Anwendung sammeln müssen. Laut dem Cambridge-Wörterbuch ist Telemetrie die Wissenschaft oder der Prozess des Sammelns von Informationen über entfernte Objekte und deren elektronische Übertragung.

Ein einfacher Klick oder eine Benutzersitzung auf einer Website erzeugt beispielsweise eine Vielzahl von Anfragen und Verfolgungen, die zwischen Netzwerken, Microservices, Datenbanken usw. fließen.

OpenTelemetry ist eine Plattform zur Beobachtbarkeit, die aus einer Sammlung von durchdachten Komponenten besteht, die einzeln oder in Kombination verwendet werden können. Entwickler von Frameworks und Bibliotheken, die wir heute verwenden, verfügen nun über eine standardisierte Methode zum Einbetten von Telemetriedaten in ihre Produkte. Dadurch erhalten Endbenutzer direkt einsatzbereite Einblicke in die Vorgänge dieser Frameworks.

Um OpenTelemetry zu verstehen, ist es wichtig, zunächst das Konzept der verteilten Ablaufverfolgung zu verstehen.

Was ist verteilte Ablaufverfolgung?

Da unsere Anwendungen immer komplexer werden und immer mehr Dienste in die Bedienung des Benutzerverkehrs und die Abwicklung von Transaktionen involviert sind, wird es entscheidend zu verstehen, wie Anfragen unsere Dienste durchlaufen und wie jeder Dienst zur Gesamtwartezeit beiträgt. Dies ist die Aufgabe der verteilten Ablaufverfolgung. Sie erfasst die Latenz von Benutzeranfragen und die Zeit, die jeder einzelne Microservice im Pfad benötigt, um zu antworten.

Wenn eine Benutzeranfrage eingeht, erstellen wir eine Ablaufverfolgung, also die Gesamtheit der Informationen, die beschreiben, wie unser System auf eine Benutzeranfrage reagiert. Ablaufverfolgungen bestehen aus Spans, wobei jeder Span ein bestimmtes Anforderungs- und Antwortpaar darstellt, das an der Bearbeitung einer Benutzeranfrage beteiligt ist. Der übergeordnete Span beschreibt die vom Endbenutzer wahrgenommene Latenz. Der untergeordnete Span dient dazu, zu verstehen, wie ein bestimmter Dienst in einem verteilten System aufgerufen wurde und wie er mit seinen Latenzinformationen geantwortet hat.

Was ist OpenTelemetry?

OpenTelemetry ist ein Open-Source-Projekt, das von der CNCF unterstützt wird und eine standardisierte Methode zur Erzeugung von Telemetriedaten bietet. Es entstand durch die Zusammenführung von OpenTracing, einem Standard zur Erzeugung von Ablaufverfolgungsdaten, und OpenCensus, einem Standard zur Erzeugung von Metrikdaten.

OpenTelemetry bietet eine einzige Reihe von APIs, Agenten, Kollektordiensten und Bibliotheken, um verteilte Ablaufverfolgungen und Metriken aus Ihrer Anwendung zu sammeln. OpenTelemetry standardisiert die Erfassung von Telemetriedaten und deren Übermittlung an ein beliebiges Backend. Dies ermöglicht eine herstellerunabhängige Instrumentierung und die Flexibilität, das Backend zu ändern, ohne den Code erneut instrumentieren zu müssen.

Sie können Ihre Anwendungen mit einem herstellerunabhängigen Agenten instrumentieren und gleichzeitig Metriken und Traces an einen SaaS-Anbieter wie Datadog senden. Ein Anbieterwechsel (z.B. von Datadog zu Dynatrace) ist ohne Änderungen am Anwendungscode möglich.

Das OpenTelemetry-Projekt zielt darauf ab, eine einzige Reihe von API-Bibliotheken und Agenten bereitzustellen, um Metriken und verteilte Ablaufverfolgungen aus Anwendungen zu erfassen. Dies gilt für viele Sprachen und Plattformen. Das Projekt umfasst auch einen optionalen Collector-Service und ein eigenes Repository für Spezifikationen. Wichtig ist: OpenTelemetry ist nicht Jaeger oder Prometheus, die als Observability-Backends fungieren. Es unterstützt jedoch den Datenexport in Open-Source- und kommerzielle Backends.

OpenTelemetry bietet folgende Funktionen:

• Standardisierung der Erfassung von Telemetriedaten, was den Wechsel zwischen Anbietern erleichtert
• Eine herstellerunabhängige, semantische Konvention für den Datenerfassungsprozess mit offenem Standard
• Ein Collector, der als Agent, Gateway oder in verschiedenen anderen Konfigurationen bereitgestellt werden kann
• Unterstützung mehrerer Kontextweitergabeformate für die Migration
• Eine End-to-End-Lösung zum Generieren, Ausgeben, Sammeln, Verarbeiten und Exportieren von Telemetriedaten
• Die Fähigkeit, Daten parallel mit vollständiger Kontrolle an verschiedene Ziele zu senden

OpenTelemetry-Komponenten

Die Kernkomponenten von OpenTelemetry sind:

• Proto: Definiert sprachunabhängige Schnittstellentypen für OpenTelemetry, die von Kollektoren, Instrumentierungsbibliotheken usw. verwendet werden.
• Collector: Dient zum Empfangen, Verarbeiten und Exportieren von Telemetriedaten. Diese Implementierung der Kollektoren muss herstellerunabhängig sein. Standardmäßig werden alle Telemetriedaten von Instrumentierungsbibliotheken hierhin exportiert.
• Spezifikation: Beschreibt die Anforderungen und Erwartungen an die Implementierung in verschiedenen Sprachen, bestehend aus APIs, SDKs und Daten. Die API generiert die Telemetriedaten und die SDKs implementieren die API, während die Verarbeitung- und Exportfunktionen bereitgestellt werden. Die Daten enthalten semantische Konventionen, um alle Arten von Anbietern ohne Codeänderungen zu unterstützen.
• Instrumentierungsbibliotheken: Im Rahmen des OpenTelemetry-Projekts sind sie in verschiedenen Sprachen verfügbar. Diese Bibliotheken werden verwendet, um die Beobachtbarkeit anderer Bibliotheken zu verbessern, sodass alle Anwendungen durch Aufrufe der OpenTelemetry-API beobachtet werden können.

OpenTelemetry-Architektur

OpenTelemetry besteht im Wesentlichen aus drei Hauptteilen:

• Eine Sammlung von APIs zum Instrumentieren von Anwendungen, Bibliotheken und Frameworks.
• Das SDK implementiert die APIs.
• Ein optionaler Kollektor kann Telemetriedaten erfassen, aggregieren und an den gewünschten Ort exportieren.

Die API ermöglicht die Erstellung von Instrumenten für Bibliotheken und Anwendungscode. Sie besteht aus vier Hauptabschnitten: Ablaufverfolgung, Zähler, gemeinsamer Kontext und semantische Konventionen.

• Die Tracer-API unterstützt das Erstellen, Kommentieren und Abschließen von Spans.
• Die Zähler-API besteht aus verschiedenen Metrikinstrumenten wie Beobachtern, Wertaufnehmern und Zählern.
• Mithilfe der Kontext-API können Sie den Span-Kontext verfolgen und ausführen und diesen Kontext innerhalb und außerhalb Ihres Systems weitergeben.
• Die semantischen Konventionen enthalten alle Richtlinien und Regeln für die Namensgebung, wie z. B. Spans, Attribute, Labels und metrische Instrumente. Diese Konventionen dienen der Konsistenz über verschiedene Sprachimplementierungen und für externe Instrumentierungen.

Im gemeinsam genutzten Kontext liegt die Kontextimplementierung zwischen Tracer und Messgerät. Sie ermöglicht es, dass alle Nicht-Beobachter-Metrikaufzeichnungen im Kontext eines ausführenden Spans erfolgen. Das SDK kann somit beispielhafte Spans für Metrikwerte erfassen. Mit Propagatoren kann der Kontext angepasst werden, der die Weitergabe des Span-Kontexts in und aus dem System ermöglicht, und somit eine echte verteilte Ablaufverfolgung realisiert.

Der Kollektor ist ein wesentlicher Bestandteil der OpenTelemetry-Architektur. Er ist ein eigenständiger Dienst, der Telemetriedaten aus verschiedenen Quellen empfangen, verarbeiten und exportieren kann, darunter OpenCensus, Zipkin, Jaeger und das OpenTelemetry-Protokoll. Mit Kollektoren können Sie Spans und Metriken an mehrere Anbieter und Open-Source-Telemetriesysteme exportieren.

Die OpenTelemetry-Architektur bietet eine umfassende Telemetrielösung. Durch den Einsatz mehrerer Erweiterungspunkte können auch Anpassungen vorgenommen werden.

Wie funktioniert OpenTelemetry?

Installieren Sie in jedem Dienst Ihrer Bereitstellung den OpenTelemetry-Client. Der Client ist das SDK und das SDK verfügt über eine API. Ihre Anwendungsframeworks und -bibliotheken verwenden diese Instrumentierungs-API, um ihre Arbeit zu beschreiben. Das SDK exportiert die gesammelten Beobachtungen an einen Daten-Pipeline-Dienst, der als Collector bezeichnet wird.

OpenTelemetry hat sein eigenes Datenprotokoll, OTLP. Der Kollektor kann OTLP in verschiedene Formate übersetzen, darunter Zipkin, Jaeger und Prometheus. OpenTelemetry stellt jedoch kein eigenes Backend oder Analysetool zur Verfügung. Der Kern von OpenTelemetry ist die Standardisierung, d.h. die Entwicklung einer universellen Sprache zur Beschreibung der Abläufe in einer Cloud-Umgebung. Ziel ist es nicht zu standardisieren, wie Daten analysiert werden, sondern neue Analysetools zu ermöglichen, die schnell gestartet werden können, ohne das gesamte Ökosystem von Telemetriesoftware neu aufbauen zu müssen.

Wenn viele Daten über das System gesendet werden, gibt es viel zu beachten. OpenTelemetry hat jedoch an all diese Aspekte gedacht und Lösungen für jedes dieser Probleme. OpenTelemetry ist flexibel und kann mehrere Formate für die Kontextweitergabe verarbeiten. Obwohl es einen Standard gibt, gibt es innerhalb dieses Standards immer noch eine Wahlmöglichkeit. Wenn Sie also Formate wie W3C Trace Context oder B3-Propagation verwenden, gibt es verschiedene Standards innerhalb des Standards, die es Ihren Diensten ermöglichen, sich zu verbinden.

Fazit

OpenTelemetry erfasst eine Vielzahl von Beobachtungsdaten, wobei verteilte Ablaufverfolgungsmetriken und Systemressourcen die wichtigsten sind. Anstatt diese als separate Signale zu behandeln, verknüpft OpenTelemetry sie miteinander und bietet eine Indizierung und einen Kontext, mit dem Sie alle diese Signale im Backend aggregieren und querindizieren können.

Zusätzlich zur Datenerfassung bietet OpenTelemetry eine Datenverarbeitungs- und Pipeline-Funktion. Sie können Datenformate ändern und Daten bearbeiten. Dies umfasst alle Werkzeuge, die Sie zum Aufbau einer robusten Telemetrie-Pipeline in einem modernen System benötigen.

Das war ein Überblick über OpenTelemetry. Probieren Sie dieses Tool aus.