Visualisering af Linux PSI-overvågning med Grafana: Sådan forstår og overvåger du ressourcebelastningen korrekt

Jeg viser, hvordan jeg linux psi registrere med Prometheus og vise i Grafana for at måle ressourcebelastningen på CPU, hukommelse og I/O som faktisk ventetid. På den måde kan jeg se Flaskehalse tidligt, tildel dem cgroups eller containere, og iværksæt om nødvendigt automatiske modforanstaltninger.

Centrale punkter

• PSI-målinger: some/full for CPU, hukommelse, I/O og glidende gennemsnit
• Fokus på cgroups: Et container- og tjenestespecifikt perspektiv i stedet for blot et globalt perspektiv
• Alarmudløser: Brug af poll/epoll ved begivenheder ved tærskelværdier
• Grafana: Paneler for tendenser, toppe og de N største årsager
• Bedste praksis: Tærskler, tidsvinduer, korrelation med systemmetrikker

PSI kort forklaret: At opfatte tryk som den reelle ventetid

PSI besvarer spørgsmålet om, hvor meget Realtid Opgaver venter forgæves på CPU, RAM eller I/O. Filerne under /proc/pressure/{cpu,memory,io,irq} giver to perspektiver: nogle viser faser, hvor nogle opgaver venter, fuld markerer øjeblikke, hvor alle ikke-inaktive opgaver blokerer. Jeg vurderer de to værdier hver for sig, fordi nogle begynder tidligere og fuld gør reelle stillestande synlige. Derudover bruger jeg avg10, avg60 og avg300, for at skelne mellem kortsigtede udsving og langsigtede tendenser. Om den voksende i alt-Nu indser jeg, hvor meget presset har hobet sig op siden båden, og hvor Hotspots løgn.

Systemomfattende vs. cgroup-PSI: Valg af det rigtige niveau

Jeg skelner bevidst mellem globale trykværdier og udsigten pr. cgroup. Filerne under /proc/pressure/ viser systemet som helhed, mens cgroup v2 derudover cpu.pressure, hukommelsespres og io.pressure pr. gruppe. I container-miljøer bruger jeg det til at organisere pods, tjenester eller Containere . Denne inddeling forhindrer »blindflyvning«: I stedet for at skulle gætte mig frem, kan jeg se årsagen direkte i gruppen. På multi-tenant-hosts adskiller jeg på denne måde delte og dedikerede belastninger og styrer Grænser målrettet.

Kontroller forudsætningerne: Aktivér kernel, PSI og cgroup v2

Inden jeg begynder at indsamle måltal, sikrer jeg mig, at platformen passer:

• Kernel-version: PSI er tilgængeligt fra Linux 4.20. Jeg tjekker med uname -r og kontroller via zcat /proc/config.gz | grep CONFIG_PSI, om supporten er kompileret ind.
• PSI-kørselstidsflag: Nogle distributioner tillader det valgfri boot-flag psi=1, for at aktivere PSI fuldt ud. Jeg bruger det efter behov og kontrollerer, at /proc/pressure/* Leverer indhold.
• cgroup v2: Til visning pr. tjeneste/container bruger jeg ensartet hierarki. Jeg tjekker med mount | grep cgroup2 og forventer en cgroup2-Mount (ofte /sys/fs/cgroup). Hvis den mangler, aktiverer jeg den via kernelparameteren systemd.unified_cgroup_hierarchy=1 (Genstart kræves).
• Tilladelser: Eksportprogrammer på værtscomputeren skal have læserettigheder til /proc/pressure/* og eventuelt på /sys/fs/cgroup/*/*.pressure. I containere monterer jeg disse stier som skrivebeskyttede.

Brug af PSI-triggere: Reager automatisk i stedet for blot at observere

Ud over tidsserier præsenterer jeg også begivenheder via afstemning eller epoll ved at indtaste tærskelværdier og tidsvinduer i PSI-filerne. Så snart ressourcebelastningen overskrider grænseværdien i tidsvinduet, udløses en hændelse, og jeg iværksætter modforanstaltninger. Det kan være en ekstra pod, en cache-flush eller en midlertidig begrænsning af en Batch-opgaver . I Systemd-enheder knytter jeg denne reaktion direkte til tjenesterne og holder forsinkelserne på et minimum. På den måde bliver overvågning til styring, ikke blot til Vis.

