Come installare Monitorix su Ubuntu 22.04

Monitorix su Ubuntu 22.04: cosa installi davvero

Monitorix è un monitor leggero per server Linux: raccoglie metriche di sistema, rete, disco, processi, servizi e, se serve, dati di applicazioni o demoni aggiuntivi. Su Ubuntu 22.04 l’installazione è semplice, ma la parte che conta davvero non è il pacchetto in sé: è farlo esporre in modo controllato, verificare che il backend stia raccogliendo dati e decidere subito chi può vedere l’interfaccia web.

La scelta pratica è questa: installazione minima, test locale, poi apertura solo verso la rete necessaria. Se lo esponi direttamente su Internet senza restrizioni, stai pubblicando informazioni utili anche a chi non dovrebbe vederle. Per un ambiente reale, conviene tenere Monitorix dietro reverse proxy, ACL o almeno autenticazione HTTP.

Prerequisiti e decisione operativa

Ubuntu 22.04 usa systemd e ha repository stabili per i componenti base, ma Monitorix può arrivare dai repository ufficiali Ubuntu oppure da un repository esterno se la versione disponibile non è quella desiderata. Prima di toccare il sistema, chiarisci due punti: vuoi solo consultazione locale o accesso remoto, e ti basta la versione del repository Ubuntu o ti serve una release più aggiornata.

Se l’obiettivo è un controllo rapido del server, la versione presente nei repository standard è spesso sufficiente. Se invece vuoi funzionalità più recenti o supporto per qualche modulo specifico, verifica prima il pacchetto disponibile. Il rischio operativo non è alto, ma ogni repository aggiunto va trattato come una modifica di supply chain: meno fonti usi, meno variabili introduci.

Installazione da repository Ubuntu

Il percorso più lineare è installare il pacchetto con APT e poi verificare che il servizio web sia attivo. I comandi sotto non sono distruttivi e sono adatti a un primo setup.

sudo apt update
sudo apt install monitorix

Dopo l’installazione, controlla che il servizio sia stato registrato e che il demone stia girando. Su Ubuntu il nome del servizio è normalmente monitorix.

systemctl status monitorix --no-pager

Se vedi uno stato active (running), hai già superato il primo controllo. Se invece il servizio parte e si ferma, il problema spesso è nella configurazione o nel binding della porta. In quel caso, il log del servizio è la prima fonte da leggere.

journalctl -u monitorix -b --no-pager

Verifica della porta e accesso all’interfaccia

Monitorix ascolta in genere su una porta dedicata, spesso la 8080, e serve una pagina web con grafici e statistiche. Il test minimo è una richiesta locale dal server stesso, così separi i problemi di servizio da quelli di rete o firewall.

curl -I http://127.0.0.1:8080/monitorix

Un risultato sano restituisce un codice HTTP valido, di solito 200 o un redirect coerente con la configurazione. Se ottieni connection refused, il demone non sta ascoltando su quella porta. Se ottieni timeout, c’è un problema di binding, firewall locale o servizio non avviato.

Per capire dove ascolta davvero, usa ss e controlla il processo in ascolto. Questo evita di inseguire ipotesi a caso quando la porta configurata è diversa da quella attesa.

ss -ltnp | grep -E 'monitorix|:8080'

Configurazione base: file, backup e punti da non toccare alla cieca

Il file principale di configurazione è tipicamente /etc/monitorix/monitorix.conf. Prima di modificarlo, fai sempre una copia. Non è formalismo: quando lavori su una macchina di produzione, vuoi poter tornare indietro in un comando, non in una ricostruzione a memoria.

sudo cp /etc/monitorix/monitorix.conf /etc/monitorix/monitorix.conf.$(date +%F).bak

Le aree che di solito meritano attenzione sono l’indirizzo di ascolto, la porta, l’eventuale autenticazione e il livello di esposizione della pagina. Se stai lavorando su un server accessibile in rete, non lasciare il servizio aperto su tutte le interfacce senza una ragione precisa.

Un approccio prudente è questo: fai ascoltare Monitorix solo su 127.0.0.1 o su una subnet amministrativa, poi pubblicalo tramite reverse proxy con autenticazione. Così separi il motore di raccolta dal punto di ingresso esterno.

Esempio di hardening minimo con accesso locale o tramite proxy

Se vuoi una configurazione prudente, il servizio può restare non esposto direttamente e parlare solo in locale. In quel caso, il proxy web davanti a Monitorix gestisce TLS, autenticazione e restrizioni IP. Il vantaggio è pratico: Monitorix resta un backend interno, il web server esterno fa da filtro.

La logica è semplice: meno superficie esponi, meno punti di attacco hai. Per un pannello di monitoraggio questo è particolarmente importante, perché i grafici rivelano carico, orari di picco, servizi presenti e talvolta informazioni indirette sulla capacità del sistema.

Se usi Apache o Nginx come front-end, puoi definire un vhost dedicato e inoltrare le richieste verso la porta locale di Monitorix. Il dettaglio del proxy dipende dallo stack già presente sul server, quindi non ha senso imporre una sola strada: l’obiettivo è tenere la porta del demone non pubblica.

Controllo dei moduli e delle metriche raccolte

