Observability-Chaos: Welche Metriken liefert das System?

Das verborgene Chaos hinter modernen Metriken

Observability verspricht Durchblick. Dashboards, Alarme und verteilte Traces sollen Ingenieuren ein präzises Bild davon vermitteln, was im Inneren ihrer Systeme vor sich geht. Stellt man jedoch eine scheinbar banale Frage: Welche Metriken liefert unser Stack eigentlich genau?, bricht die schöne Übersicht rasch zusammen.

Ein Software-Ingenieur beschrieb diese Problematik treffend, als er ein Werkzeug entwickelte, um genau diese Lücke zu schließen. Moderne Observability-Stacks generieren tausende Metriken über verschiedenste Schichten hinweg: instrumentierter Anwendungscode, Exporter, Kubernetes-Komponenten und Cloud-Plattformen. Allerdings verteilen sich diese Metrik-Definitionen auf hunderte Repositories, verstreute Dokumentationsseiten und separate Bibliotheken.

Daraus entsteht ein merkwürdiges Paradoxon: Systeme produzieren gigantische Mengen an Telemetriedaten, doch Ingenieure tun sich oft schwer zu durchschauen, welche Signale überhaupt existieren. Das ist weit mehr als eine bloße Unbequemlichkeit, denn es beeinflusst direkt, wie Teams Monitoring-Strategien entwerfen, Alarme konfigurieren und Störfälle analysieren. Zudem offenbart es ein strukturelles Versäumnis bei der Evolution moderner Observability-Ökosysteme.

Der unkontrollierte Zuwachs, den niemand geplant hatte

Heutige Infrastruktur-Stacks werden wie digitale Legosteine zusammengesetzt. Eine typische Umgebung umfasst mehrere Kubernetes-Cluster, Anwendungsdienste in verschiedenen Programmiersprachen, verwaltete Datenbanken, Message-Queues und dutzende Hilfskomponenten. Jedes dieser Systeme stellt eigene Metriken über unterschiedliche Schnittstellen bereit.

Einige Metriken stammen aus OpenTelemetry-Bibliotheken im Anwendungscode. Andere liefern Prometheus-Exporter: kleine Dienste, die Metriken aus Systemen wie PostgreSQL, Redis, Kafka oder MySQL auslesen und exponieren. Kubernetes steuert eigene Signale über Tools wie kube-state-metrics und cAdvisor bei, und Cloud-Provider fügen eine weitere Schicht mit Metriken von Diensten wie EC2, Lambda, S3 und API-Gateways hinzu.

Jede Quelle nutzt ein leicht abweichendes Format. Manche Metriken werden in strukturierten YAML-Dateien definiert, andere stehen fest im Quellcode. Python-Bibliotheken nutzen Decorators oder eigene Telemetrie-APIs. In vielen Fällen erschöpft sich die Dokumentation in vereinzelten Kommentaren im Repository.

Nimmt man all das zusammen, gleicht das Observability-Ökosystem einer archäologischen Ausgrabungsstätte: Die Daten existieren zweifellos, sie aufzufinden ist die eigentliche Herausforderung.

Ein Projekt, das Ordnung in das Dickicht bringt

Angesichts dieser Zersplitterung baute ein Ingenieur ein Werkzeug, das im Rückblick fast schon naheliegend wirkt: eine öffentlich zugängliche Metrik-Registry.

Statt Entwickler manuell durch dutzende Code-Repositories suchen zu lassen, scannt die Registry Quellcode, Dokumentationen und Metadatendateien des gesamten Observability-Ökosystems. Das Resultat ist ein durchsuchbarer Gesamtkatalog mit tausenden Metriken aus OpenTelemetry, Prometheus-Exportern, Kubernetes-Bausteinen und Cloud-Diensten. Der aktuelle Datensatz umfasst über 3,000 Metriken aus unterschiedlichsten Quellen.

Allein die Komponenten des OpenTelemetry Collectors steuern mehr als tausend Metriken bei. Der Node-Exporter von Prometheus liefert hunderte weitere, und Exporter für Redis, MySQL oder PostgreSQL bringen jeweils eigene Signalsets mit. Hinzu kommen Metriken aus AWS CloudWatch für Services wie Lambda, DynamoDB, S3 und Application Load Balancer.

Jede dieser Metriken ist isoliert betrachtet irgendwo dokumentiert. Bis zum Start dieses Projekts existierte dieser Überblick jedoch an keiner zentralen Stelle, und genau dieses Problem packt die Registry an.

Planung vor der eigentlichen Instrumentierung

Wenn Entwickler zum ersten Mal von einer Metrik-Registry hören, vermuten sie oft ein reines Nachschlagewerk. Ein Kommentar aus der Community wies auf einen weitaus praktischeren Nutzen hin: Schon vor dem Rollout eines Exporters oder einer Bibliothek genau zu sehen, welche Metriken später erscheinen werden, ergänzend zu dem, was bereits aktiv gemessen wird.

Dieser Aspekt ist bedeutsamer, als es auf den ersten Blick scheint. Die Planung von Monitoring-Strategien findet idealerweise vor dem eigentlichen Deployment statt, und Entwickler möchten wissen, welche Signale ihnen nach der Installation zur Verfügung stehen. Wenn Sie den Prometheus-PostgreSQL-Exporter bereitstellen: Welche Datenbank-Kennzahlen liefert er konkret? Wenn Sie Ihren Dienst mit OpenTelemetry instrumentieren: Welche Request-Metriken stehen automatisch bereit? Wenn Sie Kubernetes-Monitoring aktivieren: Welche Cluster-Zustandsdaten können Sie erfassen?

