Wizualizacja monitorowania PSI w systemie Linux za pomocą Grafany: jak właściwie zrozumieć i monitorować obciążenie zasobów

Pokazuję, jak linux psi rejestruję za pomocą Prometheusa i wyświetlam w Grafanie, aby zmierzyć obciążenie procesora, pamięci i operacji wejścia/wyjścia jako rzeczywisty czas oczekiwania. W ten sposób mogę rozpoznać Wąskie gardła na wczesnym etapie przypisz je do grup cgroup lub kontenerów i w razie potrzeby uruchom zautomatyzowane działania zaradcze.

Punkty centralne

• Wskaźniki PSI: some/full dla procesora, pamięci, operacji wejścia/wyjścia oraz średnich ruchomych
• Skupienie na cgroupach: Perspektywa ukierunkowana na kontenery i usługi, a nie wyłącznie globalna
• Warunki uruchomienia alertu: Wykorzystanie funkcji poll/epoll do obsługi zdarzeń przy wartościach progowych
• Grafana: Panele dotyczące trendów, szczytów i największych N sprawców
• Najlepsze praktyki: progi, przedziały czasowe, korelacja z wskaźnikami systemowymi

PSI w skrócie: rozumienie ciśnienia jako rzeczywistego czasu oczekiwania

PSI odpowiada na pytanie, ile Czas rzeczywisty Zadania czekają bezskutecznie na procesor, pamięć RAM lub operacje wejścia/wyjścia. Pliki w katalogu /proc/pressure/{cpu,memory,io,irq} przedstawiają dwie perspektywy: niektóre pokazuje fazy, w których niektóre zadania oczekują, pełny wskazuje momenty, w których wszystkie zadania niebędące w stanie bezczynności powodują blokadę. Oceniam obie wartości osobno, ponieważ niektóre pojawia się wcześniej i pełny uwidacznia rzeczywiste przestoje. Dodatkowo korzystam z avg10, avg60 oraz avg300, aby odróżnić krótkoterminowe wahania od długoterminowych trendów. W związku z rosnącą łącznie- W tym momencie zdaję sobie sprawę, jak bardzo narastała presja od czasu wypłynięcia i gdzie Hotspoty kłamstwo.

PSI na poziomie systemu a PSI w cgroup: wybór odpowiedniego poziomu

Świadomie rozróżniam wartości ciśnienia globalnego od widoku z perspektywy cgroup. Pliki znajdujące się w /proc/pressure/ przedstawiają system jako całość, podczas gdy cgroup v2 dodatkowo cpu.pressure, memory.pressure oraz io.pressure dla każdej grupy. W środowiskach kontenerowych używam tego do uporządkowanego przypisywania obciążenia do podów, usług lub kontenerowanie . Takie przypisanie pozwala uniknąć „lotów na ślepo”: zamiast zgadywać, od razu widzę źródło problemu w grupie. Na serwerach wielodostępnych oddzielam w ten sposób obciążenia współdzielone od dedykowanych i zarządzam Ograniczenia ukierunkowane.

Sprawdź wymagania: włącz jądro, PSI i cgroup v2

Zanim zacznę gromadzić dane, upewniam się, że platforma jest odpowiednia:

• Wersja jądra: PSI jest dostępne od wersji Linuksa 4.20. Sprawdzam za pomocą uname -r i sprawdzam za pomocą zcat /proc/config.gz | grep CONFIG_PSI, czy obsługa jest wkompilowana.
• Flaga czasu działania PSI: Niektóre dystrybucje umożliwiają użycie opcjonalnego parametru startowego psi=1, aby w pełni aktywować PSI. Używam go w razie potrzeby i sprawdzam, czy /proc/pressure/* Dostarcza treści.
• cgroup v2: W widoku „per‑Service/Container” korzystam z ujednolicona hierarchia. Sprawdzam za pomocą mount | grep cgroup2 i oczekuję cgroup2-Mount (często /sys/fs/cgroup). Jeśli go brakuje, włączam go za pomocą parametru jądra systemd.unified_cgroup_hierarchy=1 (Konieczne ponowne uruchomienie).
• Zezwolenia: Programy eksportujące na serwerze muszą mieć uprawnienia do odczytu w /proc/pressure/* oraz, w razie potrzeby, na /sys/fs/cgroup/*/*.pressure. W kontenerach montuję te ścieżki w trybie tylko do odczytu.

