Was sind OpenTelemetry-Metriken?

Genau wie OpenTelemetry-Logs und -Traces liefern auch OTel-Metriken standardisierte Telemetriesignale, die ein gemeinsames, sprachneutrales Datenmodell und Übertragungsprotokoll nutzen – genauer gesagt das OpenTelemetry Protocol (OTLP) –, um Daten aus verschiedenen Quellen, Systemen und Formaten zu erfassen und an Observability-Backends zu senden.

OTel-Metriken nutzen die OpenTelemetry-Instrumentierung, um Zeitreihendaten – wie beispielsweise CPU- und Speicherauslastung, Durchsatz, Fehlerraten, Anzahl der Anfragen und Antwortzeiten – von Anwendungen und Infrastrukturkomponenten während ihrer Ausführung zu erfassen. Nachdem Entwickler ihren Code so instrumentiert haben, dass die erforderlichen Metriken erfasst werden, ermöglicht OTel die Aggregation dieser Metriken und deren Export in ein beliebiges (oder jedes) Backend-Observability-Tool zur Speicherung, Abfrage und Visualisierung – und das alles, ohne die Instrumentierung ändern zu müssen.

Metriken sind in der Regel die ersten Telemetriesignale, die auf ein Systemproblem hinweisen. Im OTel-Framework werden sie mit Protokollen (unveränderlichen Aufzeichnungen einzelner Systemereignisse) und Traces (dem End-to-End-Verlauf einer Datenanfrage) integriert, die auf denselben Konzepten und Metadaten basieren.

Diese Dynamik ermöglicht es Entwicklern und Site Reliability Engineers (SREs), Metriken als übergreifendes Frühwarnsystem zu nutzen. Sie können den gesamten Verlauf eines Ausfalls (einschließlich der Metriken für jeden Dienst, mit dem die ausgefallene Komponente interagiert hat) in einer einheitlichen Ansicht verfolgen und schnell auf Traces und Protokolle zugreifen, um eine Ursachenanalyse durchzuführen.

In der Praxis bedeutet dies, dass IT-Teams mit nur wenigen Klicks von der Feststellung „Dieser Endpunkt ist langsam“ zu der Erkenntnis gelangen können, dass „diese konkreten Anfragen und Abhängigkeiten das Problem darstellen“.

Darüber hinaus ermöglichen die Standardisierungsprotokolle von OTel eine automatisierte Signalkorrelation zwischen verschiedenen Anbietern von Observability-Lösungen, wodurch Unternehmen die Flexibilität erhalten, jederzeit zwischen verschiedenen Observability-Tools zu wechseln oder mehrere Tools gleichzeitig zu nutzen.

OpenTelemetry-Metriken sind ein grundlegender Bestandteil von OpenTelemetry. OpenTelemetry ist ein Open-Source-Framework für Observability, das eine Sammlung von Software Development Kits (SDKs), herstellerneutrale Programmierschnittstelle (APIs) sowie weitere Tools zur Instrumentierung von Anwendungen, Systemen und Geräten umfasst.

Der verwendete Instrumentierungscode war früher sehr unterschiedlich, und kein einziger kommerzieller Anbieter bot ein Tool an, mit dem sich Daten aus allen Anwendungen 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.

Angenommen, ein Entwicklungsteam möchte die Backend-Tools austauschen. Dann müsste es seinen Code komplett neu instrumentieren und neue Agenten (Softwarekomponenten, die automatisierte Build- und Release-Aufgaben ausführen) so konfigurieren, dass sie Telemetriedaten an die neuen Server senden. Fragmentierte Ansätze führten zu Datensilos und Verwirrung, was eine effektive Behebung von Leistungsproblemen erschwerte.

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 bot eine Open-Source-Lösung – basierend auf von der Community entwickelten Standards – zur Erfassung von Daten über das Systemverhalten und die Sicherheit und half Teams dabei, die Überwachung und Observability in verteilten Ökosystemen zu optimieren.

OpenTelemetry-Metriken basieren auf einer Gruppe miteinander verbundener Komponenten, die gemeinsam festlegen, wie Metriken erzeugt, beschrieben und an Observability-Backends übermittelt werden. Dazu gehören:

