Linux PSI-monitoring visualiseren met Grafana: de druk op de systemressources goed begrijpen en bewaken

Ik laat zien hoe ik linux psi met Prometheus vastleggen en in Grafana weergeven, om de druk op de CPU, het geheugen en de I/O te meten als daadwerkelijke wachttijd. Zo kan ik vaststellen Knelpunten vroegtijdig, wijs ze toe aan cgroups of containers en activeer indien nodig geautomatiseerde tegenmaatregelen.

Centrale punten

• PSI-statistieken: some/full voor CPU, geheugen, I/O en voortschrijdende gemiddelden
• cgroup-focus: een container- en servicespecifieke benadering in plaats van alleen een algemene benadering
• Alarmtrigger: Gebruik poll/epoll voor gebeurtenissen bij drempelwaarden
• Grafana: Panels voor trends, pieken en de N grootste veroorzakers
• Beste praktijken: Drempels, tijdsvensters, correlatie met systeemstatistieken

PSI in het kort: druk opvatten als de werkelijke wachttijd

PSI geeft antwoord op de vraag hoeveel kloktijd Taken wachten tevergeefs op CPU, RAM of I/O. De bestanden in /proc/pressure/{cpu,memory,io,irq} bieden twee perspectieven: sommige toont fasen waarin sommige taken in de wacht staan, volledig geeft momenten aan waarop alle niet-inactieve taken worden geblokkeerd. Ik beoordeel beide waarden afzonderlijk, omdat sommige eerder toeslaat en volledig echte stilstanden zichtbaar maakt. Daarnaast maak ik gebruik van avg10, avg60 en avg300, om kortstondige schommelingen en langetermijntrends van elkaar te onderscheiden. Over de groeiende totaal-Ik merk hoezeer de druk zich sinds de boot heeft opgestapeld en waar Hotspots liggen.

Systeembreed versus cgroup-PSI: het juiste niveau kiezen

Ik maak bewust onderscheid tussen algemene drukwaarden en het perspectief per cgroup. De bestanden onder /proc/druk/ geven het systeem als geheel weer, terwijl cgroup v2 bovendien cpu.pressure, geheugendruk en io.pressure per groep aanbiedt. In containeromgevingen gebruik ik dit om pods, services of Containeren . Deze indeling voorkomt dat ik in het duister tast: in plaats van te moeten gissen, zie ik de oorzaak direct in de groep. Op multi-tenant-hosts scheid ik op deze manier gedeelde en dedicated werklasten en beheer ik Grenzen gericht.

Controleer de vereisten: activeer de kernel, PSI en cgroup v2

Voordat ik statistieken ga verzamelen, zorg ik ervoor dat het platform geschikt is:

• Kernelversie: PSI is beschikbaar vanaf Linux 4.20. Ik controleer dit met uname -r en controleer via zcat /proc/config.gz | grep CONFIG_PSI, of de ondersteuning is ingecompileerd.
• PSI-looptijdvlag: Bij sommige distributies is de optionele opstartvlag toegestaan psi=1, om PSI volledig te activeren. Ik gebruik het indien nodig en controleer of /proc/pressure/* Levert inhoud.
• cgroep v2: Voor de weergave per service/container gebruik ik de uniforme hiërarchie. Ik controleer met mount | grep cgroup2 en verwacht een cgroup2-Mount (vaak /sys/fs/cgroup). Als deze ontbreekt, activeer ik hem via de kernelparameter systemd.unified_cgroup_hierarchy=1 (Opnieuw opstarten vereist).
• Autorisaties: Exporteerders op de host moeten leesrechten hebben voor /proc/pressure/* en eventueel op /sys/fs/cgroup/*/*.pressure. In containers koppel ik deze paden als alleen-lezen.

Gebruik PSI-triggers: automatisch reageren in plaats van alleen maar toekijken

Naast tijdreeksen zet ik ook gebeurtenissen op enquête of epoll door drempelwaarden en tijdsvensters in de PSI-bestanden op te nemen. Zodra de druk op de resources de drempelwaarde in het venster overschrijdt, wordt er een gebeurtenis geactiveerd en zet ik tegenmaatregelen in gang. Dat kan een extra pod zijn, het leegmaken van de cache of het tijdelijk afremmen van een Batch-taken zijn. In Systemd-units koppel ik deze reactie rechtstreeks aan services en houd ik de vertragingen laag. Zo wordt monitoring een besturingsmiddel, en niet alleen maar een Toon.

