Was ist OpenTelemetry?

OTel vereinfacht die Erfassung von Telemetriedaten, unabhängig von Programmiersprache, Infrastruktur oder Laufzeitumgebung, und ermöglicht es Entwicklern, standardisierte Telemetriedaten für jedes Observability-Backend zu generieren, zu erfassen und zu exportieren. Dieses standardisierte Framework stärkt und erweitert die Observability-Funktionen und bietet IT- und DevOps-Teams mehr Flexibilität.  

OTel wird zwischen Anwendungen, Systemen und Geräten sowie Backend-Lösungen implementiert. Speicher und Visualisierung werden absichtlich anderen Tools überlassen, sodass Unternehmen die Freiheit haben, die Tools zu wählen, die am besten zu ihnen passen.

Observability ist die Fähigkeit, durch die Analyse seiner Ausgaben Einblicke in die interne Funktionsweise eines Systems zu gewinnen. Im IT-Betrieb (ITOps) und beim Cloud Computing werden Telemetriedaten (wie Protokolle, Metriken und Traces) verwendet, um die Systemleistung und den Zustand zu bewerten. DevOps-Experten verlassen sich auf Instrumentierung – sie fügen Anwendungen und Systemen Code hinzu, um Telemetriedaten zu erzeugen und zu erfassen – um beobachtbare Systeme zu erstellen.

Diese Instrumentierung ist oft ein komplexes Unterfangen in modernen Umgebungen – mit Hybrid-Cloud- und Multicloud-Umgebungen, Microservices-basierten Anwendungen, Kubernetes-Containern und anderen Merkmalen aktueller IT-Umgebungen. Diese verteilten Systeme und die verschiedenen Programmiersprachen und Laufzeiten, die sie integrieren, stellen ein kompliziertes Array dar, das instrumentiert, erfasst und für die Speicherung, Visualisierung und Analyse exportiert werden muss.

Um einen umfassenden Einblick in den Netzwerkservice und die Leistung von Anwendungen zu erhalten, müssen Entwickler eine benutzerdefinierte Instrumentierung für Anwendungen und Systeme in der gesamten Infrastruktur konfigurieren. OpenTelemetry hilft, dieses Problem zu lösen.

OTel bietet eine Standardmethode zum Sammeln und Übertragen von Observability-Daten, die die Überwachung in verteilten Systemen vereinfacht. Es verwendet einheitliche, herstellerneutrale Bibliotheken und APIs, um Telemetriedaten zu sammeln und an Backend-Plattformen zu senden. Durch den Einsatz von OpenTelemetry können Teams Telemetriedaten über komplexe Systeme hinweg einheitlich erfassen und verarbeiten, unabhängig davon, welche Anwendungen sie verwalten oder welche Observability-Tools sie verwenden.

Der Instrumentierungscode war bisher sehr unterschiedlich. Und da kein einzelner kommerzieller Anbieter ein Tool anbot, das in der Lage war, Daten von jeder App und jedem Dienst in einem Netzwerk zu erfassen, war es für Unternehmen schwierig, Daten in verschiedenen Sprachen und Formaten zu erfassen oder das Backend zu ändern.

Wenn beispielsweise ein Entwicklungsteam Backend-Tools austauschen wollte, musste es seinen Code komplett neu instrumentieren und neue Agenten konfigurieren, um Telemetriedaten an die neuen Server zu senden. Darüber hinaus führte dieser fragmentierte Ansatz zu Daten-Silos und Verwirrung, was es schwierig machte, Leistung effektiv zu beheben und zu lösen.

OpenTelemetry stellt einen bedeutenden Fortschritt bei der Observability dar, da es die Art und Weise standardisiert hat, wie Telemetriedaten gesammelt, analysiert und an Backend-Plattformen übertragen werden. Es bietet eine Open-Source-Lösung, die auf von der Community entwickelten Standards basiert und Daten über das Systemverhalten und die Sicherheit erfasst und Teams dabei hilft,die Überwachung und Observability in verteilten Ökosystemen zu optimieren. Als solche bietet OTel Unternehmen einen offenen, konsistenten Ansatz für die Erfassung kritischer Daten aus Netzwerkanwendungen und -diensten.

