© Dmitry Kalinovsky, 123RF

Wer eine Monitoringsuite abseits von Nagios und Co. sucht, trifft fast zwangsläufig auf Prometheus und Sensu. Beide versprechen ähnliche Funktionalität, unterscheiden sich aber fundamental voneinander.

[UCC:x-l-anfang-sys]Fragt man[/UCC] Admins, mit welchen Themen sie sich im Rahmen ihrer Arbeit besonders gerne beschäftigen, ist eine Antwort eher selten: Monitoring. Das hat mehrere Gründe. Einerseits scheinen die nötigen Programme von vornherein festzustehen: Nagios, Icinga, Check_Mk oder Zabbix und diverse Varianten oder Kombinationen dieser Suites. Andererseits genießt die Handhabung gerade jener Werkzeuge – das gilt für Nagios ganz besonders – keinen sehr guten Ruf.

Neue Herausforderungen für Monitoringsysteme tun sich zudem aus Richtung der Cloud auf: Starres Monitoring, wie es in konventionellen Setups meist zum Einsatz kommt, ist hier de facto unbrauchbar. Man stelle sich nur den Admin vor, der Hunderte Nagios-Konfigurationsdateien erstellt, weil er seine Plattform gerade erweitert hat.

Aber alles Gejammer hilft nicht: Monitoring ist unbestritten ein Teil des absoluten Pflichtprogramms. Ganz gleich also, ob es sich um Setups alter Art oder moderne Clouds handelt – ein Monitoringsystem ist unbedingt nötig. Und neben den oben genannten Kandidaten gibt es ja noch viele andere Werkzeuge.

Zwei davon sind Sensu [1] und Prometheus [2]. Beide Projekte sind nicht durch die Abspaltung von einem bereits existierenden Monitoringprodukt entstanden, sondern wurden neu entwickelt. Das ist eher untypisch, denn Icinga etwa stammte anfangs von Nagios ab, auch wenn Netways mittlerweile große Teile der Nagios-Codebase aus Icinga getilgt und durch eigenen Code ersetzt hat. Solche Altlasten gab es bei Prometheus oder Sensu erst gar nicht.

Auffällig ist bei beiden Lösungen auch, dass sie bereits viele Fans hinter sich wissen. Damit hören die Gemeinsamkeiten aber auch schon auf: Das Sensu-Konzept ist grundlegend anders als das von Prometheus. Trotzdem versprechen beide dem Admin das gleiche Resultat: Umfassendes, zuverlässiges und komfortables Monitoring. Der folgende Artikel stellt die Lösungen einander gegenüber, erklärt ihre Konzepte und zeigt, welche Lösung wofür besonders gut geeignet ist.

Sensu: Klassischer Ansatz

Das von Sean Porter geschriebene Werkzeug Sensu basiert auf Ruby und erblickte das Licht der IT-Welt im November 2011. Es steht unter der MIT-Lizenz und ist grundsätzlich kostenlos nutzbar. Ebenfalls verfügbar ist eine Enterprise-Version gegen Geld, die zusätzliche Features bietet und kommerziellen Support enthält. Das Verständnis von Monitoring, das Sensu umsetzt, gleicht grundsätzlich jenem, das auch bei Nagios & Co. zugrunde liegt: Das Tool überwacht auf den Zielsystemen vom Admin festzulegende Parameter wie CPU- oder RAM-Nutzung oder das korrekte Funktionieren eines bestimmten Dienstes.

Ein riesiges Problem bei den konventionellen Monitoringsystemen ist deren verbreitete Unfähigkeit, in die Breite zu skalieren. Ein Nagios-Server etwa kann eine bestimmte Anzahl Hosts überwachen. Es ist aber nur schwer möglich, die Monitoringarbeit auf mehrere Server aufzuteilen, ohne dabei den Single Point of Administration einzubüßen.

Erschwerend kommt hinzu, dass auch bei modernen Nagios-Installationen das Monitoring allein oft nicht mehr die einzige Funktion ist, die der Dienst erbringt: Viele Admins nutzen das Monitoring auch, um Trending-Daten aufzuzeichnen und aus diesen Graphen über die Systemauslastung zu generieren – die ironischerweise zumindest auf dem Monitoringserver selbst dadurch weiter steigt. Gleichzeitig nimmt die maximale Menge der überwachbaren Hosts durch das Datensammeln ab.

Verteilt zum Sieg

