© luckybusiness, 123RF

Das Monitoringtool Prometheus macht zwar nicht in jedem Fall eine gottgleiche Figur, doch Zusätze wie Alerta oder Telegraf vermögen es deutlich zu verschönern.

Prometheus ist speziell für die Überwachung großer und skalierbarer Setups gemacht. Die Lösung besteht aus mehreren Komponenten: Prometheus selbst ist dabei nur die Zeitreihendatenbank (Time-Series Database, TSDB). Hinzu gesellt sich der Prometheus Node Exporter, der auf den Zielsystemen die grundlegenden Systemwerte liest und bereitstellt. Zusätzlich gibt es das Push-Gateway für die Werte, die Prometheus selbst nicht direkt auf den Hosts auslesen kann.

Falls sich in den Daten ein Problem abzeichnet, tritt der Alertmanager auf den Plan. Er vergleicht die eingehenden Metrikdaten mit Grenzwerten, die der Admin festgelegt hat. Läuft ein Wert aus dem Ruder, generiert er einen Alarm.

Schön, aber nicht ausreichend

Theoretisch lässt sich mit diesen Komponenten ein komplettes MAT-System (Monitoring, Alerting, Trending) bauen, das große Umgebungen problemlos überwacht. Praktisch werden dem Admin die Komponenten in dieser Zusammenstellung aber kaum genügen, denn es fehlen elementare Funktionen: Messdaten in Prometheus sind gut, es muss aber auch einen Weg geben, sie zu visualisieren. Lange Zeit hat Prometheus dafür ein eigenes Dashboard entwickelt – heute ist die offizielle Empfehlung, Grafana zu nutzen. Dafür existiert ein Grafana-Plug-in, womit sich Prometheus als Datenquelle konfigurieren lässt.

Das ist aber nur die halbe Miete: Wer Messwerte aus Prometheus in Grafana darstellen will, braucht passende Dashboards. Hinzu kommt, dass die vom Prometheus Node Exporter angebotenen Metriken in vielen Setups nicht ausreichen. Sonderfälle wie MySQL, Rabbit MQ oder Open Vswitch beherrscht der Node Exporter nicht.

Kummer macht auch der Alertmanager: Die meisten konventionellen Systeme für Monitoring bieten eine übersichtliche Webpage an, auf der die aktuellen Alarme verzeichnet sind. Im Alltag ist das praktisch und eigentlich auch unumgänglich. Der Alertmanager selbst hat aber nur ein rudimentäres GUI, das modernen Anforderungen nicht genügt.

Dieser Artikel widmet sich ergänzenden Projekten, die es für Prometheus gibt und die dem Admin das Leben leichter machen. Neben fertigen Dashboards für Grafana geht er auch auf verschiedene Metrikdaten-Exporter ein und stellt in Form von Alerta und Unsee gleich zwei Werkzeuge vor, die Alarme grafisch und gut aufbereitet darstellen.

Grafana

Setzt der Admin auf Prometheus als klassisches Monitoringsystem, kommt er mit einem großen Teil der von dem Tool erhobenen Messdaten erst gar nicht in direkten Kontakt. Denn dann analysiert lediglich der Alertmanager eintrudelnde Werte und schlägt gegebenenfalls Alarm. Das jedoch würde bedeuten, eine Kernfunktion von Prometheus brachliegen zu lassen: das Trending.

Trending wiederum setzt voraus, dass die in Prometheus liegenden Metrikdaten sich grafisch so aufbereiten lassen, dass sie für den Admin verständlich sind. Eine Tabelle, in der für 5000 Hosts Zahlen zum aktuellen RAM-Verbrauch verzeichnet sind, hilft ihm nicht viel. Ein entsprechender Graph, der den Verlauf der RAM-Nutzung darstellt, gibt deutlich mehr Aufschluss.

Grafana bietet genau diese Möglichkeit: Das Programm ist spezialisiert auf die grafische Darstellung von Werten aus verschiedenen Tools und unterstützt mittlerweile eine Vielzahl von Datenquellen. Eine der großen Grafana-Stärken ist zweifellos seine Modularität: Was ein Admin wie dargestellt haben möchte und welche verschiedenen Graphen er miteinander kombiniert, das legt er selbst fest. Dashboard nennt sich diese Funktion im Grafana-Sprech: Dashboards sind in beliebiger Anzahl definierbar und in ihnen lassen sich beliebig viele Metriken visualisieren, solange sie aus derselben Datenquelle stammen.

