Stefan Zörner
31.01.2024
Organisationen, die geschäftskritische Softwarelösungen schreiben und betreiben, überwachen seit jeher deren Zustand zur Laufzeit, um im Ernstfall (oder besser schon davor) passende Maßnahmen einzuleiten. Im heutigen Cloud Native-Umfeld unterstützen hier viele frei verfügbare Open Source-Lösungen. Rund um Metriken und Alarme nimmt Prometheus dabei eine besondere Stellung ein. Dieses Porträt zeigt, welche Ziele das ursprünglich bei einem deutschen Start-up entstandene Werkzeug verfolgt und welche Architekturansätze zentral für deren Erreichung sind.
Steckbrief: Monitoring-Lösung Prometheus
Name: Prometheus
Software-Gattung: Zeitreihendatenbank und Monitoring-Lösung
Veröffentlicht: 2015, Version 1.0 2016
Herkunft/Ursprung: Entwicklung als Open Source bei SoundCloud ab 2012 (Apache License), Cloud Native Computing Foundation seit 2016
Zielplattform: Cross-Plattform (u.a. Linux, Windows, MacOS …)
Programmiersprache(n): Go
Homepage: prometheus.io
Wer im Internet nach Prometheus sucht, stolpert zunächst einmal über die gleichnamige Mythengestalt sowie passende Beiträge aus der Kunstgeschichte von der Antike bis hin zu Mary Shelleys „Frankenstein“ (alternativer Titel ihres Romans von 1818: „Der moderne Prometheus“ [She1818]). Prometheus – griechisch für „der Vorausdenkende“ – brachte den Menschen, so die Sage, das Feuer. Das erklärt zumindest die Fackel im Logo der prominenten gleichnamigen Monitoring-Lösung.
Der Begriff stammt aus dem Lateinischen, das Verb „monere“ bedeutet auf Deutsch „warnen“. Er ist auch außerhalb der Computer-Welt üblich, etwa im Gesundheitswesen. In der IT steht Monitoring für die Überwachung von Systemen und Netzwerkkomponenten. Julien Pivotto und Brian Brazil [Piv+2023] dröseln diese Aktivität in vier verschiedene Bereiche auf: Vorrangig geht es um das Alarmieren im Falle von Störungen, aber auch um die Fehlersuche, das Erkennen und Berücksichtigen von Trends inklusive Kapazitätsplanung und im weiteren Sinne auch um das Verschrauben („Plumbing“) von datenverarbeitenden Systemen aller Art.
Dabei kommen verschiedene Techniken zum Einsatz, die sich vor allem dem Sammeln von Informationen widmen: Logging, Tracing, Profiling und das Erheben von Metriken. Für diese Aktivitäten gibt es zahlreiche spezialisierte Softwarelösungen, kostenpflichtige Produkte ebenso wie freie. In einer klassischen Konzern-IT der Prä-DevOps-Ära kamen zur Überwachung auf Betriebsseite oftmals kommerzielle Lösungen wie Tivoli (1989, IBM ab 1996) oder OpenView (HP) zum Einsatz. Aber auch freie Software hierzu gibt es schon länger, Nagios (und deren Verwandte wie Icinga) etwa seit über 20 Jahren.
Mit dem Trend, Unternehmensanwendungen verteilter und kleinteiliger zu entwickeln („Microservices“), cross-funktionalen Teams auch die Betriebsverantwortung zu übertragen („DevOps“), und Lösungen verstärkt in der Cloud zu betreiben hat die Relevanz für Monitoring in der Breite zugenommen. Die Cloud Native Computing Foundation (CNCF) trug dem Rechnung, indem sie die Monitoring-Lösung Prometheus seit 2016 offiziell beheimatet („Hosted“) [CNCF2016]. 2018 beförderte sie es als zweites Projekt nach Kubernetes in den Reifestatus „Graduated“.
Entstanden ist Prometheus initial bereits ab 2012 als Open Source-Lösung beim Start-up-Unternehmen SoundCloud. Der Berliner Online-Dienst ist vor allem als Plattform für Musikschaffende und deren Interaktion untereinander und mit Fans bekannt. Auf den ersten Blick zählt Monitoring nicht direkt zur Kerndomäne des Unternehmens. Björn Rabenstein berichtet in [Rab2016] über die Anfänge des Projektes und die Rolle von Open Source für SoundCloud.
Im Kern ist Prometheus eine Zeitreihendatenbank (Time Series Database) zum Sammeln von Messwerten (Metriken) mit der Möglichkeit, die Daten effizient abzufragen und Alarme abzusetzen. Konzeptionell ähnelt die Software dem Google-internen Borgmon (siehe [Wil2016]). Tabelle 1 zeigt zentrale Architekturziele von Prometheus; die Reihenfolge gibt Orientierung bezüglich deren Wichtigkeit. Zuverlässigkeit steht dabei ganz oben.
| Ziel | Beschreibung (und zugehörige(s) Software-Qualitätsmerkmal(e)) |
| Zuverlässig überwachen und warnen | Prometheus sammelt Metriken zuverlässig ein und beeinträchtigt die überwachten Systeme dabei nur minimal. Egal was passiert – Prometheus ist (fast) immer in der Lage, Menschen und anderen Computer-Systemen Bescheid zu geben, um eine Entstörung einzuleiten. (Zuverlässigkeit) |
| Einfach zu erweitern | Es ist leicht möglich Prometheus um neue Zielarten (Anwendungen, Middleware), Empfänger für Warnungen etc. zu ergänzen. Außenstehenden gelingt dies mit minimalen Anpassungen an Prometheus selbst oder den überwachten Zielen, sprach- und systemunabhängig.(Wartbarkeit, Erweiterbarkeit) |
| Hilfreiches Werkzeug im Betrieb | Das Betriebspersonal leitet aus den gesammelten Informationen ohne große Mühe wertvolle Erkenntnisse ab. Die Daten sind aussagekräftig und aktuell genug, um geeignete Maßnahmen zu ergreifen. Prometheus unterstützt dabei proaktiv. (Benutzbarkeit) |
| Effizientes Sammeln, Schnelles Auswerten | Prometheus speichert Messwerte effizient ab und erlaubt sehr performante Abfragen darauf. Dies gilt auch bei einer extrem hohen Anzahl von Datenquellen und Metriken, bis hin zu einer zweistelligen Millionenanzahl in den letzten zwei Stunden.(Performance, Skalierbarkeit) |
| Leicht zu konfigurieren und zu betreiben | Prometheus läuft anstandslos in den üblichen Server-Umgebungen. Die Inbetriebnahme geht leicht von der Hand, Dynamische Umgebungen erfordern keine oder nur geringe Änderungen in der Konfiguration. (Betreibbarkeit) |
Zum überwiegenden Teil ist Prometheus in Go programmiert, eine Eigenschaft, die es mit vielen anderen CNCF-Projekten wie z.B. Kubernetes teilt. Die Web-basierte Oberfläche (Screenshot siehe Abbildung 1) ist als Single-Page-Application in TypeScript mit React realisiert.
Abb. 1: Web-UI von Prometheus mit einer PromQL-Abfrage in Graph-Darstellung
„Pull vs. Push“ – Die Datenbeschaffung gilt als Gretchenfrage bei Monitoring-Lösungen. Holt sich die Software die Daten bei den zu beobachteten Systemen ab („Pull“), oder müssen letztere sie bei der Monitoring-Komponente per Aufruf anliefern („Push“)? Beide Ansätze haben Vor- und Nachteile, David Zhang diskutiert sie ausführlich in einem Blog-Beitrag [Zha2022]. Prometheus verfolgt den „Pull“-Ansatz, d.h. es fragt die betreffenden Stellen (Targets) in regelmäßigen Abständen ab, z.B. jede Minute. Der Vorgang heißt bei Prometheus Scraping, vom Englischen „to scrape“ = „(ab)kratzen“. Das bedeutet für die Kopplung der Systeme, dass Prometheus die Targets kennt und diese einen Endpunkt zur Abfrage der Daten bereitstellen müssen. Umgekehrt sind die Targets davon befreit, aktiv Messwerte oder direkt Probleme zu melden. Sie kennen Prometheus nicht. Zu den Konsequenzen des Pull-Ansatzes zählt, dass eine Problemerkennung, abhängig vom Scraping-Intervall, mitunter zeitverzögert erfolgt. Kurzlebige Prozesse, etwa unregelmäßige Batch-Läufe, sind mit Pull kaum zu erfassen weswegen Prometheus ein Push-Gateway anbietet. Die Fehlererkennung ist bei Pull einfacher und verlässlicher.
Abb. 2: Ein informeller Architekturüberblick von Prometheus
Abbildung 2 zeigt Prometheus im Überblick mit der zentralen Server-Komponente in der Mitte und den Datenquellen auf der rechten Seite. Der Prometheus-Server ist ein einzelner Prozess, die gesammelten Daten speichert er hocheffizient direkt auf der lokalen Platte. Als Datenmodell verwendet Prometheus dabei sogenannte Zeitreihen (Time Series), also Ströme von mit Zeitstempeln versehenen Werten. Prometheus unterstützt Labels als Dimensionen in den Metriken, nach deren Werten es filtern und aggregieren kann. Ein Label kann beispielsweise die Instanz eines redundant deployten Services sein, oder der Response Code bei HTTP-Requests.
Im einfachsten Fall erfolgt die Konfiguration der Targets bei Prometheus in einer Textdatei im YAML-Format. Da die Software auch in dynamischen Umfeldern wie Kubernetes oder der Cloud zum Einsatz kommt, wo Server kommen und gehen (Stichwort „Cattle vs. Pets“) und Services automatisch hoch- und runterskalieren, ist auch die Abfrage von Service Registries wie Consul oder AWS EC2 möglich, um Datenquellen für das Scraping zu identifizieren.
Das Scraping selbst erfolgt per HTTP auf einem konfigurierten bzw. via Service Discovery ermittelten Endpunkt der Datenquelle. Prometheus erwartet die Daten in einem einfachen textbasierten Format und unterstützt dabei vier Arten von Metriken (siehe Abbildung 3).
Dieser Ansatz stellt einen wichtigen Erweiterungspunkt dar. Anwendungen, die als Quelle für Metriken dienen, müssen geeignet instrumentiert sein und einen HTTP-Server als Scraping-Ziel anbieten. Für beide Aspekte bietet das Prometheus-Team leicht zu verwendende Bibliotheken (Client Libraries) für gängige Programmiersprachen wie Python, Java oder Go an. Für eine Reihe weiterer Sprachen und Umgebungen findet sich Unterstützung durch die Community, etwa für C++, Node.js oder .NET.
Beim Instrumentieren versieht das Entwicklungsteam seine Anwendung an passenden Stellen mit Anweisungen, um zum Beispiel Aufrufe zu zählen oder deren Laufzeit zu messen. Die Werte stellt es über das textbasierte Format nach außen per HTTP bereit (englisch „Exposition“). Auf diese Weise ist es möglich, fachlich motivierte KPIs (Key-Performance-Indikatoren) zu ermitteln und zu veröffentlichen, beispielsweise den Wert von Warenkörben in einem Web-Shop. Der Einsatz von Microservices-Chassis-Frameworks wie Spring Boot in Java kann das Instrumentieren weiter erleichtern. Plugin-Entwickler verschiedenster Softwarelösungen machen sich die Client Libraries von Prometheus zunutze, um auf diese Weise Metriken für ihre Software anzubieten. So gibt es entsprechende Plugins, Extensions oder Module (Sprachweise je nach Software) beispielsweise für den Build-Server Jenkins, das Enterprise Wiki Confluence und sogar für Minecraft.
Abb. 3: Von Prometheus unterstützte Metrik-Arten
Nicht immer ist es allerdings sinnvoll, das Sammeln der Daten durch Instrumentierung im gleichen Prozess ablaufen zu lassen wie das Quellsystem. Mitunter lässt sich der Quelltext nicht verändern, oder Sicherheits- oder Effizienzgründe sprechen dagegen. In diesem Fall kommen bei Prometheus sogenannte Exporter zum Einsatz. Sie laufen als eigenständige Prozesse „neben“ der Datenquelle und dienen als Adapter. Sie sammeln die Metriken in der Regel über eine ohnehin verfügbare API des eigentlichen Targets ein und stellen sie dann mundgerecht, d.h. im passenden Text-Format, für Prometheus per HTTP bereit. Einige Exporter liefert das Prometheus-Team direkt, weitere entstammen der Community. Zu den beliebtesten „Offiziellen“ zählt der Node Exporter, der systemnahe Leistungsdaten etwa zu CPU-Auslastung, Speicherverbrauch und Netzwerkkommunikation für *NIX-Kernel wie den von Linux bereitstellt. Eine umfangreiche Aufstellung verfügbarer Instrumentierungen und Exporter findet sich auf der Webseite von Prometheus [PromExp]. Zu den unterstützten Middleware-Systemen zählen Datenbanken wie PostgreSQL oder MongoDB, Messaging-Systeme wie RabbitMQ oder Kafka und Webserver wie Apache oder Nginx.
Als Schnittstelle zum Betrieb bietet Prometheus verschiedene Kanäle (siehe Abbildung 2, linke Seite), wobei für die wichtige Alarmfunktionalität der Alertmanager als eigenständiger Prozess läuft. Die Regeln, wann ein Alarm auftreten soll (Alert Rules) und wie lange die Situation dafür mindestens vorliegen muss, werden dabei im Prometheus-Server durch geeignete Abfragen konfiguriert. Dieser wertet sie aus und liefert die Information an den Alertmanager, der zuständiges Betriebspersonal je nach Information über verschiedene Kanäle, im Extremfall per Pager, informiert.
Direkten Einblick in die Arbeit von Prometheus bietet das Web-basierte User Interface. Es liefert Statusinformationen über den Server selbst, konfigurierte Regeln für Alarme, die Service Discovery und alle Datenquellen inklusive des Zeitpunkts des jeweils letzten Scrapings und dessen Erfolg oder Misserfolg.
Weiterhin ermöglicht es das UI mit dem Expression Browser in den vorhandenen Zeitreihen zu stöbern und interaktiv mit PromQL zu arbeiten. PromQL (kurz für Prometheus Query Language) ist eine funktionale Abfragesprache für Zeitreihen in Prometheus. Sie erlaubt verschachtelte Ausdrücke, beinhaltet reichlich Operatoren und Funktionen, etwa für Arithmetik und Dinge rund um Datum und Zeit. Labels spielen in PromQL eine besondere Rolle, insbesondere kommt die Sprache zum Aggregieren von Daten zum Einsatz. Die Ergebnisse einer Abfrage kann das Web UI tabellarisch anzeigen oder auch in einem Graphen plotten, wie in Abbildung 1 zu sehen. Das Web UI ist vor allem für Ad hoc-Queries und das komfortable Entwickeln von Abfragen gedacht, um sie dann in Regeln für Alarme oder für Panels in einem separaten Dashboard-Tool zu nutzen.
Dashboards (von der englischen Bezeichnung für das Armaturenbrett im Auto) verdichten Informationen aus den gesammelten Daten und stellen sie zielgerichtet, übersichtlich und graphisch ansprechend dar. Viele Teams nutzen solche Dashboards zur Information und auch zur Kommunikation untereinander und gegenüber Dritten.
Prometheus bietet zur Entwicklung solcher Dashboards verschiedene Optionen an. Am verbreitetsten ist der Einsatz der Open Source Lösung Grafana [GraLa], die neben Prometheus auch andere Datenquellen visualisieren kann. Grafana erlaubt den Entwurf und die Bereitstellung interaktiver, webbasierter Dashboards mit zahlreichen Darstellungsmöglichkeiten. Die Anbindung an Prometheus erfolgt über dessen API, bei der Konfiguration einzelner Kacheln (Panels) im Dashboard kommt PromQL zum Einsatz. Abbildung 4 zeigt zur Illustration ein Dashboard in Grafana, das gesammelte Daten der letzten 12 Stunden aus einem Node Exporter und dem Jenkins-Plugin für Prometheus für einen Build Server visualisiert.
Abb. 4: Ein Dashboard in Grafana mit Daten aus Prometheus
Neben dem „Ausweichen“ auf Grafana bietet Prometheus selbst auch die Entwicklung von Dashboards mit sogenannten Console Panels an. Diese nutzen Go Templates zum Rendering von Webseiten und laufen direkt im Prometheus Server. D.h. sie kommen ohne weitere Laufzeitkomponente aus. Die Autoren von [Piv+2023] sehen das jedoch eher als Option für Nischeneinsätze durch Fortgeschrittene. Grafana bietet deutlich mehr Funktionen out-of the-Box, mehr Komfort, und macht optisch mehr her. Ursprünglich hatte das Prometheus-Team eine vergleichbare Lösung zu Grafana namens Promdash selbst bereitgestellt, die Entwicklung aber 2016 zugunsten der Fokussierung mit einer Empfehlung für Grafana eingestellt.
Die Speicherung der Metriken erfolgt bei Prometheus unmittelbar am ungeclustert betriebenen Server, lokal im Filesystem. Die Software verdichtet die Zeitreihen und löscht per Default Messwerte, die älter sind als 15 Tage (Stichwort „Retention“). Für Auswertungen über längere Zeiträume und auch als Schutz vor Störungen an Prometheus selbst kommen zusätzliche Storage-Optionen wie z.B. Thanos [Tha] zum Einsatz. In größeren Systemlandschaften ist auch der Einsatz mehrerer Prometheus Server und Alertmanager üblich, J. Pivotto und B. Brazil diskutieren in [Piv+2023] verschiedene Deployment-Szenarien rund um Langzeitspeicherung und Föderation. Die großen Public Cloud-Hersteller bieten Prometheus und Grafana als Managed Services an.
Abb. 5: Zentrale Lösungsansätze von Prometheus mit Zuordnung zu den Zielen (Farbcode)
Prometheus gilt im Cloud Native Umfeld als anbieterneutraler Defacto-Standard für Metriken. Das für das Scraping eingesetzte Textformat war wesentlicher Input für das OpenMetrics-Projekt [OpMet], das zusätzlich zum Text- auch ein Binär-Format (Protocol Buffers) für Datentypen und Metrik-Arten spezifiziert, und neben dem Pull- auch das Push-Modell unterstützt. Ziel ist es die Spezifikation als RFC-Standard im IETF zu etablieren. Einen noch breiteren Scope hat OpenTelemetry [OpTel]. Das Projekt adressiert allgemein Daten rund ums Monitoring, also neben Metriken auch solche zu Tracing und Logging. Es stellt neben der Spezifikation auch APIs und Tools bereit, wobei die Prometheus-Konzepte als Inspiration dienen. Sowohl OpenMetrics als auch OpenTelemetry sind wie Prometheus CNCF-Projekte, allerdings beide noch im Incubating-Status (Stand Oktober 2023, [CNCFProj]).
Aber egal ob Cloud (Native), Container-Orchestrierung oder konventionell, der Einsatz von Prometheus und verwandten Technologien findet heute überall statt.
[CNCF2016] „Cloud Native Computing Foundation accepts Prometheus as second hosted project“, Pressemitteilung 2016
[CNCFProj] Cloud Native Computing Foundation: „Graduated and Incubating Projects“, https://www.cncf.io/projects/
[GraLa] Webseite von Grafana Labs, https://grafana.com
[OpMet] Webseite von OpenMetrics, „Transmitting cloud-native metrics at scale“, https://openmetrics.io
[OpTel] Webseite von OpenTelemetry, „High-quality, ubiquitous, and portable telemetry to enable effective observability“, https://opentelemetry.io
[Piv+2023] Julien Pivotto und Brian Brazil: „Prometheus: Up & Running“, O’Reilly Media, 2. Auflage 2023
[PromExp] Prometheus-Webseite: Exporters and Integrations
[Rab2016] Björn Rabenstein: “Prometheus has come of age – a reflection on the development of an open-source project”, Blog-Beitrag 2016
[She1818] Mary Shelley: “Frankenstein oder der Moderne Prometheus – Die Urfassung 1818”, neue deutsche Überarbeitung Manesse 2017
[Tha] Webseite Thanos, “Open source, highly available Prometheus setup with long term storage capabilities”, https://thanos.io
[Wil2016] Jamie Wilkinson: “Practical Alerting from Time-Series Data”, Beitrag in “Site Reliability Engineering: How Google Runs Production Systems”, O’Reilly Media 2016
[Zha2022] David Zhang: “Pull or Push: How to Select Monitoring Systems?”, Blog-Beitrag 2022
Dieses Porträt ist ursprünglich in der IT Spektrum, Ausgabe 1 | 2024 als neunter Teil einer Reihe über Architektur-Ikonen der Softwareentwicklung erschienen. Rückmeldungen aller Art gerne an mich per E-Mail. Insbesondere auch Wünsche für weitere Porträts.
Architektur-Porträt: Das Build-Management-Tool Maven
Architektur-Porträt: Der Compute-Service AWS Lambda
Architekturikonen in Software Überblick über alle Porträts