Sensu stellt sich diesem Problem mit einer modularen Architektur entgegen, bei der verschiedene Dienste auf mehreren Hosts zusammenarbeiten. Dreh- und Angelpunkt ist der Sensu-Server: Hier liegen alle Informationen über die überwachten Hosts und die überwachten Dienste samt historischer Daten. Weist der Admin Sensu an, Alarme bei einem bestimmten Check zu ignorieren (in Sensu-Terminologie heißt diese Anweisung “Stash”), wandert diese Information ebenso in den Sensu-Server. Der kümmert sich um seine Datenhaltung aber nicht selbst, sondern lagert das Problem an den verteilten Datenspeicher Redis aus.

Eine ausgezeichnete Idee, denn bekanntlich ist es eher kompliziert, über die Grenzen einzelner Knoten hinweg Daten persistent und konsistent abzulegen. Dass die Sensu-Entwickler sich um das Thema Monitoring kümmern und nicht versuchen im Vorbeigehen noch einen Distributed Storage zu bauen, ist ihnen hoch anzurechnen.

Praktisch: Es kann mehr als einen Sensu-Server geben. Gerade weil die Daten im Hintergrund in einem – ebenfalls skalierbaren – Redis-Cluster liegen, ist das kein Problem: Wenn die verschiedenen Instanzen des Sensu-Clusters auf dasselbe Redis zugreifen, bleibt das Gesamtsetup konsistent.

Zum Server gesellt sich das Sensu-API: Ganz klassisch folgt es dem REST-Prinzip und erlaubt es, standardisierte Anfragen an Sensu über das HTTP-Protokoll zu senden. Das API ist also die Schnittstelle zur Außenwelt, weil der Admin nur über sie in der Lage ist, irgendwelche Informationen aus Sensu zu erhalten. Sie ist obendrein der Andockpunkt für das Sensu-GUI Uchiwa, auf das der Artikel später noch eingeht.

Das API greift im Hintergrund ebenso auf die Daten aus Redis zurück. Das tut es direkt, es benötigt dafür also den Sensu-Server nicht. Praktisch bedeutet das, dass Sensu-Server und Sensu-API im Interesse der Skalierbarkeit auch auf getrennten Systemen laufen können.

Woher kommen die Daten?

Bislang ungeklärt ist die Frage, woher der Sensu-Server denn nun eigentlich seine Monitoringdaten bekommt. Dafür sind die Sensu-Clients zuständig: Die können in beliebiger Anzahl vorhanden sein. Die Sensu-Clients führen Checks aus, zeichnen die Resultate auf und senden sie an die Sensu-Server. Ein Check ist in Sensu klar definiert: Jedes beliebige Kommando, das der Sensu-Client auf der Kommandozeile ausführen kann. Der Ansatz ähnelt also jenem von Nagios. Und weil Sensu auch die Rückgabewerte der aufgerufenen Checks parsen kann, ist es sogar möglich, Nagios-Checks nahtlos in Sensu aufzunehmen.

Das ist äußerst praktisch in jenen Fällen, in denen Unternehmen von Nagios hin zu Sensu migrieren: Spezielle Checks muss der Admin nicht neu schreiben, stattdessen übernimmt er sie einfach in das neue Setup. Wer den Sensu-Client nur mit alten Nagios-Checks betreibt, bleibt aber weit unter dessen Potenzial: Er bietet nämlich auch eine umfassende Plugin-Schnittstelle [3] für native Monitoring-Plugins. Die nutzen dann die internen Datenstrukturen von Sensu direkt und bieten mehr Möglichkeiten als die Kompatibilitätslösung.

In der Sensu-Community stehen diverse Plugins für verschiedene Dienste frei zur Verfügung [4]. Zum Beispiel lässt sich mit dem Consul-Plugin der verteilte Key-Value-Store Consul umfassend prüfen: Das Plugin testet nicht nur, ob Consul auf allen gewünschten Hosts läuft, sondern liest auch die Laufzeitdaten von Consul aus, analysiert sie und schlägt beim Auftreten von Problemen Alarm.

Die Zeiten, in denen Admins mühsam Konfigurationsdateien ändern mussten, um dem Monitoringsystem neue Hosts beizubringen, sind zumindest bei Sensu vorbei. Denn ein Sensu-Client kann sich automatisch bei einem Server anmelden. Dazu genügt es, auf dem Client eine Konfigurationsdatei mit der Adresse des Sensu-Servers zu hinterlegen.

Das lässt sich prima in eine vorhandene Automatisierungslösung integrieren: Sobald etwa Ansible zum ersten Mal auf einem Host losläuft, scheint der Host automatisch in Sensu auf und hat gleich auch eine Clientkonfiguration, die relevante Checks durchführt.

