Monit veille à ce que les services tournent et les relève quand ils tombent. La première question légitime : à quoi bon, si systemd sait faire la même chose avec une seule ligne Restart=always ?

La réponse détermine toute la configuration. systemd voit qu’un processus s’est terminé et le relance. Il ne sait pas si le service répond aux requêtes. PHP-FPM ayant atteint sa limite de processus est bien vivant pour systemd, tandis que le site renvoie 502. MySQL à court d’espace disque continue d’exister comme processus et n’exécute plus une seule requête. Monit ne vérifie pas l’existence d’un processus mais son comportement : le port répond-il, que renvoie une requête HTTP, combien de mémoire est occupée.

D’où la règle : systemd reste tel quel, et Monit s’ajoute pour les vérifications fonctionnelles. Dupliquer le redémarrage d’un processus planté n’a pas de sens.

Configuration

sudo apt install monit

Le fichier principal est /etc/monit/monitrc ; vos vérifications se déposent en fichiers séparés dans /etc/monit/conf.d/. Le début habituel :

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

Une interrogation par minute est un équilibre raisonnable. Plus souvent ajoute de la charge et augmente le risque d’un redémarrage inutile pour une seconde de retard.

L’interface web : en local seulement

Monit possède une page web intégrée, et on l’active d’ordinaire comme le montre le premier guide venu — sur toutes les adresses. Le résultat est un panneau de commande des services du serveur, joignable depuis l’internet. La bonne variante :

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'un-mot-de-passe-long'

L’accès depuis l’extérieur passe par un tunnel SSH :

ssh -L 2812:localhost:2812 user@203.0.113.25

Ensuite, la page s’ouvre sur votre propre ordinateur à localhost:2812, et rien n’est exposé.

Des vérifications qui ont du sens

Le serveur web — non par la présence d’un processus mais par sa réponse :

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

Trois lignes y comptent plus que le reste.

protocol http ... status = 200 est la vérification pour laquelle tout cela a été mis en place : le serveur doit rendre une page, et pas seulement garder un port ouvert.

for 3 cycles signifie ne pas réagir à un échec isolé. Sans cela, Monit relancera le service pour une réponse lente sous charge, ce qui ne fait qu’aggraver la situation.

if 3 restarts within 10 cycles then unmonitor est une ligne obligatoire. Si un service ne remonte pas à cause d’une erreur de configuration, Monit le relancera sans fin, ajoutant de la charge et remplissant les journaux. Cette ligne signifie : trois tentatives ratées, on arrête et on laisse un message. Ensuite il faut un humain ; l’automatisme ne peut plus rien.

L’espace disque se vérifie sans aucun automatisme, simplement comme une alerte :

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

La ligne sur les inodes est nécessaire à part : ils s’épuisent indépendamment de la place, et sans elle cette situation passe inaperçue.

Vérifier la configuration

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

monit -t vérifie la syntaxe avant application. monit summary donne un court tableau d’états — le point de départ de l’examen de n’importe quel problème.

Et vérifiez que le courrier part. Monit signale les événements par courriel, et si l’envoi n’est pas configuré il n’y aura aucune notification : le service redémarrera et vous n’en saurez rien — alors que des redémarrages répétés sont précisément le signal principal. Ils se voient aussi dans le journal : /var/log/monit.log.

Ce que Monit ne fait pas

Il ne supprime pas la cause. Un redémarrage est un sursis, et un service constamment relancé signifie qu’il manque de la mémoire quelque part, que la place s’épuise ou que l’application fuit. La valeur de l’outil n’est pas dans le redémarrage mais dans le compteur : trois redémarrages de nginx en une journée constituent un diagnostic qui serait autrement passé inaperçu, puisque le site fonctionnait tout du long.

Ce qu’il faut donc regarder n’est pas l’état actuel — presque toujours vert — mais l’historique : combien de fois, la semaine passée, quelque chose est remonté tout seul. À quoi cela ressemble sur une page, la démonstration ci-dessous le montre.