Wykorzystaj wyzwalacze PSI: automatycznie reaguj, zamiast tylko obserwować

Oprócz szeregów czasowych przedstawiam również zdarzenia dotyczące ankieta lub epoll poprzez zapisanie wartości progowych i przedziałów czasowych w plikach PSI. Gdy tylko obciążenie zasobów przekroczy wartość graniczną w danym przedziale, generowane jest zdarzenie i uruchamiam działania zaradcze. Może to być uruchomienie dodatkowego modułu, wyczyszczenie pamięci podręcznej lub tymczasowe ograniczenie Zadania wsadowe . W jednostkach Systemd wiążę tę reakcję bezpośrednio z usługami i ograniczam opóźnienia. W ten sposób monitorowanie staje się narzędziem sterowania, a nie tylko Wyświetlacz.

W praktyce korzystam z kompaktowego programu typu watcher, który monitoruje odpowiednie *ciśnienie*-otwiera pliki, za pomocą write() wyzwalacz (niektóre lub pełny wraz z wartością progową i oknem w µs), a następnie za pomocą epoll czekając blokująco na zdarzenia. W ten sposób oszczędzam cykle odpytywania i reaguję deterministycznie. Celowo utrzymuję okna nieco dłużej (np. 10–30 s), aby wyeliminować zjawiska przejściowe, i rozróżniam poszczególne zasoby: pamięć reaguje bardziej wrażliwie niż io, procesor musi być wyraźniejsze, aby można było strzelać.

Eksportowanie danych z PSI do Prometheusa: agenci, metryki, etykiety