Verteilte Kommunikation

Es stellt sich die Frage, wie Sensu-Clients, die es in einer Sensu-Installation ja mannigfaltig geben kann, mit den Sensu-Servern kommunizieren, von denen ebenfalls beliebig viele vorhanden sein mögen. Klar ist: In einem verteilten Setup ist es nicht praktikabel, einzelne Clients per Konfiguration fest an einzelne Instanzen der Sensu-Server zu binden. Denn das würde dazu führen, dass die mit einem Sensu-Server assoziierten Clients in der Luft hängen, falls dieser einmal ausfällt. Außerdem würde ein solcher Ansatz die Verwaltung der Sensu-Clients massiv erschweren: Der Admin müsste ja dann händisch Buch darüber führen, wie viele Clients er bereits einem Server zugewiesen hat.

Hier greifen die Sensu-Entwickler auf einen Trick zurück, der bereits aus dem Cloudumfeld, etwa von Open Stack, bestens bekannt ist: AMQP. Das ist ein eher betagtes Protokoll, dessen bekannteste Implementierung Rabbit MQ ist. Das System funktioniert auf Basis von Queues: Auf der einen Seite kippen die Lieferanten von Daten diese ins System, auf der anderen Seite konsumieren andere Dienste diese Daten und verarbeiten sie entsprechend.

Im Sensu-Kontext sind die Rollen klar verteilt: Die Sensu-Clients schieben ihre Monitoring-Ergebnisse per AMQP hin zu Rabbit MQ, wo die Sensu-Server sie auslesen (Abbildung 1). Weil alle Sensu-Server denselben Speicher nutzen, ist es egal, welche Instanz der Sensu-Server eine Information aus Rabbit MQ fischt. Es gilt das Prinzip, dass irgendein Sensu-Server zugreift, wenn er gerade freie Kapazitäten hat.

Abbildung 1: Bei Sensu kommunizieren die Server per Rabbit MQ mit Clients, die das Monitoring durchführen. Redis dient als Datenspeicher.

Bauchschmerzen bereitet hier aber die Tatsache, dass die Entwickler von Sensu sich ausgerechnet auf Rabbit MQ eingeschossen haben. Es ist zwar weit verbreitet, datiert aber in die 80er Jahre zurück und ist in der Programmiersprache Erlang verfasst. Da es nicht mehr viele Erlang-Entwickler gibt, ist Rabbit MQ für die meisten Firmen eine Blackbox.

Hinzu kommt, dass Rabbit MQ bis heute keine überzeugende HA-Lösung hat: Zwar gibt es verschiedene Ansätze, doch kämpfen diese allesamt mit mehr oder minder großen Problemen. Warum die Entscheidung der Entwickler nicht auf eine moderne AMQP-Implementierung gefallen ist, etwa Qpid des Apache-Projekts, bleibt rätselhaft.

Alarmierung

Ein Monitoring ist schön und gut, doch ohne die passende Alarmierung im Falle eines Falles ist es einigermaßen nutzlos. In Sensu kommen hier Handler ins Spiel: Die Sensu-Server rufen diese Handler auf, wenn bestimmte, zuvor durch den Admin festgelegte Ereignisse eintreten. Sensu bietet ab Werk die Möglichkeit, verschiedene Alarmierungsmechanismen in Gang zu setzen. Wer SMSs versenden will, hat auch kein Problem, weil ein Handler auch einfach ein externes Binary aufrufen kann, etwa ein Shellskript, das dann die Daten über die Webschnittstelle eines SMS-Dienstes weiterleitet. In Sachen Alarmierung zeigt sich Sensu insofern auf der Höhe der Zeit.

Neben Monitoring und Alerting wünschen Admins sich heutzutage auch eine dritte Funktion: Trending. Frühzeitig wollen sie wissen, wann sie ihr System um zusätzliche Hardware erweitern müssen, um Ressourcenengpässe gut und organisiert zu vermeiden. Sensu selbst beherrscht diese Funktion nicht, lässt sich aber problemlos an Graphite anbinden, das seinerseits die Daten verarbeitet und dann in einer Time-Series-Database wie Influx DB ablegt.

Weist der Admin einen Sensu-Client an, Metrik-Daten aufzuzeichnen, gibt Sensu diese unmittelbar an Graphite weiter. Hinzu kommt, dass sich in das Sensu-GUI Uchiwa Graphite-Daten einbinden lassen. Eine Lösung aus einem Guss ist das nicht, im Alltag funktioniert das Prinzip aber trotzdem.