Das Problem: Ab Werk ist die Liste der Dashboards von Grafana leer. Baut sich der Admin ein nagelneues Prometheus-Setup, heißt es also zunächst, sich seine Dashboards mühsam zu konstruieren. Grafana erwartet die Dashboards nämlich im Json-Format, und auch die Bezeichnungen der einzelnen Metriken sind nicht so intuitiv, dass man zwangsläufig von alleine auf sie kommt.

Zwar gibt es mittlerweile Werkzeuge, die dem Admin das Erstellen der Json-Datei per GUI ermöglichen, aber den Katalog mit den Metriken wird er dennoch brauchen, und zeitaufwändig ist die Arbeit so oder so (Abbildung 1).

Abbildung 1: Mittels eines GUI ist es dem Admin mittlerweile möglich, sich seine Dashboards in Grafana zusammenzuklicken.

Das Rad nicht neu erfinden

Die gute Nachricht ist: Wer heute Prometheus und Grafana verheiraten will, ist nicht der erste Mensch mit diesem Anliegen. Entsprechende Setups gibt es etliche, und Grafana bietet auf seiner Website [1] auch einen Marktplatz, auf dem Entwickler ihre selbst gebauten Dashboards für die Öffentlichkeit bereitstellen können. Diese Dashboards lädt der Admin herunter, bevor er sie per Import-Button einfach in Grafana importiert – fertig! Und gegebenenfalls anpassen darf er die Vorlagen auch.

Wer fertige Dashboards aus dem Web in Grafana nutzen möchte, findet auf der dortigen Auswahlseite links verschiedene Filter. Die sind wichtig, denn wie das Dashboard gestrickt sein muss, hängt vorrangig vom Exporter ab, mit dem der Admin seine Messdaten sammelt. Nutzt er etwa den Prometheus Node Exporter, braucht er dazu passende Dashboards. Setzt er auf Telegraf, werden die Grafana-Dashboards für den Node Exporter nicht funktionieren.

Mehrere Dashboards aus der Grafana-Sammlung fallen besonders auf. Das für “Node Exporter Server Metrics” von Knut Ytterhaug beispielsweise ermöglicht es, die Werte für die Metriken des Node Exporter auf verschiedenen Server miteinander zu vergleichen. Alternativ dazu fungiert das “Prometheus System”-Dashboard von Thomas Cheronneau, das die Werte eines einzelnen Servers darstellt (Abbildung 2).

Abbildung 2: Der Node Exporter sammelt Messwerte zu grundlegenden Systemdetails, die sich dann grafisch aufbereiten lassen.

Besonders großer Beliebtheit erfreuen sich Grafana-Dashboards, die Daten von Docker aufbereitet darstellen: “Docker Host & Container Overview” zum Beispiel (Abbildung 3) gehört zu ihnen; es stellt dar, welche Container auf einem Host laufen und welche Ressourcen diese verbrauchen.

Abbildung 3: Auch wer Docker nutzt, findet fertige Grafana-Dashboards im Netz, um dessen Metriken zu verarbeiten.

Aber auch für weniger hippe Software finden sich fertige Dashboards: “Apache” etwa zeigt die Metrikdaten an, die Prometheus vom Webserver Apache einsammeln kann. Setzt man zusätzlich auf andere Exporter, erweitert sich der Umfang der für Grafana bereitstehenden Dashboards erneut. Wer etwa mit Telegraf Daten eines Open-Stack-Setups sammelt, lässt sie sich mit dem passenden Dashboard für Grafana anzeigen.

Insgesamt wird schnell klar: Wer Grafana mit den Dashboards aus dessen Tauschbörse kombiniert, geht wesentlich schneller an den Start, ohne Flexibilität zu verlieren. Ein ausführlicher Blick auf die Grafana-Website sei deshalb jedem angehenden Prometheus-Admin wärmstens ans Herz gelegt.

Telegraf

In beinahe jedem Prometheus-Setup dürfte neben Prometheus selbst auch der Prometheus Node Exporter zum Einsatz kommen. Unbedingt nötig ist das nicht: Aus welchen Quellen Prometheus seine Messwerte bezieht, ist ihm zunächst egal, solange die Daten im passenden Format vorliegen. Dass der Node Exporter sich trotzdem zur Allzweckwaffe entwickelt hat, liegt an seinem Funktionsumfang. Grundlegende Daten wie CPU-Last, RAM-Nutzung oder Load Average erhebt er ohne weitere Konfiguration. Damit bietet er die gleichen Funktionen, die viele auch in klassischen Monitoringsystemen zuerst nutzen.

