Skalierbares Monitoring mit Prometheus

Fackelträger

Klassischen Monitoring-Lösungen geht die Puste aus, wenn sie mit den Anforderungen moderner, skalierbarer Setups konfrontiert sind. Prometheus tritt an, in solchen Umgebungen Monitoring, Alerting und Trending zu verwirklichen.
Damit Sie als Admin stets über alle Parameter Ihrer IT Bescheid wissen, befasst sich IT-Administrator im Juni mit dem Schwerpunkt 'Monitoring'. Darin lesen Sie ... (mehr)

Monitoring ist ein klassisches Fleißthema der IT: Ohne geht es zwar nicht, aber wirklich gern befassen sich auch nur wenige Admins mit der Materie. Das hat zum Teil mit der Komplexität althergebrachter Monitoring-Lösungen zu tun: Nagios, seine Nachfolger und Alternativen wie check_mk führen in klassischen IT-Umgebungen zwar letztlich zum Ziel, gelten vielen Admins jedoch als garstig und schwierig in der Handhabung. Und sie haben einen handfesten Nachteil: Mit den Anforderungen an moderne, skalierende Setups kommen sie mehr schlecht als recht klar.

Woran liegt das? Moderne IT-Architekturen unterscheiden sich von Lösungen der Vergangenheit meist fundamental dadurch, dass sie sich beliebig erweitern, also in die Breite skalieren lassen. Sie sind deutlich flexibler als ihre althergebrachten Kollegen: Oft laufen sie nicht mehr auf echtem Blech, sondern in virtuellen Maschinen in Clouds. Und wo man vor wenigen Jahren Wochen für die Planung und Umsetzung eines Setups brauchte, lassen sich in Clouds heute ganze virtuelle Umgebungen in 20 Minuten aus dem Boden stampfen. Hinzu kommt, dass sich diese virtuellen Setups zu jedem Zeitpunkt um beliebig viele Instanzen erweitern lassen.

Einerseits gilt die Grundregel nicht mehr, dass ein einmal konfiguriertes Monitoring für die gesamte Lebensdauer eines Setups praktisch unverändert bleibt. Und andererseits muss sinnvolles Monitoring heute nicht mehr nur auf den Ausfall eines Dienstes hinweisen. Es muss zusätzlich auch dem Admin verlässliche Daten dazu liefern, wann die Erweiterung des Setups (virtuell oder physisch) notwendig ist. Im Cloud-Kontext hat sich hierfür der Begriff "Monitoring, Alerting und Trending" etabliert, abgekürzt zu "MAT".

Monitoring und das mit ihm verbundene Alerting sowie Trending unterscheiden sich in der Art der Datenerhebung allerdings fundamental: Beim Monitoring will der Admin wissen, ob ein spezifischer Dienst zu einem bestimmten Zeitpunkt so funktioniert wie gewünscht. Ist das nicht der Fall, tritt das Alerting auf den Plan. Beim Trending interessiert den Admin hingegen, ob ein Kriterium wie “CPU-Nutzung" oder "RAM-Verbrauch" über einen bestimmten Zeitraum so hoch ist, dass das Skalieren der Plattform notwendig ist. Er muss also diverse Messdaten in einen zeitlichen Zusammenhang stellen, statt einen einzelnen Wert zu einem einzelnen Zeitpunkt abzufragen.

Die Monitoring-Lösung Prometheus [1] verspricht Admins, genau dieses Problem gut für sie zu lösen. Das ursprünglich von der Firma SoundCloud entwickelte Tool, das mittlerweile unter die Ägide der Linux Foundation geschlüpft ist, ist eine Zeitreihen-Datenbank und verspricht neben umfassendem Monitoring und Alerting auch Trending in eleganter Weise. Wodurch unterscheidet sich Prometheus etwa von Nagios? Der Knackpunkt ist, dass Prometheus seine Daten anders ablegt als Nagios und andere Lösungen (Bild 1).

Unterschiedliche Datenhaltung

Das Thema Trending im Monitoring-Kontext stellt die Admins von IT-Systemen in der Praxis vor große Probleme. Denn klassische Monitoring-Systeme wie Nagios sind eventbasiert: Geht ein Dienst kaputt, schlägt das Monitoring Alarm. PNP4Nagios soll das Problem für Nagios und damit kompatible Lösungen lösen, doch wer die Software nutzt, weiß um ihre Schwachstellen: Das Anzeigen von mit PNP4Nagios generierten Trending-Daten ist mühsam und verursacht nicht selten einiges an Last im Monitoring-System.

Bild 1: Nagios, Icinga & Co. arbeiten eventbasiert: Fällt ein Dienst aus, merkt das Monitoring das und generiert einen Alarm. Trending ist mit diesen Tools aber schwierig.

Der Grund dafür liegt in der Art und Weise, wie PNP4Nagios seine Metrikdaten speichert: Meist läuft im Hintergrund ein einfaches MySQL. Die Datenbank ist aber so gar nicht auf den Umgang mit Zeitreihen eingestellt: PNP4Nagios legt auf der einen Seite Metrikdaten als einzelne Einträge in MySQL ab. Will ein Admin auf der anderen Seite dann aus einer Vielzahl von Messpunkten, etwa zu CPU-Auslastung oder RAM-Verbrauch, eine chronologische Übersicht bauen, bombardiert PNP4Nagios die Datenbank mit entsprechenden Queries, deren Resultat sehr groß ist. Die für den Admin interessante Grafik generiert es aus dem Ergebnis der Abfrage am Ende selbst.