W przypadku szeregów czasowych gromadzę dane PSI za pomocą dedykowanego narzędzia eksportującego lub integruję te wartości z istniejącymi agentami, takimi jak Eksportator węzłów. Kluczowe znaczenie mają spójne nazwy hostów, grup cgroup i kontenerów, aby zapytania w Grafanie filtrowały dane poprawnie. W Kubernetesie korzystam dodatkowo z metryk cAdvisor i Kubelet dla *_ciśnienie_*_sekundy_oczekiwania_łącznie, aby poziomy węzłów, podów i kontenerów pozostawały zbieżne. W przypadku klasycznych hostów odczytuję /proc/pressure/* bezpośrednio i w folderze niektóre oraz pełny na oddzielne nazwy metryk. Instrukcja dotycząca integracji agentów pomoże w rozpoczęciu pracy, na przykład pod adresem Konfiguracja eksportera węzłów.

Szczegółowy opis wariantów eksportu: Node, cgroup i Kubernetes

W zależności od otoczenia stosuję różne metody:

• Eksportator węzłów (Poziom hosta): Włączam ciśnienie-Collector (jeśli nie jest domyślnie aktywny), np. poprzez --ciśnienie kolektora. Dostarcza on wskaźniki, takie jak node_pressure_cpu_some_avg10, node_pressure_memory_full_avg60 oraz node_pressure_io_waiting_seconds_total{state="some|full"}. Te ostatnie nadają się do rate()-Analizy i Top-N.
• Własny eksporter cgroup (Poziom usług/kontenerów): Aby uzyskać szczegółowy wgląd, przeglądam /sys/fs/cgroup//{cpu,memory,io}.pressure i generuję wskaźniki, takie jak cgroup_pressure_memory_waiting_seconds_total{state="full",cgroup="..."} i avg10/60/300‑Gauges. Normalizuję ścieżkę cgroup jako etykietę (cgroup) lub folder na Serwis/pojemnik Etykiety.
• Kubernetes: Na poziomie węzła Prometheus pobiera dane node‑exporter. Do przeglądania kontenerów używam eksportera DaemonSet z hostPID:true oraz montowanie w trybie tylko do odczytu z /sys/fs/cgroup oraz /proc, abym mógł zobaczyć pliki cgroup hosta. Dodatkowo korzystam z metryk Kubelet/cAdvisor, o ile podają one wartości PSI; etykiety przestrzeń nazw, pod oraz pojemnik W tym zakresie zachowuję spójność.

Pomaga mi jasne Strategia marki: instancja (Host lub nazwa węzła), cgroup (ścieżka), przestrzeń nazw/pod/pojemnik (w przypadku K8s) oraz stan (niektóre/pełny) i zasób (procesor/pamięć/io/irq). Dzięki temu mogę zarówno znacznie zagregować dane, jak i jednocześnie powiększyć obraz.

Prometheus-Jobs, reguły rejestrowania i przykładowe zapytania

Aby uzyskać przejrzyste wyniki, korzystam z dwóch wzorów: wskaźników procentowych (avg10/60/300) oraz pochodne rate()‑wartości na *_całkowita_liczba_sekund_oczekiwania_*‑liczniki.

• Scrape: 15 s to dobry początek. Krótszy czas zwiększa obciążenie, co przy avg10 ale rzadko stanowi wartość dodaną.
• Zasady nagrywania: Obliczam pochodne szeregi czasowe, aby uprościć działanie pulpitów nawigacyjnych i alertów:
  • rekord: psi:node_memory_full:avg60 = średnia w czasie (node_pressure_memory_full_avg10[60s])
  • rekord: psi:node_io_full:rate5m = rate(node_pressure_io_waiting_seconds_total{state="full"}[5m])
  • rekord: psi:cgroup_memory_full:rate5m = suma według (cgroup) (wartość (cgroup_pressure_memory_waiting_seconds_total{state="full"}[5m]))

Za pomocą PromQL tworzę typowe widoki:

• Trend dotyczący hostów: node_pressure_memory_full_avg60 w czasie, w podziale na węzły.
• Najwięksi emitenci: topk(5, psi:cgroup_memory_full:rate5m) wyświetla najgłośniejsze grupy cgroups.
• Wpływ na opóźnienie: (wzrost(http_request_duration_seconds_sum[5m]) / wzrost(http_request_duration_seconds_count[5m])) przeciwko node_pressure_io_full_avg60 w celu wykrycia korelacji.
• Rozpoznawanie płaskowyżów: clamp_min(psi:node_io_full:rate5m, 0,0) w postaci mapy cieplnej dla każdego węzła.

Panele Grafana: wizualizacja trendów i identyfikacja newralgicznych punktów

W Grafanie wyświetlam obciążenie procesora, pamięci i operacji wejścia/wyjścia osobno, odpowiednio dla niektóre oraz pełny jako osobne wykresy. Wskaźniki paskowe pokazują mi aktualny stan, podczas gdy panele szeregów czasowych ujawniają szczyty i plateau. Do analizy przyczyn korzystam z widoków Top-N według cgroup, kontenera lub poda, a stamtąd przechodzę do paneli szczegółowych. Istotne znaczenie ma połączenie avg10, avg60 oraz avg300, aby uniknąć przesterowań spowodowanych krótkimi skokami napięcia. Osoby, które chcą z wyprzedzeniem zaplanować pulpit nawigacyjny, znajdą pomocne pomysły dotyczące Grafana i Prometheus Stack.

Powiadamianie w praktyce: zasady, okna czasowe, eskalacja

Stosuję model dwuetapowy: Ostrzeżenie w przypadku wczesnych sygnałów, Krytyczny dla trwałego wąskiego gardła. Jako przykład podam:

• Pamięć
  • Ostrzeżenie: node_pressure_memory_full_avg60 > 0,01 przez 10–30 s
  • Krytyczne: node_pressure_memory_full_avg60 > 0,05 przez ≥60 s
• I/O
  • Ostrzeżenie: rate(node_pressure_io_waiting_seconds_total{state="some"}[5m]) > 0,02
  • Krytyczne: node_pressure_io_full_avg60 > 0,02 przez ≥120 s
• CPU
  • Ostrzeżenie: node_pressure_cpu_some_avg60 > 0,05
  • Krytyczne: node_pressure_cpu_full_avg60 > 0,01 (ponieważ pełny (co tutaj jest szczególnie bolesne)

W sekcji „Adnotacje” łączę konteksty (główne grupy cgroups, przepustowość, opóźnienia) i uruchamiam scenariusze: skalowanie w górę, dostosowywanie limitów, operacje związane z pamięcią podręczną, ograniczanie przetwarzania wsadowego. W przypadku powtarzających się zdarzeń priorytetowo traktuję decyzje dotyczące wydajności.

Progi i powiadamianie: właściwy dobór przedziału czasowego

Określam jasne wartości progowe dla poszczególnych zasobów i odróżniam poważne awarie od krótkotrwałych skoków obciążenia. Na przykład analizuję pamięć pełna Wartość powyżej 5 % trwająca dłużej niż 60 sekund jest traktowana jako krytyczna, podczas gdy wartość 1–2 % trwająca ponad dziesięć sekund powoduje jedynie wyświetlenie ostrzeżenia. W przypadku procesora ustalam bardziej rygorystyczne limity pełny, ponieważ powszechne opóźnienia w tym obszarze wyraźnie spowalniają działanie. Dodatkową wartość zapewnia powiązanie z wskaźnikami przepustowości i opóźnień: gdy presja rośnie, a żądania stają się wolniejsze, wzrasta poziom pilności. Zawsze ustawiam alerty na przedziały czasowe, a nie na pojedyncze wartości, aby uniknąć fałszywych alarmów spowodowanych Wybuchy których należy unikać.

Kubernetes: konfiguracja scraperów, uprawnienia i korelacja

W klastrze gromadzę PSI w taki sposób, aby poziomy pokrywały się:

• Node-Exporter jako DaemonSet: Standardowe skanowanie na węzeł dostarcza globalne wartości PSI.
• cgroup-Exporter jako Sidecar/DaemonSet: Odczytuje pliki cgroup v2 hosta, przypisuje etykiety zgodnie z przestrzeń nazw/pod/kontener. Korzystam z minimalnego niezbędnego zakresu uprawnień i montów RO.
• Kubelet/cAdvisor: Włączam wyświetlanie odpowiednich metryk kontenerów i pobieram dane z punktu końcowego Kubelet. Zachowuję klucze dołączania etykiet (np. pojemnik vs. nazwa_kontenera) spójne, aby połączenia PromQL działały bez zakłóceń.
• Funkcja JOIN z metrykami obciążenia: Analizuję korelacje między wskaźnikiem Pod-PSI a opóźnieniami w aplikacjach (np. metrykami HTTP), przekroczeniami limitów procesora oraz błędami pamięci. W ten sposób ustalam, czy przyczyną są limity, planowanie zadań czy wąskie gardła w pamięci masowej.

Pliki PSI, wskaźniki i interpretacja: zwięzły przegląd

Poniższa tabela zawiera zestawienie najważniejszych plików, wskaźników i zastosowań, co pozwala mi szybciej je interpretować i tworzyć odpowiednie panele w Grafanie. Korzystam z niej podczas analizy, aby zaplanować kolejne pytanie: optymalizacja, skalowanie czy usuwanie usterek. Szczególnie istotne pozostają różnice między niektóre oraz pełny oraz trzy okna średnich. W ten sposób porządkuję objawy chronologicznie i sprawdzam, czy ciśnienie występuje lokalnie, czy na większym obszarze. Kolumna „Zastosowanie“ pomaga w szybkim Klasyfikacja.

Zasoby	Plik	Kluczowe dane	Znaczenie	Użycie
CPU	/proc/pressure/cpu	niektóre, pełne; średnia 10/60/300; ogółem	Czas oczekiwania na wolny czas obliczeniowy	Przeciążone serwery, zbyt mała wydajność procesoraOgraniczenia
Pamięć	/proc/pressure/memory	niektóre, pełne; średnia 10/60/300; ogółem	Czas oczekiwania spowodowany operacjami „Reclaim”, „Swap” oraz zbliżeniem się do stanu OOM	Ograniczenia pamięci RAM, obciążenie pamięci podręcznej, uszkodzone Żądania
I/O	/proc/pressure/io	niektóre, pełne; średnia 10/60/300; ogółem	Czas oczekiwania na urządzenia pamięci masowej/system plików	Powolne nośniki danych, burze synchronizacji, Spłukiwanie-fazy
IRQ	/proc/pressure/irq	niektóre, pełne; średnia 10/60/300; ogółem	Wypis przez obsługę przerwań	Obciążenie sieci, optymalizacja sterowników, Affinity
cgroup	*/{cpu,memory,io}.pressure	niektóre, pełne; średnia 10/60/300; ogółem	Ciśnienie na serwis/kontener	Wyszukiwanie przyczyny źródłowej, ukierunkowane Ograniczenia

