Monit sorveglia che i servizi girino e li rialza quando cadono. La prima domanda legittima: a che scopo, se systemd sa fare lo stesso con una sola riga Restart=always?

La risposta definisce tutta la configurazione. systemd vede che un processo è terminato e lo riavvia. Non sa se il servizio risponde alle richieste. PHP-FPM che ha raggiunto il limite dei processi per systemd è vivo e vegeto, mentre il sito restituisce 502. MySQL rimasto senza spazio su disco continua a esistere come processo e non esegue una sola query. Monit non verifica l’esistenza di un processo ma il suo comportamento: se la porta risponde, che cosa restituisce una richiesta HTTP, quanta memoria è occupata.

Da qui la regola: systemd resta com’è, e Monit si aggiunge per le verifiche funzionali. Duplicare il riavvio di un processo caduto non ha senso.

Configurazione

sudo apt install monit

Il file principale è /etc/monit/monitrc; le sue verifiche vanno come file separati in /etc/monit/conf.d/. L’inizio consueto:

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

Un sondaggio al minuto è un equilibrio ragionevole. Più spesso aggiunge carico e aumenta il rischio di un riavvio inutile per un secondo di ritardo.

L’interfaccia web: solo in locale

Monit ha una pagina web integrata, e la si attiva di solito come mostra la prima guida che capita: su tutti gli indirizzi. Il risultato è un pannello di comando dei servizi del server, raggiungibile da internet. La variante corretta:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'una-password-lunga'

L’accesso dall’esterno passa per un tunnel SSH:

ssh -L 2812:localhost:2812 user@203.0.113.25

Dopodiché la pagina si apre sul suo computer all’indirizzo localhost:2812, e verso l’esterno non è esposto nulla.

Verifiche che hanno senso

Il server web, non per la presenza di un processo ma per la sua risposta:

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

Tre righe qui contano più del resto.

protocol http ... status = 200 è la verifica per cui tutto questo è stato messo in piedi: il server deve restituire una pagina, non limitarsi a tenere una porta aperta.

for 3 cycles significa non reagire a un singolo fallimento. Senza di essa Monit riavvierà il servizio per una risposta lenta sotto carico, il che non fa che peggiorare le cose.

if 3 restarts within 10 cycles then unmonitor è una riga obbligatoria. Se un servizio non riparte per un errore di configurazione, Monit lo riavvierà all’infinito, aggiungendo carico e riempiendo i registri. Quella riga significa: tre tentativi falliti, fermarsi e lasciare un messaggio. Da lì serve una persona; l’automatismo non aiuta più.

Lo spazio su disco si verifica senza alcun automatismo, semplicemente come avviso:

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

La riga sugli inode serve a parte: si esauriscono indipendentemente dallo spazio, e senza di essa quella situazione passa inosservata.

Verificare la configurazione

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

monit -t verifica la sintassi prima dell’applicazione. monit summary dà una breve tabella di stati: il punto di partenza per esaminare qualsiasi problema.

E verifichi che la posta parta. Monit segnala gli eventi per posta, e se l’invio non è configurato non ci sarà alcuna notifica: il servizio si riavvierà e lei non lo saprà, mentre i riavvii ripetuti sono proprio il segnale principale. Si vedono anche nel registro: /var/log/monit.log.

Che cosa Monit non fa

Non elimina la causa. Un riavvio è un rinvio, e un servizio riavviato di continuo significa che da qualche parte manca memoria, si esaurisce lo spazio o l’applicazione perde risorse. Il valore dello strumento non sta nel riavvio ma nel contatore: tre riavvii di nginx in un giorno sono una diagnosi che altrimenti sarebbe passata inosservata, perché il sito ha funzionato per tutto il tempo.

Va guardato quindi non lo stato attuale — quasi sempre verde — ma lo storico: quante volte nell’ultima settimana qualcosa si è rialzato da solo. Come appare su una pagina lo mostra la dimostrazione qui sotto.