Prometheus Monitoring – Fix It Before It Breaks

Mit guter Laune hat man sich gerade einen Kaffee gemacht, da klingelt plötzlich das Smartphone. Am anderen Ende der Leitung erklärt der Kunde hektisch, dass sich seine Nutzer nicht mehr auf seiner Website einloggen können. Von einer Minute auf die andere ist es vorbei mit der Ruhe, schließlich verlieren wir jede Sekunde Geld.

Aber warum? Keine Ahnung. Also gehen wir auf die Suche und schauen uns selbst die Fehlermeldung an. Das Frontend ist da und bittet uns freundlich und wie gewohnt um unsere Zugangsdaten. Nach Eingabe derselben stehen auch wir plötzlich vor einer relativ schlank gehaltenen Fehlermeldung.

Unexpected Journey – I’m Going on an Adventure!

Komisch. Das sollte so nicht sein, aber immerhin antwortet das Frontend noch. Da der Fehler nicht auf den ersten Blick klar ersichtlich ist, müssen wir wohl oder übel Service für Service prüfen.

Also schauen wir nach dem Backend. Auch dieser Service sieht von außen betriebsbereit aus, ein testweiser API-Call zeigt uns aber relativ schnell, dass der Call an den Authentifizierungsservice, welcher unser Token validieren sollte, nur mit einem wenig aussagekräftigen HTTP-Statuscode 500 beantwortet wird.

Da wir das Backend als Verursacher ausgeschlossen haben, begeben wir uns weiter auf den Pfad der Fehlersuche, wohlwissend dass die Downtime reale Konsequenzen nach sich zieht und jede Minute zählt – ein wahrhaft hilfreicher Gedanke, um konzentriert die Fehlerquelle zu identifizieren.

Die Logs des Authentifizierungsservices geben uns den Hinweis, dass dieser bei eingehenden Calls versucht, eine Datenbank zu erreichen, in der unser Rechtemanagement persistiert wird, diese aber nicht erreichbar ist. Wir nähern uns also der Wurzel des Problems. Da wir unsere Umgebung gut kennen, wissen wir, dass die betroffene Datenbank ein Mirror einer Kerndatenbank ist und regelmäßig über einen CronJob mit dieser synchronisiert wird. Die Logs der Datenbank weisen nun aber darauf hin, dass diese Synchronisierung nicht wie geplant ausgeführt wurde. Deshalb wird der Zugriff auf die Daten verweigert, da diese gegebenenfalls nicht aktuell sind und somit unser Rechtemanagement korrumpiert ist.

Der wahre Übeltäter scheint also unser Synchronisierungsjob zu sein, aber warum? Ein einziger Blick an die richtige Stelle reicht aus, um zu erkennen, dass der Node, auf dem der Job ausgeführt werden sollte, ein massives Ressourcenproblem hat. Er verfügt nicht mehr über genügend Arbeitsspeicher, um den Container für die Synchronisierung zu starten.

Nach einem Einzeiler, der die Konfiguration ändert und den Container auf einem anderen Node startet, ist der ursprüngliche Fehler behoben und wie durch Geisterhand ist auch der Loginprozess im Frontend für unsere Nutzer wieder fehlerfrei durchführbar.

Das war stressig … und kostet richtig Geld

Eigentlich ganz einfach, oder? Vielleicht, aber dennoch hat uns die Analyse zwei Stunden gekostet und den Kunden wahrscheinlich einiges an Geld. Im schlimmsten Fall ist das Vertrauen der Nutzer unwiederbringlich verloren, da manche den Service vielleicht nun nicht mehr nutzen.

Wäre es nicht schön gewesen, wenn man dieses Ressourcenproblem hätte erkennen können? Und wäre es nicht umso schöner, wenn man das Problem hätte lösen können, noch bevor es entsteht?

Monitoring als Lösung

Monitoring kann besonders in verteilten und hochdynamischen Container-Umgebungen wie Kubernetes oder OpenShift zur Herausforderung werden. Glücklicherweise hat Prometheus hier bereits eine Lösung entwickelt.

Prometheus Monitoring ist nach Kubernetes das chronologisch gesehen zweite Projekt, das von der Cloud Native Computing Foundation gehostet wird. Es bietet ein Monitoring und Alerting Toolkit, welches sich insbesondere für die erwähnten Container-Umgebungen eignet.

Die Hauptfeatures eines modernen Monitoringsystems umfassen ein multidimensionales Datenmodell bestehend aus Zeitreihendaten in Form von Key/Value-Paaren, die über den Namen der Metrik zugeordnet werden. Prometheus verfügt zudem über eine starke Query-Sprache, PromQL, mit der man die gesammelten Daten in verschiedenen Konstellationen nutzen kann. Daten werden über einen Pull-Mechanismus über HTTP abgerufen, die Ziele für diesen Abruf können entweder dynamisch über Service-Discovery offengelegt oder statisch konfiguriert werden. Für kurzlebige Jobs, die nur zwischen den Pull-Intervallen stattfinden würden, existiert ein Push Gateway, an welches diese Jobs ihre Metriken senden können, bevor sie wieder verschwinden.

Besonders im Kubernetes-Kontext ist das offizielle Helm Chart kube-prometheus-stackzu empfehlen. Mit einem einzigen Befehl erhält man hier auch Grafana mit vorkonfigurierten Dashboards, die direkte Einsicht in die Ressourcen der Nodes bieten.

Nicht nur für Kubernetes geeignet

Wer jetzt denkt, Prometheus Monitioring eigne sich vor allem für Kubernetes, der liegt nicht ganz falsch. Dennoch bietet Prometheus ein exzellentes Monitoring auch auf einzelnen VMs oder Bare-Metal-Servern, wenn es als Docker Container gestartet wird. Möchte man nun die Metriken von einer spezifischen Maschine erhalten, wird hierfür lediglich der Node Exporter benötigt, der als GitHub-Projekt geklont wird und nur noch ausgeführt werden muss. Das ist alles, was notwendig ist, um äußert tiefgehende Metriken zu erhalten. Sobald dieser läuft, kann der Prometheus Container standardmäßig unter localhost:9090/metrics auf die vom Node Exporter zur Verfügung gestellten Metriken zugreifen.

Ohne Sichtbarkeit keine Kontrolle

Mit Prometheus ist verteiltes Monitoring keine unlösbare Aufgabe mehr und sollte besonders im DevOps-Kontext neben Tracing und Logging eine der drei Standard-Stacks sein, die in jeder Umgebung ausgerollt werden. In der eingangs beschriebenen Anekdote wäre ein kurzer Blick auf den Status der Nodes ausreichend gewesen, um zu erkennen, dass ein Ressourcenproblem besteht. Das hätte uns das zeitintensive Backtracking erspart. Im besten Fall hätten wir zuvor anhand unserer Metriken ein Alerting eingerichtet, das uns auf die drohende Ressourcenknappheit auf einem Node hingewiesen hätte. Dann hätten wir dieses Risiko in wenigen Minuten ausgemerzt.

Ein gutes Monitoring erspart im DevOps-Kontext viel Stress und der Kaffee kann in Ruhe genossen werden. Die Prämisse, unter der wir Monitoring für unsere Kunden betreiben, lautet hier immer „Fix it before it breaks“.