Einerseits verfügt der Node Exporter über diverse Plugins, die neben den Basiswerten auch Sonderfälle wie etwa das Auslesen von Netzwerkstatistiken bei Infiniband-Karten erlauben. Andere Funktionen sind bei dem Programm jedoch verkümmert, etwa das Auslesen von SMART-Statistiken bei Festplatten. Hier kann der Node Exporter nur ein halbgares externes Skript aufrufen.

Die Prometheus-Entwickler finden zwar, dass ihre SMART-Implementation genau dem entspricht, was Prometheus bieten soll, und wenn einem Nutzer das nicht genügt, dann setze er Prometheus falsch ein. “You are holding it wrong” ist in der IT mittlerweile bekanntlich zum geflügelten Wort für diese Art von Antwort geworden.

Wer mit den Prometheus-Entwicklern nicht lange herumdiskutieren möchte, der findet in Telegraf möglicherweise eine gute Alternative zum Node Exporter: Das Programm gehört zwar eigentlich zum TICK-Stack von Influx DB und ist damit bei der Konkurrenz beheimatet. Die offenen APIs, die moderne Applikationen, also auch Prometheus und Influx DB, bieten, erledigen dieses Problem allerdings noch, bevor es eines geworden ist.

Prometheus redet mit Telegraf

Die offenen Standards von Prometheus ermöglichten es den Entwicklern von Telegraf, ihm eine Funktion zu spendieren, die Prometheus-kompatible Metrikwerte ausgibt. So wird Telegraf zum Drop-in-Replacement für Prometheus’ Node Exporter: Wie jener öffnet es einen TCP/IP-Port auf dem jeweiligen System und exponiert dort seine Metrikdaten. Prometheus konfiguriert der Admin so, dass es sich nicht mehr nur mit dem Prometheus Node Exporter verbindet, sondern auch den Telegraf-Port abfragt.

Dass Prometheus nicht mit seinem angestammten Exporter spricht, merkt man höchstens daran, dass die Metriken in Prometheus anschließend anders heißen. Für die Prometheus-Funktionalität aber ist das irrelevant, denn das Produkt ist darauf ausgelegt, verschiedenste Exporter zu unterstützen.

Es spricht auch nichts dagegen, die beiden Dienste zu kombinieren: Telegraf ist dem Prometheus Node Exporter nicht in jeder Hinsicht überlegen. Letzterer etwa sammelt verschiedene Metriken ein, für die es in Telegraf keine adäquate Entsprechung gibt – beispielsweise Metrikdaten zu Mellanox-Netzwerkkarten. Analog dazu ergibt es aus Admin-Sicht allerdings auch nicht viel Sinn, sowohl Telegraf als auch den Node Exporter sämtliche Metriken sammeln zu lassen. Denn viele gleichen sich und der Admin hätte letztlich eine riesige Menge redundanter Messdaten in seinem Prometheus.

Einen elementaren Vorteil bietet Telegraf übrigens in großen Setups, deren einzelne Netzwerksegmente durch Firewalls voneinander abgeschirmt sind. Will man als Admin in solchen Umgebungen verschiedene Exporter nutzen, endet das oft in einer massiven Durchlöcherung der Firewalls – denn theoretisch braucht jeder Exporter eine Portfreischaltung auf jeden Host und in jeder Firewall, die zwischen Host und Prometheus steht.

Mit Telegraf lässt sich das umgehen: Telegraf kann die Metriken von anderen Exportern einsammeln, die lediglich auf der IP-Adresse 127.0.0.1 lauschen, und diese in einem Rutsch an Prometheus übergeben. Großflächige Firewall-Bearbeitung erspart der Admin sich auf diese Weise.

Ausgesprochen praktisch ist neben der beschriebenen Sammelfunktion auch die bei Telegraf zum Lieferumfang gehörende Funktion, externe Skripte aufzurufen und deren Output als Metrikwert an Prometheus zu senden. So lassen sich sehr schnell Exporter für Metriken basteln, für die es bisher keine gibt.

Denkbar ist etwa das Überprüfen der Compliance auf Systemen per Inspec. Inspec [2] kann seine Resultate im Json-Format ausgeben. Ruft man per Telegraf also Inspec als externes Skript auf und sendet die Ergebnisse an Prometheus, so kann Prometheus einen Alarm auslösen, wenn ein Compliance-Test fehlschlägt.