Instrumente sind die Tools, mit denen der Code Metriken erfasst. Sie erfassen Werte auf zwei Arten: synchron (direkt im Ausführungsablauf, während der Code ausgeführt wird) und asynchron (immer dann, wenn das SDK Werte vom Code anfordert).

Da sie parallel zur Operation ausgeführt werden, können synchrone Instrumente den aktuellen Trace-Kontext und Attribute zum Ereignis erfassen, wodurch sich die von ihnen gesammelten Metriken leichter mit Protokollen und Traces in Beziehung setzen lassen.

Asynchrone Instrumente werden durch Pull-basierte Callback-Funktionen aktualisiert, die das SDK in einem vorgegebenen Erfassungsintervall aufruft. Diese Instrumente eignen sich zur Erfassung von Werten, die nicht bei jeder Benutzeranforderung, sondern in regelmäßigen Abständen erfasst werden (beispielsweise CPU-Auslastung oder Speicherbelegung). 

Die OTel-Instrumentierung befindet sich zwischen der Anwendungslogik und der Metrik-Pipeline und wandelt Ereignisse wie „HTTP-Anfrage abgeschlossen“ in strukturierte Messwerte um, die das SDK aggregieren und exportieren kann. Jeder Metrik-Instrumenttyp ist für ein bestimmtes Messmuster optimiert und verfügt über eine zugehörige Aggregationsstrategie, die beschreibt, wie das SDK einzelne Messwerte zu exportierten Metriken zusammenfassen soll.

Gängige Instrumententypen :

• Zähler sind synchrone Instrumente, die Inkremente erfassen, die sich im Laufe der Zeit erhöhen (wie beispielsweise die Gesamtzahl der Anfragen oder die Gesamtzahl der seit dem Start des Prozesses gesendeten Bytes). Zähler verhalten sich zudem monoton. Jedes Mal, wenn sie einen neuen Messwert erfassen, addieren sie diesen zum bestehenden Wert, anstatt den bestehenden Wert zu ersetzen.

• UpDown-Zähler sind synchrone Instrumente, die Werte erfassen, die sich im Laufe der Zeit erhöhen oder verringern können (beispielsweise die Anzahl aktiver Benutzer oder die Größe einer Warteschlange). Im Gegensatz zu Standardzählern sind UpDown-Zähler nicht monoton, d. h., sie passen die Gesamtwerte nach oben oder unten an, indem sie bestehende Werte ersetzen.

• Asynchrone Zähler und asynchrone Aufwärts-/Abwärts-Zähler ähneln ihren synchronen Gegenstücken, erfassen ihre Werte jedoch einmal pro Export, anstatt sie während der Codeausführung zu sammeln.

• Messgeräte sind synchrone Instrumente, die Werte aufzeichnen, die bei jeder Datenübermittlung beliebig ansteigen oder abfallen können und die Werte in dem Moment darstellen, in dem sie vom Code erfasst werden. Neben synchronen Messgeräten erfordert die Erfassung von Metriken sogenannte „Observable Gauges“ – asynchrone Instrumente, die aktuelle Werte abrufen, sobald das Metrik-Backend Daten erfasst.
  
  Messgeräte erfassen Momentaufnahmen von Werten auf ähnliche Weise, wie Kameras Momentaufnahmen ihres beabsichtigten Motivs aufnehmen. Und da Messgeräte nicht kumulativ sind, werden sie in der Regel auf nicht additive Werte angewendet, bei denen eine Summierung keinen Sinn ergeben würde (beispielsweise Speicherauslastung oder Temperatur).  

• Histogramme sind synchrone Instrumente, die erfassen, wie viele Messwerte in verschiedene Wertebereiche fallen, anstatt einen einzelnen Wert (wie beispielsweise eine Gesamtsumme oder einen aktuellen Wert) zu verfolgen. Sie ordnen die Werte „Buckets“ zu, wodurch IT-Teams Perzentile berechnen und die Werteverteilung für Metriken wie die Anfragedauer, die Latenz und die Nutzdatengröße nachvollziehen können.

