Visualisera Linux PSI-övervakning med Grafana: Att förstå och övervaka resursbelastningen på rätt sätt

Jag visar hur jag linux psi med hjälp av Prometheus och visar det i Grafana för att mäta resursbelastningen på CPU, minne och I/O som faktisk väntetid. På så sätt kan jag upptäcka Flaskhalsar tidigt, tilldela dem cgroups eller containrar och utlös automatiserade motåtgärder vid behov.

Centrala punkter

• PSI-mått: some/full för CPU, minne, I/O och glidande medelvärden
• cgroup-fokus: En container- och tjänstespecifik synvinkel istället för enbart en global
• Varningsutlösare: Använd poll/epoll för händelser vid tröskelvärden
• Grafana: Paneler för trender, toppar och de N största orsakerna
• Bästa praxis: Tröskelvärden, tidsfönster, korrelation med systemmetriker

PSI i korthet: Att betrakta tryck som faktisk väntetid

PSI besvarar frågan om hur mycket Realtid Uppgifter väntar förgäves på CPU, RAM eller I/O. Filerna under /proc/pressure/{cpu,memory,io,irq} ger två perspektiv: vissa visar faser där vissa uppgifter väntar, full markerar tillfällen då alla icke-inaktiva uppgifter blockeras. Jag utvärderar de båda värdena separat, eftersom vissa börjar tidigare och full synliggör verkliga stillestånd. Dessutom använder jag avg10, avg60 och avg300, för att skilja mellan kortsiktiga svängningar och långsiktiga trender. Genom den växande totalt-Nu inser jag hur mycket trycket har byggts upp sedan båten och var Hotspots lögn.

Systemomfattande kontra cgroup-PSI: Att välja rätt nivå

Jag gör medvetet skillnad mellan globala tryckvärden och vyn per cgroup. Filerna under /proc/tryck/ visar systemet som helhet, medan cgroup v2 dessutom cpu.pressure, minnesbelastning och io.pressure per grupp. I container-miljöer använder jag det för att ordna pods, tjänster eller Containrar till. Denna tilldelning förhindrar att man flyger i blindo: Istället för att behöva gissa kan jag direkt se källan till problemet i gruppen. På multitenant-värdar separerar jag på så sätt delade och dedikerade belastningar och styr Gränser riktade.

Kontrollera förutsättningarna: Aktivera kärnan, PSI och cgroup v2

Innan jag börjar samla in mätdata ser jag till att plattformen passar:

• Version av kärnan: PSI är tillgängligt från och med Linux 4.20. Jag testar med uname -r och kontrollera via zcat /proc/config.gz | grep CONFIG_PSI, om stödet är inbyggt.
• PSI-körningsflagga: Vissa distributioner tillåter den valfria startflaggan psi=1, för att aktivera PSI fullt ut. Jag använder det vid behov och kontrollerar att /proc/pressure/* Tillhandahåller innehåll.
• cgrupp v2: För vyen ”per tjänst/container” använder jag enhetlig hierarki. Jag kontrollerar med mount | grep cgroup2 och förväntar mig en cgroup2-Mount (ofta /sys/fs/cgroup). Om den saknas aktiverar jag den via kärnparametern systemd.unified_cgroup_hierarchy=1 (Omstart krävs).
• Behörigheter: Exportprogram på värddatorn måste ha läsbehörighet till /proc/pressure/* och i förekommande fall till /sys/fs/cgroup/*/*.pressure. I containrar monterar jag dessa sökvägar som skrivskyddade.

Använd PSI-triggers: Reagera automatiskt istället för att bara observera

Förutom tidsserier redovisar jag även händelser via omröstning eller . epoll genom att ange tröskelvärden och tidsfönster i PSI-filerna. Så snart belastningen på resursen överskrider gränsvärdet inom tidsfönstret utlöses en händelse och jag vidtar motåtgärder. Det kan vara en extra pod, en cache-rensning eller en tillfällig begränsning av en Batchjobb . I Systemd-enheter kopplar jag denna reaktion direkt till tjänsterna och håller fördröjningarna låga. På så sätt blir övervakningen en styrningsfunktion, inte bara en Visa.