Alerta

Der Prometheus Alertmanager verrichtet seine Arbeit grundsätzlich zuverlässig, wenn der Admin ihn entsprechend konfiguriert. Wie er Alarme grafisch aufbereitet, überzeugt dagegen nicht. Zwar existiert eine Webschnittstelle, doch die listet nur einigermaßen nüchtern jene Alarme auf, die im Alertmanager gerade existieren.

Wer die grafische Darstellung kennt, die Nagios oder Icinga verwenden, kommt mit dem Alertmanager kaum zurecht. Als Werkzeug, das in einem Kontrollzentrum auf einem Bildschirm läuft und Admins schnell über Alarme informiert, taugt das Web-GUI des Alertmanager jedenfalls nicht. Genau ein solches Werkzeug gehört in den meisten Operations-Büros jedoch zur Standardausstattung.

Weil der Alertmanager aber ein offenes API hat, können sich grundsätzlich auch andere Werkzeuge als jene aus der Prometheus-Toolchain mit ihm verbinden. Die Entwickler des TICK-Stacks machen sich das einmal mehr zunutze und haben ihrem Werkzeug Alerta eine Schnittstelle spendiert, um mit dem Prometheus Alertmanager zu reden.

Alerta selbst besteht aus mehreren Komponenten. Die wichtigste aus Nutzersicht ist zweifellos das Web-UI (Abbildung 4): Mit mehreren Farben, die der Admin per Konfigurationsdatei festlegt, zeigt Alerta Alarme an. Nicht zu vergessen ist aber auch das Alerta-API, es sorgt überhaupt erst dafür, dass im Alerta-Webfrontend Alarme auftauchen.

Abbildung 4: Alerta ist eine übersichtliche und intuitive Alternative zum GUI des Prometheus Alertmanager.

Alle Alarme verwaltet Alerta mit Hilfe seines API, das Web-UI zeigt diese nur an. Alternativ zum Web-UI gibt es folglich auch ein CLI, über das sich Alerta-Alarme mittels der Shell manipulieren lassen. Allerdings bekäme das der Alertmanager, der ebenfalls über eine CLI-Komponente verfügt, auch hin.

Das Web-UI erweist sich im Praxistest als ausgesprochen nützlich: Nicht nur zeigt es aktuelle Alarme tabellarisch aufgelistet an, es offeriert auch verschiedene Details dazu, etwa das Datum, an dem der Alarm zum ersten Mal auftauchte, oder Details zur Art des Alarms. Das passiert, sobald der Admin auf einen Alarm aus der Liste klickt.

Alerta unterscheidet bei der Anzeige von Fehlern grundsätzlich zwischen mehreren Problemstufen: Kritische Fehler (»Critical«) zeigt das Tool in tiefem Rot an. Fehler (»Major«) sind dunkelorange hinterlegt, Fehler, die weniger kritisch sind, in Gelb (»Minor«). Warnungen sind blau hinterlegt. Den Grad der Relevanz eines Problems legt Prometheus fest.

Noch mehr Übersicht

Um die Verständlichkeit von Alerta weiter zu verbessern, teilt Alerta zudem eingehende Alarme in verschiedene Kategorien auf, wenn das Monitoringsystem diese mitschickt. Hat der Admin also in Prometheus mit Labels dafür gesorgt, dass Alarme anhand verschiedener Parameter sortiert werden, übernimmt Alerta diese Kategorisierung ohne jede weitere Konfiguration. Die Kooperation zwischen Alerta und Prometheus erwies sich im Test als fehlerfrei.

Nicht ganz perfekt ist die Integration zwischen den Diensten allerdings im Hinblick auf die Manipulation von Alarmen durch den Admin in Alerta. Alerta bietet dem Admin die Möglichkeit, einen Alarm zu bestätigen, sodass er nicht länger in der Liste akuter Alarme auftaucht. Klickt der Admin allerdings auf »Acknowledge« in Alerta, wirkt sich das auf den entsprechenden Alarm im Alertmanager nicht unmittelbar aus. Immerhin: Im Alerta-Github-Ordner findet sich ein Modul [3], mit dem sich diese Art der Integration nachrüsten lässt.