OTel definiert ein standardisiertes Datenmodell für Metriken sowie Zeitreihen, das einzelne Metrikereignisse in saubere, abfragbare, zeitbasierte Zahlenreihen umwandelt, die IT-Teams in Observability-Plattformen speichern und analysieren können.

OpenTelemetry beschreibt Metriken anhand von drei miteinander verbundenen Modellen: dem Ereignismodell (Rohmesswerte von Instrumenten), dem OTLP-Stream-Modell (wie diese Messwerte gebündelt und gesendet werden) und dem Zeitreihenmodell (wie Backends sie speichern).

In der Praxis erfasst der Anwendungscode Ereignisse mithilfe des Ereignis-Modells, das SDK/der Collector wandelt diese in OTLP-Streams um, und die Backend-Plattform speichert sie als Zeitreihen, beispielsweise „Anfragen pro Sekunde für Dienst X mit dem Status 200“ im Zeitverlauf.

Semantische Konventionen – auch als Namenskonventionen bezeichnet – legen standardisierte Bezeichnungen, Einheiten und Attributschlüssel für gängige Metriken fest, damit verschiedene Dienste und Bibliotheken konsistente Telemetriedaten liefern. Beispielsweise schreiben Konventionen Bezeichnungen wie „http.server.duration“ für die Latenz von HTTP-Serveranfragen vor und empfehlen Einheiten wie Sekunden oder Millisekunden für die Dauer.

Die Verwendung der semantischen Konventionen von OTel ermöglicht es Teams, Metriken in vorgefertigte Dashboards und Alert-Systeme einzubinden, die ein bestimmtes Schema erwarten, wodurch sich der Zeitaufwand für individuelle Konfigurationsarbeiten verringert. Zudem wird die teamübergreifende Zusammenarbeit erleichtert, da alle Beteiligten über Microserviceshinweg dieselbe „Metriken-Sprache“ sprechen.

Darüber hinaus können Funktionen zur Kontextweitergabe Metriken mit zugehörigen Traces (mithilfe von Exemplaren) und Protokollen verknüpfen, indem sie gemeinsamen Kontext – wie beispielsweise Trace- oder Span-Identifikatoren – über Servicegrenzen hinweg übertragen.

Beispielsweise kann ein OTel-Propagator den eingehenden Kontext aus einem Request-Handler extrahieren, damit eine Trace-Span starten und denselben Kontext verwenden, um Metriken aufzuzeichnen und Protokolleinträge zu schreiben. Auf diese Weise werden sowohl der Metrikpunkt als auch die Protokollzeile mit dem aktuellen Trace versehen.

Wenn der Anwendungscode einen nachgelagerten Aufruf tätigt, fügt der Propagator denselben Kontext in die ausgehende Anfrage ein. Der Code extrahiert diesen, startet eine eigene untergeordnete Trace-Span und nutzt diesen Kontext für seine eigenen Metriken und Protokolle, wodurch alle Daten beider Dienste mit derselben End-to-End-Trace verknüpft bleiben.

Attribute – auch als Labels, Tags oder Dimensionen bezeichnet – sind Schlüssel-Wert-Paare, die einzelnen Messwerten oder aggregierten Datenpunkten zugeordnet sind. Sie definieren eine Zeitreihe neben dem Namen der Metrik, dem Typ der Aggregation und der Einheit vollständig oder teilweise. Ohne Attribute würden alle Messwerte einer Metrik zu einer einzigen, undifferenzierten Reihe verschmelzen.

Durch das Hinzufügen von Attributen (wie z. B. Servicename, Endpunkt, HTTP-Statuscode, Region oder Tenant-ID) werden einfache Metriken zu dimensionalen, spezialisierten Metrikströmen, die Teams in Observability-Tools nach Belieben aufschlüsseln und analysieren können. Teams erhalten hochauflösende Ansichten, die nach beliebigen Dimensionen gefiltert oder gruppiert werden können.

Ein gutes Attributdesign sorgt zudem für ein Gleichgewicht zwischen Detailgenauigkeit und der Kardinalität der Metriken (der Anzahl der eindeutigen Werte, die ein Attribut annehmen kann), sodass Teams eine „Label-Explosion“ vermeiden können und dennoch nützliche Abfragen durchführen können.

