Prometheus-Tutorial, Teil 1: Monitoring, Alerting und Trending
Allzeit im Blick
Prometheus schneidet die Zöpfe konventioneller Monitoringsysteme radikal ab und verwendet stattdessen im Kern eine Zeitreihendatenbank.
Monitoring gehört als klassisches Brot-und-Butter-Thema nicht unbedingt zu den Dingen, mit denen Administratoren sich besonders gerne beschäftigen. Klar: Ohne geht es nicht, und wer irgendeine Art von IT-Setup betreibt, plant es schon von Anfang an als wichtigen Faktor ein. Echte Freude bereitet die Umsetzung allerdings den wenigsten Systemadministratoren. Was sicherlich auch daran liegt, dass die gängigen Monitoringlösungen nur bedingt einen guten Ruf haben.
Prometheus stellt sich ihnen entgegen und hat sich in den vergangenen Jahren vom Underdog zum echten Konkurrenten entwickelt: Anders als die Vorgänger basiert Prometheus auf dem Prinzip einer Time Series Database (TSDB) und arbeitet mit Metrikdaten, die es für Monitoring ebenso wie für Trending verwenden kann. iX stellt Prometheus und passende Begleitprogramme vor. In Teil 1 dieses dreiteiligen Tutorials geht es um den theoretischen Unterbau: Welches Problem möchte Prometheus eigentlich lösen? Was ist eine Zeitreihendatenbank und wodurch unterscheidet sie sich von klassischen Monitoringansätzen? Welche Komponenten gehören zu Prometheus?
Teil 2 beschäftigt sich mit der Praxis: Wie installiert man Prometheus, was sind die typischen Fallstricke und wie lässt es sich sinnvoll betreiben? Im letzten Teil geht es schließlich um die Frage, welche nützlichen Begleitkomponenten es für Prometheus gibt, wie diese funktionieren und worauf der Administrator achten sollte, wenn er ein Setup in die Breite skalieren möchte.
Die Krux klassischen Monitorings
Konventionelle Software für Monitoring zeichnet sich meist durch mehrere Faktoren aus. Die Paradebeispiele Nagios und Zabbix machen das deutlich: Einerseits ist das eigentliche System fast immer ein monolithischer Block, der nur bedingt in die Breite skalieren kann. Je größer das Setup wird, desto stärker wird die genutzte Monitoringlösung ächzen. Zur Zeit, als die genannten Tools entstanden sind, war das noch kein Problem – ein Setup hatte in aller Regel eine klar definierte Zielgröße und andere Faktoren verhinderten von vornherein, dass es diese erheblich überschritt. Die Zahl der Hosts in solchen Setups lässt sich mit Nagios & Co. problemlos abdecken.
Hinzu kommt, dass klassische Monitoringumgebungen eventbasiert sind – ihr Verhalten stützt sich auf Ereignisse. Das typische Beispiel ist ein Serverausfall oder der Ausfall eines einzelnen Dienstes: Das System erkennt diesen und löst eine Kette von Ereignissen aus, die schließlich dazu führt, dass irgendwo beim Bereitschaftsadministrator ein Handy klingelt. Nagios & Co. ermöglichen es dem Administrator stets, den Zustand einer Plattform oder eines Dienstes zu einem Zeitpunkt zu kennen.
Eben dieser Ansatz ist im Hinblick auf moderne, skalierbare Plattformen aber zu wenig. Denn große Clouds oder Kubernetes-Umgebungen unterscheiden sich in vielerlei Hinsicht von ihren klassischen Vorgängern. Zunächst steht bei ihnen nicht mehr die Funktionalität eines einzelnen Dienstes oder eines einzelnen Servers im Vordergrund, sondern die Funktionstüchtigkeit der Schnittstelle hin zum Nutzer. Ein gutes Beispiel sind die OpenStack-APIs: Laufen hinter einem Load Balancer etliche Instanzen, ist es völlig egal, ob eine davon kaputtgeht – jedenfalls ist das kein Notfall, für den nächtens ein Administrator aus dem Bett zu klingeln wäre. Es genügt völlig, den ausgefallenen Dienst erst am nächsten Tag zu reparieren. In konventionellen Monitoringsystemen haben sich solche Probleme lange Zeit gar nicht sinnvoll abbilden lassen – mittlerweile sind entsprechende Funktionen vorhanden.
Echtes Ungemach droht den klassischen Monitoringlösungen allerdings aus einer ganz anderen Ecke. Denn in einer Cloud-Umgebung muss der Administrator zusätzlich wissen, wann er skalieren muss. Geht man von den Wachstumszahlen der vergangenen Monate aus, lässt sich ungefähr voraussagen, wann neue Hardware anzuschaffen ist. Das geht bekanntlich nicht von heute auf morgen: Ehe die passenden Geräte ausgesucht, bestellt, geliefert, verkabelt und in Betrieb genommen sind, vergehen etliche Wochen, im schlimmsten Falle Monate. Um zu wissen, wann es Zeit für die Bestellung ist, muss der Administrator allerdings die Auslastung seiner Plattform erst mal erheben und anhand diverser Kennzahlen regelmäßig überprüfen, wie groß das Polster noch ist. Der Fachbegriff hierfür lautet Trending. Nur mit einer verlässlichen Trending-Datenlage lassen sich zuverlässige Prognosen über den Hardwarebedarf erstellen.