Zweifellos die größte Stärke von Alerta ist seine Vielseitigkeit. Die zieht sich auf mehreren Ebenen durch das ganze Programm. Beispiel Accounts: Alerta hat eine eigene Accountverwaltung, die sich aber problemlos an externe Dienste wie O-Auth oder LDAP ankoppeln lässt. Beispiel Alarmquellen: Alerta ist nicht explizit für den Alertmanager von Prometheus gemacht, sondern kann Alarme auch von einer Vielzahl anderer Dienste empfangen. Dazu gehören mit Nagios und Zabbix auch Monitoringsysteme klassischer Bauart.

Was sich für Unternehmen als großer Vorteil herausstellen kann: Wer bereits klassisches Monitoring für konventionelle Setups betreibt und dann eine Cloud mit Prometheus hinzukommt, vereint mit Alerta alle Alarme unter einer einheitlichen Oberfläche. Auch für eine Vielzahl öffentlicher Cloudimplementationen hat Alerta native Schnittstellen, etwa für AWS Cloudwatch.

Außerdem lassen sich in Alerta mehrere Alarmquellen desselben Typs einrichten. Admins, die ein geografisch verteiltes Setup betreiben und dafür jeweils eigene Prometheus-Instanzen samt Alertmanager ausrollen, können diese Alarme am Ende in Alerta problemlos und an zentraler Stelle sammeln.

Wer also auf der Suche nach einem brauchbaren grafischen Alerting-Werkzeug für Alarme mit Prometheus ist, sollte sich Alerta dringend anschauen. Weil die Alerta-Entwickler ihr Tool in Form eines Docker-Containers anbieten, ist es sehr leicht auszuprobieren. Auch die Alerta-Konfiguration stellt den Admin mit Clouderfahrung kaum vor erwähnenswerte Herausforderungen. Alerta ist insofern eine echte Empfehlung.

Unsee

Ein zweites Projekt geht das Problem an, dass sich das Alertmanager-Web-UI kaum sinnvoll für Dashboards nutzen lässt: Unsee [4]. Die Software stammt aus der Feder des Cloudanbieters Cloudflare und richtet sich spezifisch an Prometheus. Die umfassende Integration in andere Werkzeuge, mit der Alerta punktet, fehlt bei Unsee komplett.

Bei der grafischen Darstellung von Alarmen geht Unsee ebenfalls andere Wege als Alerta: Letzteres erinnert bei seiner Darstellung eher an Nagios oder Icinga, Unsee hingegen nimmt das Schlagwort Dashboard ernst und ordnet seine Alarme in Form von Boxen an (Abbildung 5), die es über den Bildschirm verteilt.

Abbildung 5: Anders als Alerta folgt Unsee dem Dashboard-Ansatz und richtet sich explizit an Prometheus-Nutzer.

Auch Unsee kommuniziert direkt mit dem Alertmanager über dessen API, bekommt also auch gesetzte Labels mit, die zu einem Alarm gehören. Wie Alerta zeigt Unsee diese Labels und Tags mit an. Bestätigt der Admin einen Alarm mittels der Acknowledge-Funktion im Alertmanager, erscheint auch diese Information in Unsee.

Unsee selbst hat zudem eine Möglichkeit, Alarme zu bearbeiten – der Admin kommt hier also um das Alertmanager-Dashboard herum, wenn er will. Wer diese Funktionalität nicht nutzen möchte, kann Unsee auch im Read-only-Modus betreiben – das setzt aber Bastelei voraus und ist nicht sonderlich intuitiv.

Dass Unsee generell deutlich simpler gestrickt ist als Alerta, wird auch darin offensichtlich, dass Unsee keine eigene Benutzerverwaltung hat. Der Login funktioniert stattdessen mit denselben Credentials, die der Nutzer auch im Web-Interface des Alertmanager verwenden würde.

Damit ist klar: Wer Alerta nicht mag, findet in Unsee womöglich eine sehr leichtgewichtige und trotzdem effiziente Alternative. Die macht optisch eine ähnlich gute Figur und wird seitens der Entwickler wie Alerta als Container für Docker vertrieben – das Ausprobieren ist also nicht schwierig. Unsee gilt damit als eine Art Geheimtipp.

Fazit

Prometheus allein macht nicht uneingeschränkt glücklich. Doch wer sich der diversen Erweiterungen bedient, der erhält als Lohn für die Mühe einen echten Mehrwert in Form erweiterter Funktionen. Als Anzeiger für visuelle Alarme etwa sticht Alerta das Webinterface des Alertmanager von Prometheus ohne Frage aus. Und auch andere externe Werkzeuge wie etwa Telegraf sind sehr wertvolle Erweiterungen.