Eine Messung ist ein einzelner, auf Ereignisebene erfasster Messwert, der von einem Messgerät zu einem bestimmten Zeitpunkt erfasst wird und häufig mit Attributen versehen ist. Wenn beispielsweise eine HTTP-Anfrage abgeschlossen ist, könnten Sie eine Latenz von 120 Millisekunden erfassen, zusammen mit Attributen wie route=”/login” und status_code=200, die die Route und den Statuscode angeben.

Jede einzelne Aufzeichnung ist eine eigenständige Messung, die beschreibt, was während dieses einen Vorgangs geschehen ist.

Die Messwerte werden vorübergehend im SDK gespeichert, das die Rohdaten anschließend in Datenpunkte innerhalb größerer Metriken umwandelt. Anstatt jede einzelne Anfrage anzuzeigen, könnte ein aggregierter Datenpunkt beispielsweise lauten: „Für de Pfad /login mit dem Status 200 gab es im Zeitraum von 10:00:00 bis 10:00:10 500 Anfragen mit einer Gesamtdauer von 25 Sekunden.“ Es sind diese Datenpunkte, die schließlich in Observability-Backends exportiert und dort gespeichert werden.

Die OpenTelemetry-Metrik-API ist eine Sammlung von Schnittstellen, die vom Anwendungscode aufgerufen werden, um Metriken zu generieren. Sie ist herstellerunabhängig konzipiert und entkoppelt die Instrumentierung von der konkreten SDK-Implementierung. IT-Teams können die Instrumentierung einmalig (unter Verwendung der Standard-API) programmieren und anschließend SDKs, Exporter und Backends austauschen, ohne zusätzliche Schritte durchführen zu müssen.

Drei zentrale Schnittstellen bilden die Struktur der OTel-Metrik-API: Meter-Provider, Meter und Metrik-Instrumente.

Meter-Provider bilden den Einstiegspunkt der API und sind für die Erstellung von Meter-Instanzen zuständig. Sie legen fest, welche Metrik-Zähler und -Exporteure verwendet werden sollen, welche Ansichten und Aggregationen angewendet werden sollen und wie oft Daten erfasst und exportiert werden sollen. Der Meter-Provider wird in der Regel einmalig beim Start der Anwendung geladen (häufig als globaler Provider), sodass alle Meter und Instrumente einheitliche Ressourcendefinitionen und Exportpipelines nutzen.

Meter sind die Objekte, die der Anwendungscode zur Erstellung von Zählern, Histogrammen und Anzeigen verwendet. Jeder Meter wird in der Regel nach einer Bibliothek oder einem Dienst benannt (beispielsweise „bank.payment“), sodass die aus diesem Code stammenden Metriken einheitlich gruppiert und identifiziert werden können.

Meter speichern selbst keine Daten, sondern dienen sie als „Fabriken“ für Instrumente und leiten die aufgezeichneten Messwerte zur Aggregation und zum Export an das zugrunde liegende SDK weiter. Da Meter von einem Meter-Anbieter bezogen werden, arbeiten sie stets mit den vom Anbieter definierten Konfigurationen, Ansichten und Exportern.

Instrumente liefern dann Anweisungen, damit der Code Messwerte mit Attributen melden kann.

Das OpenTelemetry-SDK ist eine konkrete Implementierung der OpenTelemetry-API, die API-Aufrufe in tatsächliche Telemetriedatenpunkte umwandelt. Es stellt eine sprachspezifische Bibliothek (z. B. für Java oder Python) bereit, die Metrikdaten erfasst, aggregiert und für den Export aufbereitet.

SDKs verwalten den Instrumentierungslebenszyklus, übernehmen die Speicherung von Messwerten im Arbeitsspeicher, führen Callbacks für asynchrone Instrumentierungen aus, wenden konfigurierte Aggregationen und Ansichten an und steuern die Intervalle der Erfassung von Metriken (in der Regel 10–60 Sekunden).

Innerhalb des SDKs wenden Prozessoren Aggregationen und zusätzliche Logik an, darunter Filterung, Ratenbegrenzung oder die Transformation von Metrikströmen, bevor diese weitergeleitet werden.

