Un server Linux quasi sempre avvisa prima di guastarsi. Il problema è che la maggior parte dei sistemisti guarda i numeri sbagliati: il carico della CPU invece dell’iowait, la percentuale di RAM occupata invece dello swap attivo, lo spazio disco invece degli inode liberi. Il risultato è che i segnali d’allarme restano invisibili finché non si trasformano in un incidente in produzione.
Vediamo dieci metriche che vale davvero la pena monitorare su un’infrastruttura Linux, con i comandi per raccoglierle, le soglie di riferimento e — soprattutto — come metterle in relazione tra loro invece di guardarle isolate.
1. CPU: l’iowait conta più dell’utilizzo grezzo
La percentuale di utilizzo CPU complessiva è un punto di partenza, ma il segnale utile è nell’%iowait: indica quanto tempo le CPU passano ferme in attesa di I/O su disco invece di eseguire codice applicativo. Un server all’90% di CPU è occupato; un server al 40% di iowait è in sofferenza, anche se il carico “totale” sembra alto allo stesso modo.
mpstat -P ALL 1 5
Un iowait sostenuto sopra il 20-30% giustifica un’indagine sullo storage con
iostat -xz 1 (vedi punto 5).
2. Load average rapportato ai core disponibili
Il load average è tra le metriche più fraintese in assoluto: un valore di 8.0 non significa nulla senza sapere quanti core ha la macchina. La regola empirica è che un load sostenuto sopra 1.0 per core indica una possibile saturazione, anche se il collo di bottiglia potrebbe essere CPU, I/O su disco o un altro sottosistema.
cat /proc/loadavg
nproc
Le tre medie (1, 5, 15 minuti) vanno lette come trend: se il valore a 15 minuti cresce costantemente, c’è qualcosa che si sta accumulando — un processo runaway, un thread leak, un collo di bottiglia I/O.
3. Memoria: non temere l’uso, temi lo swap attivo
Linux usa la RAM libera come page cache, quindi un server che mostra il 95% di memoria occupata non è necessariamente in difficoltà, se gran parte è cache riutilizzabile. Quello che conta davvero è quanta memoria è effettivamente disponibile e se il sistema sta attivamente paginando su swap.
free -h
grep -E "MemAvailable|SwapTotal|SwapFree" /proc/meminfo
vmstat 1 5
Un po’ di swap usato non è di per sé un problema: con un
vm.swappiness ben tarato, il kernel può spostare pagine “fredde” su swap in modo proattivo senza impatti percepibili. Il segnale d’allarme reale sono le colonne
si (swap-in) e
so (swap-out) di
vmstat: valori sostenuti e diversi da zero, o uno swap che cresce sotto carico, indicano pressione di memoria che degraderà le prestazioni.
4. Spazio disco e utilizzo degli inode
Finire lo spazio disco è evidente. Finire gli inode è il killer silenzioso che manda in crisi anche i sistemisti più esperti: si possono avere gigabyte liberi e non riuscire comunque a creare un nuovo file se gli inode sono esauriti.
df -h # spazio disco
df -i # utilizzo inode
L’esaurimento degli inode capita tipicamente in directory con milioni di file piccoli — code di mail, session store, directory temporanee. Impostate soglie di allerta all’80% sia per lo spazio sia per gli inode, non solo per lo spazio.
5. Latenza e throughput I/O del disco
Il throughput dice quanti dati si muovono; la latenza dice quanto tempo impiega ogni singola operazione. Un disco che serve scritture sequenziali può avere un throughput ottimo e al contempo una latenza pessima su letture casuali — esattamente il pattern che uccide le prestazioni di un database.
iostat -xz 1
Le colonne chiave da osservare sono
await (tempo medio in ms per servire una richiesta I/O),
%util (percentuale di tempo in cui il device è occupato) e
r/s/
w/s (operazioni al secondo). Un
await sopra 20ms per HDD, o sopra 1-2ms per workload sensibili alla latenza su SSD, merita un’indagine. Su HDD e SATA SSD un
%util vicino al 100% indica saturazione; sugli NVMe questo indicatore è meno affidabile per via dell’architettura multi-queue, quindi in quel caso conviene fidarsi soprattutto dell’
await.
6. Traffico di rete e tassi di errore
La banda utilizzata è la base. Quello che le dashboard spesso non mostrano sono i pacchetti persi, gli errori e le ritrasmissioni, che possono segnalare problemi alla scheda di rete, allo switch o una rete sotto flooding.
ip -s link show eth0
ss -s
netstat -s | grep -E "retransmit|error|drop"
Un contatore di errori sulla NIC che cresce nel tempo indica quasi sempre un problema hardware o di cablaggio. Un tasso di ritrasmissione TCP sopra l’1-2% segnala spesso congestione, perdita di pacchetti o altri problemi di connettività che stanno già impattando le applicazioni.
7. File descriptor aperti
Ogni file, socket e pipe aperti consuma un file descriptor. Applicazioni sotto carico — web server, database, sistemi di messaggistica — possono esaurire il limite per processo o quello di sistema e iniziare a restituire errori “too many open files” che si propagano a cascata.
# Uso corrente a livello di sistema
cat /proc/sys/fs/file-nr
# Massimo di sistema
cat /proc/sys/fs/file-max
# Per processo
ls /proc/<PID>/fd | wc -l
cat /proc/<PID>/limits | grep "open files"
Se l’utilizzo corrente supera stabilmente il 70-80% del massimo di sistema, è il momento di indagare. Se un processo specifico si avvicina al proprio ulimit, o ha un leak di descriptor (bug da correggere) oppure ha semplicemente bisogno di un limite più alto (tuning). Per capire quale processo trattiene quali file,
lsof è lo strumento di riferimento.
8. Conteggio di processi e thread
Picchi improvvisi nel numero di processi possono indicare fork bomb, cron job impazziti o thread pool applicativi mal configurati. Su applicazioni fortemente multithread, una crescita illimitata del numero di thread è un classico sintomo di bug di concorrenza.
ps aux | wc -l
cat /proc/sys/kernel/threads-max
top -H -p <PID> # thread di un processo specifico
Conoscere la propria baseline è essenziale: se un web server gira normalmente con 50 worker e improvvisamente se ne vedono 500, qualcosa nella configurazione del servizio o dell’applicazione non va.
9. Salute hardware: temperatura e SMART
È la metrica che più spesso manca negli stack di monitoraggio software, ed è un errore: le CPU riducono le prestazioni (thermal throttling) prima di spegnersi, quindi si osserva un degrado misterioso delle performance ben prima che compaia un errore esplicito.
# Richiede lm-sensors
sensors
# Stato dischi
smartctl -a /dev/sda
# IPMI su bare metal
ipmitool sdr type Temperature
Su macchine virtuali questi dati possono essere nascosti al guest OS; su server bare metal, temperatura e dati SMART/NVMe rappresentano un livello di preallarme che nessuna metrica software può sostituire. Temperature CPU stabilmente sopra 80°C, o dischi che riportano settori riallocati o errori non correggibili nei dati SMART/NVMe, richiedono intervento immediato.
10. Tasso di errore nei log di sistema
Le metriche dicono come sono i numeri; i log dicono perché. Tracciare il tasso di voci ERROR e CRITICAL nel tempo, invece di leggere i log riga per riga, offre un segnale d’allarme precoce prima che il problema diventi un’interruzione di servizio.
# systemd
journalctl -p err --since "1 hour ago"
journalctl -p err --since "1 hour ago" | wc -l
# syslog classico
grep -iEc "error|critical" /var/log/syslog
Un improvviso aumento del tasso di errore nei log, anche se il sistema sembra funzionare normalmente, spesso precede un guasto di minuti o ore. Anche qui, definire una baseline dei tassi di errore “normali” rende evidenti le anomalie.
Mettere insieme i pezzi: le baseline battono le soglie fisse
Soglie statiche (ad esempio: allerta se la CPU supera l’80%) sono un buon punto di partenza, ma restano strumenti grezzi. La pratica più efficace di monitoraggio Linux è costruire baseline specifiche per il proprio carico di lavoro e allertare sulla deviazione dalla norma, non solo sui valori assoluti.
- Correlate le metriche, non guardatele a compartimenti stagni: CPU alta combinata con iowait elevato e await del disco in crescita racconta una storia molto più chiara di ciascuna metrica da sola.
- Allertate sui trend, non sugli scatti isolati: un load average in crescita costante nell’arco di 15 minuti è più utile di un singolo picco.
- Tenete d’occhio il gap del monitoraggio: il tempo che passa tra il superamento di una soglia e l’intervento umano è dove gli incidenti crescono. Automatizzate tutto ciò che potete, ad esempio con Prometheus + node_exporter + Alertmanager per la raccolta e la notifica, o con Grafana per la visualizzazione delle baseline nel tempo.
Su una manciata di server, eseguire questi controlli manualmente da riga di comando funziona bene. Quando l’infrastruttura cresce a decine o centinaia di macchine, diventa poco pratico farlo a mano: è il momento di investire in una piattaforma di observability centralizzata che aggreghi queste metriche, applichi soglie dinamiche e correli gli eventi tra sistemi diversi.
Gli strumenti cambiano nel tempo — oggi iostat e vmstat, domani forse eBPF-based tooling come bpftrace — ma i fondamentali restano gli stessi: sapere cosa guardare, in che relazione, e con quale baseline confrontarlo.
Fonte: LinuxBlog.io