OpenTelemetry wurde entwickelt, indem die verteilten Tracing-Funktionen von OpenTracing und OpenCensus in einem einzigen Tool kombiniert wurden. OpenTracing war ein Open Source-Projekt, das von der Cloud Native Computing Foundation (CNCF) entwickelt wurde, um Entwicklern eine herstellerneutrale API zur Verfügung zu stellen, mit der sie Anwendungen um verteilte Tracing-Instrumente erweitern können. Es wurde eine Reihe semantischer Konventionen eingeführt, um die Konstanz der Telemetriedaten sicherzustellen

Im Gegensatz zu OpenTelemetry war OpenTracing jedoch selbst keine Tracing-Implementierung. Vielmehr wurden Schnittstellen bereitgestellt, die von Tracing-Systemen implementiert werden konnten, um die Kompatibilität zwischen den Plattformen zu maximieren. OpenTracing ist ein nicht mehr existierendes Projekt (das Benutzer jetzt ermutigt, zu OpenTelemetry zu migrieren), aber verschiedene Software- und Tracing-Lösungen basieren immer noch auf seinen APIs.

OpenCensus stellt eine Reihe von Instrumentenbibliotheken dar und wurde von Google entwickelt, um Anwendungen und verteilte Traces zu sammeln, die Metriken in Echtzeit an verschiedene Backends exportieren können. Es sammelt Daten mithilfe konstanter Propagierungs-Tags und Metadaten — ein Konzept, das jetzt in OpenTelemetry als „Ressourcen“ existiert.

Mit OpenCensus können Anwendungen Daten basierend auf ihren spezifischen Anforderungen importieren und exportieren, was eine flexible Art und Weise gewährleistet, um Metriken und Traces an Observability-Backends zu senden. OpenCensus wurde nicht wie OpenTracing formell eingestellt, sondern weiterhin regelmäßig gewartet und mit Sicherheitsupdates versorgt. Die aktive Entwicklung hat sich jedoch größtenteils auf OpenTelemetry verlagert.

Beide Projekte zielten auf dasselbe Problem ab. Zu dieser Zeit hatten Entwicklungsteams keine Standardmethode, um Code zu instrumentieren und Telemetriedaten an Backend-Observability-Tools zu übertragen.

Keines der Projekte konnte dieses Problem jedoch allein lösen. Daher sponserte die CNCF das OpenTelemetry-Projekt, bei dem die besten Funktionen der beiden Lösungen kombiniert wurden. OpenTelemetry vereint die API-Standardisierung von OpenTracing und die Funktionen von OpenCensus zu einer einzigen, einheitlichen Plattform für das Senden, Sammeln und Übertragen von Telemetriedaten an Backend-Plattformen für Observability.

Ein wichtiger Teil des Betriebs schneller, hochverfügbarer Netzwerke und Anwendungen ist die Erzielung von Full Stack Observability (oder Sichtbarkeit), was den Zugriff auf Telemetriedaten erfordert. Observability-Lösungen sammeln, überwachen und analysieren Telemetriedaten, um den Systemzustand zu ermitteln und bieten IT-Teams dann umsetzbare Erkenntnisse für Reparaturen und Optimierungen.

Um OpenTelemetry besser zu verstehen, wollen wir uns ansehen, was Telemetriedaten sind und wie Unternehmen sie nutzen. OpenTelemetry unterstützt bestimmte Datentypen, nämlich die Ausgaben, die aus Logs, Metriken und Traces gesammelt werden (oft als die „drei Säulen der Observability“ bezeichnet).

Metriken sind numerische Bewertungen der Systemleistung und Ressourcennutzung. Sie bieten einen umfassenden Überblick über den Zustand des Netzwerks, indem sie wichtige KPIs wie Latenz, Paketverlust, Bandbreitennutzung und CPU-Auslastung des Geräts erfassen.

Metriken werden normalerweise mithilfe von Dashboards und anderen Visualisierungen zusammengefasst. Sie liefern den Teams häufig erste Hinweise auf ein Leistungsproblem bei Systemen oder Anwendungen.

Protokolle sind detaillierte Aufzeichnungen aller Ereignisse oder Aktionen, die in der Umgebung stattfinden. Sie liefern detaillierte Informationen darüber, was, wann und wo im Netzwerk passiert ist, und geben den Teams so einen wertvollen Kontext für die Fehlersuche, das Debugging und die forensische Analyse.