I praktiken använder jag ett kompakt Watcher-program som hanterar de relevanta *tryck*-filer öppnas via write() en utlösare (vissa eller . full (inklusive tröskelvärde och fönster i µs) registreras och därefter med epoll väntar på händelser på ett blockerande sätt. På så sätt sparar jag poll-cykler och reagerar deterministiskt. Jag låter fönstren medvetet vara öppna något längre (t.ex. 10–30 s) för att filtrera bort transienter, och skiljer mellan olika resurser: minne reagerar känsligare än io, cpu måste vara tydligare för att kunna avfyras.

Exportera PSI till Prometheus: agenter, mätvärden, etiketter

För tidsserierna samlar jag in PSI via en särskild exportfunktion eller integrerar värdena i befintliga agenter som Nod-exporterare. Det är viktigt att använda konsekventa etiketter för värd, cgroup och container, så att sökningar i Grafana filtreras korrekt. I Kubernetes använder jag dessutom cAdvisor- och Kubelet-metriker för *_tryck_*_väntetid_sekunder_totalt, så att nod-, pod- och containernivåerna förblir identiska. För traditionella värdar läser jag /proc/pressure/* direkt och mapp vissa och full på separata metriknamn. En guide till agentintegration underlättar i början, till exempel på Konfigurera Node Exporter.

Exportalternativ i detalj: Node, cgroup och Kubernetes

Jag använder olika metoder beroende på omgivningen:

• Nod-exporterare (Värdnivå): Jag aktiverar tryck-Collector (om den inte är aktiverad som standard), t.ex. via --collector.pressure. Den tillhandahåller mätvärden som node_pressure_cpu_some_avg10, node_pressure_memory_full_avg60 och node_pressure_io_waiting_seconds_total{state="some|full"}. De sistnämnda lämpar sig för rate()-Analyser och Top-N.
• Egen cgroup-exportfunktion (Tjänst-/containernivå): För en detaljerad översikt läser jag /sys/fs/cgroup//{cpu,memory,io}.pressure och genererar nyckeltal som cgroup_pressure_memory_waiting_seconds_total{state="full",cgroup="..."} och avg10/60/300‑Gauges. Jag normaliserar cgroup-sökvägen som en etikett (cgroup) eller öppna mappen service/behållare Etiketter.
• Kubernetes: På nodnivå samlar Prometheus in data node-exporter. För Container-Sicht använder jag en DaemonSet-Exporter med hostPID:true och skrivskyddade monteringar av /sys/fs/cgroup och /proc, så att jag kan se värdens cgroup-filer. Dessutom använder jag Kubelet/cAdvisor-metriker, förutsatt att de visar PSI-totals; etiketterna namnrymd, pod och behållare Jag är konsekvent i det avseendet.

Det hjälper mig att ha en tydlig Varumärkesstrategi: instans (värd eller nodnamn), cgroup (sökväg), namnrymd/pod/behållare (för K8s) samt state (vissa/full) och resurs (cpu/minne/io/irq). På så sätt kan jag både aggregera på hög nivå och samtidigt zooma in på detaljerna.

Prometheus-jobb, inspelningsregler och exempel på frågor

För tydliga utvärderingar använder jag två mönster: procentmätare (avg10/60/300) och härledda rate()‑värden på *_totalt_antal_väntetidssekunder_*‑mätare.

• Skrapa: 15 sekunder är en bra början. Kortare tid ökar belastningen, ger vid avg10 men sällan något mervärde.
• Regler för inspelning: Jag beräknar härledda tidsserier för att förenkla instrumentpaneler och varningar:
  • 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 = summa per (cgroup) (rate(cgroup_pressure_memory_waiting_seconds_total{state="full"}[5m]))

Med PromQL skapar jag typiska vyer:

• Host‑Trend: node_pressure_memory_full_avg60 över tid, uppdelat per nod.
• De största utsläppskällorna: topk(5, psi:cgroup_memory_full:rate5m) visar de cgroups som ger upphov till mest ljud.
• Inverkan på latensen: (increase(http_request_duration_seconds_sum[5m]) / increase(http_request_duration_seconds_count[5m])) mot node_pressure_io_full_avg60 för att identifiera korrelationer.
• Att känna igen plattformar: clamp_min(psi:node_io_full:rate5m, 0,0) som en värmekarta per nod.

Grafana-dashboards: Synliggöra trender och hitta problemområden

I Grafana visar jag belastningen på CPU, minne och I/O separat, för respektive vissa och full som separata kurvor. Bar-mätare visar mig det aktuella läget, medan tidsseriepaneler avslöjar toppar och platåer. För orsaksanalys använder jag Top-N-vyer sorterade efter cgroup, container eller pod och hoppar därifrån till detaljpaneler. Det är fortfarande viktigt att kombinera avg10, avg60 och avg300, för att undvika överbelastning orsakad av korta spikar. Den som vill planera sina dashboards i förväg hittar användbara idéer kring Grafana och Prometheus Stack.

Larmhantering i praktiken: regler, nivåer, eskalering

Jag följer en tvåstegsmodell: Varning för tidiga signaler, Kritisk för en bestående flaskhals. Som exempel anger jag:

• Minne
  • Varning: node_pressure_memory_full_avg60 > 0,01 i 10–30 sekunder
  • Kritiskt: node_pressure_memory_full_avg60 > 0,05 i minst 60 sekunder
• I/O
  • Varning: rate(node_pressure_io_waiting_seconds_total{state="some"}[5m]) > 0,02
  • Kritiskt: node_pressure_io_full_avg60 > 0,02 i ≥120 s
• CPU
  • Varning: node_pressure_cpu_some_avg60 > 0,05
  • Kritiskt: node_pressure_cpu_full_avg60 > 0,01 (eftersom full (det gör särskilt ont här)

I Annotations kopplar jag samman sammanhang (top-cgroups, genomströmning, latens) och startar playbooks: Scale-Up, justera gränsvärden, cache-åtgärder, batch-begränsning. Vid återkommande händelser prioriterar jag kapacitetsbeslut.

Tröskelvärden och larm: Välj rätt tidsfönster

Jag fastställer tydliga tröskelvärden för varje resurs och skiljer mellan allvarliga avbrott och kortvariga belastningstoppar. Till exempel bedömer jag minnet är fullt Värden över 5 % som varar längre än 60 sekunder betraktas som kritiska, medan värden på 1–2 % som varar i över tio sekunder endast utlöser en varning. För CPU:n sätter jag strängare gränser full, eftersom omfattande väntetider där märkbart bromsar upp verksamheten. Det ger mervärde att koppla detta till mått på genomströmning och latens: När trycket ökar och förfrågningarna blir långsammare ökar brådskan. Jag ställer alltid in varningar utifrån tidsfönster, inte utifrån enskilda värden, för att undvika falska larm på grund av Bursts som ska undvikas.

Kubernetes: Konfiguration av skrapning, behörigheter och korrelation

I klustret samlar jag PSI på så sätt att nivåerna överensstämmer:

• Node-Exporter som DaemonSet: Standard-Scrape per nod ger globala PSI-värden.
• cgroup-Exporter som sidecar/DaemonSet: Läser värdens cgroup v2-filer och märker dem enligt namnrymd/pod/container. Jag använder endast de behörigheter och RO-mounts som är absolut nödvändiga.
• Kubelet/cAdvisor: Jag aktiverar visningen av relevanta container-metriker och skrapar Kubelet-ändpunkten. Jag behåller label-join-nycklarna (t.ex. behållare mot. container_name) konsekvent, så att PromQL-sammanfogningar fungerar smidigt.
• Join med arbetsbelastningsmått: Jag korrelerar Pod-PSI med app-fördröjningar (t.ex. HTTP-mått), CPU-begränsningar och minnesfel. På så sätt kan jag avgöra om orsaken ligger i begränsningar, schemaläggning eller flaskhalsar i lagringssystemet.

PSI-filer, nyckeltal och tolkning: En kortfattad översikt

Följande tabell sammanfattar de viktigaste filerna, nyckeltalen och användningsområdena, så att jag snabbare kan tolka dem och skapa lämpliga Grafana-paneler. Jag använder den vid analysen för att planera nästa steg: finjustering, skalning eller felsökning. Särskilt relevanta är skillnaderna mellan vissa och full samt de tre genomsnittsfönstren. På så sätt ordnar jag symptomen kronologiskt och kontrollerar om trycket är lokalt eller utbrett. Kolumnen „Insats“ hjälper till att snabbt Klassificering.

Resurs	Fil	Nyckeltal	Betydelse	Användning
CPU	/proc/pressure/cpu	några, full; genomsnitt 10/60/300; totalt	Väntetid på ledig beräkningstid	Överbelastade värddatorer, för begränsad CPU-Gränser
Minne	/proc/tryck/minne	några, full; genomsnitt 10/60/300; totalt	Väntetid på grund av Reclaim, Swap, nära OOM	RAM-brist, cache-belastning, felaktiga Förfrågningar
I/O	/proc/pressure/io	några, full; genomsnitt 10/60/300; totalt	Väntetid för lagringsenheter/filsystem	Långsamma lagringsenheter, synkroniseringsöverbelastning, Spola-faser
IRQ	/proc/pressure/irq	några, full; genomsnitt 10/60/300; totalt	Utskrift genom avbrottshantering	Nätverksbelastning, drivrutinsoptimering, Affinitet
cgroup	*/{cpu,minne,io}.tryck	några, full; genomsnitt 10/60/300; totalt	Tryck per service/behållare	Sökning efter grundorsaken, målinriktad Gränser

I praktiken: Effektiv säkerhet för webbhotell och WordPress-stackar

På hårt belastade WordPress-värdar konkurrerar PHP-FPM, databasen och cache-lagret regelbundet om RAM-minne och I/O, vilket jag kan se via minne och io ser omedelbart. Stiger full När det gäller minne optimerar jag OpCache, ökar poolstorlekarna gradvis eller minskar antalet resurskrävande plugins. Vid I/O-belastning kontrollerar jag frågeplaner, journalföringsinställningar och asynkron skrivning. PSI per cgroup visar om det är webbservern, arbetare eller databasen som orsakar flaskhalsen. Den som vill fördjupa sig ytterligare hittar tips i Linux-PSI-guide, som sammanfattar introduktionen och utvärderingen.

Kapacitetsplanering och optimering: Från siffror till åtgärder

Jag kopplar samman PSI med CPU-utnyttjande, sidfel, I/O-genomströmning och latenser för att identifiera de verkliga orsakerna. Om problemet kvarstår minnet är fullt Jag skalar RAM-minnet, optimerar Reclaim-parametrarna eller fördelar arbetsbelastningarna. Visar io full Vid långa platåer ökar jag köernas djup, aktiverar write-back-strategier eller använder snabbare lagringsenheter. Vid CPU-belastning mäter jag parallellt längden på körköerna, justerar schemaläggningsklasserna och fördelar de mest aktiva trådarna. Jag fattar beslut endast när trender i avg60 och avg300 förbli konsekvent och inte bara vara en Spike är tillgänglig.

Felsökning och validering: Från värd till container

Om PSI-värdena saknas kontrollerar jag kärnversionen, CONFIG_PSI och eventuellt startparametern psi=1. Därefter kontrollerar jag utdata från filerna under /proc/pressure/* manuellt och jämför dem med Exporter-mätvärdena. I cgroup v2 kontrollerar jag dessutom *.tryck-filer i gruppkatalogerna. Jag testar varningar med belastningsgeneratorer och övervakar reaktionslogiken via epoll, för att upptäcka felkonfigurationer i ett tidigt skede. Till sist jämför jag Grafana-paneler med loggar, spårningar och profileringsresultat, så att diagnos och åtgärder kan genomföras på ett säkert sätt passform.

Typiska hinder som jag räknar med:

• Swap-interaktion: Lätt minne, lite-Värdena är normala vid aggressiv återvinning. Det blir kritiskt när full ökar samtidigt som fördröjningarna blir längre.
• CPU-isolering och affinitet: Fästa/isolerade kärnor kan lokalt CPU full generera, trots att värden fortfarande har kapacitet kvar. Jag kontrollerar irq-PSI dessutom om nätverket/lagringssystemet har en hög belastning av avbrott.
• Virtuella miljöer: I virtuella maskiner återspeglar PSI-värdena även hypervisorens inverkan. Jag mäter värd- och gästnivån separat för att entydigt kunna identifiera överbelastning.
• Scrape-överhead: PSI i sig är resurssnålt, men för korta skrapningsintervall ökar belastningen på Prometheus. 15 sekunder är ofta den optimala inställningen.
• Etikettkardinalitet: cgroup-sökvägar kan bli väldigt långa. Jag hanterar detta med labeldrop/behålla och kartlägger endast de nivåer som jag analyserar (t.ex. tjänsten istället för varje kortlivad task-cgroup).

Kortfattat sammanfattat

PSI mäter verkliga väntetid på CPU, RAM och I/O och ger därmed en tydlig indikation på resursbelastning. Med Prometheus-export och Grafana-dashboards skapar jag en översikt som skiljer mellan orsakerna och snabbt identifierar flaskhalsar. Uppdelningen av vissa och full plus fönstren avg10/60/300 gör beslutsfattandet mer tillförlitligt. Jag riktar in mig på tidsperioder, kopplar dem till fördröjningar och styr automatiska reaktioner via utlösare. På så sätt fattar jag välgrundade beslut om kapacitet, avhjälper flaskhalsar i god tid och håller tjänsterna igång i det dagliga arbetet lyhörd.