Monit houdt in de gaten dat diensten draaien en zet ze weer overeind als ze omvallen. De eerste terechte vraag: waarvoor, als systemd hetzelfde kan met één regel Restart=always?

Het antwoord bepaalt de hele inrichting. systemd ziet dat een proces is beëindigd en start het opnieuw. Of de dienst op verzoeken antwoordt, weet het niet. PHP-FPM dat tegen zijn proceslimiet is aangelopen, leeft voor systemd, terwijl de site 502 teruggeeft. MySQL zonder schijfruimte blijft als proces bestaan en voert geen enkele query uit. Monit controleert niet het bestaan van een proces maar zijn gedrag: antwoordt de poort, wat geeft een HTTP-verzoek terug, hoeveel geheugen is bezet.

Vandaar de regel: systemd blijft zoals het is, en Monit komt erbij voor de functionele controles. Het herstarten van een gecrasht proces verdubbelen heeft geen zin.

Inrichting

sudo apt install monit

Het hoofdbestand is /etc/monit/monitrc; uw eigen controles komen als aparte bestanden in /etc/monit/conf.d/. Het gebruikelijke begin:

set daemon 60
set logfile /var/log/monit.log
set mailserver localhost
set alert admin@example.com

Eén peiling per minuut is een verstandig evenwicht. Vaker voegt belasting toe en verhoogt het risico op een onnodige herstart bij één seconde vertraging.

De webinterface: alleen lokaal

Monit heeft een ingebouwde webpagina, en die wordt doorgaans aangezet zoals de eerste de beste handleiding het toont — op alle adressen. Het resultaat is een bedieningspaneel voor de diensten van de server, bereikbaar vanaf internet. De juiste variant:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'een-lang-wachtwoord'

Toegang van buitenaf loopt via een SSH-tunnel:

ssh -L 2812:localhost:2812 user@203.0.113.25

Daarna opent de pagina op uw eigen computer op localhost:2812, en naar buiten wijst niets.

Controles die zin hebben

De webserver — niet op het bestaan van een proces maar op zijn antwoord:

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

Drie regels doen hier meer ter zake dan de rest.

protocol http ... status = 200 is de controle waarvoor dit alles is opgezet: de server moet een pagina teruggeven en niet alleen een poort openhouden.

for 3 cycles betekent niet reageren op één losse storing. Zonder die herstart Monit de dienst wegens één traag antwoord onder belasting, wat de zaak alleen verergert.

if 3 restarts within 10 cycles then unmonitor is een verplichte regel. Komt een dienst door een configuratiefout niet omhoog, dan herstart Monit hem eindeloos, voegt belasting toe en vult de logboeken. Die regel betekent: drie mislukte pogingen, stoppen en een bericht achterlaten. Verder is een mens nodig; automatiek helpt niet meer.

Schijfruimte wordt zonder enige automatiek gecontroleerd, alleen als melding:

check filesystem rootfs with path /
    if space usage > 85% then alert
    if inode usage > 85% then alert

De regel over inodes is apart nodig: die raken onafhankelijk van de ruimte op, en zonder haar blijft die situatie onopgemerkt.

De configuratie controleren

sudo monit -t
sudo systemctl reload monit
sudo monit summary
sudo monit status

monit -t controleert de syntaxis vóór toepassing. monit summary geeft een korte statustabel — het beginpunt bij het uitzoeken van welk probleem dan ook.

En controleer of de mail uitgaat. Monit meldt gebeurtenissen per e-mail, en is de verzending niet ingericht, dan komt er geen melding: de dienst herstart en u weet het niet — terwijl herhaalde herstarts juist het belangrijkste signaal zijn. Ze zijn ook in het logboek te zien: /var/log/monit.log.

Wat Monit niet doet

Het neemt de oorzaak niet weg. Een herstart is uitstel, en een dienst die voortdurend wordt herstart betekent dat er ergens geheugen tekortkomt, ruimte opraakt of dat de toepassing lekt. De waarde van het hulpmiddel zit niet in de herstart maar in de teller: drie nginx-herstarts op een dag zijn een diagnose die anders onopgemerkt was gebleven, want de site werkte de hele tijd.

U moet dus niet naar de huidige status kijken — die is vrijwel altijd groen — maar naar de historie: hoe vaak er de afgelopen week iets vanzelf weer omhoog is gekomen. Hoe dat op één pagina oogt, toont de demo hieronder.