Externes GUI

Sensu selbst kommt ab Werk ohne Webinterface oder ein anderes GUI daher. Das klingt grotesk, schließlich ist die Visualisierung von Monitoringdaten unbedingt nötig, um den Überblick zu behalten. Keine Panik: Es gibt ein GUI für Sensu, das auch aus der Feder der Sensu-Autoren stammt. Es ist ganz bewusst nicht Teil von Sensu selbst, weil die Entwickler es nur als eine Möglichkeit betrachten, Monitoringdaten aus Sensu zu visualisieren: Uchiwa ([5], Abbildung 2).

Abbildung 2: Uchiwa ist ein frei verfügbares Frontend für Sensu, das mittels des Sensu-API alle relevanten Daten besorgt.

Fakt ist: Daten aus Sensu lassen sich problemlos auch in andere Systeme oder GUIs einbinden, weil es eine offene, gut dokumentierte Schnittstelle ja auch und gerade für diesen Zweck gibt. Wer ein eigenständiges GUI benötigt, installiert Uchiwa zusätzlich zu Sensu. Solange Uchiwa mit dem Sensu-API zu kommunizieren imstande ist, kann es auf beliebigen Hosts laufen.

Dort bietet es klassische Hausmannskost: Im Hintergrund fragt es das API regelmäßig ab und stellt die erhaltenen Ergebnisse grafisch dar. Stashes sind ebenso anzulegen wie Aggregates, um bestimmte Hosts zu gruppieren. Mit einer Uchiwa-Instanz lassen sich mehrere Sites verwalten. Das Tool bietet obendrein die Möglichkeit, verschiedene Benutzer anzulegen, sodass jeder Admin eines Setups einen personalisierten Login bekommt.

Alles ganz anders: Prometheus

Der andere Proband im Test ist Prometheus. Er versteht sich nicht nur als Monitoringlösung, er bietet – so der eigene Anspruch – stattdessen echtes MAT, also Monitoring, Alerting und Trending. Tatsächlich unterscheidet sich Prometheus fundamental von Sensu: Die Datenhaltung ist bei Prometheus bereits eingebaut, sodass es nicht auf externe Dienste wie Redis zurückgreifen muss. Das hat einen handfesten Grund: Klassische Key-Value-Speicher oder Datenbanken wie MySQL sind denkbar schlecht geeignet, um Metrikdaten zu erfassen.

Dass dies so ist, belegen vorhandene Beispiele wie PNP4Nagios eindrücklich. Bei der Nutzung von Nagios und PNP4Nagios zeichnen die Monitoring-Checks von den Zielsystemen Metrikdaten auf und senden diese an das Monitoringsystem. Dort speichert PNP4Nagios diese Daten in einer klassischen Datenbank wie MySQL ab.

Das Problem: Will der Admin die Entwicklung der Metriken über einen bestimmten Zeitraum erfahren, erzwingt er damit gewaltige Datenbankanfragen. Denn in MySQL sind Metrikdaten stets nur für einen bestimmten Zeitpunkt verfügbar, der Admin will aber gerade nicht einen Zeitpunkt abfragen, sondern einen Zeitraum.

Die Icinga-Entwickler haben das bereits gemerkt und PNP4Icinga so umgebaut, dass es Metrikdaten gleich in RRD abspeichert. Prometheus geht noch weiter: Es folgt dem Prinzip der Time Series Database, speichert also Zeitreihen statt einzelne Werte ab. Die Daten liegen in der Datenbank schon im richtigen Format und lassen sich einfach auslesen.

Der Witz: Klassisches Monitoring auf Incident-Basis ist ein Abfallprodukt, das bei dieser Art der Datenhaltung entsteht. Lassen sich etwa von einem Host keine Metrikdaten mehr abfragen, ist er vermutlich kaputt – ein Alarm an den Bereitschafts-Admin ist die logische Konsequenz. Das gilt sogar dann, wenn nur ein einziger Wert fehlt: Auch der ist schließlich ein Zeitreihen-Datum, wenn auch ein sehr kurzes.

Mit eigener Datenbank

