© Markus Feilner

Monit ist ein in C geschriebenes Monitoring-Werkzeug, dessen Züchter behauptet, dass es die Überwachung einzelner, gleichlautender Prozesse besonders gut beherrscht.

Monit [1] bewirbt sich selbst mit einem Slogan, der zunächst eher schräg wirkt: “Barking at daemons” ziert das Logo der Applikation, übersetzt etwa “Dämonen anbellen”. Gemeint sind offenbar Unix-Daemons, und die Monit-Entwickler verstehen ihr Programm als Wachhund, der die Dienste überprüft und gegebenenfalls auch mal neu startet.

Allerdings beschränkt sich der Umfang von Monit nicht auf das Überprüfen von Prozessen – das Werkzeug kann viel mehr. Wer Icinga oder Nagios gewohnt ist, dem fällt bei Monit aber wohl im ersten Augenblick vor allem die Schlichtheit des Tools auf.

Einfach und schnell

Noch ein Slogan: Die Monit-Entwickler versprechen Admins, dass sie nicht mehr als 30 Sekunden benötigen, um vom Entpacken von Monit bis zum lauffähigen Monitoring zu kommen. Monit setzt im Hintergrund entweder auf eine MySQL- oder eine PostgreSQL-Datenbank. Ist diese erst mal eingerichtet, braucht es nur noch die entsprechenden Zugangsdaten. Dann bedient der Admin Monit mit dem eingebauten Webserver, der per Browser ganz normal zu erreichen ist.

Einzige Voraussetzung ist die Installation der Monit-Pakete auf dem Server: Auf einem Centos- oder RHEL-System ist das kein Problem, sofern das EPEL-Repository aktiviert ist. Auf Debian- und Ubuntu-Systemen ist die Sache noch leichter, denn Monit kommt direkt als fertiges Paket vom Distributor und lässt sich wie gewohnt installieren.

Wer jedoch Monit vom Browser aus einrichten will, sieht sich getäuscht: Seine Konfiguration bezieht Monit ausschließlich aus der zentralen Konfigurationsdatei, die üblicherweise in »/etc/monitrc« zu finden ist. Im Vergleich zu Nagios oder Icinga wird eine Konfiguration aber meist nie so komplex, dass man sie auf mehrere Dateien mit Inklusionsbefehlen aufteilen müsste – überhaupt ist die Syntax, die in »monitrc« zum Einsatz kommt, einprägsam und nachvollziehbar (Abbildung 1).

Abbildung 1: Monit ist leicht einzurichten und testet Prozesse auf Hosts.

Monit und M/Monit

Monit kommt übrigens in zwei Varianten daher, wobei die kommerzielle Version M/Monit lediglich Monit um kostenpflichtige, aber vor allem in Unternehmen wichtige Features erweitert.

Das klassische Monit ist darauf ausgelegt, nur die Dienste eines Servers zu überprüfen, gegebenenfalls Alarm zu schlagen und Dienste, falls gewünscht, neu zu starten. Gemeint ist dabei genau der Host, auf dem Monit tatsächlich läuft. Soll das Setup eher dem typischen, sternförmigen Monitoring-Setup entsprechen, benötigt der Admin quasi als Aufsatz für Monit das kommerzielle Addon M/Monit ([2], Abbildung 2). Dessen simple Weboberfläche ermöglicht es, verschiedene Monit-Instanzen sinnvoll und zentral zu verwalten.

Abbildung 2: M/Monit ist die kommerzielle Version von Monit.

Ein Setup aus Monit und M/Monit entspricht insofern eher dem, was Nagios- oder Icinga-Installationen abbilden. Der Pferdefuß an der Sache ist, dass Admins für M/Monit eine Lizenz benötigen, deren Kosten sich an der Zahl der zu überwachenden Rechner orientiert. Für eine Lizenz ohne jede Einschränkung verlangt der Hersteller rund 500 Euro.

Das ist nun kein Riesenbetrag, dürfte dem einen oder anderen Admin aber trotzdem sauer aufstoßen. Denn ohne M/Monit ist Monit nur eingeschränkt in komplexen IT-Setups zu gebrauchen. Um die Funktionalität einer VM aus sich heraus zu überwachen und sicherzustellen, dass die gewünschten Dienste laufen, reicht Monit aber völlig aus. Geht etwas schief, startet es entweder die betroffenen Programme selber neu oder alarmiert per Mail den Admin.