Zeitreihen-Datenbanken schaffen Abhilfe

Hier kommen die Zeitreihen-Datenbanken oder "Time Series Databases" ins Spiel: Sie nutzen intern ein anderes Prinzip, um ihre Daten abzulegen. Statt einzelner Ereignisse stehen hier Zeitreihen im Vordergrund: Über ein entsprechendes Query lässt sich aus einer solchen Datenbank etwa sofort herausfinden, wie sich etwa die CPU-Nutzung über einen Zeitraum entwickelt hat. Die Zeitreihen-Datenbank gibt direkt die entsprechende Zeitreihe aus, statt Einzelwerte anzuzeigen, die dann ein anderes Programm in Relation setzen muss. Und das Prinzip ist nicht neu: Die OpenTSDB etwa existiert seit Jahren und Lösungen wie InfluxDB oder Sensu erfreuen sich einiger Beliebtheit. Was zeichnet dann aber Prometheus aus?

Prometheus entstand ursprünglich als interne Monitoring-Lösung von SoundCloud. Der Dienst bietet Musik-Streaming nach dem Vorbild von Spotify oder Apple Music an und betreibt eine entsprechend große und breite Infrastruktur. Klassisches Monitoring, das war den SoundCloud-Entwicklern schnell klar, würde nur einen Teil ihrer Probleme lösen. Denn neben umfassendem Monitoring würden sie auch die Information brauchen, wann sie Hardware erweitern müssen – Trending und Monitoring müssen also zusammengehören. Die seinerzeit verfügbaren Lösungen stellten die SoundCloud-Admins aber nicht glücklich: InfluxDB etwa war ihnen nicht performant genug und OpenTSDB benötigt einen Hadoop-Cluster. Ein solches Setup ist entsprechend komplex. Kurzerhand entschiedenn sie sich also dafür, ein eigenes Moni- toring- und Trending-Werkzeug zu bauen – eben Prometheus. Mittlerweile ist Prometheus quasi der Shooting-Star beim Monitoring großer, skalierter Setups.

Prometheus wurde mit dem Ziel entwickelt, moderne Applikationen zu unterstützen, die auf einer Microservice-Architektur basieren. Folgerichtig baut auch das Programm selbst auf diesem Ansatz auf: Prometheus ist nicht ein einzelnes Programm, es handelt sich vielmehr um eine Sammlung von Werkzeugen, die ineinandergreifen und so zum gewünschten Ergebnis führen (Bild 2).

Bild 2: Die Grundarchitektur von Prometheus: Dem Server stehen die Exporter, das Push-Gateway sowie der Alertmanager und Grafana als Webinterface zur Seite.

Eine Kernkomponente gibt es aber doch: den Prometheus-Server, der vereinfacht ausgedrückt die Datenbank darstellt, in der die eingesammelten Daten abgelegt werden. Er erfüllt in einem Setup drei Aufgaben: Zunächst empfängt er alle Messdaten, die in einem Setup anfallen. Die integrierte Storage-Engine des Prometheus-Servers legt diese organisiert auf der Festplatte des Servers ab, auf dem der Prometheus-Server läuft. Zudem bietet der Prometheus-Server eine API-Schnittstelle, über die sich die Daten auf Basis eines festgelegten Standards auch wieder auslesen lassen. Dafür hat das SoundCloud-Team sogar eine eigene Abfragesprache entwickelt, die auf den Namen "PromQL" hört. Ein genauerer Blick auf die drei Aufgaben des Servers hilft, um die grundlegenden Design-Ansätze der Lösung zu verstehen.

Da ist zunächst die Frage, wie der Prometheus-Server an die Metrikdaten aus der Installation kommt. Zwei Schulen stehen sich gegenüber, und zwar auch bei klassischen Monitoring-Lösungen wie Nagios: Einerseits basieren viele Setups auf dem Prinzip, dass entsprechende Programme oder Checks die Daten selbst beim Monitoring-System abgeben, also dem Push-Prinzip folgen. Dementgegen beruht der alternative Ansatz darauf, dass das Monitoring-System die Messdaten selbst einsammelt, also einen Pull-Mechanismus nutzt. Beide Ansätze haben je nach Setup Vor- und Nachteile. Die Prometheus-Entwickler haben sich jedoch für ihr Produkt für einen Pull-Mechanismus entschieden: Der Prometheus-Server muss sich also selbst seine Messdaten bei den diversen Servern abholen. Diese Entscheidung begründen die Entwickler pragmatisch: Im Zweifelsfall sei es bei diesem Design möglich, besser vorauszusagen, ob ein Monitoring-Ziel komplett ausgefallen ist oder nicht. Zudem lassen sich so einzelne Werte auf Zielservern gezielt untersuchen, statt darauf zu warten, dass von dort Messdaten eintrudeln.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023