W praktyce: skuteczne zabezpieczanie hostingu i środowisk WordPress

Na intensywnie obciążonych serwerach WordPress PHP-FPM, baza danych i warstwa pamięci podręcznej regularnie konkurują o pamięć RAM i operacje wejścia/wyjścia, co mogę sprawdzić za pomocą pamięć oraz io od razu widzę. Wzrasta pełny Jeśli chodzi o pamięć, optymalizuję OpCache, stopniowo zwiększam rozmiary pul lub ograniczam liczbę zasobnych wtyczek. W przypadku obciążenia operacjami wejścia/wyjścia sprawdzam plany zapytań, ustawienia dziennikowania oraz zapis asynchroniczny. Wskaźnik PSI na grupę cgroup pozwala ustalić, czy wąskie gardło powoduje serwer WWW, proces roboczy czy baza danych. Osoby pragnące zgłębić temat znajdą wskazówki w Poradnik dotyczący PSI w systemie Linux, w którym podsumowano wprowadzenie i ocenę.

Planowanie wydajności i optymalizacja: od liczb do działań

Łączę wskaźnik PSI z obciążeniem procesora, błędami stronicowania, przepustowością operacji wejścia/wyjścia oraz opóźnieniami, aby zidentyfikować rzeczywiste przyczyny. W przypadku utrzymującego się pamięć pełna skaluję pamięć RAM, optymalizuję parametry odzyskiwania lub rozdzielam obciążenia. Pokazuje io full W przypadku długich okresów stabilizacji zwiększam głębokość kolejek, włączam strategie typu „write-back” lub stosuję szybsze nośniki danych. W przypadku obciążenia procesora równolegle mierzę długości kolejek zadań, dostosowuję klasy planowania i rozdzielam najbardziej obciążone wątki. Decyzje podejmuję tylko wtedy, gdy trendy w avg60 oraz avg300 zachować spójność i nie być tylko Kolec jest dostępny.

