Prometheus, Alertmanager und Grafana mit Hilfe der Simpsons erklärt

28. September 2026

Prometheus und Grafana mit Hilfe der Simpsons

Wer eine App selbst betreibt, weiß, dass Monitoring nicht wegzudenken ist. Aber Monitoren allein reicht natürlich noch nicht, man muss auch irgendwie mitbekommen, wenn etwas nicht mehr funktioniert. Wer dafür eine Open-Source-Lösung sucht, stößt unweigerlich auf Prometheus und Grafana. Obwohl sie nicht immer zusammen benutzt werden müssen, tauchen sie selbst in Jobanzeigen häufig wie ein fester Block auf. Aber was genau ist eigentlich ihre jeweilige Aufgabe, und warum sind sie getrennt voneinander?

Prometheus

Metriken sammeln

Fangen wir damit an, uns zunächst Prometheus anzugucken. Die Aufgabe von Prometheus ist es, Metriken über laufende Systeme zu sammeln. Metriken sind Datenpunkte, Momentaufnahmen eines Zustandes. Zum Beispiel die Auslastung der CPU um 15:43:24 UTC. Die kann dann zum Beispiel 0.23, also 23 %, sein. Es kann aber auch der aktuell freie Festplattenspeicher sein.

Prometheus macht das, indem es die laufenden Anwendungen in regelmäßigen Abständen nach ihren aktuellen Metriken fragt. Dafür schickt es einen HTTP-GET-Request an den /metrics-Endpunkt der Anwendung. Die Anwendung reportet dann alles, was sie halt reporten möchte, und Prometheus speichert es für sie. Wenn man sich für Metriken von Anwendungen oder Systemen interessiert, die selbst keinen solchen Endpunkt haben, bedient man sich sogenannter Exporter. Um zum Beispiel die Metriken eines einzelnen Computers einzuspeisen, installiert man auf diesem Rechner den Node Exporter. Das ist ein kleiner Dienst, der auf dem Computer läuft und Daten über den Rechner über den /metrics-Endpunkt bereitstellt. So kommt man zum Beispiel an die CPU-Auslastung eines gesamten Rechners.

Daten abfragen