Exporters wandeln verarbeitete Metriken in backend-spezifische Formate um und senden sie unter Verwendung unterstützter Protokolle (wie beispielsweise OTLP) an externe Backends oder Observability-Plattformen.

Teams können im SDK mehrere Exporter miteinander verketten, um in Umgebungen, die hohe Verfügbarkeit und Redundanz erfordern, die Unterstützung mehrerer Backends zu gewährleisten. In diesen Fällen fungieren OpenTelemetry-Collectors als intelligente Proxys, die Metriken gleichzeitig an mehrere Backends senden, Exportversuche wiederholen oder Daten in großem Maßstab authentifizieren können. 

Aggregationen definieren, wie einzelne Rohmesswerte mathematisch zu zusammengefassten Statistiken kombiniert werden, die von den Backend-Systemen als Zeitreihendatenpunkte gespeichert und abgefragt werden. Die Rohdaten werden vom Aggregator des SDK für jede einzelne Zeitreihe zu einem einzigen Datenpunkt pro Erfassungsintervall zusammengefasst.

Zu den gängigen Aggregationsmustern gehören:

• Sum, das alle Werte für kumulative Größen (wie beispielsweise die übertragene Byteanzahl) addiert.

• LastValue, das nur den aktuellsten Messwert beibehält und frühere Werte verworfen werden.

• Histogramm-Aggregation, bei der Werte in Klassen zusammengefasst werden, damit Teams Perzentile berechnen und Ausreißer erkennen können.

• Drop, wodurch alle Werte verworfen werden, um Daten mit hoher Kardinalität (Daten mit einer hohen Anzahl eindeutiger Werte) zu vermeiden.

Aggregationen enthalten zudem Metadaten zur Zeitlichkeit, die den Backends mitteilen, wie ein Wert einer Metrik im Zeitverlauf zu interpretieren ist. Die beiden Haupttypen sind:

• Die kumulierten Werte geben die Gesamtsumme seit Prozessbeginn wieder. Diese Werte werden erst bei einem Neustart des Prozesses zurückgesetzt, und die Backends berechnen die Raten durch Differenzbildung der Datenpunkte.

• Die Delta-Werte spiegeln die Veränderungen seit der letzten Datenerhebung wider. Backends können die Deltas direkt summieren, um die Raten zu ermitteln.

SDKs wenden je nach Instrumententyp automatisch die richtige Aggregation an. Außerdem ermöglichen sie es IT-Teams, von einfachen Summen zu detaillierten Histogrammen oder anderen Algorithmen zu wechseln, ohne die Instrumentierung zu verändern.

Metriken zeigen Trends auf und lösen Alerts aus, Traces geben Aufschluss über den Verlauf von Anfragen, und Protokolle liefern umfassende Informationen auf Ereignisebene. Durch die Korrelation von Metriken mit Traces und Protokollen werden die drei wichtigsten Observability-Signale (die sogenannten „Säulen der Observability“) miteinander verknüpft, sodass Teams einen mehrschichtigen Überblick über das Systemverhalten erhalten.

Metriken können beispielsweise aggregierte Trends wie „Die Fehlerrate stieg um 14:15 Uhr sprunghaft an“ anzeigen, sie können jedoch nicht aufzeigen, welche Anfragen fehlgeschlagen sind oder warum. Traces geben Aufschluss über problematische einzelne Anfragepfade über Dienste hinweg, doch ohne Metriken können sie den Teams nicht dabei helfen, festzustellen, ob es sich bei einer fehlerhaften Anfrage um einen Ausreißer oder um ein systemisches Problem handelt. Protokolle liefern detaillierte Fehlermeldungen und Ereignisse, doch ohne Kontext sind sie lediglich Rauschen.

Durch die Verknüpfung aller drei Signale können IT-Teams innerhalb von Sekunden nahtlos von übergeordneten Metriken zu den betroffenen Traces und den zugehörigen Protokollen wechseln.

OTel-Metriken unterscheiden sich grundlegend von herkömmlichen Metriken. Herkömmliche Metriken beziehen sich in der Regel auf veraltete Überwachungsansätze, die sich auf einfache, vordefinierte Zähler zur Ressourcenauslastung konzentrieren. Diese Metriken legen den Schwerpunkt auf Messungen auf Host-Ebene oder anwendungsspezifische Messungen. 