Protokolle enthüllen die zugrunde liegenden Ursachen von Problemen, indem sie Systemereignisse wie Änderungen der Gerätekonfiguration, fehlgeschlagene Authentifizierungen und unterbrochene Verbindungen detailliert auflisten.

Traces erfassen den Datenfluss im Netzwerk und geben Einblicke in den Pfad und das Verhalten von Paketen, während sie mehrere Geräte und Systeme durchlaufen. Sie sind unerlässlich, um verteilte Systeme zu verstehen und Latenzprobleme zu diagnostizieren.

Tracing-Daten ermöglichen es IT-Teams, den gesamten Verlauf einer Transaktion durchgängig zu verfolgen, und helfen dabei, Verzögerungen und Fehler zu lokalisieren, die in komplexen, mehrschichtigen Umgebungen auftreten.

OpenTelemetry stützt sich auf mehrere Komponenten und Prozesse für eine erfolgreiche Datenerfassung, darunter:

Eine API ist eine Reihe von Regeln oder Protokollen, die es Softwareanwendungen ermöglichen, miteinander zu kommunizieren, um Daten, Features und Funktionen auszutauschen.

OpenTelemetry bietet sprachspezifische APIs für Java™, Ruby, JavaScript, Python und andere Sprachen, die Entwickler verwenden können, um ihre Anwendungen für die Telemetriedatenerfassung zu instrumentieren. OpenTelemetry-APIs entkoppeln Apps von der Netzwerkinfrastruktur und geben Teams die Flexibilität, das Endgerät zu verwenden, das ihrem Instrumentierungscode entspricht.

OpenTelemetry SDKs ermöglichen es Ingenieuren, das API-Verhalten zu konfigurieren und anzupassen. SDKs bilden die Brücke zwischen APIs und Kollektoren und ermöglichen es, die manuelle Instrumentierung für allgemeine Bibliotheken mit der manuellen App-Instrumentierung zu verbinden. 

OTel bietet SDKs für eine Reihe von Programmiersprachen an, sodass Entwickler OTel-APIs verwenden können, um Telemetriedaten speziell für die von ihnen gewählte Sprache und ihr gewähltes Backend zu generieren und zu exportieren. Die OTel SDKs unterstützen auch die benutzerdefinierte Instrumentierung für eigene Frameworks, die noch nicht von der OpenTelemetry-Community abgedeckt werden.

Ein Collector ist ein Agent, der Telemetriedaten von Anwendungen sammelt, die mit OpenTelemetry instrumentiert sind. Der Collector besteht aus Empfängern, Prozessoren, Aggregaten und Exporteuren und fungiert als anbieterneutraler Vermittler, der Daten von Anwendungen empfängt und sie zur Analyse an Observability-Plattformen oder andere Ziele weiterleitet.

Der OpenTelemetry Collector unterstützt Contrib-Pakete, die es ihm ermöglichen, Daten in mehreren Formaten – darunter OpenTelemetry Protocol (OTLP), Prometheus und Jaeger – aufzunehmen und in verschiedene Backends zu exportieren, manchmal gleichzeitig (aus Redundanzgründen). Contrib-Pakete sind Erweiterungen von Drittanbietern, die Entwicklungsteams Instrumentierung, Sampler, Propagatoren und Ressourcendetektoren in einem Submodul-Format zur Verfügung stellen.

Collectors können Telemetriedaten vor dem Exportieren auch verarbeiten und filtern, um die Bereitstellung der wichtigsten Daten zu priorisieren und die Fehlerbehebungs- und Debugging-Prozesse zu beschleunigen.

Exporter sind Teil des Collectors und dafür verantwortlich, Telemetriedaten an ein oder mehrere bestimmte Observability-Backends zu senden. Während Collectors den gesamten Datenfluss verwalten, priorisieren Exporter die Übertragung von Daten nach außen an ihr Ziel.

OpenTelemetry-Datenexporteure entkoppeln die Instrumentierung von den Backend-Konfigurationen und konvertieren die Daten in das entsprechende Format für jede Observability-Plattform (z.B. Konvertierung von Traces in das Zipkin-Protokoll). Diese Dynamik ermöglicht es dem Collector, dieselben Telemetriedaten an mehrere Backends zu senden, wodurch es einfacher wird, die Ziele zu ändern, ohne die Instrumentierungslogik des Codes zu ändern.