Rozwiązywanie problemów i walidacja: od hosta do kontenera

W przypadku braku wartości PSI sprawdzam wersję jądra, CONFIG_PSI oraz opcjonalnie parametr rozruchowy psi=1. Następnie sprawdzam zawartość tych plików pod adresem /proc/pressure/* ręcznie i porównaj je z wskaźnikami narzędzia Exporter. W cgroup v2 dodatkowo sprawdzam *.pressure-pliki w katalogach grupowych. Testuję alerty za pomocą generatorów obciążenia i obserwuję logikę reakcji za pośrednictwem epoll, aby wcześnie wykrywać błędy w konfiguracji. Na koniec porównuję panele Grafany z logami, śladami i wynikami profilowania, aby zapewnić prawidłową diagnostykę i podjęcie odpowiednich działań naprawczych dopasowanie.

Typowe przeszkody, które biorę pod uwagę:

• Interakcja swapowa: Lekkie zapamiętaj trochę-Wartości te są w normie w przypadku agresywnego odzyskiwania. Sytuacja staje się krytyczna, gdy pełny wzrasta, a jednocześnie wydłużają się opóźnienia.
• Izolacja procesora i powinowactwo: Rdzenie przypięte/izolowane mogą lokalnie procesor obciążony w pełni generować, mimo że host ma jeszcze wolne zasoby. Sprawdzam irq-PSI dodatkowo, jeśli sieć/magazyn danych generuje dużą liczbę przerwań.
• Środowiska wirtualne: W maszynach wirtualnych wartości PSI odzwierciedlają również wpływ hiperwizora. Dokonuję pomiarów oddzielnie na poziomie hosta i gościa, aby jednoznacznie zidentyfikować nadmierne przydziały zasobów.
• Nakład związany ze scrapowaniem: Sam PSI jest wydajny, ale zbyt krótkie interwały zeskrobywania zwiększają obciążenie Prometheusa. 15 s to często optymalny czas.
• Kardynalność etykiet: ścieżki cgroup mogą się rozgałęziać. Reguluję to za pomocą labeldrop/zachowaj i mapuję tylko te warstwy, które analizuję (np. Service zamiast każdej krótkotrwałej grupy zadań typu task-cgroup).

Krótkie podsumowanie

PSI mierzy rzeczywiste czas oczekiwania na procesorze, pamięci RAM i wejściu/wyjściu, co stanowi wyraźny sygnał o obciążeniu zasobów. Dzięki eksportowi danych z Prometheusa i pulpitom nawigacyjnym Grafany tworzę widok, który pozwala rozróżnić przyczyny i szybko wykrywać newralgiczne punkty. Rozdzielenie niektóre oraz pełny plus okna avg10/60/300 zapewnia solidne podstawy do podejmowania decyzji. Ustawiam alerty na określone przedziały czasowe, łączę je z opóźnieniami i steruję automatycznymi reakcjami za pomocą wyzwalaczy. W ten sposób podejmuję przemyślane decyzje dotyczące wydajności, na czas eliminuję wąskie gardła i zapewniam ciągłość działania usług na co dzień responsywny.