Container-Monitoring mit Prometheus

Entwickler benötigen Informationen über technische Fehlfunktionen in verteilten Systemen und Anwendungen, um schnell reagieren und Ausfälle verhindern zu können. Observability steht für einen umfassenden Ansatz, der zahlreiche Faktoren für die Überwachung und Beobachtung des Verhaltens von Software einbezieht. Ein zentrales Instrument dafür ist das Tool Prometheus.

Die Monitoring-Infrastruktur für Applikationen wird immer wichtiger, auch weil die Zahl der mit dem Internet vernetzten Nutzer und Geräte jedes Jahr ansteigt. Wie verhält sich das System unter Last? Wie lange dauert eine Transaktion? Wie sieht es mit der Reaktionszeit aus? Unternehmen sollten verstehen, inwieweit ein System verfügbar ist, wie es funktioniert und wie die Nutzer eine Applikation wahrnehmen. Neben den üblichen Metriken gewinnen daher auch andere Kriterien an Bedeutung, um die Funktionsweise und das Verhalten von Systemarchitekturen oder Software besser zu verstehen. Dieser Trend wird auch als Observability bezeichnet und umfasst zumindest drei Säulen: Metrikdaten, Logging und Tracing. Zu Observability gehört jedoch auch jede Erkenntnis, mit der Unternehmen Applikationen besser verstehen, wie sie sich verhalten und wie sie funktionieren. Es geht darum, systematisch zu erkennen, was die Softwarelösungen leisten und wie sie funktionieren, um Ausfälle zu verhindern beziehungsweise die Software nach einem Ausfall schnell wiederherzustellen (Recovery). Ein strategischer Ansatz ist unerlässlich, um Metriken, Protokolle und Profile systematisch bewerten sowie kombinieren zu können und damit ein vollständiges Bild der Systeme zu erhalten. Doch eignen sich die derzeit eingesetzten Tools dafür, um die Verfügbarkeit zu maximieren und die durchschnittliche Zeit bis zur Problemlösung zu minimieren? Unabhängig davon, wie viel Zeit und Geld Unternehmen in die Verfügbarkeit eines Systems investieren, es wird immer Zwischenfälle oder Störungen geben. Daher ist es wichtig, sich auf solche Ereignisse vorzubereiten, diese zu untersuchen und zu bewerten. Ist Monitoring im Zeitalter der Observability noch weiter relevant? Diese Frage beantwortet sich nach einem Blick auf die Entwicklung von Monitoring und die zugehörigen Tools im Laufe der letzten Jahre, insbesondere aber seit der Verfügbarkeit des Monitoring-Tools Prometheus.

Prometheus erlaubt den Blick ins Innere

Ein Trend ist eindeutig zu erkennen: Monitoring entwickelt sich hin zum Whitebox-Monitoring. Im Gegensatz zur Blackbox-Überwachung beobachten die Tools die internen Abläufe eines Prozesses genauer, anstatt nur von außen zu prüfen, ob die Anwendung oder der Prozess wie erwartet reagiert. Dies ist der kleine, aber wichtige Unterschied: Das Whitebox-Monitoring überwacht das Verhalten und nicht die Reaktionen. Daher ist jetzt auch proaktives Monitoring möglich, sprich Fehler, technische Mängel oder andere Ereignisse lassen sich vorhersehen und verhindern, bevor sie eintreten. Die ursprünglichen Entwickler von Prometheus ließen sich von der Monitoring-Lösung Borgmon inspirieren, die Google erstellte, um das interne Orchestrierungssystem zu überwachen. Ein Tool wie Borgmon fehlte in der Welt außerhalb von Google und daher entschlossen sich die Programmierer, die damals bei SoundCloud arbeiteten, eine solche Lösung zu entwickeln.

Der Erfolg von Prometheus beruht vor allem auf seiner Zuverlässigkeit. Diese Eigenschaft ist für ein Monitoring-Tool zentral, da die Lösung für die Überwachung von Systemen der robusteste Teil der Infrastruktur sein muss – alles andere hängt davon ab, dass sie funktioniert. Prometheus arbeitet deswegen so zuverlässig, weil das Tool im Pull-Modell arbeitet und Daten abfragt. Das bedeutet nicht, dass Pull der einzige brauchbare Modus ist, aber damit ist es einfacher, zuverlässig zu arbeiten.

Prometheus lässt sich als einzelne, statisch verknüpfte Binärdatei einrichten, die in jeder Art von Umgebung sehr einfach gestartet und aktualisiert werden kann – unabhängig davon, ob Container verwendet werden oder nicht. Diese Einfachheit stellt in Verbindung mit der zuverlässigen Funktionalität einen wichtigen Faktor für den Erfolg von Prometheus dar.