Ohne eine zentrale Referenz erfordert die Beantwortung dieser Fragen mühsames Wühlen in Dokumentationen und fremdem Quellcode. Eine Metrik-Registry vereinfacht diesen Schritt erheblich.

Ein alltägliches Problem, das viele Entwickler kennen

Das Echo aus der Entwicklergemeinde folgte prompt. Viele bestätigten, dass die Zersplitterung von Metriken zu den frustrierendsten Seiten des Monitorings gehört: Metrik-Definitionen liegen verstreut über unzählige GitHub-Repositories, Exporter-Pakete und Dokumentationsseiten. Selbst erfahrene Teams tun sich mitunter schwer, die exakte Bedeutung eines bestimmten Metriknamens zweifelsfrei herauszufinden.

Ein Entwickler brachte es auf den Punkt: Wenn man Metrik-Informationen von Prometheus und OpenTelemetry an einem einzigen Ort bündelt, wird die Konzeption von Monitoring-Strategien vor dem Ausrollen neuer Infrastruktur um ein Vielfaches leichter.

Dieser Kommentar verweist auf ein grundlegenderes Thema. Observability hat im vergangenen Jahrzehnt enorme Fortschritte gemacht. Die Werkzeuge zur Erfassung von Telemetriedaten sind hochentwickelt und Speichersysteme bewältigen gewaltige Datenmengen problemlos. Die Bedeutung der einzelnen Signale zu verstehen, bleibt dennoch überraschend kompliziert.

Warum Observability-Dokumentation fragmentiert bleibt

Die Ursache liegt teilweise in der historischen Entstehung des Ökosystems. Die meisten Exporter und Telemetrie-Bibliotheken wurden unabhängig voneinander von unterschiedlichen Open-Source-Communitys entwickelt. Jedes Projekt dokumentierte seine Metriken in dem Format, das damals am zweckmäßigsten erschien: Manche nutzen strukturierte Metadaten, andere betten Beschreibungen direkt in den Code ein, und wieder andere verlassen sich auf automatisch generierte Dokumente. Einen einheitlichen Standard gibt es kaum.

Selbst OpenTelemetry, das Telemetrie über Programmiersprachen und Frameworks hinweg harmonisieren möchte, umfasst viele separate Instrumentierungspakete, die von unterschiedlichen Teams gepflegt werden.

Niemand trägt an dieser Fragmentierung die Schuld, doch für Entwickler, die ihre Monitoring-Landschaft überblicken wollen, entsteht daraus eine handfeste Hürde beim Auffinden relevanter Signale.

Das schiere Ausmaß moderner Metriken

Ein Detail des Registry-Projekts illustriert eindrucksvoll, wie rasant die Zahl der Metriken anwächst. Allein der Prometheus-Node-Exporter liefert über fünfhundert Systemmetriken zu CPU-Auslastung, Speicherbelegung, Platten-I/O und Netzwerkaktivität. Kubernetes-Monitoring-Komponenten ergänzen hunderte weitere Signale zu Pods, Nodes und Cluster-Zuständen. Hinzu kommen anwendungsspezifische Metriken zu Requests, Latenzverteilungen, Fehlerraten und fachlichen Geschäftsdaten.

Selbst mittelgroße Systeme erzeugen mühelos tausende unterschiedliche Metriken. Die meisten Teams überwachen aktiv nur einen kleinen Bruchteil davon, während der Rest verborgen bleibt, bis ein Zwischenfall eine tiefe Fehlersuche erzwingt.

Die nächste Herausforderung: Auffindbarkeit von Metriken

Über Jahre konzentrierte sich die Monitoring-Branche auf drei technische Hauptaufgaben: wie man Telemetriedaten erfasst, wie man sie speichert und wie man sie visualisiert. Diese Fragestellungen gelten heute weitgehend als gelöst.

Die nächste große Herausforderung betrifft die Auffindbarkeit. Entwickler benötigen bessere Möglichkeiten zu erfassen, welche Telemetriesignale ihre Systeme erzeugen können, samt Werkzeugen, die erklären, welche Signale existieren, woher sie stammen und was sie bedeuten. Metrik-Registries stellen einen ersten Schritt in diese Richtung dar und verwandeln Observability vom Ratespiel in eine strukturierte Wissensbasis.

Der Wandel hin zu Wissenssystemen für Observability

Mit wachsender Komplexität werden Werkzeuge, die Telemetriewissen strukturieren, womöglich genauso wichtig wie die Erfassungswerkzeuge selbst. Entwickler beginnen, Metriken als strukturierte Informationsobjekte zu betrachten: Wo entsteht eine Metrik, welches Teilsystem sendet sie, welche Dimension misst sie und welche Alarmierungsregeln greifen typischerweise darauf zu?

Wer diese Fragen schnell beantworten kann, verkürzt die Fehleranalyse und gestaltet Monitoring-Konzepte deutlich zielgerichteter. Zudem erspart es Entwicklungsteams unzählige Arbeitsstunden bei der mühsamen Suche in fremden Repositories.

Was die Registry verdeutlicht

Auf den ersten Blick mag ein durchsuchbarer Metrik-Katalog wie ein Nischenwerkzeug wirken. Er sagt jedoch viel über moderne Infrastruktur aus: Wir beherrschen das Erzeugen gewaltiger Mengen an Telemetriedaten meisterhaft, lernen aber gerade erst, diese Fülle strukturiert zu verstehen.

Solange Entwickler die Frage „Welche Metriken liefert mein System eigentlich?“ nicht einfach beantworten können, bleibt Observability zur Hälfte Wissenschaft und zur Hälfte detektivische Sucharbeit.