OpenTelemetry-Metriken hingegen sind Teil eines einheitlichen, herstellerunabhängigen Observability-Frameworks, das die Erfassung von Traces, Protokollen und Metriken in verteilten IT-Umgebungen standardisiert. Sie bauen auf herkömmlichen Metriken auf und bieten ein flexibleres Datenmodell sowie eine flexiblere Instrumentierung, darunter UpDownCounters für bidirektionale Änderungen und Histogramme, die exponentielle Buckets unterstützen. Zudem stellen sie explizite Attribute, Einheiten und Zeitstempel bereit, um Metriken anzureichern.

OTel-Metriken unterscheiden sich zudem hinsichtlich ihrer Konzeption, der Erhebungsmethoden und ihrer Anwendbarkeit auf moderne Systeme von herkömmlichen Metriken.

Herkömmliche Metriken basieren auf einem starren Full-Stack-Modell, bei dem Erfassung, Speicherung und Abfrage eng miteinander verknüpft sind. Dabei werden häufig ausschließlich kumulierte Werte aus einfachen Zählern, Messanzeigen, Zusammenfassungen und Histogrammen mit expliziten Buckets verwendet (was eine manuelle Einteilung in Buckets erfordert).

OpenTelemetry-Metriken verwenden ein modulares, dreischichtiges Design – bestehend aus einer API, einem SDK und einem Protokoll –, das die Signalerzeugung von der Verarbeitung und dem Export trennt. Diese Konfiguration ermöglicht es OTel-Metriken, erweiterte Funktionen zu unterstützen, wie beispielsweise Delta-Temporalität, ganzzahlige Werte, Minimal- und Maximalwerte in Metadaten von Histogrammen sowie exponentielle Histogramme für die dynamische Skalierung.

Herkömmliche Ansätze basieren auf einem Pull-basierten Data-Scraping über öffentlich zugängliche API-Endpunkte, vor allem für isolierte Metriken. Sie nutzen manuelle Instrumentierung und bieten nur begrenzte Unterstützung für Traces oder Protokolle, was fragmentierte Telemetrie- und Observability-Pipelines verursacht.

OpenTelemetry nutzt OTLP (ein binäres Protokoll) für die Push-basierte Datenerfassung und ermöglicht so die einheitliche Erfassung von Traces, Metriken und Protokollen durch automatische und manuelle Instrumentierung. OTel stellt zudem einen Collector bereit, der die Datenkonvertierung, die Bündelung und die Weiterleitung an Backend-Tools erleichtert, wodurch IT-Teams Probleme im Zusammenhang mit der Speicherung von Anwendungsdaten besser bewältigen können.

Herkömmliche Telemetriedaten eignen sich gut für einfache, monolithische Systemkonfigurationen. In Microservice-Umgebungen stoßen sie jedoch an ihre Grenzen – aufgrund unzureichender Tracing-Fähigkeiten, Problemen mit der Herstellerabhängigkeit und isolierten Signalen, die Abhängigkeiten verschleiern und kaskadierende Ausfälle nicht aufdecken.

OpenTelemetry zeichnet sich besonders in cloudnativen, verteilten Umgebungen aus, da es korrelierte, herstellerunabhängige Telemetriedaten bereitstellt, die einen durchgängigen Einblick in den Ablauf von Anfragen über verschiedene Dienste hinweg, in Latenzengpässe sowie in die Ressourcendiagnostik ermöglichen. OTel unterstützt zudem Sampling und die Integration hybrider Tools, wodurch Telemetrie und Instrumentierung gemeinsam mit der IT-Umgebung skaliert werden können. 

OpenTelemetry-Metriken liefern standardisierte, quantitative Messwerte, die dazu beitragen, die Observability in modernen Architekturen zu verbessern. Sie bieten detaillierte Erkenntnisse über die Systemleistung und ermöglichen es Entwicklern und Ingenieuren, proaktive Strategien zur Fehlerbehebung und Optimierung umzusetzen.

Weitere Vorteile sind: