Come monitorare le prestazioni di un server Linux: comandi, metriche e strumenti

Per monitorare le prestazioni di un server Linux, controllate quattro risorse: CPU, memoria, I/O del disco e rete. Usate comandi integrati come top, vmstat, free, iostat e ss per la diagnosi in tempo reale, e uno strumento basato su agent come Prometheus con node_exporter, Zabbix o il CloudWatch agent per conservare lo storico e inviare allarmi.

Punti chiave

• Per ogni risorsa, controllate utilizzo, saturazione ed errori (il metodo USE). Un utilizzo elevato da solo non è un problema; lo sono code ed errori.
• Confrontate il load average con il numero di core della CPU e tenete d'occhio %wa (attesa di I/O) e %st (steal time) sulle VM cloud.
• Per la memoria, leggete la colonna available di free, non free. Linux usa di proposito la memoria libera come cache.
• Le pressure stall information in /proc/pressure/ mostrano direttamente quanto tempo i task attendono CPU, memoria o I/O.
• I comandi mostrano il presente. Per tendenze e allarmi servono un agent di monitoraggio e un database di serie temporali.

Quali metriche di prestazioni di Linux contano?

Partite dal metodo USE dell'esperto di prestazioni Brendan Gregg: per ogni risorsa, controllate utilizzo, saturazione ed errori. Vi dà una checklist al posto delle congetture.

Come si controllano utilizzo e carico della CPU su Linux?

Eseguite top (o htop) e leggete la riga della CPU, poi confrontate il load average con il numero di core restituito da nproc.

top # live view; press 1 to show each core
nproc # number of CPU cores
uptime # load average over 1, 5 and 15 minutes
mpstat -P ALL 1 # per-core usage every second (sysstat package)

Secondo la man page di proc_loadavg, il load average conta i processi in esecuzione o in attesa di I/O su disco, mediati su 1, 5 e 15 minuti. Un carico di 6 su un server a 8 core va bene. Un carico di 6 su un server a 2 core significa che il lavoro è in coda. Poiché il carico include i processi in attesa del disco, un carico alto con CPU poco usata di solito indica un problema di storage.

Nella riga della CPU di top, due campi contano sui server cloud:

