Monit achtet darauf, dass Dienste laufen, und holt sie zurück, wenn sie ausfallen. Die erste berechtigte Frage: wozu, wenn systemd dasselbe mit einer einzigen Zeile Restart=always kann?
Die Antwort bestimmt die gesamte Einrichtung. systemd sieht, dass ein Prozess beendet wurde, und startet ihn erneut. Ob der Dienst auf Anfragen antwortet, weiß es nicht. PHP-FPM, das an sein Prozesslimit gestoßen ist, ist für systemd wohlauf, während die Website 502 liefert. MySQL, dem der Plattenplatz ausging, läuft als Prozess weiter und führt keine einzige Abfrage aus. Monit prüft nicht die Existenz eines Prozesses, sondern sein Verhalten: ob der Port antwortet, was eine HTTP-Anfrage zurückgibt, wie viel Speicher belegt ist.
Daraus die Regel: systemd bleibt, wie es ist, und Monit kommt für die funktionalen Prüfungen hinzu. Den Neustart eines abgestürzten Prozesses zu verdoppeln bringt nichts.
Einrichtung
sudo apt install monit
Die Hauptdatei ist /etc/monit/monitrc; eigene Prüfungen kommen als separate Dateien nach /etc/monit/conf.d/. Der übliche Anfang:
set daemon 60
set logfile /var/log/monit.log
set mailserver localhost
set alert admin@example.com
Eine Abfrage pro Minute ist ein vernünftiges Gleichgewicht. Häufiger erzeugt Last und erhöht das Risiko eines Fehlneustarts wegen einer Sekunde Verzögerung.
Die Weboberfläche: nur lokal
Monit bringt eine eingebaute Webseite mit, und die wird meist so aktiviert, wie es die erstbeste Anleitung zeigt — auf allen Adressen. Ergebnis ist ein Steuerungspanel für die Dienste des Servers, erreichbar aus dem Internet. Die richtige Variante:
set httpd port 2812 and
use address localhost
allow localhost
allow admin:'ein-langes-passwort'
Der Zugriff von außen läuft über einen SSH-Tunnel:
ssh -L 2812:localhost:2812 user@203.0.113.25
Danach öffnet sich die Seite auf Ihrem eigenen Rechner unter localhost:2812, und nach außen zeigt nichts.
Prüfungen, die Sinn ergeben
Der Webserver — nicht am Vorhandensein eines Prozesses, sondern an seiner Antwort:
check process nginx with pidfile /run/nginx.pid
start program = "/bin/systemctl start nginx"
stop program = "/bin/systemctl stop nginx"
if failed host 127.0.0.1 port 80 protocol http
request "/" status = 200
for 3 cycles then restart
if 3 restarts within 10 cycles then unmonitor
Drei Zeilen sind hier wichtiger als der Rest.
protocol http ... status = 200 ist die Prüfung, derentwegen das Ganze eingerichtet wurde: Der Server muss eine Seite liefern und nicht bloß einen Port offen halten.
for 3 cycles heißt, auf einen einzelnen Fehlschlag nicht zu reagieren. Ohne das startet Monit den Dienst wegen einer langsamen Antwort unter Last neu und verschlimmert die Lage nur.
if 3 restarts within 10 cycles then unmonitor ist eine zwingende Zeile. Kommt ein Dienst wegen eines Konfigurationsfehlers nicht hoch, startet Monit ihn endlos neu, erzeugt Last und füllt die Protokolle. Diese Zeile bedeutet: drei Fehlversuche, dann aufhören und eine Meldung hinterlassen. Weiter braucht es einen Menschen; die Automatik hilft nicht mehr.
Der Plattenplatz wird ganz ohne Automatik geprüft, nur als Meldung:
check filesystem rootfs with path /
if space usage > 85% then alert
if inode usage > 85% then alert
Die Zeile zu den Inodes wird gesondert gebraucht: Sie gehen unabhängig vom Platz zur Neige, und ohne sie bleibt diese Lage unbemerkt.
Die Konfiguration prüfen
sudo monit -t
sudo systemctl reload monit
sudo monit summary
sudo monit status
monit -t prüft die Syntax vor der Anwendung. monit summary gibt eine kurze Zustandstabelle — der Ausgangspunkt bei der Untersuchung jedes Problems.
Und prüfen Sie, ob Mail versendet wird. Monit meldet Ereignisse per Mail, und ist der Versand nicht eingerichtet, gibt es keine Benachrichtigung: Der Dienst startet neu, und Sie erfahren nichts davon — dabei sind wiederholte Neustarts genau das Hauptsignal. Zu sehen sind sie auch im Protokoll: /var/log/monit.log.
Was Monit nicht leistet
Es beseitigt die Ursache nicht. Ein Neustart ist ein Aufschub, und ein ständig neu gestarteter Dienst bedeutet, dass irgendwo Speicher fehlt, Platz ausgeht oder die Anwendung leckt. Der Wert des Werkzeugs liegt nicht im Neustart, sondern im Zähler: drei nginx-Neustarts an einem Tag sind eine Diagnose, die sonst unbemerkt geblieben wäre, weil die Website die ganze Zeit lief.
Anzusehen ist deshalb nicht der aktuelle Zustand — er ist fast immer grün —, sondern der Verlauf: wie oft in der vergangenen Woche etwas von selbst wieder hochkam. Wie das auf einer Seite aussieht, zeigt die Demo unten.