Was ist OpenTelemetry?

Telemetriedaten sind die Daten, die im Rahmen von Observability aus Systemquellen erfasst werden. Werden diese Daten gemeinsam analysiert, bieten sie einen Einblick in die Beziehungen und Abhängigkeiten innerhalb eines verteilten Systems. Es werden im Wesentlichen drei Datenkategorien verwendet, die oft als „die drei Säulen der Observability“ bezeichnet werden: Logs, Metriken und Traces.

• Logs: Ein Log ist eine in Textform vorliegende Aufzeichnung eines Events, das zu einem bestimmten Zeitpunkt stattgefunden hat. Sobald ein Code-Block ausgeführt wird, wird ein Logeintrag erstellt, der den Zeitpunkt des Auftretens des Events aufzeichnet und eine große Menge an Kontext über das Event bereitstellt. Logdaten kommen in drei Formaten: unformatierter Text (Plain Text), strukturiert und unstrukturiert. Unformatierter Text ist das gängigste Format, doch strukturierte Logs, die zusätzliche Metadaten enthalten und sich einfacher abfragen lassen, werden immer beliebter. Nicht strukturierte Logs sind dagegen schwieriger zu parsen. Logs sind in der Regel die Informationsquelle für die Abläufe in der Anwendung. Hier sehen Sie nach, wenn in einem System Probleme auftreten. Entwickler nutzen Logs, um Fehler in ihrem Code zu beheben und die Code-Ausführung zu überprüfen. Ein Fehler in einem verteilten System hat in der Regel mehrere Ursachen (manchmal auch „Kernursachen“ genannt). Logging liefert hier ausführliche Details zur Ausführung bestimmter Code-Blöcke.
• Metriken: Eine Metrik ist ein Zahlenwert, der über ein Zeitintervall gemessen wird. Er beinhaltet spezifische Attribute wie Zeitstempel, Name und Wert eines Events. Im Gegensatz zu Logs sind Metriken standardmäßig strukturiert und lassen sich daher leichter abfragen. Durch die Strukturierung sind sie auch für die Speicherung optimiert, sodass Sie mehr Metriken länger aufbewahren können und so einen besseren Überblick über historische Entwicklungen eines Systems haben. Metriken eignen sich am besten für große Datensets oder in regelmäßigen Intervallen erfasste Daten, um eine spezielle Frage zu beantworten. Meist werden über die Zeit aggregierte Metriken betrachtet, und das ist in unseren modernen Systemen wichtig, damit Probleme analysiert und darauf reagiert werden kann. Metriken liefern die Grundlage für Warnmeldungen – entweder als Aggregatwert oder einzelner Datenpunkt – und sind oftmals das erste Anzeichen für Probleme im System.
• Traces: Ein Trace zeichnet den vollständigen Weg einer Anfrage durch ein verteiltes System auf. Während sich eine einzelne Anfrage durch ein System bewegt, werden viele Operationen für sie durchgeführt. Jede Operation wird mit wichtigen Daten kodiert („Span“ genannt), zu denen Trace-ID, Span-ID, Name der Operation, ein Start- und Endzeitstempel, Logs, Events und andere indizierte Informationen gehören. Wenn Sie beim sogenannten verteilten Tracing ein Trace anzeigen, können Sie einen vollständigen Ausführungspfad nachverfolgen und feststellen, welcher Teil des Codes Probleme wie Fehler, Latenzen oder Ressourcenengpässe verursacht. Traces können auch Metriken erzeugen, und zwar insbesondere in Form sogenannter RED-Metriken (Rate, Error, Duration). Darüber hinaus liefern Traces wichtigen Kontext, damit festgestellt werden kann, welche Instanzen der anderen beiden Säulen für die Behebung eines bestimmten Problems die größte Relevanz haben.

Einzeln betrachtet dienen Logs, Metriken und Traces unterschiedlichen Zwecken, doch zusammen liefern sie die umfassenden und detaillierten Einblicke, die nötig sind, um verteilte Systeme zu verstehen und Fehler darin zu beheben.

OpenTelemetry wird dazu verwendet, Telemetriedaten aus verteilten Systemen zu erfassen, die dann für Troubleshooting, Debugging und das Verwalten von Anwendungen und ihrer Host-Umgebung eingesetzt werden. Es bietet IT- und Entwicklerteams eine einfache Möglichkeit, ihre Codebasis für die Datenerfassung zu instrumentieren und mit zunehmender Unternehmensgröße Anpassungen vorzunehmen.