Wunderbar, meine Daten sind jetzt also alle in Prometheus. Was mache ich mit denen? Erstmal kann man sie abfragen. Dafür stellt Prometheus eine eigene Query Language namens PromQL bereit. Abfragen lassen sich über die HTTP-API von Prometheus stellen (standardmäßig unter http://localhost:9090/api/v1/query) oder bequem mit dem mitgelieferten CLI-Tool promtool:

# Freier Speicherplatz auf / in Prozent
promtool query instant http://localhost:9090 \
  '100 * node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}'

Damit Prometheus allerdings nicht selbst zum Verursacher einer vollen Festplatte wird, speichert es die Daten nicht unendlich lange. Standardmäßig bewahrt Prometheus die Daten 15 Tage auf, danach werden sie gelöscht. Das lässt sich aber natürlich flexibel konfigurieren.

Alerts

Gut, Daten sind aber erstmal nur Daten. Ein Mensch weiß vielleicht, dass eine Festplattenauslastung von 97 % oder ein verfügbarer Arbeitsspeicher von 23 MB besorgniserregend sind, das weiß Prometheus aber nicht. Deswegen erlaubt es Prometheus, Alerts einzustellen. Diese sind im Wesentlichen entweder aktiv oder inaktiv, also rote Warnblinklampe an oder rote Warnblinklampe aus. Dazwischen gibt es noch einen Wartezustand: Man kann festlegen, dass eine Bedingung erst eine Weile anhalten muss, bevor die Lampe wirklich angeht, damit nicht jeder kurze Ausreißer Alarm schlägt. So kann man sagen: „Wenn diese App seit fünf Minuten über 80 Dateien gleichzeitig offen hat, dann ist was falsch.“ Oder: „Wenn die durchschnittliche Beantwortung einer Anfrage auf diesem Endpunkt länger als 3 ms dauert, dann ist auch etwas falsch.“

Diese Alerts wertet Prometheus laufend aus und hält ihren Zustand selbst als abfragbare Metrik (ALERTS) aktuell. Man könnte also regelmäßig eine Query gegen Prometheus laufen lassen, um sich aktive Alerts anzeigen zu lassen. Das wäre sozusagen der Blick über die Schulter, ob eine der Warnblinklampen an ist. Gut, das klingt ja schon mal ganz nett, aber wo kommt jetzt Grafana ins Spiel? Einen Moment noch, vorher gucken wir uns noch etwas anderes an.

Alertmanager

Eine Warnblinklampe in einem Raum, in dem sich niemand aufhält, bringt wenig. Und alle paar Minuten selbst eine Query zu schreiben, naja. Ein Shell-Script, möglich. Aber natürlich hat sich darüber schon jemand anderes Gedanken gemacht: Der Alertmanager gehört offiziell zum Prometheus-Projekt. Er ist ein kleines Programm, dem Prometheus jeden aktiven Alert meldet und das dann unseren Anweisungen (Konfiguration) folgend andere Dinge macht, z. B. uns eine SMS schicken, auf ein ntfy.sh-Topic schreiben oder einen Matrix-Raum benachrichtigen. Er ist quasi ein fleißiger Mitarbeiter, dem Prometheus Bescheid gibt, sobald eine Lampe angeht, und der dann akribisch sein Protokoll abarbeitet.

Wir können dem Alertmanager also zum Beispiel sagen: „Wenn App1 ODER App2 ODER App3 down ist, dann informiere Mitarbeiter A per Anruf“ oder „Wenn der Alert ‚Wenig Speicher‘ für Node2 aktiv ist, dann informiere Mitarbeiter B, aber nicht, wenn Node2 sowieso schon als komplett ausgefallen gemeldet ist“. Die jeweiligen Kanäle müssen wir natürlich selbst mitbringen (also einen Telefonprovider oder einen Matrix-Account etc.). Manche davon, wie E-Mail oder Slack, unterstützt der Alertmanager direkt, andere nur über einen Webhook oder eine kleine Brücke. Ob etwas schiefläuft, entscheidet also Prometheus. Wen der Alertmanager dann wann und wie oft informiert, ist seine Logik.

Warum ist das nicht einfach Teil von Prometheus? In größeren Umgebungen laufen oft mehrere Prometheus-Server, zum Beispiel zwei identische für die Ausfallsicherheit. Beide erkennen dasselbe Problem und melden denselben Alert. Würde jeder selbst Nachrichten verschicken, käme alles doppelt. Weil beide an denselben Alertmanager melden, sortiert dieser die Duplikate aus und schickt nur eine Nachricht.

Damit haben wir doch eigentlich alles, oder? Wir überwachen, was wir überwachen wollen. Wir definieren, was ein schlechter Zustand ist, und wir haben etwas, das im Problemfall jemanden informiert. Wofür brauchen wir dann noch Grafana?

Grafana

An sich kommen wir tatsächlich schon relativ weit mit dem, was wir haben, und können sicherlich auch ziemlich effektiv auf Ausfälle reagieren. Aktuell ist es allerdings noch so, dass wir, wenn wir in der Nacht durch einen Alert aus dem Bett geholt werden, nur wissen, welche Metrik ihren Schwellwert überschritten hat, aber nicht, warum. Da kommt Grafana ins Spiel. Grafana erlaubt es uns, mit den Metriken aus Prometheus eigene Dashboards zu erstellen. Die Daten speichert Grafana dabei nicht selbst, sondern fragt sie jedes Mal bei Prometheus ab. In diesen Dashboards können wir die Entwicklung unserer Metriken über einen Zeitraum beobachten. Und vor allem können wir so auch verschiedene Metriken nebeneinanderlegen, um nach Korrelationen zu suchen.

Stellen wir uns vor, dass wir um 4:30 Uhr aus dem Bett geholt werden, weil unser Alarm „Hauptspeicher über 95 %“ angeschlagen hat. Das ist Mist. Also schnell an den Rechner und ins Firmennetz. Weil wir keine Ahnung haben, warum der Speicher jetzt auf einmal bei 95 % ist, obwohl er eigentlich nie über 80 % liegen sollte, werfen wir einen Blick auf ein Grafana-Dashboard. Dort sehen wir, dass die Speicherauslastung über die letzten Stunden sukzessive auf 95 % geklettert ist, jede Stunde nur 1,5 %. Also verfolgen wir den Graphen ein paar Stunden zurück, bis wir den Knick erkennen. Genau zu dem Zeitpunkt, als wir den Deploy-Tag von 8.2.3 auf 8.2.4 geändert haben, ging der RAM-Anstieg los. Also das Image auf 8.2.3 zurückgerollt und ab zurück ins Bett. Am nächsten Morgen dann der Check: In unserem letzten Release wurde ein free vergessen, jeder Request hat etwa 200 B zurückgelassen. Mit Rust wäre uns das nicht passiert.

Die Simpsons

Spaß beiseite. So oder so ähnlich spielen Prometheus und Grafana (und häufig auch der Alertmanager) im produktiven Alltag zusammen. Und damit man sich das jetzt noch besser vorstellen kann, noch ein Bild vor Augen: Wir denken an die Sicherheitszentrale im Atomkraftwerk bei den Simpsons, wo Homer mal wieder Donuts verschlingt, statt zu arbeiten. Prometheus sind hier die kleinen Kontrolllampen, die überall am Pult blinken, wenn etwas schiefgeht. Das Handbuch, das Homer sich verzweifelt schnappt, sobald irgendein Alarmlämpchen losgeht, ist die Konfiguration des Alertmanagers. Homer ist unser Alertmanager, der akribisch alles macht, was in seinem Handbuch steht (hoffentlich). Du bist der kompetentere Mitarbeiter, der Homer zu Hilfe eilt, sobald er die richtige Benachrichtigung losgeschickt hat. Und Grafana sind die Graphen auf der Konsole, die von Homer immer ignoriert werden.

Der Dead Man’s Switch

Eine Sache haben wir aber tatsächlich noch vergessen. In Homers Kontrollraum gibt es auch noch eine Kamera, und hinter dieser sitzt Smithers. Und Smithers wird sauer, wenn Homer schläft. Das ist eine Komponente, über die wir noch gar nicht geredet haben, und die wird „Dead Man’s Switch“ genannt. Das beste Alerting hilft niemandem, wenn es einfach still und heimlich ausfallen kann. Deswegen muss sich unser Alerting regelmäßig bei einem externen Dienst melden und berichten, dass es noch wach ist. In der Praxis legt man dafür einen Alert an, der immer aktiv ist und den der Alertmanager regelmäßig weiterleitet. So wird gleich die ganze Kette geprüft: Server, Prometheus und Alertmanager. Bleibt die Meldung aus, schlägt der externe Dienst Alarm. Dafür kann man zum Beispiel healthchecks.io verwenden, entweder selbst gehostet (aber dann bitte auf anderer Infrastruktur) oder als gemanagten Service.

Solltet ihr Hilfe mit eurem Alerting oder mit sonstiger IT-Infrastruktur brauchen, dann meldet euch gerne bei mir.