Monitoraggio server Linux: le 10 metriche che contano davvero (e quelle che ingannano)
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
Manuel Stöth
in reply to netzpolitik.org • • •MaryMarasKittenBakery
in reply to Manuel Stöth • • •Wenn wir dafür sorgen
DentroChat
in reply to netzpolitik.org • • •MaryMarasKittenBakery
in reply to netzpolitik.org • • •Daher: Generalstreik und wir stellen dann einfach eine Liste mit Forderungen auf, von sozialen Themen bis Datenschutz.
Oder wir lassen es halt.
#GeneralstreikJetzt
#BuyMoreGuillotines
Andreas K
in reply to netzpolitik.org • • •Unternehmen sind eigentlich bereits verpflichtet ihre Software GDPR konform anzulegen.
Nur keiner mag es aussprechen das Microsoft 365 eben nicht GDPR kompatibel ist.
Ende der Diskussion.
Und wegen Schrems II und Cloud Act ist es eigentlich ziemlich klar dass Microsoft keine SaaS anbieten kann die GDPR kompatibel ist.
Und das ist eigentlich nicht wirklich ein Geheimnis in der Fachdiskussion.
Und die Politik wird irgendwann von EuGH eingeholt werden.
☮#MircoBrahmann☮
in reply to netzpolitik.org • • •Andreas K
in reply to netzpolitik.org • • •Anzumerken wäre das es keine "risikoarme" Personen bezogene Datenverarbeitung gibt.
Gerade die Vereine sind nicht harmlos.
Eine einfache Mitgliedsliste gibt mir als Minimum Name und Adresse und ein Tag wie diese Leute Wandern gerne in den Alpen oder gehen Bogenschießen.
Wenn ich jetzt sie Listen oben zusammenführe, habe ich gleich ein Profil von Leuten die Bogenschießen und/oder in den Bergen wandern.
Wenn sich Vereine plötzlich durch
Andreas K
in reply to Andreas K • • •den Verkauf ihrer Mitgliedsliste dazu finanzieren können ist es trivial sehr viele dieser Listen zu kriegen. Und sehr umfangreiche Profile von Personen zu erstellen.
Und das man das potenziell als KMU machen kann, sehe ich da schon eine Geschäftsidee: lerne die Vorlieben deines Blind Dates schon vor dem Date kennenlernen.
Nur dass das diese Schnapsidee an der Gründerechtscharta scheitern wird.
@netzpolitik_feed
jesterchen42
in reply to netzpolitik.org • • •lothenon
in reply to netzpolitik.org • • •Panta Rhei
in reply to netzpolitik.org • • •Hobo
in reply to netzpolitik.org • • •