1 17/10/2026 12 min

Monit su Ubuntu 20.04: cosa controlla davvero

Monit non è un sostituto di Prometheus o di un sistema di osservabilità completo. È più vicino a un controllore locale, leggero e molto utile quando vuoi sapere se un processo è vivo, se una porta risponde, se un file cresce fuori controllo o se una condizione di sistema ha superato una soglia. Su Ubuntu 20.04 funziona bene proprio per questo: installazione rapida, pochi componenti, configurazione leggibile e riavvio automatico dei servizi quando qualcosa smette di comportarsi come previsto.

La scelta giusta è usarlo come strato di protezione locale, non come unica fonte di verità. Se il nodo è raggiungibile ma il servizio applicativo è bloccato, Monit può intervenire. Se il nodo è giù, serve comunque un monitor esterno. Questa distinzione evita di sopravvalutare lo strumento e aiuta a progettare un controllo realistico.

In questa guida vediamo un’installazione pulita su Ubuntu 20.04, con configurazione base, test dei servizi, accesso alla web UI, notifiche via mail e alcuni esempi pratici. L’obiettivo è arrivare a una configurazione utile in produzione senza introdurre dipendenze inutili o aperture superflue.

Installazione del pacchetto Monit

Su Ubuntu 20.04 il pacchetto è disponibile nei repository ufficiali. Conviene partire da lì: meno rischio di mismatch, aggiornamenti gestiti dal sistema e integrazione semplice con systemd.

Prima di installare, aggiorna l’indice dei pacchetti e verifica che il repository sia raggiungibile. In un ambiente di produzione questa è la prima verifica sensata: se l’host non aggiorna, non ha senso discutere la configurazione applicativa.

sudo apt update
sudo apt install monit

Dopo l’installazione, controlla lo stato del servizio e la presenza dei file principali. Su Ubuntu, il file di configurazione base è in /etc/monit/monitrc, mentre le definizioni aggiuntive spesso vivono in /etc/monit/conf.d/.

systemctl status monit --no-pager
ls -l /etc/monit/
ls -l /etc/monit/conf.d/

Se il servizio risulta inattivo subito dopo l’installazione, non è necessariamente un problema: Monit può partire con una configurazione minima e senza definizioni attive. Il punto è capire se il demone è installato correttamente e se legge i file previsti.

Abilitare l’interfaccia web in modo prudente

La web UI di Monit è comoda, ma va trattata come qualsiasi altro servizio di amministrazione: ascolto limitato, autenticazione forte, esposizione ridotta al minimo. In molti casi basta tenerla in ascolto su localhost e accedervi tramite SSH tunnel o reverse proxy controllato.

Il file principale da modificare è /etc/monit/monitrc. Prima di toccarlo, fai una copia di backup. È una modifica piccola, ma reversibile solo se conservi lo stato precedente.

sudo cp /etc/monit/monitrc /etc/monit/monitrc.bak

Apri il file e verifica che siano presenti le direttive base per il daemon e per la web interface. Un esempio essenziale, con ascolto locale, è questo:

set daemon 60
set httpd port 2812 and use address 127.0.0.1 allow admin:password

La riga allow admin:password è solo un esempio funzionale per la sintassi. In produzione non lasciare credenziali deboli o prevedibili. Meglio usare una password lunga, ruotarla e, se possibile, limitare l’accesso alla UI con binding locale o con una rete amministrativa separata. Se devi esporre la UI su una rete, valuta almeno un filtro firewall e un account dedicato.

Dopo la modifica, verifica la sintassi prima di riavviare. Monit fornisce un check dedicato che evita errori banali e riavvii inutili.

sudo monit -t

Se il test è corretto, riavvia il servizio e controlla che la porta sia in ascolto.

sudo systemctl restart monit
sudo ss -lntp | grep 2812

Se usi localhost, puoi raggiungere la UI solo dal server stesso oppure tramite tunnel SSH:

ssh -L 2812:127.0.0.1:2812 user@server

Aprendo http://127.0.0.1:2812 dal tuo browser vedrai l’interfaccia di Monit senza esporre la porta direttamente su Internet.

Struttura della configurazione su Ubuntu 20.04

La configurazione di Monit si presta bene a una separazione ordinata: un file principale per le impostazioni globali e file dedicati per i singoli servizi. Questo approccio riduce il rischio di errori e rende più facile il rollback di una singola definizione.

Su Ubuntu 20.04 il pattern più pulito è lasciare le impostazioni globali in /etc/monit/monitrc e mettere i controlli applicativi in /etc/monit/conf.d/. Se il sistema non include automaticamente i file della directory, aggiungi l’include esplicito nel file principale.

