OpenTelemetry (OTel) ist ein Observability-Framework und -Toolkit, das eine gemeinsame Sprache und ein gemeinsames Datenmodell bereitstellt und das zugrunde liegenden Propagierungsverhalten vereinheitlicht. Darüber hinaus ist OTel für die Verwaltung von Telemetriedaten wie Verlaufsdaten, Metriken und Protokollen konzipiert und ist Open Source-basiert, was größere Flexibilität ermöglicht.
OpenTelemetry ist das Ergebnis der Fusion zweier früherer Projekte: OpenTracing und OpenCensus. Beide Projekte wurden entwickelt, um dasselbe Problem zu lösen: fehlende Standards für das Programmieren und Senden von Telemetriedaten an Observability-Back-Ends. Doch keines der beiden Projekte war in der Lage, das Problem allein zu lösen. Daher wurden sie zu OpenTelemetry zusammengeführt, um ihre Stärken zu vereinen und einen einheitlichen Standard zu bieten.
OpenTelemetry ist anbieter- und toolunabhängig. Das bedeutet, dass es mit einer Vielzahl von Observability-Back-Ends verwendet werden kann, darunter Open Source-Tools wie Jaeger und Prometheus sowie kostenpflichtige Angebote. OTel ist ein Projekt der Cloud Native Computing Foundation (CNCF), das als leistungsstarke, portierbare und einfach zu instrumentierende Lösung für viele Sprachen entwickelt wurde. Es stellt einen einzigen Satz von APIs, Bibliotheken, Agents und Collector-Services bereit, um verteilte Ablaufverfolgungen und Metriken aus Ihrer Anwendung zu erfassen. OpenTelemetry ermöglicht echte Beobachtbarkeit (Observability)
„Observability“ ist ein Begriff, der in der Welt des Software-Engineerings und der Systemverwaltung große Aufmerksamkeit erlangt hat – fast so sehr, dass ein Teil seiner Bedeutung verloren geht: Heute verwenden viele IT-Mitarbeiter den Begriff lose, um jede Art von Systemtransparenz zu beschreiben. Aber was genau ist Observability, und wie unterscheidet sie sich vom herkömmlichen Monitoring?
Beim Monitoring wird der Systemstatus aktiv überprüft. Dabei werden in der Regel vordefinierte Schwellenwerte und Warnungen verwendet. Dieser Ansatz kann Ihre Aufmerksamkeit zwar auf die betroffenen Systeme lenken, wenn etwas schiefgeht. Doch Monitoring bietet oft keinerlei Einblicke in die Ursache des Problems oder die beste Lösung.
Observability hingegen ist ein umfassenderer Ansatz. Er beinhaltet die Fähigkeit, durch die Analyse externer Ausgaben zu verstehen, was innerhalb eines Systems passiert. Dank Observability können Sie jederzeit Fragen zu den Ereignissen stellen, ohne vorher definieren zu müssen, was Sie wissen möchten. Im Wesentlichen kann Monitoring Sie informieren, wenn ein Problem vorliegt, während Observability Ihnen hilft, zu verstehen, warum dieses Problem aufgetreten ist.
Es gibt drei Hauptpfeiler, die für Observability entscheidend sind:
- Traces
Ein Trace stellt die Journey einer Anfrage durch ein System dar und kann ein detailliertes Bild der Serviceinteraktionen bieten. OpenTelemetry-Traces sind in sogenannte Spans unterteilt, die Attribute und Events enthalten. Sie beschreiben die Arbeit, die über verschiedene Prozesse und Services hinweg ausgeführt wird, und fügen ihr Kontext hinzu. - Metriken
Metriken sind numerische Darstellungen von Daten, die über Zeitintervalle gemessen werden. Sie ermöglichen die kontinuierliche Überwachung der Leistung und des Verhaltens des Systems. In OpenTelemetry kann die Metrics API verwendet werden, um Systemmetriken aufzuzeichnen, festzulegen und hinzuzufügen. Sie bietet auch Tools für die spätere Filterung und aggregierte Analyse. - Protokolle
Protokolle sind textbasierte Datensätze, die von Systemen und Anwendungen generiert werden. Sie bieten eine chronologische Darstellung der Ereignisse und können für Debugging und das Verständnis des Systemverhaltens von entscheidender Bedeutung sein.
Diese drei Elemente gelten schon seit Langem als die wichtigsten Faktoren der Beobachtbarkeit. Doch aufgrund der zunehmenden Größe und Komplexität moderner verteilter Systeme war es notwendig, dieses traditionelle Modell weiterzuentwickeln. Es hat sich die Erkenntnis durchgesetzt, dass die drei Säulen nicht isoliert betrachtet werden dürfen, sondern dass sie grundlegend miteinander verbunden sind und koordiniert verwendet werden müssen.
OpenTelemetry spielt eine entscheidende Rolle bei der Überwachung in verteilten Microservices-basierten Systemen. Der Schwerpunkt liegt auf der Portierbarkeit, auf der Verfügbarkeit von Implementierungen sowie auf Software Development Kits (SDKs) in den meisten Sprachen, insbesondere bei den Exporter- und Collector-Modellen. Somit ist OpenTelemetry ein wichtiges Tool für die Erfassung und Verteilung von Daten, die für das System geeignet sind.
Mit OpenTelemetry können Teams effizient wichtige Trace- und Metrikdaten sammeln, die zur Analyse des Systemverhaltens erforderlich sind. Diese Ausrichtung an Observability-Praktiken ermöglicht ein tieferes Verständnis der Systemleistung und verbessert so die Fähigkeit, Probleme zu diagnostizieren und zu lösen.
Genauso wie Traces eine der drei Säulen der Observability darstellen, ist die Ablaufverfolgung (Tracing) ein wichtiges Verfahren in der Softwareentwicklung. Sie wird in der Regel verwendet, um mithilfe spezieller Debugging-Tools Profile für Anwendungscode zu erstellen und den Code zu analysieren. Im Kontext von OpenTelemetry hat Tracing jedoch eine andere Bedeutung: Hier bezieht es sich meist auf die verteilte Ablaufverfolgung, ein wichtiges Konzept in komplexen modernen Architekturen.
Bei der verteilten Ablaufverfolgung werden die Techniken der traditionellen Ablaufverfolgung auf moderne Microservices-basierte Anwendungen übertragen. Im Gegensatz zu monolithischen Anwendungen – bei denen für die Fehlerdiagnose oft schon die Ablaufverfolgung eines einzelnen Stacks ausreicht – sind verteilte Systeme für diesen Ansatz einfach zu komplex. Wenn eine Anwendung aus potenziell Tausenden von Services besteht, die auf zahlreichen Hosts ausgeführt werden, reichen die individuellen Ablaufverfolgungen nicht mehr aus. Die verteilte Ablaufverfolgung löst dieses Problem, indem sie Profile für Anfragen erstellt, die sich über verschiedene Servicegrenzen hinweg bewegen, und hochwertige Daten für Analysen generiert. Diese Methode bietet unter anderem folgende Funktionen:
- Anomalie-Erkennung
- Workload-Modellierung
- Stationäre Problemdiagnose
In OpenTelemetry ist eine Ablaufverfolgung („Trace“) eine Sammlung verknüpfter Bereiche („Spans“). Hierbei handelt es sich um benannte und zeitlich festgelegte Vorgänge, die eine Arbeitseinheit in einer Anfrage darstellen. Ein Span kann einem anderen Element untergeordnet sein oder ein sogenannter Root Span sein, der die End-to-End-Latenz der gesamten Ablaufverfolgung beschreibt. Untergeordnete Spans stellen untergeordnete Vorgänge innerhalb des Trace dar.
- Root Span
Der übergeordnete Punkt oder Startpunkt der Ablaufverfolgung, der die Latenzzeit der gesamten Anfrage darstellt. - Untergeordneter Span
Ein bestimmter Untervorgang innerhalb der Ablaufverfolgung.
Spans beinhalten wichtige Informationen, einschließlich des Namens des Vorgangs, der Start- und Endzeitstempel, Events und Attribute, die während des Span aufgetreten sind. Sie enthalten auch Links zu anderen Spans und zum Betriebsstatus.
Angesichts der Komplexität verteilter System-Ablaufverfolgungsdaten kann der Zugriff auf Kontext und andere relevante Details viele Vorteile für die Datenanalyse bieten. In OpenTelemetry werden diese Tags als Attribute und Events bezeichnet:
- Attribute
Schlüssel-Wert-Paare (in OpenTracing als „Tags“ bezeichnet), die einem Span hinzugefügt werden können, um die Analyse von Trace-Daten zu unterstützen. - Events
Mit Zeitstempel versehene Zeichenfolgen mit einem optionalen Satz von Attributen, die eine weitere Beschreibung bieten und eine detailliertere Analyse ermöglichen.
Spans werden in OpenTelemetry vom Tracer generiert, einem Objekt, das den aktuell aktiven Span verfolgt und die Erstellung neuer Spans ermöglicht. Propagator-Objekte unterstützen die Übertragung des Kontexts über Prozessgrenzen hinweg – ein wichtiger Aspekt der Ablaufverfolgung in verteilten Systemen. Der Tracer sendet abgeschlossene Spans an den SDK-Exporter von OTel, der die Spans zur weiteren Analyse an ein Back-End-System sendet.
Ablaufverfolgung bietet nicht nur detaillierte Einblicke in einzelne Anfragen und Vorgänge, sondern ist innerhalb von OpenTelemetry auch mit dem breiteren Kontext der Observability verknüpft, einschließlich Metriken. Durch die Verknüpfung von Trace-Daten mit relevanten Metriken können Unternehmen ein umfassendes Verständnis des Verhaltens und der Leistung des Systems erlangen.
Im Kontext von OpenTelemetry ist die Metrics API dafür ausgelegt, kontinuierlich Rohmessungen zu verarbeiten und zusammenzufassen. So erhalten Unternehmen mehr Einblicke in wichtige betriebliche Metriken, einschließlich Auslastung des Prozessspeichers, Fehlerraten und mehr. Metriken können zur Zusammenfassung und Aufzeichnung an verschiedene Geräte gesendet werden. Die OpenTelemetry Metrics API klassifiziert metrische Instrumente nach ihrer semantischen Bedeutung und nicht nach dem finalen Typ von Werten, den sie exportieren.
Die Metrics API stellt sechs unterschiedliche Metrikinstrumente bereit, von denen jedes eine bestimmte Funktion erfüllt. Diese Instrumente werden durch Aufrufe einer Meter API erstellt und definiert – dem Einstiegspunkt des Benutzers zum SDK. Metrikinstrumente sind entweder synchron oder asynchron.
Synchrone Instrumente werden innerhalb einer Anfrage aufgerufen und verfügen über einen zugeordneten verteilten Kontext. Zu den synchronen Instrumenten gehören:
- Counter
Das Zählerinstrument akzeptiert positive Werte mit der Funktion „Add()“. Das ist ideal für die Zählung von Daten, wie empfangene Bytes und abgeschlossene Anfragen, oder die Messung der Fehlerhäufigkeit und eignet sich besonders gut für Volumenmessungen. - UpDownCounter
Eine Erweiterung der Zählerfunktion, die sowohl positive als auch negative Inkremente über die Funktion „Add()“ verarbeitet. Dies ist nützlich für die Überwachung von Mengen wie aktiven Anfragen, genutztem Speicher und Warteschlangenlänge. - ValueRecorder
Das Instrument ValueRecorder erfasst Werte für einzelne Ereignisse mit der Funktion „Record()“. Diese wird verwendet, um Latenz, Anfragegröße und Warteschlangenlänge zu erfassen und dabei eine Verteilung von Werten hervorzuheben.
Im Gegensatz zu synchronen Instrumenten fehlt asynchronen Instrumenten ein zugehöriger Kontext. Diese Instrumente werden durch einen Callback gemeldet und nur einmal pro Erfassungsintervall aufgerufen. Zu den synchronen Instrumenten gehören:
- SumObserver
Das Instrument SumObserver nutzt die Funktion „See()“ für asynchrone monotone Summen und eignet sich am besten für Daten wie Cache-Fehlschläge und System-CPU. - UpDownSumObserver
UpDownSumObserver ist ein asynchroner, nicht monotoner Zähler, der positive und negative Summen mit der Funktion „See()“ akzeptiert. Dieses Gerät wird für Messungen verwendet, die Anstieg und Rückgang von Summen erfassen, z. B. die Größe des Prozess-Heap. - ValueObserver
Der ValueObserver schließlich bietet präzise Kontrolle über nicht additive Messungen mit der Funktion „Observe()“. Das ist ideal, wenn der Schwerpunkt der Messungen auf der Verteilung liegt.
Metrikereignisse, die von einem Instrument erfasst werden, bestehen aus einem Zeitstempel, einer Instrumentdefinition (Name, Art, Beschreibung, Maßeinheit), einem Beschriftungssatz (Schlüssel und Werte), einem Wert (Ganzzahl oder Gleitkommazahl), Ressourcen, die mit dem SDK verknüpft sind, sowie verteiltem Kontext (nur für synchrone Ereignisse). Die Vielfalt der verfügbaren Metrikinstrumente bietet Flexibilität bei der Erfassung verschiedener Datentypen und unterstützt die Analyse und Überwachung verschiedener Systemattribute.
Ob Fehlerraten, Latenz oder Ressourcennutzung – die Metrikinstrumente von OpenTelemetry bieten Entwicklern vielfältige Optionen, um wichtige Einblicke in ihre Anwendungen zu gewinnen.
Der Exporter ist für die Stapelverarbeitung und den Transport von Telemetriedaten an ein Back-End-System zwecks Analyse und Warnung verantwortlich. Das Exporter-Modell von OpenTelemetry unterstützt die Integration der Instrumentierung auf drei verschiedenen Ebenen:
- Integration auf Serviceebene
Dies beinhaltet die Deklaration einer Abhängigkeit vom relevanten OpenTelemetry-Paket in Ihrem Code sowie die entsprechende Bereitstellung. - Bibliotheksabhängigkeiten
Ähnlich wie die Integration auf Serviceebene, aber spezifisch für Bibliotheken, die in der Regel nur eine Abhängigkeit von der OpenTelemetry-API deklarieren. - Plattformabhängigkeiten
Hierbei handelt es sich um unabhängige Softwarekomponenten, die Ihren Service unterstützen, wie Envoy und Istio. Sie stellen ihre Kopie von OpenTelemetry bereit und geben Trace-Kontext aus, der für Ihren Service nützlich ist.
Die von OpenTelemetry-SDKs implementierte Exporter-Schnittstelle verwendet ein Plug-in-Modell, das Telemetriedaten in das für das jeweilige Back-End-System erforderliche Format übersetzt, bevor die Daten übertragen werden. Dieses Modell unterstützt auch die Zusammensetzung und Verkettung von Exportern, wodurch die Funktionen über verschiedene Protokolle hinweg gemeinsam genutzt werden können.
Ein wesentlicher Vorteil des OpenTelemetry-Ansatzes besteht darin, dass sich Exporter-Komponenten problemlos austauschen oder hinzufügen lassen. Darin unterscheidet er sich von OpenTracing, wo eine Änderung des Systems den Austausch der gesamten Tracer-Komponente erfordert.
Das Exporter-Modell bietet zwar viel Komfort, doch bestimmte organisatorische oder technische Einschränkungen können die einfache Neubereitstellung eines Service zum Hinzufügen eines neuen Exporters verhindern. Der OpenTelemetry-Collector dient als „Sammelbecken“ für Telemetriedaten aus mehreren Prozessen und exportiert sie in verschiedene Back-End-Systeme wie ServiceNow Cloud Observability, Jaeger oder Prometheus. Der Collector kann entweder als Agent neben einem Service oder als Remoteanwendung bereitgestellt werden:
- Agent
Wird mit Ihrem Service bereitgestellt und als separater Prozess oder Sidecar ausgeführt. - Remote-Collector
Wird separat in einem Container oder einer virtuellen Maschine bereitgestellt, empfängt Telemetriedaten von jedem Agent und exportiert sie in Back-End-Systeme.
OpenTelemetry besteht aus den folgenden Hauptkomponenten:
- Eine Spezifikation für alle Komponenten
- Ein Standard-Protokoll, das das Format von Telemetriedaten definiert
- Semantische Konventionen, die ein Standardbenennungsschema für gängige Telemetriedatentypen definieren
- APIs, die definieren, wie Telemetriedaten generiert werden
- Ein Bibliotheksökosystem, das Instrumentierung für gängige Bibliotheken und Frameworks implementiert
- Automatische Instrumentierungskomponenten, die Telemetriedaten generieren, ohne dass Codeänderungen erforderlich sind
- Sprach-SDKs, die die Spezifikation, die APIs und den Export von Telemetriedaten implementieren
- Der OpenTelemetry-Collector, ein Proxy, der Telemetriedaten empfängt, verarbeitet und exportiert
- Verschiedene andere Tools, z. B. OpenTelemetry Operator for Kubernetes
OpenTelemetry ist mit einer Vielzahl von Open Source-Ökosystemintegrationen kompatibel und wird auch von einer Vielzahl von Anbietern unterstützt, von denen viele kommerziellen Unterstützung für OpenTelemetry bieten und direkt am Projekt mitwirken.
OpenTelemetry ist erweiterbar. Hier einige Beispiele dafür, wie der Ansatz erweitert werden kann:
- Empfänger zum OpenTelemetry-Collector hinzufügen, um Telemetriedaten aus einer benutzerdefinierten Quelle zu unterstützen
- Benutzerdefinierte Instrumentierung in ein SDK laden
- Verteilung eines SDK oder Collector erstellen, die auf einen bestimmten Anwendungsfall zugeschnitten ist
- Einen neuen Exporter für ein benutzerdefiniertes Back-End erstellen, das das OpenTelemetry Protocol (OTLP) noch nicht unterstützt
- Einen benutzerdefinierten Propagator für ein nicht standardmäßiges Format für Kontextverbreitung erstellen
Die meisten Benutzer müssen OpenTelemetry zwar nicht erweitern, das Projekt ist aber so konzipiert, dass die Erweiterung auf fast allen Ebenen möglich ist.
Mit dem Aufkommen von Cloud-Computing, Microservices-Architekturen und immer komplexeren Geschäftsanforderungen ist Beobachtbarkeit wichtiger denn je.
Um ein System beobachtbar zu machen, muss es instrumentiert werden. Das heißt, der Code muss Traces, Metriken und Protokolle ausgeben. Die instrumentierten Daten müssen dann an ein Observability-Back-End gesendet werden.
OpenTelemetry erfüllt zwei wichtige Aufgaben:
- Es ermöglicht Ihnen, die Daten zu besitzen, die Sie generieren, anstatt sich mit einem proprietären Datenformat oder Tool herumschlagen zu müssen.
- Sie müssen nur einen einzigen Satz von APIs und Konventionen erlernen.
Diese beiden Faktoren bieten Teams und Unternehmen die Flexibilität, die sie in der modernen Computing-Welt benötigen.
OpenTelemetry ist kein Observability-Back-End wie Jaeger, Prometheus oder andere kommerzielle Anbieter. Der Schwerpunkt von OpenTelemetry liegt auf der Generierung, der Erfassung, der Verwaltung und dem Export von Telemetriedaten. Die Speicherung und Visualisierung dieser Daten wird absichtlich anderen Tools überlassen.
End-to-End-Transparenz ist wichtiger denn je. OpenTelemetry bietet einen standardisierten Ansatz für die Erfassung von Telemetriedaten über verschiedene Anwendungen und Programmiersprachen hinweg. Durch umfassende Einblicke in das Systemverhalten können Unternehmen die Leistung optimieren, Probleme beheben und eine nahtlose Benutzer-Experience bieten. Doch wenn es um die Beobachtbarkeit geht, gibt es immer Raum für Verbesserungen.
ServiceNow Cloud Observability, früher als Lightstep bekannt, unterstützt OpenTelemetry als Methode, um Telemetriedaten (Traces, Protokolle und Metriken) zu erhalten, wenn Anfragen durch Services und andere Infrastrukturen geleitet werden. Cloud Observability erfasst OpenTelemetry-Daten über das native OpenTelemetry Protocol (OTLP). OTLP-Daten können dann über HTTP oder gRPC in Cloud Observability exportiert werden.
Um Observability und Governance in cloudnativen Umgebungen weiter zu verbessern, hat ServiceNow auch den Service Graph-Connector für OpenTelemetry (SGC) eingeführt. Mithilfe von OpenTelemetry-Daten und dem ServiceNow Cloud Observability-Back-End revolutioniert diese Lösung die Art und Weise, wie Unternehmen Einblicke in ihre cloudnativen Anwendungen und die Kubernetes-Infrastruktur erhalten. SGC erkennt und ordnet Serviceabhängigkeiten automatisch zu und erstellt so eine genaue und aktuelle Servicetopologie. Mit dieser Lösung können Unternehmen die Auswirkungen von Änderungen bewerten, das Incident-Management optimieren und die funktionsübergreifende Zusammenarbeit fördern. So steigert die Lösung die Effizienz, reduziert Risiken und sorgt für bestmögliche Observability in komplexen IT-Umgebungen.
Erleben Sie die revolutionären Funktionen des Service Graph-Connector für OpenTelemetry. Kontaktieren Sie ServiceNow noch heute.