⚙️ Monit – Supervision, "Watchdog" & Auto-Remediation

Qu'est-ce que Monit ?

Monit (par M/Monit) est un utilitaire open-source (léger) pour Linux/Unix. C'est un "Watchdog" (Chien de Garde).

Son objectif n'est pas (principalement) le graphing (comme Zabbix/Prometheus), mais l'Auto-Remediation (Auto-Réparation).

Philosophie : Monit surveille (poll) activement les processus, fichiers, et connexions réseau. S'il détecte une panne (ex: service "down", port 80 ne répond pas, usage CPU > 95%), il exécute une action (ex: restart, alert).

Cas d'Usage Typique

"Mon serveur Nginx (nginx) ou mon application (gunicorn) crashe parfois à 3h du matin (ex: fuite mémoire)."

• Sans Monit : Le site est DOWN. L'admin est réveillé à 3h05 par PagerDuty.
• Avec Monit :
  • (3h01) Monit (qui checke nginx.pid toutes les 30s) détecte que le PID a disparu.
  • (3h01) Monit exécute l'action : then restart.
  • (3h01) Monit lance /etc/init.d/nginx start.
  • (3h01) Le service est UP. L'admin n'est jamais réveillé.

Monit (comme Supervisor) utilise une architecture "Client/Serveur", mais les deux rôles sont gérés par le même binaire : monit.

