Il monitoraggio Ubuntu Server non deve per forza partire con dashboard gigantesche, agent installati ovunque e notifiche che sembrano il centralino della NASA. Per molti server, soprattutto in contesti piccoli, PMI o ambienti interni, la prima cosa davvero utile è molto più semplice: sapere se lo spazio disco sta finendo, capire quali cartelle stanno crescendo troppo e controllare se i log stanno cercando di trasformare /var/log in una discarica digitale.
Questo non significa ignorare strumenti più evoluti. Zabbix, Prometheus, Grafana, Netdata e compagnia bella hanno senso in ambienti strutturati. Ma prima di arrivare lì, su un Ubuntu Server conviene conoscere bene gli strumenti già presenti o facilmente utilizzabili da terminale: df, du, journalctl, logrotate e qualche piccolo script di controllo.
In pratica: meno fuochi d’artificio, più sostanza.
Perché controllare spazio disco e log è fondamentale
Un server può avere CPU tranquilla, RAM sufficiente e servizi apparentemente funzionanti, ma se il disco si riempie sono dolori.
Quando una partizione arriva al 100%, possono comparire problemi molto concreti:
- database che non riescono più a scrivere;
- servizi web che smettono di salvare sessioni o cache;
- backup che falliscono;
- aggiornamenti bloccati;
- log che non vengono più registrati;
- applicazioni che iniziano a comportarsi in modo “creativo”, e di solito non è un complimento.
Il punto è semplice: lo spazio disco è una risorsa silenziosa. Non fa rumore finché non è troppo tardi.
I log, invece, sono utilissimi per diagnosticare problemi, ma se non vengono gestiti correttamente possono diventare essi stessi il problema. Un servizio configurato male, un’applicazione troppo verbosa o un errore ripetuto migliaia di volte possono riempire rapidamente il disco.
Controllare lo spazio disco con df
Il primo comando da conoscere è:
df -h
df mostra lo spazio disponibile sui filesystem montati. L’opzione -h rende l’output leggibile, usando unità come GB e MB invece di numeri poco amichevoli.
Un esempio:
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 50G 38G 10G 80% /
/dev/sdb1 200G 120G 80G 60% /backup
Le colonne più importanti sono:
- Size: dimensione totale;
- Used: spazio usato;
- Avail: spazio disponibile;
- Use%: percentuale di utilizzo;
- Mounted on: punto di mount.
La colonna da guardare subito è Use%. Se la partizione / supera l’80%, conviene iniziare a controllare. Se supera il 90%, è ora di intervenire. Se arriva al 100%, complimenti: il server ha appena deciso di ricordarti chi comanda.
Controllare anche gli inode
A volte il disco non è pieno in termini di GB, ma sono finiti gli inode, cioè le strutture usate dal filesystem per gestire i file. Succede quando ci sono tantissimi file piccoli.
Il comando è:
df -ih
Se la percentuale degli inode è altissima, cancellare un singolo file grande non servirà. Bisogna capire dove si stanno accumulando migliaia o milioni di file.
Capire cosa occupa spazio con du
df dice che il disco è pieno. Bene. Ma non dice chi è il colpevole.
Per quello si usa du.
Un controllo rapido delle cartelle principali:
sudo du -h --max-depth=1 / 2>/dev/null
Questo comando mostra quanto spazio occupano le directory di primo livello sotto /.
Esempio:
4.0K /mnt
2.1G /usr
8.5G /var
120M /etc
25G /home
Se /var è enorme, probabilmente il problema riguarda log, cache, database, container o pacchetti. Se /home è enorme, magari qualche utente ha deciso che il server fosse anche un archivio fotografico.
Per analizzare /var:
sudo du -h --max-depth=1 /var 2>/dev/null | sort -h
Per analizzare i log:
sudo du -h --max-depth=1 /var/log 2>/dev/null | sort -h
Il comando sort -h ordina i risultati in modo leggibile, rispettando le unità umane come MB e GB.
Trovare file molto grandi
Per cercare file superiori a 500 MB:
sudo find / -type f -size +500M -exec ls -lh {} \; 2>/dev/null
Oppure, per limitarsi ai log:
sudo find /var/log -type f -size +100M -exec ls -lh {} \;
Attenzione: trovare un file enorme non significa cancellarlo a caso. Prima bisogna capire a cosa serve.
df e du non dicono sempre la stessa cosa
Può capitare che df segnali molto spazio occupato, mentre du non trovi una quantità equivalente di dati. Non è magia nera, anche se da terminale può sembrarlo.
Una causa frequente è un file cancellato ma ancora aperto da un processo. Il file non compare più nella directory, ma lo spazio non viene liberato finché il processo continua a usarlo.
Per controllare:
sudo lsof | grep deleted
Se trovi un log enorme marcato come deleted, spesso il riavvio del servizio che lo tiene aperto libera lo spazio.
Esempio:
sudo systemctl restart nome-servizio
Non riavviare servizi a caso su server di produzione. Prima identifica bene il processo.
Controllare i log con journalctl
Su Ubuntu Server moderno, molti log passano dal journal di systemd. Il comando principale è:
journalctl
Così, però, rischi di vedere una valanga di righe. Meglio usare filtri.
Vedere gli errori recenti
sudo journalctl -p err -n 100
Questo mostra gli ultimi 100 messaggi con priorità errore.
Vedere i log dell’avvio corrente
sudo journalctl -b
Utile dopo un riavvio, soprattutto se un servizio non parte correttamente.
Vedere i log di un servizio specifico
sudo journalctl -u nginx
Oppure:
sudo journalctl -u apache2
sudo journalctl -u mysql
sudo journalctl -u ssh
Per seguire i log in tempo reale:
sudo journalctl -u nginx -f
L’opzione -f funziona un po’ come tail -f: resta in ascolto e mostra le nuove righe man mano che arrivano.
Controllare quanto spazio usa il journal
journalctl --disk-usage
Se il journal occupa troppi GB, conviene impostare dei limiti.
Limitare lo spazio usato da journald
Il file di configurazione principale è:
/etc/systemd/journald.conf
Prima di modificarlo, meglio fare una copia:
sudo cp /etc/systemd/journald.conf /etc/systemd/journald.conf.bak
Poi apri il file:
sudo nano /etc/systemd/journald.conf
Puoi impostare, ad esempio:
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=30day
Significato:
- SystemMaxUse=500M limita lo spazio massimo usato dai log persistenti;
- SystemKeepFree=1G cerca di mantenere libero almeno 1 GB;
- MaxRetentionSec=30day conserva i log per un massimo di 30 giorni.
Dopo la modifica:
sudo systemctl restart systemd-journald
Per liberare manualmente spazio dai journal vecchi:
sudo journalctl --vacuum-time=30d
Oppure:
sudo journalctl --vacuum-size=500M
Il primo comando mantiene solo gli ultimi 30 giorni. Il secondo riduce lo spazio occupato dal journal entro il limite indicato.
Gestire i log classici con logrotate
Non tutti i log passano solo da journalctl. Molti file si trovano ancora in:
/var/log
Qui entrano in gioco file come:
/var/log/syslog
/var/log/auth.log
/var/log/nginx/access.log
/var/log/apache2/error.log
Ubuntu usa logrotate per ruotare, comprimere ed eliminare i log vecchi.
La configurazione principale è:
/etc/logrotate.conf
Le configurazioni specifiche dei servizi sono in:
/etc/logrotate.d/
Per vedere i file disponibili:
ls -lh /etc/logrotate.d/
Esempio di configurazione per un’applicazione personalizzata:
/var/log/mia-app/*.log {
daily
rotate 14
compress
missingok
notifempty
copytruncate
}
Significato:
- daily: ruota i log ogni giorno;
- rotate 14: mantiene 14 rotazioni;
- compress: comprime i vecchi log;
- missingok: non segnala errore se il file non esiste;
- notifempty: non ruota file vuoti;
- copytruncate: copia il log e poi svuota il file originale.
copytruncate è comodo, ma non sempre perfetto. In alcuni casi è meglio configurare l’applicazione perché riapra correttamente i file di log dopo la rotazione. Però per molte applicazioni semplici è una soluzione pratica.
Testare logrotate senza fare danni
Per simulare:
sudo logrotate -d /etc/logrotate.conf
L’opzione -d esegue il debug e non applica modifiche reali.
Per forzare una rotazione:
sudo logrotate -f /etc/logrotate.conf
Da usare con attenzione, soprattutto su server in produzione.
Un controllo rapido da fare ogni tanto
Su un server piccolo, può bastare una mini-checklist periodica:
df -h
df -ih
sudo du -h --max-depth=1 /var 2>/dev/null | sort -h
sudo du -h --max-depth=1 /var/log 2>/dev/null | sort -h
journalctl --disk-usage
sudo journalctl -p err -n 50
Con questi comandi hai già una fotografia abbastanza chiara:
- quanto spazio è libero;
- se gli inode sono sotto controllo;
- quali cartelle crescono di più;
- quanto pesa il journal;
- se ci sono errori recenti rilevanti.
Non è una piattaforma di monitoraggio completa, ma è molto meglio del classico “me ne accorgo quando il sito non si apre più”.
Script semplice di alert per spazio disco
Per un controllo minimale puoi creare uno script che segnala quando una partizione supera una certa soglia.
Crea il file:
sudo nano /usr/local/sbin/check-disk.sh
Inserisci:
#!/bin/bash
SOGLIA=85
HOST=$(hostname)
df -hP | awk 'NR>1 {print $5 " " $6}' | while read output; do
uso=$(echo $output | awk '{print $1}' | sed 's/%//')
mount=$(echo $output | awk '{print $2}')
if [ "$uso" -ge "$SOGLIA" ]; then
echo "ATTENZIONE: su $HOST il filesystem $mount è al ${uso}%"
fi
done
Rendi lo script eseguibile:
sudo chmod +x /usr/local/sbin/check-disk.sh
Provalo:
sudo /usr/local/sbin/check-disk.sh
Questo script stampa un avviso solo se una partizione supera la soglia indicata.
Per ricevere una mail, il server deve avere un sistema di invio configurato. In quel caso puoi adattare lo script così:
#!/bin/bash
SOGLIA=85
EMAIL="admin@example.com"
HOST=$(hostname)
df -hP | awk 'NR>1 {print $5 " " $6}' | while read output; do
uso=$(echo $output | awk '{print $1}' | sed 's/%//')
mount=$(echo $output | awk '{print $2}')
if [ "$uso" -ge "$SOGLIA" ]; then
echo "ATTENZIONE: su $HOST il filesystem $mount è al ${uso}%" | mail -s "Alert spazio disco $HOST" "$EMAIL"
fi
done
Naturalmente admin@example.com va sostituito con l’indirizzo reale.
Eseguire lo script con cron
Per controllare lo spazio disco ogni giorno:
sudo crontab -e
Aggiungi:
0 8 * * * /usr/local/sbin/check-disk.sh
Così lo script viene eseguito ogni mattina alle 08:00.
Se vuoi un controllo ogni ora:
0 * * * * /usr/local/sbin/check-disk.sh
Per server semplici può bastare. Per server critici, invece, meglio usare un sistema di monitoraggio vero, con storico, notifiche affidabili e controllo dei servizi.
Script rapido per controllare la crescita dei log
Puoi creare anche uno script per vedere i log più pesanti:
sudo nano /usr/local/sbin/check-logs-size.sh
Contenuto:
#!/bin/bash
echo "Log più grandi in /var/log:"
find /var/log -type f -size +50M -exec ls -lh {} \; | sort -k5 -h
echo
echo "Spazio usato dal journal:"
journalctl --disk-usage
Permessi:
sudo chmod +x /usr/local/sbin/check-logs-size.sh
Esecuzione:
sudo /usr/local/sbin/check-logs-size.sh
Questo non risolve automaticamente i problemi, ma ti dice dove guardare. Ed è già un enorme passo avanti rispetto al “riavviamo e vediamo”.
Quando bastano questi strumenti e quando no
Questi comandi sono ottimi quando:
- gestisci pochi server;
- vuoi una checklist semplice;
- devi fare manutenzione periodica;
- vuoi capire rapidamente perché il disco si sta riempiendo;
- non vuoi installare agent o piattaforme esterne;
- hai server interni o ambienti non troppo complessi.
Non bastano, invece, quando:
- hai molti server;
- servono notifiche garantite;
- devi monitorare CPU, RAM, rete, uptime e servizi;
- vuoi grafici storici;
- devi rispettare procedure aziendali o SLA;
- vuoi integrazione con ticket, chat o sistemi di incident management.
In quei casi una suite di monitoraggio ha senso. Ma anche lì, conoscere df, du, journalctl e logrotate resta fondamentale. Perché quando qualcosa si rompe alle 18:30, la dashboard è bella, ma il terminale è quello che ti salva davvero.
Piccola checklist finale
Per un Ubuntu Server sotto controllo, almeno a livello base, conviene verificare periodicamente:
- spazio disco con
df -h; - inode con
df -ih; - cartelle pesanti con
du; - dimensione dei log in
/var/log; - spazio usato dal journal con
journalctl --disk-usage; - errori recenti con
journalctl -p err; - configurazione di
logrotate; - eventuali script di alert via cron;
- backup funzionanti, perché cancellare log non è una strategia di disaster recovery.
Conclusione
Monitorare un Ubuntu Server non significa per forza installare una piattaforma enorme solo per scoprire che /var/log è ingrassata come dopo le feste.
Per molti casi, un buon controllo di base parte da strumenti semplici: df per vedere lo spazio disponibile, du per capire cosa occupa spazio, journalctl per leggere i log di sistema, logrotate per evitare che i log crescano senza controllo e qualche script di alert per ricevere un avviso prima che il server finisca con il disco pieno.
La cosa importante è non aspettare l’emergenza. Perché quando il disco arriva al 100%, il server non ti manda una poesia: smette semplicemente di collaborare.