Come monitorare la banda di rete su un server Linux

Se devi capire quanta banda consuma davvero un server Linux, la domanda giusta non è solo “quanto traffico passa”, ma “su quale interfaccia, in quale momento, verso quali destinazioni e con quale impatto sul servizio”. La differenza tra un picco innocuo e un collo di bottiglia sta quasi sempre nei dettagli: traffico aggregato sul link, burst brevi, errori di interfaccia, saturazione della coda, oppure un processo applicativo che parla troppo con database, backup o CDN.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Il monitoraggio della banda va impostato su tre livelli: visione immediata del traffico in corso, storico per capire tendenze e picchi, e controllo di sistema per correlare rete, CPU, memoria e disco. Se ti limiti a un solo strumento, rischi di vedere il sintomo ma non la causa.

1. Parti dall’interfaccia giusta

Prima di lanciare strumenti a caso, identifica l’interfaccia che porta il traffico reale. Su un server moderno può essere eth0, ens3, enp1s0, una bond, una VLAN o un bridge. Se guardi quella sbagliata, i numeri saranno formalmente corretti ma inutili.

Per vedere le interfacce e i contatori base usa:

ip -br link
ip -s link show dev ens3

Nel secondo comando osserva soprattutto RX, TX, errori, dropped e overruns. Se i byte crescono ma anche gli errori aumentano, non stai solo misurando traffico: stai già vedendo un problema di qualità del link o di saturazione del percorso.

Se il server è dietro una bond o un bridge, verifica anche l’interfaccia logica e i member fisici. Un bonding può distribuire il traffico in modo non intuitivo, e un bridge può sommare flussi di VM o container che a livello host sembrano “misteriosi”.

2. Controllo live: vedere il traffico mentre accade

Per un colpo d’occhio immediato, i due strumenti più utili restano iftop e nload. Il primo mostra chi parla con chi; il secondo rende evidente il volume in ingresso e in uscita. Sono complementari: uno ti dice la direzione del problema, l’altro ti fa capire la scala.

Con iftop:

sudo iftop -i ens3

Leggi le righe più attive e guarda se il traffico è concentrato su pochi IP o distribuito. Se vedi connessioni persistenti verso un backend, un mirror o un nodo di replica, hai già una pista concreta. Se invece il traffico è verso molte destinazioni diverse, può trattarsi di traffico applicativo, scansioni o aggiornamenti di pacchetti.

Con nload:

sudo nload ens3

Qui la lettura è più semplice: picchi, media e andamento. È utile quando devi capire se il link è stabile o se ha burst brevi che sfuggono a controlli più lenti.

Se vuoi una vista più operativa e meno “grafica”, usa anche watch su contatori di sistema:

watch -n 1 'ip -s link show dev ens3'

Questo è utile quando sospetti errori o dropped che crescono sotto carico. Se i contatori aumentano solo durante un evento preciso, hai un indizio temporale da incrociare con log applicativi e metriche di sistema.

3. Storico e trend con sar e sysstat

Il monitoraggio live serve a reagire, ma per capire se il server ha un problema ricorrente serve lo storico. Su Linux, la suite sysstat è ancora una delle soluzioni più pratiche: ti dà dati periodici su CPU, I/O e rete con overhead basso.

Su molte distribuzioni puoi installarla così:

sudo apt install sysstat

Oppure, su sistemi basati su RPM:

sudo dnf install sysstat

Una volta attivo il servizio di raccolta, puoi consultare la banda con sar:

sar -n DEV 1 5

Qui vedi traffico per interfaccia, con valori medi di ricezione e trasmissione. Se vuoi un dato storico di giornata, usa l’archivio locale di sysstat:

sar -n DEV -f /var/log/sysstat/sa$(date +%d)

Il percorso può variare in base alla distro e alla configurazione, ma il concetto resta lo stesso: leggere i file di raccolta per ricostruire il comportamento del link nelle ore precedenti. Se il picco compare sempre alla stessa ora, di solito non è casuale: backup, job batch, sincronizzazioni, replica database o traffico di aggiornamento.

4. Misurare il traffico per processo

Il dato di interfaccia dice quanto passa sulla rete. Il dato per processo ti aiuta a capire chi lo genera. Non sempre è perfetto, soprattutto con container, NAT o traffico multiplexato, ma è spesso il passaggio che chiarisce il quadro.

Con nethogs puoi vedere i processi che consumano banda in tempo reale:

sudo nethogs ens3

Se il traffico è dominato da un web server, da un backup agent o da un processo di sincronizzazione, lo vedi subito. Se invece la banda è “sparsa” su tanti processi piccoli, l’analisi va spostata su connessioni, socket e log applicativi.

Un’altra strada utile è associare connessioni e PID:

ss -tupn

Questo comando è prezioso quando vuoi sapere quale processo mantiene molte connessioni aperte verso un servizio esterno o interno. Non misura la banda da solo, ma ti aiuta a collegare flussi di rete e identità del processo.

5. Netstat, ss e i contatori del kernel

Se devi verificare lo stato delle socket, oggi ss è in genere preferibile a netstat perché è più rapido e più completo sui sistemi moderni. Per controllare quante connessioni ci sono verso una certa porta o verso un host specifico, è spesso il modo più veloce per capire se la banda è causata da molte connessioni brevi o da pochi flussi lunghi.

Esempio pratico:

ss -tan state established '( sport = :443 or dport = :443 )'