Multidimensionales Datenmodell

Prometheus setzt auf ein multidimensionales Datenmodell zum Identifizieren von Zeitreihen, sprich zeitlichen Abfolgen von Daten. Als Prometheus entwickelt wurde, gab es kein integriertes Überwachungssystem, das die Abfrage von Zeitreihen anhand einer Teilmenge ihrer Kennzahlen ermöglichte. OpenTSDB erlaubte zwar ähnliche Abfragen, verursachte aber hohe Betriebskosten, die Prometheus vermeiden wollte. Prometheus speicherte in der ersten Version seinen gesamten Inhalt in der integrierten Datenbank LevelDB. Sie diente der Indexierung der Zeitreihen und in der zweiten Version von Prometheus wurde jede Zeitreihe in eine separate Datei geschrieben. Dies funktionierte lange Zeit sehr gut, da die Entwickler ursprünglich dynamische Umgebungen und weniger statische virtuelle Maschinen erwarteten und Prometheus entsprechend aufbauten. Doch das Ausmaß und die Häufigkeit der Änderungen der heutigen großen Kubernetes-Cluster und der Möglichkeit multipler Cluster übertrafen alle Annahmen. Die größte Herausforderung bildete hier die Kardinalität der Metriken und ihre Veränderung (Churn). Die Kardinalität steht für die Gesamtzahl der von Prometheus aufgenommenen Zeitreihen. Sie beschreibt die Anzahl der Zeitreihen mit gleicher Metrik, allerdings mit variablen Werten für einzelne Labels. Churn beschreibt die Lebensdauer der Zeitreihen. Der schlimmste Fall für Prometheus ist eine hohe Churn-Rate, bei der die Zeitreihen häufig gestartet und beendet werden. In der zweiten Storage-Version von Prometheus wurde dafür aufwändig jedes Mal eine neue Datei erstellt. Das Problem: Millionen von Zeitreihen führen zu Millionen von Dateien, für die viele Dateisysteme eigens abgestimmt werden müssen oder möglicherweise gar nicht funktionieren.

Das Prometheus-Team entwickelte daher eine dritte Storage-Version, um dieses Problem zu lösen. Anstatt eine Datei pro Zeitreihe zu speichern, besteht die Storage jetzt aus zwei Teilen mit voll funktionsfähigen Datenbanken, die eine eigene Kopie des Index speichern und sich nicht verändern lassen. Wie bei vielen Datenbanken kann der Kernel jetzt die Storage effizient von der Festplatte mappen. Die neue Storage-Architektur löst das Skalierbarkeitsproblem und reduziert den Ressourcenverbrauch in den meisten Szenarien erheblich. Die neue Storage-Version bildete den Hauptgrund für die im November 2017 veröffentlichte Version Prometheus 2.0.

Funktionen stabilisieren

Seit diesem Release besteht das Ziel des Prometheus-Projekts darin, die vorhandenen Funktionen zu stabilisieren. Das Team führte einen sechswöchigen Release-Zyklus, eine detailliertere Release-Dokumentation sowie eine Lead-Rolle ein und lässt regelmäßig externe Sicherheitstests durchführen. Zudem gibt es eine Reihe von automatisierten Leistungstests, um Probleme bereits während der Entwicklungsphase zu identifizieren und die Leistung von Prometheus vor der Veröffentlichung zu überprüfen. Die Arbeit lohnte sich, denn die Cloud-Native-Computing-Foundation (CNCF) verlieh Prometheus im August 2018 den Graduate-Status. Damit gilt Prometheus als zukunftsfähiges Projekt mit stabiler Leistung und Sicherheit, das nicht mehrheitlich einem einzigen Unternehmen gehört. Das Siegel der CNCF ist ein wichtiger Meilenstein für das Projekt und die gesamte Community.

Fazit:

Monitoring wird immer wichtiger, bildet aber nur den Einstieg in eine erfolgreiche Observability. Monitoring bleibt neben anderen Kriterien ein starker Faktor für ein besseres Verständnis von verteilten Systemen und Anwendungen. Künftig wird der Fokus auf der Korrelation dieser verschiedenen und in ihrer Anzahl steigenden Beobachtungskriterien liegen. Die über Metrikdaten gesteuerte Alarmierung (Alerting) wird weiterhin den Ausgangspunkt darstellen, um Fehler oder Ausfälle schnellstmöglich zu beheben.