Visualizzare il monitoraggio PSI su Linux con Grafana: comprendere e monitorare correttamente l'utilizzo delle risorse

Mostro come linux psi raccolgo i dati con Prometheus e li visualizzo in Grafana per misurare il carico sulle risorse (CPU, memoria e I/O) come tempo di attesa effettivo. In questo modo riesco a individuare Colli di bottiglia fin dall'inizio, assegnale a cgroup o container e, se necessario, attiva contromisure automatizzate.

Punti centrali

• Metriche PSI: some/full per CPU, memoria, I/O e medie mobili
• Focus sui cgroup: una visione specifica per container e servizi, anziché solo globale
• Fattori scatenanti degli allarmi: Utilizzo di poll/epoll per gli eventi con soglie
• Grafana: Pannelli dedicati alle tendenze, ai picchi e ai primi N responsabili
• Migliori pratiche: soglie, finestre temporali, correlazione con le metriche di sistema

PSI in breve: intendere la pressione come tempo di attesa effettivo

PSI risponde alla domanda: quanto Tempo reale Le attività attendono invano la CPU, la RAM o l'I/O. I file in /proc/pressure/{cpu,memory,io,irq} offrono due prospettive: alcuni mostra le fasi in cui alcune attività sono in attesa, completo indica i momenti in cui tutte le attività non inattive sono bloccate. Valuto entrambi i valori separatamente perché alcuni si manifesta prima e completo mette in evidenza i veri tempi di inattività. Inoltre, utilizzo avg10, avg60 e avg300, per distinguere le oscillazioni a breve termine dalle tendenze a più lungo termine. Attraverso la crescente in totale- Mi rendo conto di quanto la pressione si sia accumulata sin dalla partenza e dove Hotspot bugia.

PSI a livello di sistema vs. PSI a livello di cgroup: scegliere il livello corretto

Distinguo consapevolmente tra i valori di pressione globali e la visualizzazione per cgroup. I file presenti in /proc/pressione/ mostrano il sistema nel suo complesso, mentre cgroup v2 offre inoltre cpu.pressure, memory.pressure e io.pressure per ogni gruppo. Negli ambienti containerizzati, lo utilizzo per organizzare in modo ordinato i pod, i servizi o contenitori . Questa assegnazione impedisce di brancolare nel buio: invece di dover tirare a indovinare, vedo immediatamente la causa all’interno del gruppo. Sugli host multi-tenant separo così i carichi condivisi da quelli dedicati e gestisco Limiti mirato.

Verificare i prerequisiti: attivare il kernel, PSI e cgroup v2

Prima di raccogliere i dati, mi assicuro che la piattaforma sia quella giusta:

• Versione del kernel: PSI è disponibile a partire dalla versione 4.20 di Linux. Sto verificando con uname -r e controlla tramite zcat /proc/config.gz | grep CONFIG_PSI, se il supporto è integrato nel codice.
• Flag di durata PSI: Alcune distribuzioni consentono l'uso di un flag di avvio opzionale psi=1, per attivare completamente PSI. Lo utilizzo quando necessario e verifico che /proc/pressure/* Fornisce contenuti.
• cgroup v2: Per la visualizzazione per servizio/contenitore utilizzo la gerarchia unificata. Verifico con mount | grep cgroup2 e mi aspetto un cgroup2-Mount (spesso /sys/fs/cgroup). Se manca, lo attivo tramite il parametro del kernel systemd.unified_cgroup_hierarchy=1 (È necessario riavviare il sistema).
• Autorizzazioni: Gli esportatori presenti sull’host devono disporre dei diritti di lettura su /proc/pressure/* e, se del caso, su /sys/fs/cgroup/*/*.pressure. In Containers monto questi percorsi in modalità di sola lettura.

Utilizzare i trigger PSI: reagire automaticamente invece di limitarsi a osservare

Oltre alle serie temporali, presento anche gli eventi tramite sondaggio oppure epoll inserendo soglie e intervalli di tempo nei file PSI. Non appena la pressione sulle risorse supera il valore limite nell'intervallo, viene generato un evento e avvio le contromisure. Queste possono consistere in un pod aggiuntivo, uno svuotamento della cache o la limitazione temporanea di un Processi batch . Nelle unità Systemd associo questa reazione direttamente ai servizi e mantengo basse le latenze. In questo modo il monitoraggio diventa un strumento di controllo, non solo un Visualizzare.

Nella pratica utilizzo un programma Watcher compatto che gestisce i relativi *pressione-apre i file, tramite write() un trigger (alcuni oppure completo (compresi il valore di soglia e la finestra in µs) e successivamente con epoll attende gli eventi in modo bloccante. In questo modo risparmio cicli di polling e reagisco in modo deterministico. Mantengo le finestre volutamente un po’ più lunghe (ad es. 10–30 s) per filtrare i fenomeni transitori e faccio una distinzione a seconda della risorsa: memoria reagisce in modo più sensibile rispetto a io, CPU deve essere più chiaro per poter sparare.

Esportazione da PSI a Prometheus: agenti, metriche, etichette

Per le serie temporali, raccolgo i dati PSI tramite un esportatore dedicato oppure integro i valori in agenti già esistenti come il Esportatore di nodi. È fondamentale utilizzare etichette coerenti per host, cgroup e container, affinché le query in Grafana filtrino correttamente i dati. In Kubernetes utilizzo inoltre le metriche di cAdvisor e Kubelet per *_pressione_*_secondi_di_attesa_totali, in modo che i livelli di nodo, pod e container rimangano allineati. Per gli host classici, leggo /proc/pressure/* diretto e cartella alcuni e completo su nomi di metriche distinti. Una guida all'integrazione degli agenti può essere d'aiuto all'inizio, ad esempio all'indirizzo Configurazione di Node Exporter.

Le varianti di Exporter in dettaglio: Node, cgroup e Kubernetes

A seconda del contesto, utilizzo metodi diversi:

• Esportatore di nodi (Livello host): Attivo il pressione-Collector (se non è attivo per impostazione predefinita), ad esempio tramite --collector.pressure. Fornisce metriche quali node_pressure_cpu_some_avg10, node_pressure_memory_full_avg60 e node_pressure_io_waiting_seconds_total{state="some|full"}. Questi ultimi sono adatti per rate()-Analisi e Top-N.
• Esportatore cgroup personalizzato (Livello servizio/contenitore): Per una visione dettagliata, leggo /sys/fs/cgroup//{cpu,memory,io}.pressure ed emetto metriche quali cgroup_pressure_memory_waiting_seconds_total{state="full",cgroup="..."} e il avg10/60/300‑Gauges. Normalizzo il percorso del cgroup come etichetta (cgroup) oppure nella cartella servizio/contenitore Etichette.
• Kubernetes: A livello di nodo, Prometheus esegue lo scraping node-exporter. Per la visualizzazione dei container utilizzo un DaemonSet-Exporter con hostPID:true e i montaggi in sola lettura da /sys/fs/cgroup e /proc, in modo da poter visualizzare i file cgroup dell’host. Inoltre, utilizzo le metriche di Kubelet/cAdvisor, purché riportino i valori totali PSI; le etichette spazio dei nomi, capsula e contenitore In questo mi mantengo coerente.

Mi aiuta avere le idee chiare Strategia del marchio: istanza (host o nome del nodo), cgroup (percorso), spazio dei nomi/capsula/contenitore (per i K8) e stato (alcuni/completo) e risorsa (CPU/memoria/io/irq). In questo modo posso aggregare i dati su larga scala e allo stesso tempo ingrandire in modo dettagliato.

Prometheus-Jobs, regole di registrazione e query di esempio

Per ottenere analisi precise utilizzo due modelli: i percent-gauge (avg10/60/300) e derivati rate()- Valori sui *_secondi_di_attesa_totali_*-contatori.

• Scrape: 15 secondi sono un buon punto di partenza. Un tempo più breve aumenta il carico, ma comporta avg10 ma raramente un valore aggiunto.
• Regole di registrazione: Calcolo serie temporali derivate per semplificare i dashboard e gli avvisi:
  • record: psi:node_memory_full:avg60 = avg_over_time(node_pressure_memory_full_avg10[60s])
  • record: psi:node_io_full:rate5m = rate(node_pressure_io_waiting_seconds_total{state="full"}[5m])
  • record: psi:cgroup_memory_full:rate5m = somma per (cgroup) (rate(cgroup_pressure_memory_waiting_seconds_total{state="full"}[5m]))

Con PromQL creo le tipiche viste:

• Tendenza degli host: node_pressure_memory_full_avg60 nel tempo, suddiviso per nodi.
• I principali responsabili: topk(5, psi:cgroup_memory_full:rate5m) Mostra i cgroup più rumorosi.
• Impatto sulla latenza: (increase(http_request_duration_seconds_sum[5m]) / increase(http_request_duration_seconds_count[5m])) contro node_pressure_io_full_avg60 per individuare le correlazioni.
• Riconoscere i plateau: clamp_min(psi:node_io_full:rate5m, 0.0) come mappa termica per ogni nodo.

Dashboard di Grafana: individuare le tendenze e individuare i punti critici

In Grafana visualizzo separatamente il carico della CPU, della memoria e dell'I/O, rispettivamente per alcuni e completo come grafici separati. I grafici a barre mi forniscono lo stato attuale, mentre i pannelli delle serie temporali rivelano picchi e plateau. Per l’analisi delle cause utilizzo le viste Top-N per cgroup, container o pod e da lì passo ai pannelli di dettaglio. Rimane importante la combinazione tra avg10, avg60 e avg300, per evitare sovralimentazioni causate da brevi picchi. Chi vuole progettare in anticipo i dashboard troverà idee utili su tutto ciò che riguarda il Grafana e Prometheus Stack.

La segnalazione degli allarmi nella pratica: regole, finestre, escalation

Mi attengo a un modello in due fasi: Avviso per i primi segnali, Critico per un collo di bottiglia permanente. A titolo esemplificativo, inserisco:

• Memoria
  • Avviso: node_pressure_memory_full_avg60 > 0,01 per 10–30 s
  • Critico: node_pressure_memory_full_avg60 > 0,05 per ≥60 s
• I/O
  • Avviso: rate(node_pressure_io_waiting_seconds_total{state="some"}[5m]) > 0,02
  • Critico: node_pressure_io_full_avg60 > 0,02 per ≥120 s
• CPU
  • Avviso: node_pressure_cpu_some_avg60 > 0,05
  • Critico: node_pressure_cpu_full_avg60 > 0,01 (perché completo (qui fa particolarmente male)

In "Annotations" collego i contesti (Top-cgroups, throughput, latenza) e avvio i playbook: Scale-Up, adeguamento dei limiti, azioni sulla cache, limitazione dei batch. In caso di eventi ricorrenti, do la priorità alle decisioni relative alla capacità.

Soglie e allarmi: scegliere correttamente la finestra temporale

Definisco soglie chiare per ogni risorsa e distinguo i guasti gravi dai brevi picchi di carico. Ad esempio, valuto memoria piena valori superiori a 5 % per più di 60 secondi sono considerati critici, mentre valori compresi tra 1 e 2 % per più di dieci secondi generano solo un avviso. Per la CPU imposta limiti più severi completo, poiché in quel contesto i tempi di attesa su tutta la rete rallentano sensibilmente il sistema. Il valore aggiunto deriva dall’abbinamento con le metriche relative alla velocità di trasmissione e alla latenza: quando la pressione aumenta e le richieste diventano più lente, cresce l’urgenza. Impostare gli avvisi sempre in base a intervalli di tempo, non a singoli valori, per evitare falsi allarmi dovuti a Scoppi da evitare.

Kubernetes: configurazione dello scrape, autorizzazioni e correlazione

Nel cluster raccolgo i PSI in modo che i livelli coincidano:

• Node-Exporter come DaemonSet: Lo "scrape" standard per nodo fornisce valori PSI globali.
• cgroup-Exporter come Sidecar/DaemonSet: Legge i file cgroup v2 dell'host, assegna le etichette in base a namespace/pod/container. Utilizzo solo i permessi e i mount RO strettamente necessari.
• Kubelet/cAdvisor: Attivo la visualizzazione delle metriche rilevanti dei container ed eseguo lo scraping dell'endpoint del Kubelet. Conservo le chiavi di join delle etichette (ad es. contenitore vs. nome_contenitore) coerente, affinché i join PromQL funzionino senza intoppi.
• Join con metriche del carico di lavoro: Metto in correlazione i dati Pod-PSI con le latenze delle app (ad es. le metriche HTTP), i superamenti dei limiti della CPU e gli errori di memoria. In questo modo riesco a capire se la causa è da ricercarsi nei limiti, nella schedulazione o nei colli di bottiglia dello storage.

File PSI, indicatori chiave e interpretazione: panoramica sintetica

La tabella seguente riassume i file, gli indicatori chiave e gli scopi principali, in modo da consentirmi di interpretare più rapidamente i dati e creare pannelli Grafana adeguati. La utilizzo durante l’analisi per pianificare la domanda successiva: ottimizzazione, scalabilità o risoluzione dei problemi. Particolarmente rilevanti rimangono le differenze tra alcuni e completo nonché le tre finestre di media. In questo modo classifichio i sintomi in ordine cronologico e verifico se la pressione è localizzata o diffusa. La colonna „Intervento“ aiuta a individuare rapidamente Classificazione.

Risorse	File	Cifre chiave	Significato	Utilizzo
CPU	/proc/pressure/cpu	alcuni, completo; media 10/60/300; totale	Tempo di attesa per ottenere tempo di calcolo disponibile	Host sovraccarichi, CPU troppo limitateLimiti
Memoria	/proc/pressione/memoria	alcuni, completo; media 10/60/300; totale	Tempo di attesa dovuto a Reclaim, Swap, quasi OOM	Colli di bottiglia della RAM, sovraccarico della cache, difettosi Richieste
I/O	/proc/pressure/io	alcuni, completo; media 10/60/300; totale	Tempo di attesa per i dispositivi di archiviazione/il file system	Supporti di memorizzazione lenti, picchi di sincronizzazione, A filo-fasi
IRQ	/proc/pressure/irq	alcuni, completo; media 10/60/300; totale	Stampa tramite elaborazione degli interrupt	Carico di rete, ottimizzazione dei driver, Affinità
cgroup	*/{cpu,memory,io}.pressure	alcuni, completo; media 10/60/300; totale	Pressione per servizio/contenitore	Indagine sulle cause alla radice, mirata Limiti

Caso pratico: proteggere in modo efficiente l'hosting e gli stack WordPress

Sugli host WordPress molto trafficati, PHP-FPM, il database e il livello di cache si contendono regolarmente la RAM e le risorse I/O, cosa che ho notato tramite memoria e io lo vedo subito. Sale completo Per quanto riguarda la memoria, ottimizzo l’OpCache, aumento in modo mirato le dimensioni dei pool o elimino i plugin più onerosi. In caso di carico di I/O, controllo i piani di query, le impostazioni di journaling e la scrittura asincrona. PSI per cgroup evidenzia se il collo di bottiglia è causato dal server web, dai worker o dal database. Chi desidera approfondire l’argomento troverà indicazioni nel Guida a Linux-PSI, che riassume l'introduzione e la valutazione.

Pianificazione della capacità e ottimizzazione: dai numeri alle azioni

Associo il PSI al carico della CPU, ai page fault, alla velocità di trasmissione I/O e alle latenze per individuare le cause reali. In caso di persistenza memoria piena scalare la RAM, ottimizzare i parametri di reclaim o distribuire i carichi di lavoro. Mostra io completo In caso di lunghi periodi di stallo, aumento la profondità delle code, attivo strategie di write-back o utilizzo supporti di memorizzazione più veloci. Per gestire il carico sulla CPU, misuro in parallelo le lunghezze delle code di esecuzione, adeguo le classi di scheduling e distribuisco i thread più intensi. Prendo decisioni solo quando le tendenze nel avg60 e avg300 rimanere coerenti e non limitarsi a un Spike è disponibile.

Risoluzione dei problemi e convalida: dall'host al container

Se mancano i valori PSI, controllo la versione del kernel, CONFIG_PSI e, facoltativamente, il parametro di avvio psi=1. Successivamente verifico i risultati dei file in /proc/pressure/* manualmente e confrontale con le metriche di Exporter. In cgroup v2 controllo inoltre il *.pressione-file all’interno delle directory di gruppo. Sto testando gli avvisi con generatori di carico e osservando la logica di risposta tramite epoll, per individuare tempestivamente eventuali errori di configurazione. Infine, confronto i pannelli di Grafana con i log, le tracce e i risultati del profiler, in modo che la diagnosi e le contromisure siano affidabili in forma.

Ostacoli tipici che metto in conto:

• Interazione swap: Leggera memoria un po'- Questi valori sono normali in caso di recupero aggressivo. La situazione diventa critica quando completo aumenta e, allo stesso tempo, aumentano le latenze.
• Isolamento della CPU e affinità: I nuclei fissati/isolati possono essere localmente CPU al massimo generare, anche se l'host nel complesso ha ancora margine. Controllo irq-PSI aggiuntivo, se la rete/lo storage è sottoposto a un carico elevato di interrupt.
• Ambienti virtuali: Nelle macchine virtuali, i valori PSI riflettono anche l'influenza dell'hypervisor. Misuro separatamente i livelli host e guest per attribuire in modo univoco l'overcommitment.
• Overhead di scraping: Il PSI in sé è conveniente, ma intervalli di scraping troppo brevi aumentano il carico su Prometheus. 15 s è spesso il punto di equilibrio ideale.
• Cardinalità delle etichette: i percorsi dei cgroup possono diventare troppo lunghi. Io li regolo con labeldrop/mantieni e mappare solo i livelli che sto analizzando (ad esempio, il servizio anziché ogni cgroup di task a vita breve).

Riassumendo brevemente

PSI misura i veri tempo di attesa sulla CPU, sulla RAM e sull'I/O, fornendo così un chiaro segnale della pressione sulle risorse. Grazie all'esportazione Prometheus e ai dashboard di Grafana, realizzo una vista che distingue le cause e individua rapidamente i punti critici. La separazione tra alcuni e completo più le finestre avg10/60/300 rende le decisioni più affidabili. Imposta gli avvisi in base a intervalli di tempo, li associo alle latenze e controllo le reazioni automatiche tramite trigger. In questo modo prendo decisioni fondate in materia di capacità, risolvo tempestivamente i colli di bottiglia e garantisco il funzionamento dei servizi nella quotidianità reattivo.