Se le connessioni sono molte e il throughput è alto, puoi avere un normale carico HTTPS. Se invece il numero di socket è basso ma la banda è elevata, probabilmente hai trasferimenti grandi: download, upload, backup, stream o repliche.

Per i contatori kernel, /proc/net/dev resta una fonte semplice e affidabile per un controllo rapido:

cat /proc/net/dev

Qui trovi byte, pacchetti, errori e drop per ogni interfaccia. È un dato grezzo, ma utile quando vuoi integrare una verifica in script o in un check automatico. Se i contatori crescono in modo anomalo rispetto al traffico atteso, hai una base oggettiva per aprire un’analisi più profonda.

6. Grafana, Prometheus e visibilità continua

Se il server è importante, il monitoraggio manuale non basta. Per una visibilità continua conviene esportare metriche verso un sistema di raccolta centrale, tipicamente Prometheus con Grafana oppure una piattaforma equivalente. L’obiettivo non è fare “grafici belli”, ma avere una soglia, un allarme e una timeline che colleghi la rete a ciò che è successo nell’applicazione.

Le metriche da tenere d’occhio sono poche ma decisive:

• throughput in ingresso e uscita per interfaccia;
• errori e dropped packet;
• saturazione della banda rispetto al link fisico o virtuale;
• latenza e packet loss, se il problema è distribuito;
• correlazione con CPU, memoria, disco e tempi di risposta applicativi.

Se hai già un exporter di nodo, spesso il dato di rete è incluso. In quel caso vale la pena costruire alert semplici: una soglia sulla banda media, una sul rate di errori, una sul numero di retry applicativi se il servizio ne espone uno. L’errore comune è allarmarsi solo sul traffico assoluto: un server può usare tanta banda senza problemi, oppure poca banda ma con latenza e errori che distruggono l’esperienza utente.

7. Interpretare i segnali: banda alta non significa sempre problema

Un picco di traffico non è automaticamente un guasto. Può essere un backup pianificato, un deploy, una replica, un upload massivo o un aggiornamento software. Il punto è capire se il picco è coerente con la finestra operativa prevista. Se coincide con un job noto e non degrada il servizio, è normale. Se invece si associa a timeout, 5xx, lentezza o saturazione, allora diventa un incidente o quantomeno un rischio tecnico da correggere.

Gli indizi che meritano attenzione sono soprattutto questi:

1. Traffico elevato ma connessioni normali: possibile trasferimento grande o streaming.
2. Traffico medio con errori di interfaccia: possibile problema fisico o driver.
3. Traffico basso ma latenza alta: possibile congestione altrove, non sulla banda pura.
4. Traffico improvviso con CPU alta: possibile compressione, crittografia o proxying.

Questo passaggio è importante perché evita diagnosi sbagliate. Non tutto ciò che “va lento” è colpa della rete; non tutto ciò che “usa tanta banda” è un problema. La lettura corretta nasce dall’incrocio tra contatori, log e comportamento del servizio.

8. Monitorare senza disturbare il server

In produzione conviene usare strumenti leggeri e non invasivi. sar, ip e lettura dei contatori kernel hanno impatto minimo; strumenti come iftop o nethogs sono comodi ma vanno usati con criterio, soprattutto su host molto caricati o su sessioni remote lente. Se possibile, eseguili in finestre brevi e solo sull’interfaccia rilevante.

Se devi fare un controllo ripetuto, è meglio automatizzare una raccolta minima piuttosto che restare collegato per mezz’ora a guardare una schermata. Per esempio, puoi schedulare un campionamento di sar e conservarlo per confronto con i log del servizio. In questo modo non solo vedi il problema, ma puoi provarlo nel tempo.

9. Una procedura pratica da usare in produzione

Quando ti chiamano perché “la rete è lenta”, una sequenza sensata è questa:

1. Identifica l’interfaccia attiva con ip -br link e verifica che sia quella giusta.
2. Controlla contatori e errori con ip -s link show dev <iface>.
3. Apri una vista live con iftop o nload per capire se il problema è in ingresso o in uscita.
4. Usa ss -tupn o nethogs per associare traffico a processi e socket.
5. Confronta con lo storico sar -n DEV per capire se è un picco previsto o un’anomalia ricorrente.
6. Correla con log applicativi, backup, job schedulati e metriche di latenza.

Questa sequenza funziona perché parte dal dato meno ambiguo e arriva gradualmente al dettaglio. Evita di saltare subito a modifiche di configurazione: se il problema è un job serale o un backup fuori finestra, cambiare tuning TCP non risolve nulla.

10. Quando serve un monitoraggio più serio

Se il server ospita servizi critici, il monitoraggio della sola banda non basta. Serve almeno una vista su disponibilità, latenza, error rate e saturazione delle risorse. La rete può essere il collo di bottiglia, ma spesso il sintomo visibile è altrove: query lente, storage pieno, garbage collection aggressiva, saturazione del reverse proxy o limiti di connessioni simultanee.

Per questo vale una regola semplice: la banda va letta come parte di un quadro più ampio. Se vuoi capire davvero il comportamento di un server Linux, non fermarti ai megabit al secondo. Guarda anche quando succedono i picchi, chi li genera, quanto durano e quale effetto hanno sul servizio. È lì che il dato diventa utile.

In pratica, il monitoraggio migliore non è quello con più grafici, ma quello che ti fa arrivare alla causa in pochi passaggi e con il minimo rumore possibile.