Monitorare Server Linux Performance: 8 Strumenti a Confronto

Quando un applicativo critico su un server con 64GB di RAM inizia a scambiare sul disco, la CPU schizza al 100% e gli utenti chiamano il supporto, devi capire dove cercare. Il problema quasi mai è dove credi. Ho passato ore a guardare il comando top su un cluster virtualizzato per un ente sanitario pubblico, chiedendomi perché le VM fossero lente, prima di capire che il collo di bottiglia era la coda di I/O sul datastore condiviso. Monitorare le performance di un server Linux richiede lo strumento giusto per il livello corretto dello stack. In questa guida metto a confronto 8 strumenti essenziali per individuare il reale responsabile dei rallentamenti.

Prerequisiti / Ambiente di test

Per seguire questa guida ti serve un server Linux con accesso root. Tutti gli strumenti sono disponibili sulle distribuzioni basate su Debian e RHEL. Su Ubuntu e derivate, installa i pacchetti principali con questo comando:

sudo apt install htop iotop nload glances sysstat -y

Il pacchetto sysstat include iostat e sar. Per gli esempi userò un server con carico di lavoro misto (web server e database) per mostrare output realistici.

Il problema: sai che il server è lento, non sai perché monitorare server linux performance è vitale

Lentezza è un termine vago. Significa che l’applicazione risponde in ritardo. Significa che le query impiegano il doppio del tempo. Significa che il caricamento delle pagine supera gli SLA. Per risolvere il problema devi classificare il collo di bottiglia. Si divide in quattro categorie: CPU, memoria, disco I/O e rete. Se apri un tool generico e guardi i dati senza un’ipotesi iniziale, ti perdi nel rumore. La capacità di monitorare server linux performance in modo efficace dipende dalla tua capacità di isolare la risorsa satura.

top e htop — il punto di partenza

Il comando top è presente su ogni sistema Linux. Mostra l’utilizzo della CPU, la memoria e la lista dei processi ordinati per consumo. La sua interfaccia è spartana e interattiva, ma spesso poco leggibile.

htop è il suo successore spirituale. Offre un’interfaccia colorata, supporta lo scorrimento orizzontale e verticale, permette di killare i processi senza digitare il PID e mostra l’albero dei processi. Quando mi connetto a un server lento, htop è il primo comando che lancio.

Per contestualizzare l’utilizzo della memoria, affianco sempre htop al comando free -h. Il flag -h mostra i valori in formato leggibile (megabyte o gigabyte). Controlla la colonna available e non la colonna free. Linux usa la memoria libera per la cache del filesystem, quindi la memoria free apparentemente bassa non indica un problema. La memoria available indica quanta ram è effettivamente recuperabile se le applicazioni la richiedono.

free -h

Se la memoria available è inferiore al 10% della RAM totale, il server sta swappando. Lo swap sul disco è centinaia di volte più lento della RAM. Questa è la causa più comune di degrado silenzioso.

glances — il cruscotto tutto-in-uno

Se vuoi una visione completa senza cambiare finestra, lancia glances. Questo strumento scritto in Python raccoglie CPU, memoria, swap, disco I/O, rete e processi in una singola schermata. Si aggiorna in tempo reale e segnala con colori differenti le soglie critiche (rosso per i valori pericolosi, magenta per i warning).

glances

Glances offre anche una modalità client-server. Puoi avviare glances -s sul server remoto e collegarti dal tuo PC con glances -c @IP_DEL_SERVER. Questo approccio evita di aprire una sessione SSH sul server in crisi, riducendo il carico aggiuntivo.

iostat e iotop — quando il problema è il disco

Quando la CPU sembra alta ma i processi non consumano cicli, controlla il parametro %iowait in top o htop. Un valore sostenuto di %iowait indica che la CPU è ferma ad aspettare che il disco completi le operazioni di lettura o scrittura.

Per analizzare nel dettaglio le performance del disco, usa iostat. Il comando iostat -xz 1 mostra le statistiche estese aggiornate ogni secondo. Guarda le colonne %util e await. Se %util si avvicina al 100%, il disco è saturo. Se await supera i 10-20 millisecondi per un disco SSD (o 50-100 per un disco meccanico), il dispositivo ha un problema di latenza.

iostat -xz 1

Per scoprire quale processo genera il carico di I/O, usa iotop. Il flag -o mostra solo i processi che stanno effettivamente scrivendo o leggendo, filtrando il rumore di fondo.

sudo iotop -o

In un ambiente con database pesanti, ho visto iotop identificare una query Oracle sospesa che scriveva decine di megabyte al secondo nel file di temp. Senza iotop, avrei continuato a cercare un problema di CPU inesistente.

nethogs e iftop — quando il problema è la rete

Se il disco e la CPU sono tranquilli, il collo di bottiglia potrebbe essere la rete. Per vedere il traffico in tempo reale su una specifica interfaccia, nload è immediato. Mostra due grafici, uno in entrata e uno in uscita, con il traffico corrente e il totale.

nload eth0