In de praktijk gebruik ik een compact watcher-programma dat de betreffende *druk*-bestanden opent, via write() een trigger (sommige of volledig (inclusief drempelwaarde en venster in µs) geregistreerd en vervolgens met epoll wacht blokkerend op gebeurtenissen. Zo bespaar ik poll-cycli en reageer ik deterministisch. Ik houd de vensters bewust iets langer open (bijv. 10–30 s) om transiënten te filteren, en maak onderscheid per bron: geheugen reageert gevoeliger dan io, cpu moet duidelijker zijn om te kunnen vuren.

PSI naar Prometheus exporteren: agents, metrics, labels

Voor de tijdreeksen verzamel ik PSI-gegevens via een speciale exporteerfunctie of integreer ik de waarden in bestaande agents zoals de Node-exporter. Het is van cruciaal belang dat de labels voor host, cgroup en container consistent zijn, zodat query’s in Grafana correct filteren. In Kubernetes gebruik ik bovendien cAdvisor- en Kubelet-metrieken voor *_druk_*_totaal_aantal_seconden_wachten_*, zodat de knooppunt-, pod- en containerniveaus met elkaar in overeenstemming blijven. Voor klassieke hosts lees ik /proc/pressure/* direct en map sommige en volledig op afzonderlijke metrieknamen. Een handleiding voor de integratie van agents helpt je op weg, bijvoorbeeld op Node Exporter instellen.

Exporter-varianten in detail: Node, cgroup en Kubernetes

Afhankelijk van de omgeving pas ik verschillende methoden toe:

• Node-exporter (Host-niveau): Ik activeer de druk-Collector (indien niet standaard ingeschakeld), bijvoorbeeld via --collector.druk. Het levert statistieken zoals node_pressure_cpu_some_avg10, node_pressure_memory_full_avg60 en node_pressure_io_waiting_seconds_total{state="some|full"}. Deze laatste zijn geschikt voor rate()-analyses en Top-N.
• Eigen cgroup-exporter (Service-/containerniveau): Voor een gedetailleerd overzicht bekijk ik /sys/fs/cgroup//{cpu,memory,io}.pressure en genereer statistieken zoals cgroup_pressure_memory_waiting_seconds_total{state="full",cgroup="..."} en de avg10/60/300‑Gauges. Ik normaliseer het cgroup-pad als label (cgroup) of map op dienst/container Labels.
• Kubernetes: Op knooppuntniveau voert Prometheus een scraping uit node-exporter. Voor het weergeven van containers gebruik ik een DaemonSet-exporter met hostPID:true en read-only-mounts van /sys/fs/cgroup en /proc, zodat ik de cgroup-bestanden van de host kan zien. Daarnaast maak ik gebruik van Kubelet/cAdvisor-metrieken, voor zover deze de PSI-totalen weergeven; de labels naamruimte, capsule en container daarin blijf ik consequent.

Een duidelijke Labelstrategie: instantie (host of knooppuntnaam), cgroup (pad), naamruimte/capsule/container (bij K8's) en status (sommige/volledig) en bron (cpu/geheugen/io/irq). Zo kan ik sterk samenvatten en tegelijkertijd heel gedetailleerd inzoomen.

Prometheus-taken, opnameregels en voorbeeldquery's

Voor duidelijke analyses gebruik ik twee patronen: procentmeter (avg10/60/300) en daaruit afgeleide rate()‑waarden op de *_totaal_aantal_seconden_wachten_*‑meters.

• Scrape: 15 seconden is een goed begin. Korter verhoogt de belasting, maar leidt bij avg10 maar zelden een meerwaarde.
• Opnameregels: Ik bereken afgeleide tijdreeksen om dashboards en waarschuwingen te vereenvoudigen:
  • 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 = som per (cgroup) (rate(cgroup_pressure_memory_waiting_seconds_total{state="full"}[5m]))

Met PromQL bouw ik typische weergaven:

• Host-trend: node_pressure_memory_full_avg60 in de tijd, uitgesplitst per knooppunt.
• Top-N-vervuilers: topk(5, psi:cgroup_memory_full:rate5m) toont de luidste cgroups.
• Gevolgen voor de latentie: (toename(http_request_duration_seconds_sum[5m]) / toename(http_request_duration_seconds_count[5m])) tegen node_pressure_io_full_avg60 om correlaties te herkennen.
• Plateaus herkennen: clamp_min(psi:node_io_full:rate5m, 0,0) als heatmap per knooppunt.

Grafana-dashboards: trends zichtbaar maken en hotspots opsporen

In Grafana geef ik de CPU-, geheugen- en I/O-belasting afzonderlijk weer, telkens voor sommige en volledig als afzonderlijke grafieken. Balkgrafieken geven me de huidige status weer, terwijl tijdreeks-panelen pieken en plateaus laten zien. Voor oorzakenanalyse gebruik ik Top-N-weergaven op basis van cgroup, container of pod en ga ik van daaruit naar detailpanelen. Belangrijk blijft de combinatie van avg10, avg60 en avg300, om overbelasting door korte pieken te voorkomen. Wie vooruit wil denken bij het ontwerpen van dashboards, vindt hier nuttige ideeën over de Grafana en Prometheus Stack.

Alarmering in de praktijk: regels, vensters, escalatie

Ik hanteer een model in twee fasen: waarschuwing voor vroege signalen, Kritisch voor een blijvende knelpunt. Als voorbeeld neem ik:

• Geheugen
  • Waarschuwing: node_pressure_memory_full_avg60 > 0,01 gedurende 10–30 seconden
  • Kritisch: node_pressure_memory_full_avg60 > 0,05 gedurende ≥60 s
• I/O
  • Waarschuwing: rate(node_pressure_io_waiting_seconds_total{state="some"}[5m]) > 0,02
  • Kritisch: node_pressure_io_full_avg60 > 0,02 gedurende ≥120 s
• CPU
  • Waarschuwing: node_pressure_cpu_some_avg60 > 0,05
  • Kritisch: node_pressure_cpu_full_avg60 > 0,01 (omdat volledig (wat hier bijzonder pijnlijk is)

In annotaties koppel ik contexten aan elkaar (top-cgroups, doorvoer, latentie) en start ik playbooks: scale-up, limieten aanpassen, cache-acties, batch-beperking. Bij terugkerende gebeurtenissen geef ik voorrang aan beslissingen over de capaciteit.

Drempels en alarmering: het juiste tijdsvenster kiezen

Ik stel duidelijke drempelwaarden vast per hulpbron en maak onderscheid tussen ernstige storingen en korte piekbelastingen. Zo beoordeel ik bijvoorbeeld geheugen vol meer dan 5 % gedurende meer dan 60 seconden wordt als kritiek beschouwd, terwijl 1–2 % gedurende meer dan tien seconden slechts een waarschuwing activeren. Voor de CPU stel ik strengere limieten in volledig, aangezien langdurige wachttijden daar een merkbare vertraging veroorzaken. De koppeling met doorvoersnelheid- en latentie-statistieken biedt toegevoegde waarde: wanneer de druk toeneemt en verzoeken trager worden, stijgt de urgentie. Ik stel waarschuwingen altijd in op tijdsvensters, niet op afzonderlijke waarden, om vals-alarm door Uitbarstingen te vermijden.

Kubernetes: scraping-configuratie, rechten en correlatie

In het cluster verzamel ik PSI zodanig dat de niveaus met elkaar overeenkomen:

• Node-Exporter als DaemonSet: Standaard-scrape per node levert globale PSI-waarden op.
• cgroup-exporter als sidecar/DaemonSet: Leest de cgroup v2-bestanden van de host en voegt labels toe op basis van naamruimte/pod/container. Ik maak gebruik van zo min mogelijk benodigde rechten en RO-mounts.
• Kubelet/cAdvisor: Ik schakel de weergave van relevante containermetrics in en scrape het Kubelet-eindpunt. Ik bewaar de label-join-sleutels (bijv. container vs. container_name) consistent, zodat PromQL-joins soepel verlopen.
• Join met workload-statistieken: Ik breng Pod-PSI in verband met app-latenties (bijv. HTTP-statistieken), CPU-limietoverschrijdingen en geheugenfouten. Zo kan ik vaststellen of limieten, planning of opslagknelpunten de oorzaak zijn.

PSI-bestanden, kengetallen en interpretatie: beknopt overzicht

De volgende tabel geeft een overzicht van de belangrijkste bestanden, kengetallen en toepassingsdoelen, zodat ik deze sneller kan interpreteren en geschikte Grafana-panelen kan bouwen. Ik gebruik deze tabel bij de analyse om de volgende vraag te formuleren: afstemming, schaalvergroting of storingsoplossing. Vooral de verschillen tussen sommige en volledig en de drie gemiddeldevensters. Zo breng ik de symptomen in chronologische volgorde en controleer ik of de druk plaatselijk of over een groter gebied optreedt. De kolom „Inzet“ helpt bij het snel Classificatie.

Bron	Bestand	Belangrijke cijfers	Dat betekent	Gebruik
CPU	/proc/pressure/cpu	some, full; avg10/60/300; totaal	Wachttijd op beschikbare rekentijd	Overbelaste hosts, te krappe CPU-Grenzen
Geheugen	/proc/druk/geheugen	some, full; avg10/60/300; totaal	Wachttijd door Reclaim, Swap, bijna OOM	RAM-tekorten, cache-druk, defecte Verzoeken
I/O	/proc/pressure/io	some, full; avg10/60/300; totaal	Wachttijd op opslagapparaten/bestandssysteem	Trage opslagmedia, synchronisatieproblemen, Doorspoelen-fasen
IRQ	/proc/pressure/irq	some, full; avg10/60/300; totaal	Druk door interruptverwerking	Netwerkbelasting, stuurprogramma-optimalisatie, Affiniteit
cgroup	*/{cpu,memory,io}.pressure	some, full; avg10/60/300; totaal	Druk per service/container	Oorzakelijkheidsonderzoek, gericht Grenzen

Praktijk: hosting en WordPress-stacks efficiënt beveiligen

Op drukbezochte WordPress-hosts strijden PHP-FPM, de database en de cachelaag regelmatig om RAM en I/O, wat ik via geheugen en io meteen zie. Stijgt volledig Wat het geheugen betreft, optimaliseer ik de OpCache, vergroot ik de poolgroottes geleidelijk of schrap ik dure plug-ins. Bij I/O-druk controleer ik queryplannen, journaling-instellingen en asynchroon schrijven. PSI per cgroup maakt zichtbaar of de webserver, de worker of de database de bottleneck veroorzaakt. Wie zich hier verder in wil verdiepen, vindt aanwijzingen in de Linux-PSI-handleiding, waarin de inleiding en de beoordeling worden samengevat.

Capaciteitsplanning en optimalisatie: van cijfers naar acties

Ik koppel PSI aan CPU-belasting, page-fouts, I/O-doorvoer en latenties om de werkelijke oorzaken te achterhalen. Bij aanhoudende geheugen vol Ik schaal het RAM-geheugen op, optimaliseer de Reclaim-parameters of spreid workloads uit. Toont io volledig Bij lange wachtrijen vergroot ik de wachtrijdiepte, activeer ik write-back-strategieën of zet ik snellere opslagmedia in. Bij CPU-belasting meet ik parallel de lengte van de runqueue, pas ik de scheduling-klassen aan en verdeel ik ‘hete’ threads. Ik neem alleen beslissingen als er trends zichtbaar zijn in de avg60 en avg300 consistent blijven en niet alleen een Spike beschikbaar is.

Probleemoplossing en validatie: van host tot container

Als er geen PSI-waarden zijn, controleer ik de kernelversie, CONFIG_PSI en eventueel de opstartparameter psi=1. Vervolgens controleer ik de uitvoer van de bestanden onder /proc/pressure/* handmatig en vergelijk ze met de exporter-statistieken. In cgroup v2 controleer ik bovendien de *.druk-bestanden in de groepsmappen. Ik test waarschuwingen met belastinggeneratoren en observeer de reactielogica via epoll, om verkeerde configuraties in een vroeg stadium op te sporen. Tot slot vergelijk ik Grafana-panelen met logbestanden, traces en profileresultaten, zodat de diagnose en de tegenmaatregelen betrouwbaar zijn fit.

Typische valkuilen waarmee ik rekening houd:

• Swap-interactie: Lichte geheugen wat-De waarden zijn normaal bij een agressieve reclaim. Het wordt kritiek wanneer volledig stijgt en tegelijkertijd de latentie toeneemt.
• CPU-isolatie en affiniteit: Vastgezette/geïsoleerde kernen kunnen lokaal CPU volledig belast produceren, hoewel de host in zijn geheel nog ruimte heeft. Ik controleer irq-PSI extra, als het netwerk/de opslag veel interrupts verwerkt.
• Virtuele omgevingen: In VM’s weerspiegelen PSI-waarden ook de invloed van de hypervisor. Ik meet het host- en gastniveau afzonderlijk om overcommitment eenduidig te kunnen toewijzen.
• Scrape-overhead: PSI zelf is voordelig, maar te korte scrape-intervallen verhogen de belasting van Prometheus. 15 seconden is vaak het ideale interval.
• Label-cardinaliteit: cgroup-paden kunnen uitdijen. Ik pas aan met labeldrop/bewaren en breng alleen de lagen in kaart die ik analyseer (bijvoorbeeld Service in plaats van elke kortstondige task-cgroup).

Kort samengevat

PSI meet echte wachttijd op CPU, RAM en I/O en geeft daarmee een duidelijk signaal van druk op de systemen. Met Prometheus-export en Grafana-dashboards bouw ik een overzicht dat de oorzaken onderscheidt en snel knelpunten aan het licht brengt. Het onderscheid tussen sommige en volledig plus de ramen avg10/60/300 maakt besluitvorming robuust. Ik richt waarschuwingen op tijdsperioden, koppel ze aan vertragingen en stuur automatische reacties aan via triggers. Zo neem ik weloverwogen beslissingen over de capaciteit, los ik knelpunten tijdig op en houd ik diensten in de dagelijkse praktijk draaiende responsief.