OpenTelemetry erfasst verschiedene Kategorien von Telemetriedaten, einschließlich Logs, Metriken und Traces, und exportiert diese zur Verarbeitung in Backend-Plattformen. Die Analyse dieser Telemetriedaten ermöglicht es Teams, mehrschichtige Ökosysteme kohärenter zu gestalten. Dies macht es deutlich einfacher, das Verhalten der Systeme zu beobachten und Performance-Probleme zu beheben.

Das OpenTelemetry-Framework umfasst verschiedene Komponenten:

• Sprachenspezifische OpenTelemetry-APIs: Java, Python, JavaScript und mehr – für die Instrumentierung von Code für die Datenerfassung
• Exporter für die Übertragung von Telemetriedaten an die von Ihnen gewählte Observability-Plattform im Backend
• Sprachenspezifische OpenTelemetry-SDKs als Bindeglied zwischen den APIs und den Exportern
• The OpenTelemetry Collector als anbieterunabhängige Implementierung für Empfang, Verarbeitung und Export von Telemetriedaten

OpenTelemetry ist wichtig für DevOps, da die bereitgestellten Daten Warnmeldungen, das Troubleshooting und das Debugging von Anwendungen vereinfachen. Telemetriedaten wurden zwar schon immer verwendet, um das Systemverhalten zu verstehen, doch die allgemeine Netzwerkkomplexität macht das Erfassen und Analysieren von Tracing-Daten schwieriger. So kann das Nachverfolgen der Ursache eines einzigen Incidents mit herkömmlichen Methoden in diesen labyrinthartigen Systemen Stunden oder gar Tage dauern.

OpenTelemetry verbessert die Observability in diesen Systemen, indem es Traces, Logs und Metriken übergreifend aus Anwendungen und Services zusammenführt und korreliert. Darüber hinaus beseitigt das Open Source-Projekt Instrumentierungshindernisse, sodass Unternehmen sich ganz den absolut notwendigen Funktionen wie zum Beispiel Application Performance Monitoring (APM) widmen können. Letztendlich führt dies zu mehr Effizienz beim Erkennen und Beheben von Incidents, zuverlässigeren Services und weniger Downtime.

OpenTelemetry bietet verschiedene Vorteile. Die drei wichtigsten sind:

Konsistenz: Schon bevor es OpenTelemetry gab, wurden Telemetriedaten aus Anwendungen erfasst, es war allerdings deutlich schwieriger. Es war eine Herausforderung, die richtige Zusammenstellung von Instrumentierungen zu finden, und hatte man sich dann für eine bestimmte Lösung oder einen Anbieter entschieden, war man vertraglich daran gebunden. Zudem war es sehr unwahrscheinlich, dass die gewählte Lösung für alle Anwendungen konsistent war, was es fast unmöglich machte, sich einen Gesamteindruck von der Performance einer Anwendung zu verschaffen.

OpenTelemetry bietet dagegen einen konsistenten Pfad für die Erfassung von Telemetriedaten und ihre Übertragung an das Backend, bei dem die Instrumentierung nicht geändert werden muss und im Prinzip ein Standard für das Hinzufügen von Observability zu Cloud-nativen Apps geboten wird. Entwickler und IT können jetzt mehr Zeit auf die Erstellung neuer App-Funktionen aufwenden, da sie nicht mehr mit ihrer Instrumentierung kämpfen müssen.

Vereinfachte Wahl: Vor OpenTelemetry mussten Unternehmen zwischen OpenTracing und OpenCensus wählen, die jeweils einen anderen Ansatz zum Erreichen von Observability darstellen. Da OpenTelemetry den Code dieser beiden Frameworks zusammenführt, erhalten Sie das Beste aus den beiden Produkten in einer einzelnen Lösung. Außerdem gehen Sie beim Wechsel zu OpenTelemetry kein Risiko ein, wenn Sie zuvor bereits eines der beiden anderen Frameworks genutzt haben, da OpenTelemetry mit beiden rückwärts kompatibel ist.

Optimierte Observability: Mit OpenTelemetry können Entwickler Daten zur Anwendungsnutzung und -Performance von jedem Gerät oder Webbrowser aus einsehen. Diese praktische Oberfläche vereinfacht es, Observability-Daten in Echtzeit nachzuverfolgen und zu analysieren.

Der größte Vorteil besteht natürlich darin, die Observability zu realisieren, die zum Erreichen der Unternehmensziele notwendig ist. OpenTelemetry konsolidiert die Telemetriedaten, um festzustellen, ob die Systeme ordnungsgemäß funktionieren, um zu verstehen, wo Probleme die Leistung beeinträchtigen, und um die Ursachen zu beheben – und zwar möglichst bevor sie eine Service-Unterbrechung auslösen. All dies führt zu mehr Stabilität und Zuverlässigkeit innerhalb der Geschäftsprozesse.

OpenTelemetry kann gesammelte Daten in eine KI-Engine einspeisen, um automatisiert verwertbare Erkenntnisse zu generieren. Die KI-Engine kann beispielsweise ganz ohne menschliches Eingreifen von OpenTelemetry erfasste Daten zusammen mit anderen nützlichen, gefragten Daten kontinuierlich analysieren und im gesamten Stack nach Anomalien suchen. Die KI kann Milliarden von Abhängigkeiten innerhalb eines verteilten Systems in Sekundenbruchteilen erkennen und verarbeiten und dadurch verdeckte Aktivitäten aufspüren. Außerdem kann sie die Ursache von Problemen automatisch identifizieren und, wenn möglich bzw. gewünscht, beheben, bevor sich Auswirkungen für den Endbenutzer ergeben. Bei diesem kontinuierlichen Prozess lernt die KI, was der „Normalzustand“ des Systems ist, und kann ihre Antworten entsprechend anpassen, um die Performance mit der Zeit zu verbessern – auch im Hinblick auf die Fähigkeit, Probleme vor ihrem Auftreten zu prognostizieren.

Die Integration von künstlicher Intelligenz (KI) steigert im Grunde den Nutzen von OpenTelemetry, indem die KI den manuellen Aufwand reduziert, der bei der Nutzung von Observability für die Analyse von Bedingungen entstehen kann. Somit wird die Gewinnung verwertbarer Erkenntnisse erleichtert.

OpenTelemetry ist die Kombination aus den zwei sich überschneidenden Open Source-Projekten für verteiltesTracing, OpenTracing und OpenCensus, die in diesem Projekt zusammengeführt wurden.

Das von der Cloud Native Computing Foundation (CNCF) gehostete OpenTracing dient dem Zweck, eine standardisierte API für das Tracing bereitzustellen. Es ermöglicht Entwicklern unter anderem, Instrumentierungen in häufig verwendete Bibliotheken oder ihren eigenen Code einzubetten, ohne sich an einen bestimmten Anbieter zu binden. Zum Zeitpunkt seiner Einführung war dies ein einzigartiges Konzept. Obwohl OpenTracing Entwicklern zwar die dringend benötigte Flexibilität bot, gab es nur begrenzte Anwendungen und inkonsistente Implementierungen, da der Fokus ausschließlich auf Tracing lag.

Google entwickelte OpenCensus auf der Basis seiner internen Tracing-Plattform. Nach der Freigabe als Open Source-Projekt engagierten sich Microsoft und andere Anbieter und Förderer bei der Weiterentwicklung des Standards. OpenCensus umfasste eine Reihe mehrsprachiger Bibliotheken, die Metriken zum Anwendungsverhalten sammelten und diese Daten dann zur Unterstützung beim Debugging an die vom Entwickler gewählte Analyseplattform im Backend übertrugen. Außerdem konnte OpenCensus Meldungen, Anfragen und Services von ihrer Quelle bis zum Ziel verfolgen. Da es allerdings keine API für die Einbettung von OpenCensus in Code gab, mussten Entwickler für diese Aufgabe von der Community erstellte automatische Instrumentierungsagenten einsetzen.

OpenTelemetry entstand als sich die beiden Projekte darauf einigten, die Codebasen von OpenTracing und OpenCensus zusammenzulegen und damit die Stärken beider Projekte unter der Kontrolle der CNCF zusammenzuführen. OpenTelemetry (derzeit Beta) bietet eine Sammlung von APIs, Bibliotheken, Agenten und Datenkollektorservices für die Erfassung verteilter Anwendungs-Traces und -metriken (und bald auch Logs), die dann mit gängigen Observability-Tools analysiert werden können.

OpenTracing umfasst anbieterunabhängige API-Spezifikationen, Frameworks und Bibliotheken (die nicht Eigentum eines bestimmten Unternehmens sind), mit denen Entwickler problemlos Tracing in ihrer Codebasis instrumentieren können. OpenTracing erleichtert das verteilte Tracing, indem es Entwicklern einen Standardmechanismus bietet, mit dem sie ihren eigenen Code instrumentieren können, ohne an einen bestimmten Anbieter gebunden zu sein.

Distributed Tracing (manchmal auch Distributed Request Tracing genannt) ist eine Methode für das Monitoring von Anwendungen, die auf einer Microservices-Architektur aufsetzen. Programmierer verwenden Tracing zusammen mit anderen Logging-Methoden, um Informationen über das Verhalten einer Anwendung zu sammeln. Entwickler nutzen diese Informationen für das Debugging, und Systemadministratoren, der technische Support und andere verwenden sie für das Troubleshooting von Apps und Services.

Bei Observability wird der Zustand eines Systems anhand seiner Ausgabewerte gemessen. Der Begriff stammt aus der Systemesteuerungstheorie, bei der es um das Beschreiben und Verstehen selbstregelnder Systeme geht. Immer mehr Unternehmen setzen bei ihren verteilten Systemen auf Observability, um ihre Performance zu verstehen und zu verbessern. In diesem Kontext werden für Observability Telemetriedaten genutzt, um detaillierte Einblicke in diese Systeme zu erhalten und Teams Antworten auf vielfältige Fragen über das Systemverhalten zu liefern.

Aufgrund der großen Zahl ineinander greifender Elemente, die durch lose Kommunikationswege verknüpft sind, ist die Verwaltung verteilter Systeme nicht einfach. Außerdem treten dadurch bei diesen Systemen mehr und vielfältigere Fehler auf, und es ist schwierig, Probleme im aktuellen Zustand eines verteilten Systems zu verstehen, geschweige denn künftige Probleme zu prognostizieren. Im Prinzip produzieren verteilte Systeme mehr „unbekannte Unbekannte“ als einfachere Systeme. Da konventionelles Monitoring auf „bekannten Unbekannten“ basiert, lassen sich Probleme in solch komplexen Umgebungen damit nur schwer identifizieren.

Observability ist besser für diese Unvorhersehbarkeit geeignet. Sie ermöglicht eine bessere Kontrolle dieser komplexen, modernen Systeme und erleichtert es, ihr Verhalten zu verstehen. Teams können unterbrochene Verknüpfungen in einer komplexen Umgebung leichter erkennen und zu ihrem Ursprung zurückverfolgen. Außerdem ermöglicht Observability den Entwicklern auch, bei Systemfehlern einen explorativen Ansatz zu verfolgen, indem sie Fragen wie „Warum ist X defekt?“ oder „Was verursacht gerade die Latenz?“ stellen.

Um Observability zu erreichen, müssen Sie Ihr System und seine Apps auf die Erfassung der passenden Telemetriedaten vorbereiten. Sie können dafür eine kommerzielle Observability-Plattform kaufen, eine Open Source-Lösung nutzen oder ein eigenes Tool entwickeln. In jedem Fall beinhaltet Observability vier Komponenten:

• Instrumentierung: Messwerkzeuge erfassen Telemetriedaten von CPUs, Containern, Services, Anwendungen und anderen Komponenten Ihres Systems, die Daten generieren. Dadurch erhalten Sie Transparenz über Ihre gesamte Infrastruktur hinweg, wenn Sie neue Komponenten und Datentypen hinzufügen. Die automatische Instrumentierung ist für eine schnelle Implementierung ausschlaggebend.
• Datenkorrelation: Die aus Ihrem System gesammelten Telemetriedaten werden verarbeitet und korreliert. Dies liefert Kontext und ermöglicht eine automatische oder benutzerdefinierte Datenkuratierung für die Visualisierungen des Observability-Tools.
• Incident Response: Automatisierte Technologien leiten Daten über Ausfälle an die richtigen Personen und Teams weiter.
• AIOps: Machine Learning wird eingesetzt, um Incident-Daten automatisch zu aggregieren, zu korrelieren und zu priorisieren. So werden nicht relevante Warnmeldungen herausgefiltert, und Teams können Probleme erkennen und die Incident Response beschleunigen.

OpenTelemetry ist ein Mittel zum Erreichen von Observability. Unternehmen müssen Instrumentierungen zu ihrer Infrastruktur hinzufügen, um durchgängige End-to-End-Transparenz zu erreichen. Dies lässt sich mit einer einzelnen kommerziellen Lösung zwar nur schwer erreichen, doch OpenTelemetry standardisiert die für die Erfassung der Telemetriedaten notwendige Instrumentierung und ermöglicht damit Observability.

Das OpenTelemetry-Projekt befindet sich noch in der Anfangsphase. Es hat derzeit Beta-Status und unterstützt nur Traces und Metriken; hinsichtlich der Unterstützung von Logs gibt es erste Pläne. Projektteams arbeiten daran, die Kernkomponenten von OpenTelemetry zu stabilisieren, automatische Instrumentierung durch Agenten zu integrieren, Sprachkompatibilität hinzuzufügen und die Metrikfunktionen zu verbessern. Danach sollte die allgemeine Verfügbarkeit einer produktionsreifen Version erfolgen. OpenTelemetry ist eines der größten Open Source-Projekte der CNCF (neben Prometheus und Kubernetes) und es erhält beträchtliche Unterstützung aus der Technologie-Community. OpenTelemetry wird mit Sicherheit zum vorherrschenden Observability-Framework in der Cloud-nativen Telemetrielandschaft werden.