Per capire quali processi consumano banda, nethogs raggruppa il traffico per processo. Per verificare quali porte sono in ascolto e quante connessioni attive ci sono su ciascuna, il comando ss ha sostituito netstat ormai da anni.

ss -tulnp

Il flag -t filtra le connessioni TCP, -u quelle UDP, -l mostra solo le porte in ascolto, -n non risolve i nomi di dominio e -p mostra il processo associato. Se vedi centinaia di connessioni ESTABLISHED su una porta di un web server, potresti avere un problema di esaurimento delle porte o un attacco DDoS lento.

vmstat — CPU, memoria e swap in un colpo solo

vmstat è il coltellino svizzero del monitoraggio. Riassume processi, memoria, swap, I/O, sistema e CPU in una singola tabella. Lancialo specificando un intervallo di aggiornamento e il numero di righe.

vmstat 2 10

Questo comando stampa 10 righe aggiornate ogni 2 secondi. Ignora la prima riga, che mostra le medie dal boot del sistema. Guarda le colonne chiave. La colonna b sotto procs indica i processi bloccati in attesa di I/O. Le colonne si e so sotto swap indicano rispettivamente la memoria swap-in e swap-out. Se questi valori sono diversi da zero in modo continuativo, il server ha bisogno di più RAM. La colonna wa sotto cpu è la percentuale di iowait.

[Leggi anche: Hardening SSH su Linux: 10 Impostazioni Essenziali]

sar — storico delle performance nel tempo

Tutti gli strumenti visti finora mostrano dati in tempo reale. Se il rallentamento è avvenuto alle 3 di notte e tu controlli alle 9 di mattina, non vedi nulla. Qui entra in gioco sar.

Il pacchetto sysstat raccoglie le metriche di sistema ogni 10 minuti tramite un cron job. Puoi interrogare lo storico con il comando sar seguito dal flag dell’intervallo temporale. Ad esempio, sar -u mostra l’utilizzo della CPU storico, sar -r la memoria, sar -d l’attività dei dischi.

Per visualizzare l’utilizzo della CPU di ieri:

sar -u -f /var/log/sysstat/sa$(date -d yesterday +%d)

Configura sysstat per mantenere i dati per almeno 30 giorni modificando il file /etc/sysstat/sysstat-config e imposta HISTORY=30. Questo ti permette di confrontare il comportamento del server nel tempo e identificare pattern ricorrenti.

Prometheus + Grafana — monitoraggio professionale per produzione

Per un’infrastruttura con più server, collegarsi in SSH su ogni macchina non è scalabile. Prometheus raccoglie le metriche tramite exporter (come node_exporter per Linux) e le archivia in un database time-series. Grafana si collega a Prometheus e visualizza i dati in dashboard interattive.

L’approccio cambia da reattivo a proattivo. Configuri alert su Grafana o Alertmanager per ricevere una notifica quando l’iowait supera il 20% per più di 5 minuti, o quando lo swap supera i 2GB. Questo è lo standard per monitorare server linux performance in ambienti enterprise.

La documentazione ufficiale di Prometheus spiega nel dettaglio come configurare il scraping delle metriche: https://prometheus.io/docs/prometheus/latest/configuration/configuration/

Tabella comparativa: quando usare quale strumento

Per scegliere rapidamente lo strumento adatto alla situazione, usa questa tabella di riferimento.

|—|—|—|—|

Errori comuni e troubleshooting

Il primo errore è guardare solo la CPU. Un server con la CPU al 20% può essere lento se il 19% è iowait. La CPU aspetta il disco e le applicazioni si bloccano.

Il secondo errore è fidarsi della memoria free riportata da top. Come detto, la cache del filesystem occupa la memoria libera. Guarda sempre la memoria available con free -h.

Il terzo errore è non avere lo storico. Senza sar o Prometheus, un problema intermittente diventa impossibile da diagnosticare. Installa sysstat oggi sui tuoi server di produzione.

Infine, attenzione all’overhead degli strumenti stessi. Lanciare glances o iotop su un server già al limite aggiunge carico. Usa vmstat o iostat per un impatto minimo quando le risorse sono critiche.

Conclusioni con takeaway operativi

Diagnosticare i problemi di performance su Linux richiede metodo, non fortuna. Non aprire top sperando di trovare la risposta. Segui un ordine logico.

Primo passo: controlla memoria e swap con free -h e vmstat 2 10. Se il server swappa, hai trovato il problema.

Secondo passo: controlla l’iowait con vmstat e approfondisci con iostat -xz 1. Se il disco è lento, usa sudo iotop -o per trovare il processo colpevole.

Terzo passo: se memoria e disco sono a posto, controlla la CPU con htop e la rete con nload eth0 e ss -tulnp.

Quarto passo: installa sar oggi stesso per non farti trovare impreparato la prossima volta che il rallentamento avviene di notte.

Per ambienti con più server, pianifica la migrazione a Prometheus e Grafana. Il monitoraggio reattivo va bene per il troubleshooting. Il monitoraggio proattivo protegge il tuo SLA.