I praksis bruger jeg et kompakt Watcher-program, der overvåger de relevante *tryk*-filer åbnes via write() en trigger (nogle eller fuld (inklusive tærskelværdi og vindue i µs) registreres og derefter med epoll venter på begivenheder i en blokerende tilstand. På den måde sparer jeg poll-cyklusser og reagerer deterministisk. Jeg holder vinduerne bevidst lidt længere åbne (f.eks. 10–30 s) for at udfiltrere transienter og skelner mellem de forskellige ressourcer: hukommelse reagerer mere følsomt end io, CPU skal være tydeligere for at kunne affyre.

Eksport af PSI til Prometheus: agenter, målinger, labels

Til tidsserierne indsamler jeg PSI via en dedikeret eksportfunktion eller integrerer værdierne i eksisterende agenter som f.eks. Node-Exporter. Det er afgørende at anvende ensartede navne på host, cgroup og container, så forespørgsler i Grafana filtrerer korrekt. I Kubernetes bruger jeg desuden cAdvisor- og Kubelet-metrikker til *_tryk_*_ventetid_i_sekunder_i_alt, så node-, pod- og containerniveauerne forbliver sammenfaldende. For klassiske værter læser jeg /proc/pressure/* direkte og mappe nogle og fuld på separate metriknavne. En vejledning til agentintegration hjælper med at komme i gang, f.eks. under Opsætning af Node Exporter.

Eksportvarianter i detaljer: Node, cgroup og Kubernetes

Jeg bruger forskellige metoder afhængigt af omgivelserne:

• Node-Exporter (Host-niveau): Jeg aktiverer tryk-Collector (hvis den ikke er aktiveret som standard), f.eks. via --collector.pressure. Den leverer nøgletal som node_pressure_cpu_some_avg10, node_pressure_memory_full_avg60 og node_pressure_io_waiting_seconds_total{state="some|full"}. Sidstnævnte egner sig til rate()-analyser og Top-N.
• Egen cgroup-eksportør (Service-/containerniveau): For at få et detaljeret overblik læser jeg /sys/fs/cgroup//{cpu,memory,io}.pressure og genererer måleværdier som cgroup_pressure_memory_waiting_seconds_total{state="full",cgroup="..."} og den avg10/60/300‑Gauges. Jeg normaliserer cgroup-stien som en label (cgroup) eller åbn mappen service/container Etiketter.
• Kubernetes: På knudepunktsniveau henter Prometheus data node‑exporter. Til container-visning bruger jeg en DaemonSet-exporter med hostPID:true og skrivebeskyttede monteringer fra /sys/fs/cgroup og /proc, så jeg kan se værtsens cgroup-filer. Derudover bruger jeg Kubelet/cAdvisor-metrikker, forudsat at de angiver PSI-totalerne; mærkerne navneområde, pod og container Jeg er konsekvent i den henseende.

Det hjælper mig at have en klar Mærkestrategi: instans (vært eller nodenavn), cgroup (sti), navneområde/pod/container (ved K8s) samt tilstand (nogle/fuld) og ressource (CPU/hukommelse/io/irq). På den måde kan jeg både aggregere i stor skala og zoome dybt ind på samme tid.

Prometheus-opgaver, registreringsregler og eksempler på forespørgsler

For at få præcise resultater bruger jeg to skabeloner: procentmålere (avg10/60/300) og afledte rate()‑værdier på *_waiting_seconds_total*‑tællere.

• Skrab: 15 sekunder er en god start. Kortere tid øger belastningen, men giver avg10 men sjældent merværdi.
• Regler for optagelse: Jeg beregner afledte tidsserier for at forenkle dashboards og alarmer:
  • 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 = sum efter (cgroup) (rate(cgroup_pressure_memory_waiting_seconds_total{state="full"}[5m]))

Med PromQL opretter jeg typiske visninger:

• Host-trend: node_pressure_memory_full_avg60 over tid, opdelt efter knudepunkter.
• De største N-forurenere: topk(5, psi:cgroup_memory_full:rate5m) viser de cgroups, der er mest støjende.
• Indvirkning på latenstiden: (stigning(http_request_duration_seconds_sum[5m]) / stigning(http_request_duration_seconds_count[5m])) mod node_pressure_io_full_avg60 anvende for at identificere sammenhænge.
• At genkende plateauer: clamp_min(psi:node_io_full:rate5m, 0,0) som et heatmap pr. knudepunkt.

Grafana-dashboards: Synliggør tendenser og find hotspots

I Grafana viser jeg CPU-, hukommelses- og I/O-belastningen hver for sig, henholdsvis for nogle og fuld som separate kurver. Bar-gauges viser mig den aktuelle status, mens tidsseriepaneler afslører toppe og plateauer. Til årsagsanalyse bruger jeg Top-N-visninger efter cgroup, container eller pod og springer derfra videre til detaljepaneler. Det er stadig vigtigt at kombinere avg10, avg60 og avg300, for at undgå overspænding som følge af korte spidsbelastninger. Hvis man ønsker at tænke fremad i forhold til dashboards, kan man finde nyttige ideer omkring Grafana og Prometheus Stack.

Alarmhåndtering i praksis: Regler, vinduer, eskalering

Jeg følger en to-trins-model: Advarsel for tidlige tegn, Kritisk for en vedvarende flaskehals. Som eksempel angiver jeg:

• Hukommelse
  • Advarsel: node_pressure_memory_full_avg60 > 0,01 i 10–30 sekunder
  • Kritisk: node_pressure_memory_full_avg60 > 0,05 i ≥60 sekunder
• I/O
  • Advarsel: rate(node_pressure_io_waiting_seconds_total{state="some"}[5m]) > 0,02
  • Kritisk: node_pressure_io_full_avg60 > 0,02 i ≥120 s
• CPU
  • Advarsel: node_pressure_cpu_some_avg60 > 0,05
  • Kritisk: node_pressure_cpu_full_avg60 > 0,01 (fordi fuld (det gør især ondt her)

I Annotations sammenkæder jeg kontekster (top-cgroups, gennemstrømning, latenstid) og starter playbooks: Scale-Up, justering af grænser, cache-handlinger, batch-begrænsning. Ved gentagne hændelser prioriterer jeg kapacitetsbeslutninger.

Tærskelværdier og alarmering: Vælg det rigtige tidsvindue

Jeg fastlægger klare tærskelværdier for hver ressource og skelner mellem alvorlige nedbrud og korte belastningsspidser. For eksempel vurderer jeg hukommelsen er fuld over 5 % i mere end 60 sekunder betragtes som kritisk, mens 1–2 % i over ti sekunder kun udløser en advarsel. For CPU'en sætter jeg strengere grænser fuld, da ventetider over hele systemet der mærkbart bremser processen. Det giver en merværdi at kombinere dette med målinger af gennemstrømning og latenstid: Når presset stiger, og anmodningerne bliver langsommere, øges hasten. Jeg indstiller altid alarmer ud fra tidsvinduer og ikke ud fra enkeltværdier for at undgå falske alarmer på grund af Udbrud for at undgå.

Kubernetes: Opsætning af scraping, rettigheder og korrelation

I klyngen samler jeg PSI på en sådan måde, at planerne kommer til at falde sammen:

• Node-Exporter som DaemonSet: Standard-scrape pr. node leverer globale PSI-værdier.
• cgroup-Exporter som Sidecar/DaemonSet: Læser værtens cgroup v2-filer og tildeler mærker efter navneområde/pod/container. Jeg bruger kun de absolut nødvendige rettigheder og RO-mounts.
• Kubelet/cAdvisor: Jeg aktiverer visningen af relevante containermetrikker og scrapper Kubelet-endpunktet. Jeg gemmer label-join-nøglerne (f.eks. container vs. container_name) skal være konsistent, så PromQL-sammenføjninger fungerer uden problemer.
• Join med arbejdsbelastningsmålinger: Jeg sammenholder Pod-PSI med app-forsinkelser (f.eks. HTTP-metrikker), overskridelser af CPU-grænser og hukommelsesfejl. På den måde kan jeg se, om årsagen ligger i grænser, planlægning eller flaskehalse i lagringssystemet.

PSI-filer, nøgletal og fortolkning: Et kortfattet overblik

Den følgende tabel opsummerer de vigtigste filer, nøgletal og anvendelsesformål, så jeg hurtigere kan fortolke dataene og oprette passende Grafana-paneler. Jeg bruger den under analysen til at planlægge det næste spørgsmål: finjustering, skalering eller fejlfinding. Forskellene mellem nogle og fuld samt de tre gennemsnitsvinduer. På den måde inddeler jeg symptomerne tidsmæssigt og undersøger, om trykket er lokalt eller udbredt. Kolonnen „Indsats“ hjælper med hurtigt at Klassificering.

Ressource	Fil	Nøgletal	Betydning	Brug
CPU	/proc/pressure/cpu	nogle, fuld; gennemsnit 10/60/300; i alt	Ventetid på ledig regnetid	Overbelastede værter, for begrænsede CPU-Grænser
Hukommelse	/proc/tryk/hukommelse	nogle, fuld; gennemsnit 10/60/300; i alt	Ventetid på grund af Reclaim, Swap, nær OOM	RAM-flaskehalse, cache-belastning, defekte Forespørgsler
I/O	/proc/pressure/io	nogle, fuld; gennemsnit 10/60/300; i alt	Ventetid på lagringsenheder/filsystem	Langsomme lagringsmedier, synkroniseringsstorms, Skylle-faser
IRQ	/proc/pressure/irq	nogle, fuld; gennemsnit 10/60/300; i alt	Udskrivning via interrupt-behandling	Netværksbelastning, driveroptimering, Affinitet
cgroup	*/{cpu,memory,io}.pressure	nogle, fuld; gennemsnit 10/60/300; i alt	Tryk pr. service/container	Søgning efter grundårsagen, målrettet Grænser

Praksis: Effektiv sikkerhed for hosting og WordPress-stacks

På stærkt belastede WordPress-hosts konkurrerer PHP-FPM, databasen og cache-laget jævnligt om RAM og I/O, hvilket jeg kan se via hukommelse og io ser straks. Stiger fuld Hvad angår hukommelse, optimerer jeg OpCache, øger poolstørrelserne gradvist eller fjerner ressourcekrævende plugins. Ved I/O-belastning tjekker jeg forespørgselsplaner, journaliseringsindstillinger og asynkron skrivning. PSI pr. cgroup viser, om det er webserveren, worker-processen eller databasen, der forårsager flaskehalsen. Hvis du vil dykke dybere ned, finder du vejledning i Linux-PSI-vejledning, der opsummerer introduktionen og vurderingen.

Kapacitetsplanlægning og optimering: Fra tal til handlinger

Jeg sammenholder PSI med CPU-udnyttelse, sidefejl, I/O-gennemstrømning og latenstider for at identificere de egentlige årsager. Hvis problemet fortsætter hukommelsen er fuld Jeg skalerer RAM, optimerer Reclaim-parametre eller spreder arbejdsbelastninger. Viser io fuld Ved lange ventetider øger jeg kødybden, aktiverer write-back-strategier eller anvender hurtigere lagringsmedier. Ved CPU-belastning måler jeg parallel Runqueue-længder, justerer planlægningsklasserne og fordeler de mest belastede tråde. Jeg træffer kun beslutninger, når der er tendenser i avg60 og avg300 forblive konsekvent og ikke blot være en Spike er tilgængelig.

Fejlfinding og validering: Fra værten til containeren

Hvis PSI-værdierne mangler, tjekker jeg kerneversionen, CONFIG_PSI og eventuelt boot-parameteren psi=1. Derefter kontrollerer jeg filernes udskrifter under /proc/pressure/* manuelt og sammenlign dem med eksportmålingerne. I cgroup v2 kontrollerer jeg desuden *.tryk-filer i gruppemapperne. Jeg tester alarmer med belastningsgeneratorer og overvåger reaktionslogikken via epoll, for at opdage fejlkonfigurationer på et tidligt tidspunkt. Til sidst sammenligner jeg Grafana-paneler med logfiler, sporingsdata og profileringsresultater, så diagnosticering og afhjælpning kan foregå sikkert passer.

Typiske forhindringer, som jeg tager højde for:

• Swap-interaktion: Let hukommelse noget-Værdierne er normale ved aggressiv genvinding. Det bliver kritisk, når fuld stiger, samtidig med at forsinkelserne øges.
• CPU-isolering og affinitet: Fastgjorte/isolerede kerner kan lokalt CPU fuld skabe, selvom værten samlet set stadig har kapacitet. Jeg tjekker irq-PSI yderligere, hvis netværk/lagring medfører mange afbrydelser.
• Virtuelle miljøer: I virtuelle maskiner afspejler PSI-værdierne også hypervisorens indflydelse. Jeg måler host- og gæst-niveauet hver for sig for entydigt at kunne identificere overcommitment.
• Scrape-overhead: PSI i sig selv er ressourcebesparende, men for korte scrape-intervaller øger belastningen på Prometheus. 15 sekunder er ofte det optimale.
• Etikettkardinalitet: cgroup-stier kan eksplodere. Jeg regulerer med labeldrop/behold og kortlægger kun de lag, som jeg analyserer (f.eks. Service i stedet for hver enkelt kortvarig task-cgroup).

Kort opsummeret

PSI måler ægte ventetid på CPU, RAM og I/O og giver dermed et klart signal om ressourcepres. Ved hjælp af Prometheus-eksport og Grafana-dashboards opretter jeg en oversigt, der skelner mellem årsagerne og hurtigt afslører flaskehalse. Adskillelsen af nogle og fuld plus vinduerne avg10/60/300 gør beslutningerne mere pålidelige. Jeg indstiller alarmer til bestemte tidsperioder, knytter dem til ventetider og styrer automatiske reaktioner via triggere. På den måde træffer jeg velbegrundede beslutninger om kapacitet, afhjælper flaskehalse i tide og sikrer, at tjenesterne fungerer i hverdagen lydhør.