• wa: tempo in cui la CPU è rimasta inattiva in attesa di I/O. Valori alti e prolungati indicano dischi o storage di rete lenti.
• st: secondo la man page di top, "time stolen from this vm by the hypervisor" (tempo sottratto a questa VM dall'hypervisor). Uno steal prolungato su una VM cloud significa che l'host è occupato o che un'istanza burstable ha esaurito i crediti CPU.

Come si controlla l'uso della memoria su Linux?

Eseguite free -h e leggete la colonna available. La man page di free la definisce come una stima della memoria disponibile per nuove applicazioni senza ricorrere allo swap, tenendo conto della page cache.

free -h # human-readable memory summary
vmstat 1 5 # si/so columns show swap in/out per second
journalctl -k | grep -i "out of memory" # OOM killer events

Un server con poca memoria "free" ma molta "available" è in salute: Linux riempie la RAM libera con la cache del disco e la rilascia quando i programmi ne hanno bisogno. I segnali di allarme sono una memoria available in calo nell'arco di giorni (possibile leak), un'attività di swap costante in vmstat e voci dell'OOM killer nel log del kernel.

Come si controllano prestazioni e spazio del disco?

Usate iostat -xz 1 per le prestazioni di I/O e df per spazio e inode.

iostat -xz 1 # per-device utilisation, queue and latency (sysstat)
df -h # disk space per filesystem
df -i # inode usage: many small files can fill these first
du -sh /var/log/* | sort -h # find what is using space

In iostat, osservate r_await e w_await (millisecondi medi per richiesta) e aqu-sz (lunghezza della coda). La man page di iostat osserva che, per i dispositivi che servono richieste in parallelo, come gli array RAID e gli SSD moderni, %util non riflette i loro limiti di prestazioni. Latenza e lunghezza della coda in aumento sono indicatori migliori di saturazione.

Come si monitorano le prestazioni di rete?

sar -n DEV 1 # throughput per interface
sar -n TCP,ETCP 1 # TCP connections and retransmits
ss -s # socket summary
ip -s link # errors and drops per interface

Ritrasmissioni, pacchetti scartati o errori di interfaccia in aumento indicano problemi di rete anche quando il throughput sembra normale. Sulle VM cloud, confrontate il throughput con il limite di rete del tipo di istanza.

Che cosa sono le pressure stall information (PSI)?

PSI è una funzione del kernel che riporta quanto tempo i task trascorrono in attesa di CPU, memoria o I/O. La documentazione del kernel spiega che ogni file in /proc/pressure/ ha una riga "some" (quota di tempo in cui almeno alcuni task sono bloccati) e, per memoria e I/O, una riga "full" (tutti i task non inattivi bloccati contemporaneamente, che il kernel descrive come thrashing).

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

PSI risponde direttamente alla domanda "questa risorsa sta rallentando il lavoro?", il che lo rende un buon segnale per gli allarmi. Se i file non esistono, il vostro kernel è stato compilato o avviato senza supporto PSI.

Quali strumenti usare per il monitoraggio continuo?

I comandi mostrano cosa succede adesso. Per individuare i problemi di notte, vedere le tendenze e avvisare la persona giusta, installate un agent di monitoraggio che invii le metriche a un database di serie temporali.

Quali allarmi impostare per primi?

1. Spazio su disco e inode oltre l'80-85% su qualsiasi filesystem, con un allarme previsionale per "pieno entro 24 ore".
2. Memoria disponibile bassa per più di 10 minuti, oppure qualsiasi evento dell'OOM killer.
3. Load average sopra il numero di core per più di 15 minuti, oppure pressione sulla CPU in aumento.
4. Latenza del disco o pressione sull'I/O molto sopra la baseline normale del server.
5. Controlli dei servizi: la porta dell'applicazione risponde e un URL di health restituisce esito positivo.
6. Backup e scadenza dei certificati, che falliscono in silenzio.

Queste soglie sono punti di partenza. Taratele sul comportamento normale di ogni server, così gli allarmi restano utili. La nostra guida al monitoraggio delle prestazioni dei server tratta Windows e le pratiche generali, e il monitoraggio dell'infrastruttura cloud tratta i servizi gestiti oltre il server.

Come vi aiuta Opsio

Opsio monitora e gestisce server Linux su AWS, Azure e on-premises nell'ambito dei nostri servizi IT gestiti, con risposta agli allarmi 24/7, patching e revisioni della capacità, usando Prometheus e Grafana o strumenti nativi del cloud. Ad esempio, la piattaforma AWS che abbiamo realizzato per WorkBuster gira su istanze EC2 in un gruppo di auto-scaling, con dashboard e allarmi CloudWatch per le operazioni quotidiane.

Domande frequenti

Qual è il miglior comando per controllare le prestazioni di un server Linux?

Partite da top per una panoramica in tempo reale, poi vmstat 1 per le tendenze di CPU, memoria e swap e iostat -xz 1 per i dischi. Insieme mostrano la maggior parte dei colli di bottiglia in un minuto.

Qual è un buon load average per un server Linux?

Dipende dal numero di core della CPU. Un load average pari o inferiore al numero di core di solito significa che non ci sono code. Un carico prolungato sopra il numero di core significa che i task attendono CPU o disco.

Perché Linux mostra quasi nessuna memoria libera?

Linux usa la RAM inutilizzata come cache del disco e la restituisce quando le applicazioni ne hanno bisogno. Controllate invece la colonna available di free -h: è la memoria realmente disponibile per nuovo lavoro.

Come vedo quale processo usa più CPU o memoria?

In top, premete P per ordinare per CPU e M per ordinare per memoria. Da uno script, usate ps aux --sort=-%cpu | head oppure ps aux --sort=-%mem | head.

Come monitoro un server Linux da remoto?

Installate un agent come node_exporter, l'agent Zabbix o il CloudWatch agent e invia le metriche a un server centrale o a un servizio cloud. Ottenete così storico, dashboard e allarmi senza accedere a ogni macchina.