Die automatische Instrumentierung bietet Framework und Bibliotheken, die es Apps ermöglichen, automatisch Telemetriedaten mit minimalen oder no-code Änderungen zu generieren. Dieser Prozess vereinfacht die Instrumentierung für Entwickler, indem manuelle Codierungsaufgaben reduziert – und manchmal sogar eliminiert – werden.

Die automatische Instrumentierung bietet jedoch im Vergleich zur manuellen Instrumentierung möglicherweise weniger Kontrolle über bestimmte Arten der Datenerfassung. Der Umfang der automatischen Instrumentierung kann auch je nach Laufzeiten, Computerumgebungen und dem Grad der Unterstützung der Community für Observability-Frameworks variieren.

OpenTelemetry kombiniert APIs, SDKs, Collectors und automatische Instrumentierungsprozesse, um Daten abzurufen und an das Zielsystem zu senden.

Zunächst instrumentiert das DevOps-Team den Anwendungscode mit OTel-APIs und legt fest, welche Metriken, Traces und Protokolle auf welche Weise erfasst werden sollen. Der OTel SDK-Collector sammelt die Daten und bereitet sie für die Verarbeitung und den Export vor. Anschließend sampelt, filtert und korreliert er die Daten mit Abhängigkeiten und anderen Datenquellen.

Wenn die verarbeiteten Daten ordnungsgemäß formatiert sind, gruppiert das SDK sie in zeitbasierte Batches (in denen sie bei Bedarf stärker gefiltert werden) und sendet sie an das angegebene Backend-System.

Das Hauptziel von OpenTelemetry besteht darin, Telemetriedaten zu sammeln und zu exportieren und die Observability zu verbessern, um Unternehmen ein Tool an die Hand zu geben, das die Herstellerneutralität sowie die Plattform- und Tool-Integration bietet. Es hilft DevOps-Teams und Site Reliability Engineers (SREs), Anwendungen und Systeme zu verwalten und zu debuggen, sodass sie fundiertere Entscheidungen treffen und flexibel bleiben können, wenn sich die Geschäftsanforderungen ändern.

Zu den Vorteilen von OTel gehören:

• Implementierung einer konsistente Datenerfassung. OpenTelemetry ermöglicht es Teams, Telemetriedaten einheitlich über verschiedene Apps, Systeme und Anwendungsfälle hinweg zu erfassen.

• Vermeidung der Anbieterbindung. OTel ist eine herstellerneutrale Lösung, die es Entwicklern ermöglicht, Backend-Observability-Tools und -Anbieter auszutauschen, ohne wesentliche Änderungen am Instrumentierungscode vorzunehmen.

• Observability optimieren. OTel vereinfacht die Observability, indem Telemetriedaten gesammelt werden, ohne dass IT-Personal den Quellcode oder die Metadaten ändern muss. Außerdem können Entwickler eine Full-Stack-Visualisierung beibehalten, unabhängig von den verwendeten Observability-Backends oder Anbietern.

• Zukunftssichere IT-Ökosysteme. Da OpenTelemetry von einer Open Source-Community und der CNCF unterstützt wird, kann es sich mit den sich ändernden Anforderungen an Technologie und Observability weiterentwickeln. Zum Beispiel hat OTel kürzlich kontinuierliches Profiling zu seiner Gruppe primärer Telemetriesignale hinzugefügt.¹

• Tracking der Ressourcennutzung. OpenTelemetry kann Datenanfragen zwischen Servern erfassen, um die Ressourcennutzung nach Gruppen zu kategorisieren, sodass IT-Teams die Auslastung zwischen gemeinsam genutzten Systemen verfolgen können.

• Datenanfragen priorisieren. OpenTelemetry kann eine Prioritätspipeline für Datenanforderungen innerhalb der Architektur erstellen, so dass konkurrierende Anfragen das Netzwerk in der Reihenfolge ihrer Kritikalität durchlaufen.

• Erweiterung des Zugriffs auf Überwachungsdaten. Mit OTel können Entwickler Telemetriedaten überwachen und Benachrichtigungen von jedem Webbrowser oder Gerät aus erhalten, wodurch es einfacher ist, die Softwareleistung und den gesamten Systemzustand in Echtzeit zu verfolgen.