Die Aufgabe der Datenspeicherung übernimmt in Prometheus der Prometheus Server. Er ist selbst eine Time Series Database und entstammt dem Musikdienst Soundcloud. Dessen Anforderung war klar: Für ein großes und ständig wachsendes Servernetz brauchte man ein System, das MAT beherrscht. Es existieren zwar durchaus Zeitreihendatenbanken, etwa Open TSDB oder die etwas neuere Influx DB. Zufrieden war das Unternehmen aber mit all diesen Lösungen nicht, sodass es sich zu einer Eigenentwicklung entschloss. Der Erfolg gibt den Entwicklern mittlerweile recht: Prometheus gilt heute als ein sehr gutes und zuverlässiges MAT-System, obwohl es noch nicht sonderlich alt ist.

Prometheus-Server unterscheiden sich in einem Punkt fundamental von ihren Kollegen bei Sensu: Sie speichern die Daten im Hintergrund nicht verteilt ab. Zwar lässt sich ein Prometheus-Server grundsätzlich in die Breite skalieren, sodass mehrere Serverinstanzen in einer Installation existieren und so die Verteilung der anliegenden Last ermöglichen. All diese Serverinstanzen haben dann jedoch denselben Datensatz.

In größeren Setups ist die Empfehlung der Prometheus-Entwickler daher, auf ein Prinzip zu setzen, das dem Sharding bei E-Mails sehr ähnlich ist: Verschiedene Prometheus-Server sind dann für jeweils “ihre” Clients verantwortlich. Das ist nicht sonderlich elegant – aus genau den Gründen, die dieser Artikel bereits bei Sensu beschrieben hat. Bisher aber geben sich die Prometheus-Entwickler stur und empfehlen, lieber mehrere Prometheus-Instanzen zu betreiben.

Wie es mittlerweile üblich ist, bietet Prometheus ein API für Zugriffe von außen. Dafür haben die Prometheus-Entwickler sich sogar eine eigene Query-Sprache überlegt, die SQL ähnelt: PromQL. Mittels PromQL lassen sich Anfragen an einen Prometheus-Server auf spezifische Zeitreihenwerte beschränken, sodass der Admin nur genau jene Informationen erhält, die er in einem spezifischen Kontext benötigt.

Exporter

Damit es für den Admin was zum Auslesen gibt, müssen die Daten aber erst mal in Prometheus rein: Darum kümmern sich die so genannten Exporter. Sie basieren auf dem Pull-Prinzip: Der Prometheus-Server verbindet sich also mit den ihm bekannten Exportern und fragt die dort hinterlegten Werte ab. Für Dienste, die selbst das Pushverfahren nutzen, gibt es eine Gateway-Applikation, nämlich das Pushgateway: Das nimmt auf der einen Seite Daten entgegen und erlaubt es Prometheus andererseits, diese per Pull-Verfahren auszulesen.

Kompatibilität mit konventionellen Monitoring-Systemen wie Nagios erwartet der Admin hier besser nicht: Exporter für verschiedene Dienste sind Maßanfertigungen, die nur Prometheus sinnvoll nutzen kann. Die typischen Ausgaben von Nagios-Checks hingegen sind für Prometheus nutzlos.

Die gute Nachricht ist: Für die gängigen Dienste stehen Prometheus-Exporter im Netz zur Verfügung. Eine entsprechende Google-Suche hilft hier weiter. Bei vielen modernen Applikationen pflegt den jeweiligen Prometheus-Exporter sogar der Autor der Software selbst, etwa beim verteilten Objektspeicher Ceph. Ganz ähnlich wie bei Nagios & Co. funktioniert die Community auch bei Prometheus also ausgezeichnet. Prometheus selbst liefert zusätzliche Exporter, etwa den Nodeexporter, der klassische Systemwerte wie RAM- oder CPU-Nutzung an den Prometheus-Server übermittelt.

Neue Hosts per automatischer Erkennung

Auch bei Prometheus ist es nicht mehr nötig, zu überwachende Hosts zuerst händisch in irgendwelche Konfigurationsdateien zu schreiben. Prometheus kann mit vielen verschiedenen Diensten sprechen, um zu überwachende Knoten zu identifizieren: Es hat eine direkte Anbindung an Consul sowie an Kubernetes. Wer möchte, kann über entsprechende DNS-Einträge ebenfalls erreichen, dass Prometheus mit dem Abfragen von Informationen beginnt. Freilich lässt sich die Knoten-Integration auch spezifisch für das Setup vor Ort bauen.

Ähnlich wie bei Sensu kann man die Exporter bei Prometheus direkt über die Automatisierung in frisch installierte Hosts integrieren: Läuft also Ansible erstmals auf einem Host los und rollt verschiedene Exporter aus, tauchen diese anschließend direkt in Prometheus auf.