Verteilte Bereitstellungen reichen von kleinen Bereitstellungen für einzelne Abteilungen auf LANs bis hin zu riesigen weltweiten Bereitstellungen. Neben der Größe und der Komplexität insgesamt können Organisationen sich aufgrund der Größe und Kapazität ihres Computernetzwerks, der Datenmenge, um die es geht, der Häufigkeit ihrer Prozesse, ob sie geplant ausgeführt werden sollen oder ad hoc, der Anzahl der Benutzer, die auf das System zugreifen, der Kapazität ihres Rechenzentrums, der erforderlichen Datentreue und ihrer Verfügbarkeitsanforderungen für die für sie geeignete Bereitstellung entscheiden.

Auf der Grundlage dieser Überlegungen werden verteilte Bereitstellungen als Bereitstellungen für Abteilungen, kleine Unternehmen, mittelständische Unternehmen oder große Unternehmen kategorisiert. Auch wenn es keine offiziellen Taxonomien gibt, durch die sich abgrenzen lässt, was ein mittelständisches Unternehmen von einem großen Unternehmen trennt, so stellen diese Kategorien einen Ausgangspunkt für die Planung der benötigten Ressourcen für ein Distributed Computing-System dar. Verteilte Systeme lassen sich im Laufe der Zeit weiterentwickeln, wenn sie mit zunehmender Erweiterung des Unternehmens den Sprung auf das nächste Level schaffen.

Modernes Computing wäre ohne verteilte Systeme nicht möglich. Sie sind unverzichtbar für die Prozesse kabelloser Netzwerke, für Cloud-Computing-Dienste und für das Internet. Wenn es keine verteilten Systeme gäbe, würden auch diese Technologien nicht existieren.

Aber brauchen wir auch verteilte Systeme für unternehmensinterne Aufgaben, die nicht die Komplexität eines kompletten Telekommunikationsnetzwerks haben? In den meisten Fällen lautet die Antwort: ja. Verteilte Systeme bieten eine Skalierbarkeit und bessere Leistung, an die monolithische Systeme nicht heranreichen. Und da sie sich die Funktionen anderer Datenverarbeitungsgeräte und Prozesse zunutze machen, bieten verteilte Systeme Funktionen, die auf einem einzelnen System nicht oder nur schwer entwickelt werden könnten.

Dazu gehören Dinge wie z. B. eine externe Server- und Anwendungssicherung. Wenn der Master-Katalog die Segmente, die für eine Wiederherstellung benötigt werden, nicht sieht, kann er die anderen externen Knoten bitten, ihm die Segmente zu schicken. So gut wie alles, was Sie jetzt mit einem Computing-Gerät tun, profitiert von verteilten Systemen, ganz gleich, ob es darum geht, eine E-Mail zu versenden, ein Spiel zu spielen oder diesen Artikel im Internet zu lesen.

In den letzten zwanzig Jahren hat die Digitalisierung die Arbeitswelt verändert, und mobile Apps und Web-Apps sind wichtiger denn je.

Die Datenerfassung ist ein wichtiger Faktor für diese Cloud-nativen Anwendungen, doch viele Unternehmen sind nicht dafür ausgerüstet. Branchenübergreifend geben 57 % der Unternehmen an, dass das Datenvolumen schneller zunimmt als sie ihre Möglichkeiten zur Datenverwertung ausbauen können, und 47 % sind der Ansicht, dass ihr Unternehmen mit diesem rasanten Wachstum der Datenmenge nicht Schritt halten kann. Und während der Großteil zustimmt, dass Daten für den Gesamterfolg und die Innovationskraft unerlässlich sind, geben ganze zwei Drittel an, dass mindestens die Hälfte ihrer Daten Dark Data sind – das entspricht einem Anstieg um 10 Prozent gegenüber dem Vorjahr.

OpenTelemetry ist der Schlüssel, um Ihre Telemetrie in den Griff zu bekommen und die umfassende Transparenz zu schaffen, die Sie zur Verbesserung Ihrer Observability-Verfahren benötigen. Mit den Tools dieses Open Source-Projekts können Sie Daten aus Ihrem gesamten Technologie-Stack erfassen, ohne sich um Tool-spezifische Überlegungen kümmern zu müssen. Letztlich trägt OpenTelemetry dazu bei, eine gesunde Anwendungs-Performance zu erreichen und das Geschäftsergebnis deutlich zu verbessern.