$ sudo monit status   (Voir l'état)
$ sudo monit summary  (Résumé)
$ sudo monit restart nginx
$ sudo monit reload     (Recharger la config)

Ces trois outils gèrent des processus, mais n'ont pas le même objectif.

Le fichier de configuration principal est /etc/monit/monitrc (ou /etc/monitrc).

Il définit le comportement du daemon monit.

# --- Cycle de Polling ---
# (Se réveille toutes les 30 secondes pour faire les checks)
set daemon 30

# --- Logs ---
set logfile /var/log/monit.log

# --- Alertes Email (Optionnel) ---
set mailserver smtp.example.com
set mail-format { from: monit@my-server.com }
set alert admin@ideolab.com # (Email par défaut si 'then alert')

# --- Web UI (Port 2812) ---
set httpd port 2812 and
    allow 127.0.0.1        # (Autoriser localhost)
    allow admin:password   # (Autoriser 'admin' (mdp: 'password'))
    
# --- Modularité (Voir 2.3) ---
include /etc/monit/conf.d/*

Comme Nginx, Apache, ou Supervisor, Monit utilise une directive include pour gérer une configuration modulaire.

Ne jamais mettre de check dans le monitrc principal.

/etc/monit/monitrc (Principal)

# ... (Config globale : set daemon, set httpd...)

# --- Inclure tous les fichiers de conf.d ---
include /etc/monit/conf.d/*

/etc/monit/conf.d/nginx.conf

check process nginx pidfile /var/run/nginx.pid
    start program = "/usr/sbin/service nginx start"
    stop program = "/usr/sbin/service nginx stop"
    if failed port 80 protocol http then restart

/etc/monit/conf.d/ssh.conf

check process sshd pidfile /var/run/sshd.pid
    if failed port 22 protocol ssh then alert

La syntaxe de Monit est très lisible (Anglais) et suit une structure check / if / then.

# 1. Le "Quoi" (Check)
check process [NOM_SERVICE] [IDENTIFICATION]
  # (ex: pidfile /var/run/nginx.pid)
  # (ex: matching "gunicorn")

# 2. La "Condition" (If)
# (Test de la condition)
if [TEST] then [ACTION]
  # (ex: if failed port 80 then restart)
  # (ex: if cpu > 80% for 5 cycles then alert)

# 3. L'"Action" (Then)
# (Action de remédiation)
then [ACTION]
  # (ex: then restart)
  # (ex: then alert)
  # (ex: then exec "/path/to/script.sh")

C'est la méthode la plus fiable pour superviser un service "daemon" (Nginx, MySQL, SSHD).

Elle se base sur la présence et la validité du fichier PID (.pid) du service.

# (Exemple: Superviser SSHD)
check process sshd
    # 1. Identification (PID)
    with pidfile "/var/run/sshd.pid"
    
    # 2. Action (Start/Stop) (Voir 3.3)
    start program = "/usr/sbin/service ssh start"
    stop program  = "/usr/sbin/service ssh stop"
    
    # 3. Condition (Test)
    # (Si le PID n'existe pas, ou si le port 22
    #  ne répond pas au protocole SSH
    #  pendant 3 cycles...)
    if failed port 22 protocol ssh for 3 cycles
        # 4. Action (Remédiation)
        then restart
        
    # 5. Action (Alerte)
    if 5 restarts within 5 cycles
        then alert

C'est la méthode "alternative" si le processus n'a pas de fichier .pid (ex: un script .py, un java -jar).

Monit scanne la table des processus (ps aux) à la recherche d'une correspondance (Regex).

# (Exemple: Superviser un worker Gunicorn)
check process gunicorn-worker
    # 1. Identification (Regex)
    matching "gunicorn: worker \[myapp\]"
    
    # 2. Action (Start/Stop)
    start program = "/bin/su - www-data -c '/path/to/start_gunicorn.sh'"
    stop program = "/bin/killall gunicorn"
    
    # 3. Condition (Test)
    if failed port 8000 then restart
    
    # 4. Condition (Groupe)
    # (Met 'gunicorn-worker' dans le groupe 'myapp')
    group myapp

Inconvénient : Moins précis qu'un PID (peut matcher le mauvais processus si la regex est large), et plus lourd (scan ps).

Ces directives (dans un check process) définissent comment Monit doit gérer le processus.

start program

La commande (shell) que Monit doit exécuter si :

1. L'action then restart (ou then start) est déclenchée.
2. L'admin exécute monit start.

stop program

La commande que Monit doit exécuter si :

1. L'action then stop est déclenchée.
2. L'admin exécute monit stop.
3. (Avant un restart).

Bonne Pratique (systemd)

Si le service (ex: nginx) est géré par systemd (ce qui est le cas), ne pas utiliser les scripts init.d (/etc/init.d/nginx).

Utiliser systemctl (qui parle à PID 1) :

check process nginx pidfile /var/run/nginx.pid
    start program = "/bin/systemctl start nginx"
    stop program  = "/bin/systemctl stop nginx"
    if failed port 80 then restart
    # (C'est Monit qui surveille le port 80,
    #  et qui dit à systemd de redémarrer si besoin)

check system permet de superviser les métriques globales de la machine (l'Hôte), identifié par la variable spéciale $HOST (souvent localhost).

Exemple (Surveillance des ressources)

# (Doit être dans un fichier .conf de /etc/monit/conf.d/)

check system $HOST
    # 1. Alerte si Load Average (1 min) > 5.0
    if loadavg (1min) > 5.0 for 5 cycles
        then alert
        
    # 2. Alerte si Load Average (5 min) > 3.0
    if loadavg (5min) > 3.0 for 10 cycles
        then alert
        
    # 3. Alerte si Usage CPU (User+Sys) > 90%
    if cpu(user) > 70% for 3 cycles
        then alert
    if cpu(system) > 20% for 3 cycles
        then alert
        
    # 4. Alerte si Usage Mémoire (RAM) > 85%
    if memory usage > 85% for 5 cycles
        then alert

check filesystem surveille l'utilisation (espace/inodes) d'un point de montage (partition).

Exemple (Disque / (root))

check filesystem rootfs with path /
    # (Alerte si l'espace disque dépasse 85%)
    if space usage > 85% for 3 cycles
        then alert
        
    # (Alerte si les Inodes dépassent 90%)
    if inode usage > 90%
        then alert

Exemple (Disque /data)

check filesystem datafs with path /dev/sda4
    if space usage > 95%
        then exec "/usr/local/bin/cleanup_data.sh"

check file surveille un fichier spécifique (ou un dossier).

Exemple (Fichier de Log "mort")

Vérifie si un fichier (ex: un log critique) n'a pas été modifié (ex: si le script de backup est bloqué).

check file backup_log with path /var/log/backup.log
    # (Alerte si le fichier n'a pas changé
    #  depuis plus de 60 minutes)
    if timestamp > 60 minutes
        then alert

Exemple (Checksum / Sécurité)

Vérifie si un fichier critique (ex: /etc/passwd) a été modifié (altéré).

check file shadow with path /etc/shadow
    # (Alerte si le checksum MD5/SHA change)
    if failed checksum
        then alert

check host est utilisé pour le monitoring réseau externe. Il teste la connectivité (L3/L4) vers une IP ou un hôte distant.

Exemple (Test de la Gateway / DNS)

# (Vérifier si on peut pinger la Gateway)
check host my_gateway with address 192.168.1.1
    # (Ping 3 fois)
    if failed icmp type echo count 3 with timeout 15 seconds
        then alert
        
# (Vérifier si le DNS de Google répond)
check host google_dns with address 8.8.8.8
    if failed icmp
        then alert

C'est la supervision "synthétique" de Monit. Il teste non seulement si le port (L4) est ouvert, mais aussi si le protocole (L7) répond correctement.

Exemple (Test L4 - Port TCP)

check host MonServeurWeb address 1.2.3.4
    # (Teste si le port 443 (TCP) est ouvert)
    if failed port 443
        then alert

Exemple (Test L7 - Protocole HTTP)

Monit va simuler un client HTTP (GET /) et vérifier la réponse.

check host MonServeurWeb address 1.2.3.4
    # (Teste si le port 80 répond
    #  à une requête HTTP valide)
    if failed port 80 protocol http
        then restart # (Action : redémarrer le 'program' lié)

    # (Test HTTP avancé)
    if failed port 80 protocol http
        # (Demande une URL spécifique)
        request "/"
        # (Vérifie le contenu)
        content = "Welcome"
        # (Vérifie le code HTTP)
        status = 200
    then alert

Protocoles supportés : HTTP, HTTPS, SSH, SMTP, MYSQL, PGSQL, REDIS, ...

check network permet de superviser l'état (L1/L2) ou le débit (L3) d'une interface locale.

Exemple (Lien DOWN)

check network wan_link interface eth0
    # (Si le lien (L1/L2) est DOWN)
    if link down
        then alert

Exemple (Saturation)

check network lan_link interface eth1
    # (Alerte si le débit sortant (upload)
    #  dépasse 50 MB/s (moyenné sur 1 min))
    if upload > 50 MB/s for 1 cycle
        then alert

La clause then [ACTION] est la "réponse" de Monit à un échec (if failed...).

Pour éviter les alertes "flapping" (ex: un CPU qui dépasse 90% pendant 1 seconde), Monit utilise un système de "Cycles".

Un Cycle est la durée du "sleep" du daemon (ex: set daemon 60 = 1 cycle = 60 secondes).

Exemple (Tolérance CPU)

check system $HOST
    # (SI le CPU est > 90% PENDANT 3 cycles (3*60s = 3 min)
    #  ALORS envoyer 1 alerte)
    if cpu(user) > 90% for 3 cycles
        then alert

Exemple (Escalade)

check process nginx ...
    # (Si le port 80 échoue (1 cycle))
    if failed port 80
        # (Action 1 : Redémarrer (immédiat))
        then restart
        
    # (Si le redémarrage échoue 5 fois
    #  sur les 5 derniers cycles...)
    if 5 restarts within 5 cycles
        # (Action 2 : Escalade ! Envoyer alerte
        #  et arrêter de superviser (pour éviter 1000 restarts))
        then alert
        then unmonitor

Configuration des alertes (Email) dans monitrc.

# 1. Configurer le serveur SMTP (ex: GMail)
set mailserver smtp.gmail.com port 587
    username "monit@gmail.com" password "mon_pass"
    using tlsv12
    
# 2. (Optionnel) Définir le format
set mail-format {
  from: monit@mon-serveur.com
  subject: [ALERTE MONIT] $SERVICE - $EVENT
  message:
    Monit event: $EVENT
    Service:     $SERVICE
    Description: $DESCRIPTION
    Date:        $DATE
}

# 3. Définir le destinataire (Recipient)
set alert admin@ideolab.com

# 4. Utiliser 'then alert' dans un 'check'
check process sshd ...
    if failed port 22 then alert

Le binaire monit (utilisé sans arguments, ou avec des commandes de "runtime") est le client (similaire à supervisorctl).

# Affiche le statut complet (verbeux)
$ sudo monit status

# Affiche un résumé (compact)
$ sudo monit summary

# --- Gestion (Manuelle) ---

# Arrêter UN service (exécute 'stop program')
$ sudo monit stop nginx

# Démarrer UN service
$ sudo monit start nginx

# Redémarrer UN service
$ sudo monit restart nginx

# Arrêter TOUS les services gérés
$ sudo monit stop all

# Démarrer TOUS les services (dont autostart=false)
$ sudo monit start all

Monitor / Unmonitor (Gestion de la surveillance)

# (Très utile) Arrêter la *surveillance* de Nginx
# (Monit va l'ignorer, sans l'arrêter)
$ sudo monit unmonitor nginx

# Reprendre la surveillance
$ sudo monit monitor nginx

monit -t (Test / Validation)

Indispensable. Avant d'appliquer une nouvelle configuration, toujours la tester avec -t.

# (Vérifie la syntaxe de /etc/monit/monitrc
#  et de tous les 'include')
$ sudo monit -t
Control file syntax OK

monit reload (Rechargement)

Force le daemon monit (en cours) à relire ses fichiers de configuration (similaire à supervisorctl update ou systemctl daemon-reload).

$ sudo monit reload
Reinitializing monit daemon

Problème : Monit (l'outil open-source) est excellent pour gérer 1 serveur. Mais comment gérer 1000 serveurs (chacun avec son propre Monit et sa Web UI sur port 2812) ?

Solution : M/Monit (Commercial)

M/Monit (le "M" = Management) est le produit commercial (payant) de M/Monit (l'entreprise).

C'est un serveur de management centralisé (SaaS ou On-premise) qui fournit un Dashboard (Tableau de bord) unique pour agréger les données de tous vos daemons monit.

Fonctionnement

1. Vous installez M/Monit (le serveur central).
2. Sur chaque monitrc (vos 1000 serveurs), vous ajoutez un "collector" (un "push") :

   set mmonit https://user:pass@mmonit-server.com/collector

3. Chaque daemon monit (local) envoie son statut (Up/Down, CPU, RAM...) au serveur M/Monit.

Résultat : Un Dashboard central (similaire à Zabbix/Grafana) montrant l'état de tout le parc, l'historique des pannes, et la gestion centralisée des alertes.