Alarmierung per Alertmanager

Zur Abwicklung des Alerting kommt Prometheus mit einer eigenen Komponente daher, dem Alertmanager. Wie der Rest von Prometheus ist auch dieser in der Programmiersprache Go verfasst. Er kann wahlweise Alarme per E-Mail oder per Pagerduty-Dienst versenden; eine generische Schnittstelle, um andere Lösungen anzubinden, existiert ebenfalls. Mittels Konfigurationsdatei deckt der Dienst viele unterschiedliche Fälle ab: So kann er Datenbankalarme direkt an das für sie zuständige Team senden, während Probleme für andere Komponenten bei anderen Empfängern landen.

Die Entscheidung darüber, was ein Alarm ist, trifft der Prometheus-Server übrigens auf Basis der Admin-Vorgaben selbst. Der Alertmanager ist also nur dazu da, im Falle eines Falles die richtigen Nachrichten zu versenden (Abbildung 3).

Abbildung 3: Über Alarme entscheidet Prometheus selbst, die Alarmierung jedoch ist Aufgabe des Alertmanagers.

Ohne GUI, dafür aber mit Grafana

Wie Sensu bietet auch Prometheus ab Werk kein GUI. Zwar gab es innerhalb der Prometheus-Community einst Bestrebungen, ein solches unter dem Namen Prom Dash zu schreiben. Letztlich besann man sich jedoch eines Besseren und unterstützte stattdessen die Grafana-Community darin, Grafana um Support für die Prometheus-Query-Sprache zu erweitern. Heute gilt Grafana ganz offiziell als die empfohlene grafische Schnittstelle zu Prometheus. Ein Stück weit rettet Grafana Prometheus hier im Rahmen dieses Vergleichs sogar, denn innerhalb einer Grafana-Installation lassen sich die Ausgaben vieler Prometheus-Server problemlos visualisieren.

Dadurch hat der Admin also weiterhin einen Single Point of Administration, sodass seine Unfähigkeit zum sinnvollen Skalieren in die Breite Prometheus doch nicht das Genick bricht. Wer Daten aus Prometheus-Servern optisch aufbereiten möchte, dem sei Grafana jedenfalls ans Herz gelegt (Abbildung 4).

Abbildung 4: Grafana dient als Standard-Frontend für Prometheus.

Fazit

Sensu ist besonders für jene Unternehmen gut geeignet, die aktuell noch ein Nagios-Setup betreiben und es loswerden möchten. Dass sich vorhandene Nagios-Checks einfach weiterverwenden lassen, bedeutet einen großen Vorteil im Zuge einer anstehenden Migration. Sehr angenehm ist auch, dass Sensu mit vielen der bekannten Nachteile konventioneller Monitoring-Systeme aufräumt: Etwa dass es problemlos möglich ist, Sensu in die Breite zu skalieren – und dass neue Hosts sich sogar automatisch bei den Sensu-Servern anmelden.

Weniger schön ist, dass Sensu für das oft benötigte Trending auf eine zusätzliche externe Komponente wie Graphite angewiesen ist – das erhöht die Komplexität des Setups merklich.

Prometheus folgt einem gänzlich anderen Ansatz: Hier steht nicht so sehr das Monitoring im Vordergrund, sondern das Trending, dessen Nebenprodukt dann das Monitoring der überwachten Dienste ist. Wer die Arbeit mit Nagios, Zabbix oder anderen klassischen Monitoringwerkzeugen gewohnt ist, der muss hier erst einmal umdenken.

Erschwerend kommt hinzu, dass sich Checks anderer Monitoringsysteme nicht problemlos mit Prometheus nutzen lassen. Die Migration von Nagios & Co. hin zu Prometheus ist daher deutlich schwieriger als bei Sensu. Im Gegenzug erhält der Admin bei Prometheus aber umfassendes Trending ab Werk, wofür er bei Sensu zusätzliche Dienste braucht.

Beide können mit modernen Features punkten: Neue Knoten erkennen sie auf Wunsch automatisch, und bei beiden Produkten lässt sich die anliegende Last auch auf mehrere Systeme verteilen. Sensu geht dabei aber um einiges eleganter vor als Prometheus, weil es tatsächlich horizontal skaliert, während Prometheus auf Sharding setzt, also eine Art Partitionierung mit festen Zuordnungen. Ursprünglich sollte einmal das Vulcan-Projekt Prometheus um echte horizontale Skalierbarkeit erweitern [6]. Allerdings war es bei Redaktionsschluss leider schon wieder verwaist.