include /etc/monit/conf.d/*

Un errore frequente è accumulare tutto nel file principale. Funziona, ma diventa presto scomodo quando devi disattivare un singolo controllo o fare troubleshooting. Con file separati puoi commentare, sostituire o ripristinare una sola regola senza toccare il resto.

Esempio pratico: monitorare un processo Nginx

Il caso più semplice è il controllo di un processo systemd. Monit può verificare che il demone sia vivo e, se muore, riavviarlo. Per Nginx la definizione è lineare e già sufficiente in molti contesti.

sudo nano /etc/monit/conf.d/nginx

Inserisci una definizione simile alla seguente:

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 then restart if 5 restarts within 5 cycles then timeout

Ci sono due livelli di controllo: il pidfile e la risposta HTTP. Il pidfile dice se il processo esiste; il check HTTP dice se il servizio sta realmente servendo contenuti. Questa doppia verifica è importante perché un processo può essere vivo ma non funzionare correttamente, ad esempio con upstream bloccati o configurazione errata.

Dopo aver creato il file, verifica la sintassi completa e ricarica Monit.

sudo monit -t
sudo systemctl reload monit

Per vedere se il controllo è stato caricato, interroga lo stato locale:

sudo monit status nginx

Se il servizio è correttamente registrato, dovresti vedere stato, ultimo check, eventuali restart eseguiti e la logica di azione associata. Se compare un errore di parsing, il problema è quasi sempre nel file appena aggiunto o in un path non corretto.

Controllare un processo PHP-FPM senza falsi positivi

Con PHP-FPM conviene evitare controlli superficiali. Se controlli solo il processo, rischi di non accorgerti di pool bloccati o socket non raggiungibili. Meglio associare il processo al socket o alla porta effettiva, così Monit verifica anche il punto di ingresso reale del traffico.

Su Ubuntu 20.04 un pool tipico può ascoltare su socket Unix. In quel caso la definizione potrebbe essere simile a questa:

check process php-fpm with pidfile /run/php/php7.4-fpm.pid start program = "/bin/systemctl start php7.4-fpm" stop program = "/bin/systemctl stop php7.4-fpm" if failed unixsocket /run/php/php7.4-fpm.sock then restart if 5 restarts within 5 cycles then timeout

Qui il punto critico è il path del socket. Se il path non corrisponde alla configurazione reale del pool, il check fallisce anche se il servizio è sano. Prima di aggiungere la regola, verifica il file di configurazione del pool in /etc/php/7.4/fpm/pool.d/ e conferma il valore di listen.

grep -R "^listen" /etc/php/7.4/fpm/pool.d/

Questo è uno dei punti in cui Monit è utile ma va trattato con precisione: un controllo troppo generico crea restart inutili, un controllo troppo permissivo non intercetta i problemi. La soglia deve riflettere il comportamento atteso del servizio, non solo la sua presenza in memoria.

Monitorare spazio disco, load e memoria

Una delle funzioni più pratiche di Monit è il controllo delle risorse locali. Qui non si tratta di sostituire strumenti di capacity planning, ma di intercettare i casi in cui il nodo sta andando verso il collasso: filesystem pieni, memoria esaurita, load anomalo o swap in crescita.

Un esempio utile per il filesystem root:

check device rootfs with path / if space usage > 80% then alert if space usage > 90% then stop

La soglia dipende dal contesto. Su un server con log intensi o aggiornamenti frequenti può avere senso restare più bassi, soprattutto se non hai un meccanismo automatico di rotazione ben dimensionato. La parte interessante è che Monit non ti avvisa solo quando è troppo tardi: può anche eseguire un’azione, ma quella parte va trattata con molta cautela.

Per la memoria e il carico, puoi usare condizioni di alert senza azioni invasive:

check system localhost if memory usage > 75% then alert if cpu usage (user) > 80% for 5 cycles then alert if loadavg (1min) > 4 for 5 cycles then alert

Qui il valore non è la singola soglia, ma la continuità dell’evento. Il parametro for 5 cycles evita che un picco temporaneo generi rumore inutile. È una scelta importante in produzione, dove il problema non è solo rilevare gli incidenti ma evitare allarmi che nessuno leggerà più.

Notifiche email: configurazione minima sensata

Per molte installazioni la notifica via email è ancora il canale più utile. Non serve complicarla: basta definire un destinatario affidabile, un relay SMTP coerente con l’infrastruttura e un formato che consenta di capire subito cosa è successo.

Monit supporta l’invio di alert con un semplice blocco di configurazione. Un esempio minimale:

set mailserver smtp.example.net port 587 username "monit@example.net" password "PASSWORD" using tlsv1.2 set alert admin@example.net

Non lasciare password in chiaro se puoi evitarlo. Se il relay richiede credenziali, usa un account dedicato e ruotalo secondo policy. Se l’ambiente lo consente, preferisci autenticazione tramite meccanismi più robusti o relay interno senza credenziali esposte nel file principale.

Prima di considerare la parte chiusa, verifica che il server possa davvero consegnare posta. L’errore tipico è configurare Monit correttamente ma non avere connettività verso il relay, oppure avere un firewall che blocca la porta 587.

nc -vz smtp.example.net 587

Se il test di rete fallisce, il problema non è Monit ma l’accesso al relay. In quel caso correggi prima il percorso SMTP, poi torna alla configurazione dell’alert.

Testare i controlli senza aspettare un guasto vero

Un’installazione fatta bene non si limita a partire: va verificata con un test controllato. Monit offre comandi utili per forzare il ricaricamento e leggere lo stato dei controlli. Questo è il punto in cui ti accorgi se la configurazione è davvero operativa o solo sintatticamente corretta.

sudo monit reload
sudo monit summary
sudo monit status

Se vuoi verificare il comportamento di restart, puoi fermare temporaneamente un servizio non critico e osservare se Monit interviene. Fallo solo su un componente con rischio contenuto e con rollback chiaro. Su servizi di produzione delicati, meglio simulare il guasto in finestra controllata o in staging.

Per esempio, su un nodo di test puoi fermare Nginx e osservare il ciclo di check:

sudo systemctl stop nginx
sudo monit status nginx

Se la regola è corretta, Monit rileva il fallimento al ciclo successivo e tenta il riavvio. Una volta verificato, riporta il servizio allo stato originale e controlla che il monitor torni in verde.

sudo systemctl start nginx
sudo monit status nginx

Questo test ha un valore pratico: conferma non solo che Monit vede il problema, ma che le azioni definite sono eseguibili dal sistema. Se il comando di start o stop è sbagliato, il monitor segnalerà il guasto ma non riuscirà a ripristinare il servizio.

Log, troubleshooting e punti deboli tipici

Quando qualcosa non funziona, i primi due posti da guardare sono il log di Monit e la sintassi dei file inclusi. Su Ubuntu il journal systemd è spesso sufficiente per capire dove si è rotto il flusso.

journalctl -u monit --no-pager -n 100

Se il servizio non parte, controlla prima la validità del file principale con monit -t. Se il file è valido ma un controllo non compare nello status, il problema è quasi sempre nel path del file incluso, in un errore di sintassi o in una direttiva non supportata dalla versione installata.

Un errore frequente è il file con permessi troppo aperti o troppo stretti. Monit è sensibile alla leggibilità delle configurazioni. Se hai dubbi, verifica proprietario e permessi della directory di configurazione e dei singoli file.

sudo ls -l /etc/monit/monitrc
sudo ls -l /etc/monit/conf.d/

Un altro caso comune è la porta web configurata ma non raggiungibile perché un firewall locale blocca l’accesso. In quel caso non inseguire il problema nella configurazione di Monit: controlla prima le regole firewall e l’indirizzo di bind.

Hardening essenziale prima di andare in produzione

Se Monit rimane solo su localhost, la superficie d’attacco è minima. Se invece deve essere raggiungibile sulla rete, conviene fare almeno tre cose: limitare l’interfaccia di ascolto, usare credenziali robuste e ridurre la portata del firewall alla sola rete amministrativa.

In più, separa i ruoli: l’utente che accede alla web UI non deve necessariamente coincidere con chi modifica i file di configurazione. Questo evita di trasformare un pannello di controllo in un accesso amministrativo totale senza motivo.

Se le notifiche via email passano attraverso un relay esterno, valuta anche il segreto come materiale sensibile. Non salvarlo in note operative o ticket aperti. Se devi distribuirlo, usa un vault o un meccanismo di secret management coerente con il resto dell’infrastruttura.

Una configurazione base che regge nel tempo

La qualità di una configurazione Monit non si misura dal numero di controlli, ma dalla loro utilità operativa. Meglio pochi controlli ben scelti che una lista lunga ma rumorosa. I candidati migliori sono sempre gli stessi: processo critico, porta di servizio, filesystem, memoria, coda mail o job essenziali.

Se vuoi mantenere la manutenzione semplice, crea un file per servizio, documenta la soglia scelta e annota il motivo. Una riga di commento può evitare ore di rilettura mesi dopo, soprattutto quando qualcuno eredita la macchina e deve capire perché una soglia è stata impostata in un certo modo.

Monit resta efficace proprio perché è prevedibile. Non richiede una piattaforma complessa, ma chiede disciplina: file ordinati, test di sintassi, verifiche dopo ogni cambio e attenzione alle azioni automatiche. Su Ubuntu 20.04 questa combinazione è spesso sufficiente per coprire i controlli locali più importanti senza introdurre altro rumore nell’infrastruttura.