Solch ein Setup scheint vorrangig deshalb attraktiv, weil Monit nicht besonders komplex zu konfigurieren ist und eine vollständige Monit-Instanz sich sogar problemlos als fester Bestandteil eines VM-Blanko-Image oder als Dienst per Puppet oder Chef etablieren lässt. Eine neue VM aktiviert Monit dann schon beim ersten Booten. Allerdings wäre es mit Monit allein unmöglich, vom Hypervisor aus den Gesundheitszustand einer virtuellen Maschine zu überwachen – hierfür wäre M/Monit nötig.

Hosts und Services

Monit unterscheidet zwischen mehreren Servicetypen. Mit dreien davon wird der Admin im Alltag konfrontiert: In der Kategorie »Host« legt der Admin grundsätzlich nur den Rechner fest, auf dem Monit selbst läuft (das ist auf die zuvor beschriebene Einschränkung im freien Monit zurückzuführen). Für den Typ »Host« kennt Monit Parameter, nach denen das Werkzeug den Zustand eines Systems bewertet. Dazu gehört die Systemlast »Load Average« genauso wie die RAM- und Swap-Auslastung sowie die insgesamt benötigte CPU-Leistung aller Prozesse. Für jeden der Parameter lassen sich die Schwellenwerte für die Alarmierung beliebig festsetzen.

Typ 2 der Dienste bezeichnet den Parameter »Diskusage« , der den Zustand von Dateisystemen eines Systems überwachen hilft. Auch bei diesem Parameter lassen sich Schwellenwerte angeben, die Monit zum Alarm veranlassen.

Als dritte Kategorie gibt es die »Process-Checks« . Mit diesen Checks hat eigentlich alles angefangen, denn ursprünglich hat Monit sich darauf konzentriert, Prozesse zu überprüfen und ihre gewünschte Funktionalität über einzelne Parameter zu überwachen. Admins, die viele Ruby-on-Rails-Seiten auf ihren Systemen hosten, haben bis heute genau deshalb ein Faible für Monit.

Denn im Gegensatz zu anderen Monitoring-Systemen überwachen sie mit Monit überaus komfortabel Mongrel-Prozesse. Mongrel [3] ist der Webserver, der bei Ruby-on-Rails-Setups üblicherweise zum Einsatz kommt. Damit ein Setup gut performt, benötigt man eine Vielzahl identischer Mongrel-Prozesse. Bei solch feingliedrigem Monitoring zeigt sich die Stärke von Monit.

Hypervisor

Im Hinblick auf den Hypervisor kann Monit offensichtlich nur einen Teil der geforderten Funktionalität bieten. Mit der Belegung der Dateisysteme, der CPU-Last oder der RAM-Nutzung hat Monit keinerlei Probleme. Mit den Smart-Daten von Laufwerken vermag es hingegen gar nichts anzufangen, genauso wenig kann Monit überprüfen, wie die Auslastung des Netzes des jeweiligen Systems gerade ist.

Selbst ein Test, der feststellt, ob eine beliebige virtuelle Maschine tatsächlich läuft, erfordert Handarbeit. Denn für solch einen Check müsste der Admin die Kommandozeile des Qemu-Aufrufs genauer analysieren und einen spezifischen Prozesscheck basteln, der auf eine Instanz von Qemu testet und überprüft, ob diese den Namen der VM enthält – komfortabel ist was anderes.

Ganz ähnlich verhält es sich auch mit dem Gast. In dem müsste zwangsläufig eine eigene Monit-Instanz laufen, die auch selbst alarmiert. Hier kann Monit allerdings seine große Flexibilität im Hinblick auf zu prüfende Prozesse nutzen und fein abgestimmt alle in der VM laufenden Programme testen. Praktisch sind der Fantasie dabei keine Grenzen gesetzt; Checks lassen sich beliebig einbauen.

Fazit: Wirklich nötig?

Es wäre ungerecht, Monit mit den großen Monitoring-Lösungen zu vergleichen. Denn ein umfassendes Monitoring-Framework will Monit gar nicht sein. Das Programm hat seine große Stärke darin, die Funktionalität einzelner Programme auf Systemen über Checks mit einer Vielzahl von frei definierbaren Parametern zu überprüfen.

Wer das Framework einrichten will, kommt um M/Monit nicht herum, muss also zur kommerziellen Variante greifen. Vor einem solchen Schritt täten IT-Planer allerdings gut daran, über ihre Anforderungen nachzudenken und sich die Frage zu stellen, ob sie wirklich ein komplexes Monitoring brauchen. Wenn es nur darum geht, die Verfügbarkeit eines Hosts zu überprüfen und die anderen Tests durch Monit auf dem Host selbst abzufackeln, dann genügt möglicherweise auch ein simpler Ping-Test, wie er sich auf vielen Seiten im Netz problem- und kostenlos einrichten lässt.