Una volta avviato, Monitorix inizia a creare i grafici in base ai moduli attivi. Non dare per scontato che tutto sia già coperto: alcune metriche dipendono da pacchetti aggiuntivi, da demoni specifici o da file di log che devono essere leggibili dal processo.

Per esempio, se vuoi vedere statistiche su Apache, MySQL/MariaDB, postfix, fail2ban o altri servizi, devi verificare la presenza del modulo e la compatibilità con il formato dei dati. Il punto non è abilitare tutto, ma abilitare ciò che serve davvero e che sai interpretare.

Un errore comune è installare Monitorix e aspettarsi grafici ricchi subito. In realtà, alcune sezioni si popolano solo dopo un po’ di tempo o richiedono che il sistema abbia già una certa attività. Se il grafico è vuoto nelle prime ore, non è per forza un guasto.

Firewall e accesso di rete

Se l’interfaccia deve essere raggiungibile da una rete amministrativa, apri la porta in modo mirato. Con UFW, per esempio, evita aperture generiche su 0.0.0.0/0 se puoi limitarle a un indirizzo o a una subnet.

sudo ufw allow from 192.0.2.0/24 to any port 8080 proto tcp

Dopo la modifica, verifica che la regola sia attiva e che il servizio risponda solo dal segmento autorizzato. Se il server è dietro un security group o un firewall cloud, la stessa logica si applica anche lì: la regola locale non basta se il livello esterno blocca il traffico, e viceversa.

Per un controllo rapido, prova da una macchina nella rete autorizzata e da una non autorizzata. La differenza di comportamento deve essere netta: accesso consentito dove previsto, negato altrove. Se non hai un host di test, il gap va chiuso prima di dichiarare la configurazione corretta.

Avvio automatico e manutenzione del servizio

Dopo l’installazione, controlla che il servizio parta al boot. Se non lo fa, in produzione hai un problema di disponibilità al riavvio, non solo un problema di installazione.

systemctl enable monitorix
systemctl is-enabled monitorix

Il secondo comando deve restituire enabled. Se restituisce disabled, qualcosa ha impedito l’attivazione o il pacchetto non ha registrato correttamente l’unità. In quel caso, leggi il file unit o il log di installazione prima di intervenire a mano.

Per la manutenzione, il consiglio è semplice: aggiorna il pacchetto con il normale ciclo di patch del sistema, ma fai sempre un rapido controllo post-update su porta, log e pagina web. I monitor sono utili solo se li controlli davvero dopo le modifiche, non solo quando li installi.

Integrazione con Apache o Nginx

Su molti server conviene mettere Monitorix dietro un virtual host dedicato, soprattutto se vuoi usare TLS e autenticazione. In questo scenario, il browser parla con il web server front-end, mentre il front-end inoltra il traffico al backend locale di Monitorix.

Il vantaggio è duplice: puoi usare certificati già gestiti dal server web e puoi applicare le stesse policy di accesso usate per altri pannelli amministrativi. Se hai già un reverse proxy in produzione, aggiungere Monitorix lì dentro è più pulito che aprire una nuova porta pubblica.

Se invece vuoi tenere tutto semplice in LAN, puoi anche lasciare la porta diretta e proteggerla con firewall e ACL. È una scelta accettabile solo quando sai esattamente chi può raggiungere il servizio e il contesto è davvero interno.

Problemi tipici dopo l’installazione

Il primo problema classico è la pagina non raggiungibile. In ordine, verifica servizio, porta e firewall. Il comando più utile resta systemctl status monitorix, seguito da ss -ltnp e da un curl locale. Se questi tre controlli falliscono, non ha senso aprire subito il file di configurazione a caso.

Il secondo problema è l’assenza di grafici o sezioni vuote. Qui il controllo va spostato sui moduli e sui dati reali disponibili sul sistema. Se il server non ha, per esempio, un database locale o un servizio specifico, è normale che la relativa sezione sia vuota.

Il terzo problema è l’accesso dall’esterno bloccato. Qui il punto non è Monitorix, ma il percorso di rete: firewall locale, security group, reverse proxy, policy di rete o binding su localhost. Un test da remoto con curl -I e uno locale sul server separano subito i due casi.

Checklist finale di installazione pulita

1. Pacchetto installato con apt e servizio presente con systemctl status monitorix.
2. Porta confermata con ss -ltnp o equivalente.
3. Risposta HTTP verificata in locale con curl -I http://127.0.0.1:8080/monitorix.
4. Configurazione salvata con backup del file in /etc/monitorix/.
5. Accesso remoto limitato da firewall, proxy o binding locale.
6. Avvio automatico confermato con systemctl is-enabled monitorix.

Se tutto questo è a posto, hai un’installazione sensata: servizio attivo, superficie esposta ridotta e grafici consultabili senza improvvisazioni. L’ultima verifica utile resta sempre la stessa: apri la dashboard da un client autorizzato e controlla che i grafici si popolino nel tempo, non solo che la pagina si carichi.

Assunzione: il server è Ubuntu 22.04 aggiornato, con accesso sudo e una policy minima di rete già disponibile per limitare l’accesso alla porta di Monitorix.