Vai al contenuto 
sar sysstat Mi fornisce metriche storiche dei server Linux, grazie alle quali posso monitorare con precisione nel tempo i modelli di carico, i colli di bottiglia e i comportamenti anomali. In questo modo analizzo retrospettivamente CPU, RAM, I/O e rete, individuando i picchi ricorrenti che uno strumento che opera solo in tempo reale potrebbe facilmente trascurare.
Punti centrali
Riassumo qui di seguito i punti salienti in modo conciso e chiaro.
- La storia Anziché un'istantanea: la registrazione regolare mette in evidenza i modelli di carico.
- Combinazione Raccolta e analisi: sysstat raccoglie i dati, sar li elabora.
- Larghezza Metriche: CPU, RAM, swap, I/O su disco, rete e altro ancora.
- Diagnosi per individuare le cause: regolare in modo mirato le fasce orarie e confrontarle.
- Pianificazione Con Trends: dimensionare le capacità in modo realistico.
A cosa servono sar e sysstat nell'uso quotidiano?
Uso sar come System Activity Reporter, che rende leggibili i dati memorizzati da sysstat. sysstat raccoglie regolarmente i valori relativi a CPU, memoria, I/O e rete, mentre io utilizzo sar per estrarre report mirati relativi a intervalli di tempo specifici. In questo modo riesco a individuare senza difficoltà i picchi di carico ricorrenti causati da backup, cronjob o picchi di traffico. A differenza di Strumenti in tempo reale A differenza di top o htop, non valuto lo stato momentaneo, ma prendo in considerazione l’andamento nel tempo. Questa prospettiva evita diagnosi errate, poiché distingue causa ed effetto e mi fornisce indicazioni affidabili.
Installazione e attivazione sulle distribuzioni più diffuse
Installo sysstat tramite il gestore dei pacchetti, attiva il monitoraggio e controlla i timer di systemd. Su Debian/Ubuntu di solito è sufficiente apt install sysstat e uno sguardo a /etc/default/sysstatseguito da systemctl enable --now sysstat. Su RHEL/CentOS/Oracle Linux utilizzo dnf install sysstat e gestisci i timer tramite systemctl. Successivamente, i file giornalieri vengono solitamente salvati in /var/log/sa/ con nomi come sa10 per il 10 del mese. Verifico la registrazione con sar senza parametri o con sar -u 1 3 per un breve controllo ad hoc.
Spiegazione delle principali chiamate SAR
Per la CPU utilizzo sar -u e, se necessario, per ogni core sar -u -P ALLal fine di Suggerimenti impossibile non notarlo. Considero la memoria e il caching con sar -r e lo swapping con sar -S. L'attività del disco la leggo con sar -d, la rete con sar -n DEV,ETCP,TCP,UDP. I file storici li apro con sar -f /var/log/sa/sa10 e definire una finestra temporale con -s HH:MM -e HH:MM uno. Per analisi dettagliate sui tempi di attesa, integro sar con Analizzare le attese I/O, perché in questo modo riesco a valutare meglio le code e la produttività e Colli di bottiglia identifico con precisione.
Come interpretare correttamente i valori misurati: CPU, memoria, I/O, rete
Prendo in esame alcuni indicatori chiave che mi forniscono rapidamente un quadro affidabile e che confronto nel corso del tempo. CPU-Inattivo Valori vicini a 0 e un %iowait elevato indicano la presenza di code sul disco. Un valore elevato di %steal rivela una carenza di CPU nella virtualizzazione. Per quanto riguarda la RAM, prendo in considerazione le pagine di memoria libere, il comportamento della cache di pagina e gli swap-in/out. Per la rete, gli errori di pacchetto, i drop e le ritrasmissioni aiutano a individuare i limiti di capacità o i malfunzionamenti.
| Metriche | interruttore sar | Valori anomali | misura immediata |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle molto basso, %iowait alto | Verificare l'I/O, distribuire i thread, verificare il fabbisogno di CPU |
| Memoria | sar -r | poca memoria libera, forte riduzione della cache di pagina | Ottimizzare i servizi, aumentare la RAM, valutare la cache |
| Scambio | sar -S | Swap-in/out frequenti | Alleggerire la memoria di lavoro, regolare i limiti |
| Disco I/O | sar -d | Valori elevati di await/svctm, la coda cresce | Verificare il profilo I/O, regolare il tiering dello storage o le finestre di elaborazione batch |
| Rete | sar -n DEV,ETCP | Drops, errori, ritrasmissioni | Testare MTU/offloading, analizzare la larghezza di banda e la latenza |
Analizzare dati storici e intervalli di tempo
Lavoro quasi sempre con Finestre temporali, ad esempio sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 per i lavori notturni. In questo modo confronto gli stessi orari in giorni diversi e individuo delle tendenze anziché casi isolati. Per l’analisi automatica, salvo i dati con sadf -d in formato CSV e li carico in una dashboard dedicata. In caso di picchi insoliti, esamino gli intervalli adiacenti per escludere effetti collaterali. Trovo che questo metodo sia snello perché mi fornisce indicazioni rapidamente utilizzabili senza un lungo lavoro preparatorio.
Analisi delle tendenze e pianificazione delle capacità
Utilizzo i valori archiviati per Previsioni e dimensiono le risorse in base a dati reali anziché all’istinto. Se il carico della CPU aumenta di settimana in settimana, prevedo core o riserve di frequenza. Se il fabbisogno di memoria aumenta a causa delle cache, valuto i pro e i contro di un’espansione della RAM. Se il percorso I/O mostra tempi di attesa più lunghi, opto per uno storage più veloce o per finestre di elaborazione batch disaccoppiate. Per la visualizzazione, integro i dati in alternativa a Grafana e Prometheus e combina le tendenze SAR con le metriche provenienti dagli esportatori.
Caso pratico: server web con picchi di carico
Descrivo un caso in cui i siti WordPress rispondono con ritardo ogni sera e Utenti Segnalare gli aborti. Con sar -u -s 18:00:00 -e 20:00:00 e sar -d Noto picchi di I/O simultanei durante i backup. Allo stesso tempo, si osserva sar -n DEV un aumento della larghezza di banda della rete, che completa il quadro del carico. Il test di verifica effettuato il giorno successivo senza backup conferma questo andamento. Sposto il processo, ottimizzo le query del database e ripulisco le cache, facendo così scomparire i picchi serali e riportando i tempi di risposta a livelli costanti.
Consigli per la gestione, la rotazione e la conservazione dei dati
Controllo il Immagazzinamento in /etc/sysconfig/sysstat oppure /etc/default/sysstat e imposto la conservazione in base alle esigenze. Per gli host critici conservo i dati per 30–90 giorni, in modo da individuare eventuali effetti stagionali. La dimensione dei file rimane gestibile fintanto che gli intervalli sono ragionevoli e non è attiva una sincronizzazione al secondo eccessiva. Sposto gli archivi più vecchi in una directory centrale o li trasferisco in un semplice archivio a lungo termine. In questo modo mantengo i dati disponibili senza sovraccaricare il sistema né rallentare l’analisi.
Integrazione con stack di monitoraggio e log
Metto "sar" come Dati grezzi-fornitore e lo combino con il monitoraggio centralizzato, l'analisi dei log e gli avvisi. Uno stack APM o di log mi fornisce gli eventi, mentre sar ordina cronologicamente i valori dell'infrastruttura. Per gli host particolarmente "rumorosi" utilizzo inoltre pidstat e iostat, per mappare i processi e i percorsi I/O. Inoltre, mi aiuta Contabilità dei processi, individuare con precisione i processi che consumano molte risorse. Questa combinazione tra la vista degli eventi e quella delle metriche mi evita di procedere alla cieca e riduce notevolmente i tempi di ricerca degli errori.
Regolazione fine della configurazione: intervalli, sa1/sa2 e timer
Ho messo il Intervalli di rilevamento in modo tale che si adattino alla dinamica del sistema. Un intervallo di un minuto è lo standard, mentre nel caso di host altamente volatili possono essere opportuni anche intervalli di 10–30 secondi. La raccolta viene effettuata sa1 (campioni frequenti), il riepilogo giornaliero sa2 (Resoconti della giornata). Su systemd controllo i timer o i servizi corrispondenti e ne regolo la frequenza. Su Debian/Ubuntu spesso attivo esplicitamente la raccolta con ENABLED="true" in /etc/default/sysstat. Documento gli intervalli per ciascun ambiente, in modo che i confronti successivi siano corretti e nessuno tragga conclusioni errate confrontando campioni di 5 secondi con dati relativi a 1 minuto.
Panoramica delle opzioni avanzate di sar
Oltre ai pulsanti classici, mi sono utili anche altri pulsanti per un Visione completa: sar -b mostra la velocità di trasmissione I/O a blocchi aggregata, sar -B il comportamento di paging del kernel e sar -W L'attività di swap in dettaglio. Con sar -q Vedo la Runqueue (i processi in attesa della CPU) e l'andamento del carico. sar -H fornisce dati Hugepage, se pertinenti. Per i dischi, se necessario, utilizzo sar -d -p, per esaminare le partizioni separatamente. Sono cauto riguardo a svctm: Questo valore, nei kernel moderni, è talvolta inaffidabile o pari a 0; preferisco considerare attendere (latenza end-to-end) e avgqu-sz/aqu-sz (dimensione della coda). E quando ho bisogno di farmi rapidamente un'idea generale, mi fornisce sar -A una panoramica generale, che poi approfondirò.
Valutare correttamente le macchine virtuali e i container
All'indirizzo Virtualizzazioni Presto particolare attenzione a %steal: valori elevati di Steal indicano che l’hypervisor sottrae tempo di CPU alla VM. Ciò può facilmente portare a valutazioni errate se mi limito ad analizzare solo %idle. Pertanto, metto in correlazione il carico della CPU, lo «steal» e la «runqueue» (sar -q) insieme. Negli ambienti con container, separo la vista dell'host da quella del carico di lavoro: sar monitora l'host, non i singoli container. Se ho bisogno di dettagli per ogni servizio, integro con pidstat (per processo) e tengo conto dei limiti dei cgroup. Verifico inoltre il ridimensionamento della frequenza della CPU e gli stati di alimentazione (cambiamenti di clock), poiché possono causare latenze di breve durata che, fuori contesto, sembrano indicare una carenza di CPU.
Riferimento temporale: fusi orari, ora legale e correlazione affidabile
Presto attenzione a base temporale costante, affinché i confronti siano corretti. Per impostazione predefinita, sar salva i dati nell'ora locale; nei cluster è consigliabile utilizzare un fuso orario uniforme (spesso UTC). In occasione del passaggio all'ora legale, controllo se ci sono intervalli di tempo duplicati o mancanti e, se necessario, utilizzo l'output di sadf con timestamp in formato ISO. Per le correlazioni con i log o gli eventi APM, allineo i fusi orari in modo da associare con precisione i picchi nelle metriche agli eventi (deployment, backup, cronjob). Riferimenti temporali chiari riducono notevolmente i malintesi nelle analisi post-incidente.
Automatizzazione ed esportazione con sadf
Per i report e i dashboard, esporto i dati con sadf. Nella vita di tutti i giorni uso sadf -d (CSV) per analisi semplici, in alternativa sadf -j (JSON) per pipeline flessibili. Un'esportazione tipica si presenta così: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_abend.csv. In questo modo genero un file contenente i dati relativi a CPU, RAM, I/O a blocchi e indicatori di rete per una finestra serale. Negli script utilizzo questi dati per confrontare automaticamente i giorni della settimana, calcolare la mediana e il 95° percentile ed evidenziare i valori anomali. Mantengo volutamente ridotto il numero di metriche per preservare la leggibilità ed evitare falsi allarmi.
Caso pratico: server di database con pressione sulla cache delle pagine
Un host MySQL segnala latenze sporadiche nelle query. sar -r mostra una diminuzione della cache delle pagine durante la sera, sar -S swap-out occasionali. Parallelmente, presso sar -d il attendere-tempo, e sar -b indica un aumento dei flussi di scrittura. La correlazione con le rotazioni dei log e un processo ETL spiega questo andamento: grandi ondate di scrittura sequenziale svuotano la cache e spingono le operazioni di lettura del database verso l’I/O. Distribuisco i processi, aumento moderatamente la RAM e imposto in modo mirato un valore più elevato per il buffer del database. In seguito, i valori di «await» e «swap» rimangono stabili, le latenze diminuiscono e la cache di pagina mantiene in modo affidabile gli «hotset» in memoria.
Aspetti operativi: overhead, elenchi delle apparecchiature e filtri
Tengo il Spese generali piccolo, scegliendo campioni proporzionati. Sysstat legge principalmente da /proc e scrive in formato binario; con intervalli di un minuto, il carico è quasi impercettibile. Su host con un numero molto elevato di dispositivi o dispositivi a blocchi di breve durata (ad esempio negli snapshot), filtro l’output in modo mirato e valuto solo i percorsi rilevanti. Per dm-crypt, MD-RAID o dispositivi multipath, verifico sia il dispositivo logico che, ove possibile, quello sottostante, per attribuire correttamente i colli di bottiglia. Documento i nomi dei dispositivi, in modo che i confronti successivi non falliscano a causa di percorsi rinominati.
Metodologia: valori di riferimento e giorni di confronto
Per ogni host definisco una Linea di base per fascia oraria (ad es. 01–05 ore: batch, 09–18 ore: ufficio, 18–22 ore: picco). Per ogni fascia oraria prendo nota dei valori mediani tipici e dei percentili accettabili (ad es. CPU-%idle, attendere, avgqu-sz, ritrasmissioni). In caso di scostamenti, cerco innanzitutto nuovi lavori, implementazioni o modelli di traffico; solo in seguito prendo in considerazione l’espansione delle capacità. Questa sequenza metodica evita decisioni affrettate: spesso una piccola modifica al piano o un adeguamento dei limiti risolve il problema più efficacemente di un costoso potenziamento hardware. A tal fine, sar mi fornisce una solida base di dati affidabili raccolti nel corso di settimane e mesi.
Limiti e integrazioni utili
Non considero sar un sostituto di Allarme, poiché di default non monitora alcuna soglia né invia notifiche. Gli avvisi in tempo reale devono essere gestiti da sistemi dedicati che definiscono regole, procedure di escalation e flussi di lavoro dei team. Per quanto riguarda le metriche approfondite relative ad applicazioni, database o JVM, mi avvalgo di strumenti di esportazione e tracciamento. sar dà il meglio di sé quando voglio confrontare storicamente le risorse di sistema e individuare i colli di bottiglia nel funzionamento. In sintesi, lo utilizzo in modo mirato laddove sono richieste risposte rapide e ripetibili a domande relative all’infrastruttura.
Riassumendo brevemente
Uso sar e sysstat, per trasformare i valori misurati in una cronologia chiara del carico del server. La combinazione tra raccolta regolare dei dati e analisi mirata del passato permette di individuare le cause, anziché limitarsi a ipotizzare i sintomi. Con pochi comandi riesco a individuare problemi relativi a CPU, memoria, I/O e rete, documentandone l’andamento temporale. Da ciò traggo decisioni realistiche in materia di capacità e individuo routine inefficienti, come i backup effettuati in momenti inopportuni. Chi è responsabile di server Linux ottiene con questo metodo un orientamento affidabile e risparmia tempo nell’analisi, nella pianificazione e nella gestione.
