Monitoring wydajności w czasie rzeczywistym: narzędzia dla adminów i power userów

Monitoring na żywo bez bólu: na co uważać na starcie

Trzy pułapki, które od razu podkopują monitoring

Real-time monitoring kusi „magicznie żywymi” wykresami z odświeżaniem co sekundę. Najczęściej kończy się to trzema problemami: przeciążeniem samych maszyn przez zbyt agresywne zbieranie metryk, lawiną powiadomień bez wartości oraz dashboardami, które niczego nie wyjaśniają. Zamiast zaczynać od instalowania wszystkiego wszędzie, ustal, po co potrzebujesz wglądu sekundowego i które decyzje podejmiesz na jego podstawie. W praktyce wystarczy garść metryk w wysokiej rozdzielczości i reszta w interwale 10–60 s.

Co znaczy „w czasie rzeczywistym” w środowisku systemów

„Na żywo” w kontekście admina nie oznacza milisekund. Wystarczy odświeżanie co 1–5 sekund dla najważniejszych paneli operacyjnych i pełny historyczny zapis w rozdzielczości 10–60 s. Krytyczne zdarzenia i tak rozpoznasz po powtarzalnych wzorcach (np. wzrost iowait, throttle CPU, dropy na interfejsie), a nie po pojedynczych próbkach. Definiując „real-time”, świadomie dobierz interwały i retencję oraz testuj narzut na CPU i I/O samego narzędzia.

Minimalny, sensowny zestaw na dzień dobry

Na pojedynczym serwerze lub stacji roboczej wystarczy lekki podgląd: htop lub btop do procesów i CPU, iostat/atop do dysku, nload/iftop do sieci, plus logi w jednym miejscu. W środowisku z kilkoma hostami postaw jedną lekką instancję Prometheusa z node_exporterem lub Telegrafa z InfluxDB, podłącz prosty dashboard i tylko trzy alerty: wysycenie CPU, wykorzystanie pamięci, opóźnienia i I/O czekające w kolejce. Resztę dobudujesz, gdy naprawdę okaże się potrzebna.

Zanim wybierzesz narzędzia: pytania, które naprawdę zadasz

• Jak zdefiniować cel monitoringu w czasie rzeczywistym, żeby nie monitorować „wszystkiego i niczego”?
• Jakie metryki zacząć śledzić i w jakiej rozdzielczości, by szybko znaleźć wąskie gardła?
• Które narzędzia działają najlepiej lokalnie, a które mają sens w środowisku rozproszonym?
• Jak połączyć widok „sekunda po sekundzie” z długoterminową historią i prostymi alertami?
• Jak ograniczyć narzut monitoringu i uniknąć fałszywych alarmów?
• Jak czytać typowe symptomy: iowait, throttling CPU w kontenerach, memory leak, dropy w sieci?
• Jak zorganizować dashboardy i progi alarmowe, żeby pomagały, a nie przeszkadzały?
• Jak testować monitoring i utrzymywać go w czasie: czas systemowy, test alertów, backup konfiguracji?
• Co z bezpieczeństwem i prywatnością metryk i logów?
• Kiedy przejść z narzędzi lokalnych na centralną platformę i jak to zrobić bez bólu?

Krok 1: Doprecyzuj cel i zakres monitoringu

Wybierz decyzję, którą podejmiesz na podstawie metryk

Konkretne decyzje wymuszają konkretne metryki. Jeśli chcesz złapać chwilowe „przycięcia” UI na stacji roboczej, potrzebujesz 1–2 sekundowego wglądu w CPU per core, I/O wait, procesy i latency dysku. Jeśli celem jest wczesne ostrzeganie o degradacji usługi webowej, wystarczy 10–30 s dla CPU, pamięci, throughput i latencji HTTP (P90/P99), plus 5-minutowe agregaty do alertów SLO. Każdy cel przetestuj krótkim scenariuszem obciążenia i sprawdź, czy dashboard i alert działają, zanim pójdziesz dalej.

Kluczowe metryki na start bez dyskusji

• CPU: użycie per core, load average, steal (na VM), throttling (kontenery), run queue length.
• Pamięć: used/available, cache/buffers, page faults, swap in/out, OOM events.
• Dysk i I/O: iowait, util (% busy), read/write IOPS, throughput, avg queue size, latencja (r/s, w/s), fio testy punktowe.
• Procesy: top N wg CPU/Memory/I/O, liczba w stanie D (uninterruptible sleep), zombie.
• Sieć: throughput Rx/Tx, errors/drops, retransmisje TCP, latency do krytycznych endpointów, socket states.
• Aplikacje: metryki specyficzne (np. HTTP 5xx, P95 latency, queue depth, GC pause), ale dopiero gdy fundamenty systemowe są na miejscu.

Rozdzielczość i retencja: kompromis, który działa

Dla podglądu operacyjnego: 1–5 s. Dla alertów: 10–60 s i agregacje 5-minutowe. Dla historii: 7–30 dni w 10–60 s, starsze dane w downsamplingu 5–10 min. Unikaj 1 s scrapes na dziesiątkach hostów bez potrzeby – rośnie ruch, obciążenie i koszty przechowywania, a diagnostyka rzadko na tym zyskuje. W punktach krytycznych (np. storage) możesz tymczasowo zwiększać rozdzielczość do czasu znalezienia problemu.

Kryteria zakończenia kroku: masz spis 3–5 decyzji, dla każdej przypisaną listę metryk i interwały, oraz krótką notatkę, jak to przetestujesz. Ostrzeżenie: jeśli lista metryk przekracza jedną stronę, wróć i skróć – real-time monitoring nie zniesie nadmiaru.

Ogranicz zakres na poziomie nazw i etykiet. Zrób krótką mapę: które usługi są krytyczne, jakie mają zależności (np. API → DB → storage → sieć) i jakie wymiary metryk faktycznie pomagają (host, strefa, wersja aplikacji). Unikaj etykiet o wysokiej krotności (np. user_id, request_id) w metrykach czasu rzeczywistego — eksplodują koszty i spowalniają zapytania.

Krok 2: Dobierz narzędzia do skali i topologii

Mapowanie środowiska na wybór narzędzi

Wybierz najprostszy zestaw, który odpowiada Twojej skali i temu, gdzie zapadają decyzje.

• Pojedynczy host lub stacja robocza: htop/btop, iostat/iotop/atop, nload/iftop, journald/logtail; na Windows: Resource Monitor, PerfMon (z Data Collector Sets), Get-Counter; na macOS: Activity Monitor, powermetrics, iStat Menus. Opcjonalnie Netdata w trybie lokalnym.
• Kilka–kilkanaście hostów/VM: Prometheus + node_exporter/cadvisor lub Telegraf + InfluxDB; Grafana do widoków i alertów; lokacja centralna w tej samej sieci.
• Kubernetes/kontenery: kube-state-metrics, cAdvisor, node_exporter; eBPF do głębszej diagnostyki (bpftrace/BCC, parca/pyroscope do CPU Profiling); Pixie lub eBPF-based observability jako doraźne narzędzie, nie jako „zawsze włączone”.
• Środowisko rozproszone/wiele lokalizacji: federacja Prometheusa lub Grafana Agent + remote_write do centralnego TSDB; lokacje zbierają lokalnie wysoką rozdzielczość, do centrum płyną agregaty.

Widok na żywo + historia i alerty bez „dwóch światów”

Połącz lekki podgląd per host (np. btop/Netdata) z magazynem metryk (Prometheus/InfluxDB). Wysoka rozdzielczość zostaje lokalnie, do centrali trafia 10–60 s. Alerty buduj na danych z magazynu, nie z narzędzi interaktywnych — te służą do ręcznej inspekcji.

Kryteria zakończenia kroku: wybrane 1–2 narzędzia per warstwę (host, kontenery, aplikacje), jasny przepływ: skąd zbierasz, gdzie trzymasz, gdzie alertujesz. Ostrzeżenie: nie dubluj agentów robiących to samo (np. dwa eksportery dysku) — rośnie narzut i zamieszanie w etykietach.

Krok 3: Szybkie wdrożenie „D-1”: 30 minut do pierwszych alertów

Procedura minimalna

1. Zsynchronizuj czas (NTP/chrony/Timesyncd). Bez tego alerty i korelacja logów rozjadą się.
2. Zainstaluj agenta: na Linux node_exporter/Telegraf; na Windows PerfMon Data Collector + telegraf.exe; w k8s DaemonSety (node_exporter, cAdvisor).
3. Ustaw interwały: scrape 15 s (host), 30 s (aplikacje); 1–5 s tylko dla 1–2 krytycznych paneli lokalnych.
4. Włącz tylko potrzebne kolektory (CPU, mem, disk, net, processes). Wyłącz wysokokardynalne (np. mountstats na tysiącach PV) na start.
5. Dashboard „1-stronicowy”: CPU per core + run queue, pamięć (available, cache), dysk (util%, iowait, latency), sieć (errors/drops), top procesy.
6. Trzy alerty bazowe: CPU, pamięć, I/O. Zrób inhibicję duplikatów z hostów wtórnych (jeśli masz HA).
7. Test pod kontrolowanym obciążeniem: stress-ng (CPU/mem), fio (I/O), ping/iperf (sieć). Sprawdź, czy pojawiają się alerty i czy wykresy „opowiadają” historię.

Checklist wdrożeniowy:

• Ports/ACL: endpointy eksportera osiągalne z serwera zbierającego (lub odwrotnie przy push).
• Retencja TSDB: ustaw w dniach i w przestrzeni (limit dysku, downsampling).
• Opis hostów: etykiety environment, role, service — tylko to, co naprawdę filtrujesz.

Ostrzeżenie: jeśli podczas testu CPU agenta >3% na idle hoście lub czas odpowiedzi eksportera >200 ms, przykręć częstotliwość i wyłącz zbędne kolektory.

Krok 4: Progi i alerty, które nie budzą w nocy bez powodu

Reguły bazowe z warunkiem kontekstu

• CPU: średnie >85% przez 5 min ORAZ run_queue > liczba rdzeni w 3 z 5 próbek. Daje sygnał o kolejce, nie tylko „wysokim procencie”.
• Pamięć: available <10% przez 3 min ORAZ swapin/swapout > 0. Ignoruj chwilowe cache drops.
• I/O: util% >80% przez 5 min ORAZ iowait >20% ORAZ avg_queue >1. Mierz per dysk, nie tylko sumę.
• Sieć: interface drops/errors rosną o X/s przez 3 min ORAZ retrany TCP > bazowej linii trendu.
• HTTP/GRPC: P95 latency > SLO przez 5 min ORAZ wzrost 5xx > tła. Agreguj per usługę, nie per pod.

Dodaj tłumiki: okna ciszy podczas planowanych działań, reguły „inhibit” przy awarii upstream (np. storage → wycisz pochodne alerty aplikacyjne).

Test gotowości: celowo wywołaj każdy alert (krótkie testy obciążenia). Sprawdź eskalację, treść wiadomości (co, gdzie, jak potwierdzić) i linki do dashboardów.

Ostrzeżenie: nie używaj pojedynczych progów bez czasu trwania. „CPU>90%” w sekundach da wyłącznie szum.

Krok 5: Dashboard operacyjny „jednym rzutem oka”

Układ, który prowadzi do hipotezy

• Wiersz 1: status (zielony/żółty/czerwony) i trzy liczby: CPU avg/run queue, Mem available/pressure, Disk util%/lat P95.
• Wiersz 2: CPU per core + throttle (kontenery), memory timeline (RSS vs cache), swap activity.
• Wiersz 3: I/O per device (util%, r/w IOPS, lat r/w), queue depth.
• Wiersz 4: Sieć (Rx/Tx, errors/drops, retrany), connectivity do krytycznych endpointów (rtt, packet loss).
• Wiersz 5: Top procesy/kontenery (CPU/mem/I/O), link do logów i profilera.

Kryteria użyteczności: w 30 sekund jesteś w stanie stwierdzić: który zasób jest wąskim gardłem, kto go konsumuje i czy problem jest lokalny czy systemowy. Ostrzeżenie: nie rozbijaj na 10 dashboardów z pięcioma kliknięciami między nimi — operacyjny musi być jeden.

Krok 6: Minimalny narzut i kontrola kosztów

Praktyczne przykręcanie „gałek”

• Interwały: 15–30 s domyślnie; 1–5 s tylko tymczasowo i tylko lokalnie.
• Kolektory: wyłącz wysoką krotność (per-cgroup, per-mount, per-conntrack) jeśli nie analizujesz tego dziś.
• Etykiety: zrelabeluj/droppuj dynamiczne identyfikatory (pod UID, container_id pełny) — zostaw krótsze klucze.
• Retencja: 14–30 dni na 10–60 s, starsze downsample 5–10 min. Ustaw limit dysku TSDB i monitoring jego zużycia.
• remote_write: tylko agregaty i wybrane metryki; reszta lokalnie. Backoff i limit równoległych wysyłek.
• Profil CPU agenta: sprawdź raz w tygodniu (–log.level=debug, pprof). Jeśli >3–5% stałego CPU — optymalizuj.

Minitest: porównaj średnie zużycie CPU/IO przed i po włączeniu monitoringu. Wzrost >5% to sygnał do korekt.

Ostrzeżenie: nie włączaj wszystkich exporterów „bo są”. Zbieranie bez celu utrudnia diagnozę bardziej niż pomaga.

Krok 7: Szybka diagnostyka typowych symptomów

iowait rośnie, system „muli”

• Sprawdź: iowait, util% per dysk, queue depth, latencje r/w. Jeśli CPU idle rośnie razem z iowait — wąskie gardło to storage.
• Działanie: identyfikuj proces/kontener o najwyższym r/w; ogranicz concurrency, przenieś workload na szybki wolumen, tymczasowo zwiększ cache.

Throttling CPU w kontenerach

• Sprawdź: cgroup throttled time, quota/limit vs request, run queue na węźle.
• Działanie: podnieś limit lub zbalansuj pod’y; unikaj request=limit w horyzontalnie skalowanych usługach.

Memory leak lub presja pamięci

• Sprawdź: RSS procesu rośnie liniowo, spadek cache/buffers, wzrost page faults i swapin/out.
• Działanie: restart kontrolowany, limit pamięci na kontener, analiza alokacji (profiling/heap dump) poza godzinami szczytu.

Drops i błędy w sieci

• Sprawdź: errors/drops per interfejs, retrany TCP, saturację łącza, zmiany w MTU/VLAN.

Naprawa: dropsy i błędy w sieci — szybkie działania

• Działanie: zacznij od końcówek — sprawdź błędy FCS i CRC na interfejsach, podmień patchcord lub port switcha. Częściej winna jest warstwa fizyczna niż stos TCP.
• Sprawdź MTU end‑to‑end (np. po wejściu tunelu/VPN). Jeśli PMTU discovery nie działa, ustaw spójne MTU lub włącz clamp MSS na brzegu.
• Jeśli kolejki są pełne (qdisc), włącz fair queue lub Cake na brzegu łącza i ogranicz bursty na egress (policer/shaper).
• Wzmożone retrany TCP? Zmniejsz concurrency na kliencie/serwerze, włącz nagrzewanie połączeń (HTTP/2 keepalive), zredukuj Nagle/Delayed ACK tylko gdy rozumiesz skutki.
• Jeśli zrywa po TLS, sprawdź rotację certyfikatów i zegar; dryf czasu powoduje błędy handshake, które wyglądają jak „sieć się sypie”.

Minitest: iperf3 w obu kierunkach (z i bez TLS tunelu), ping z DF bit i rosnącym payloadem (mturoute). Spadek strat poniżej 0,1% i stabilne RTT oznaczają poprawę.

Ostrzeżenie: nie próbuj leczyć strat zwiększaniem timeoutów w aplikacji w ciemno — ukryjesz problem i wydłużysz czas awarii.

Skoki opóźnień bez utraty pakietów

• Sprawdź: RTT do sąsiadujących hopów, jitter, obciążenie CPU na brzegowych hostach, GC/stop‑the‑world w usługach, kolejki w LB.
• Działanie: ogranicz bursty (rate limit na klientach), włącz adaptive concurrency (np. w Envoy), rozbij długie requesty na mniejsze porcje, przerzuć seryjną pracę na kolejki asynchroniczne.
• Kryterium poprawy: P95 latency wraca w 2–3 okna wygładzania do linii bazowej po zdjęciu obciążenia.

Krok 8: Bezpieczeństwo i prywatność metryk oraz logów

Transport i dostęp

• Eksporter nasłuchuje na localhost; scraper łączy się przez agent sidecar lub przez reverse proxy z mTLS (np. Grafana Agent, Envoy). Bez gołego HTTP w sieci wspólnej.
• mTLS między agentami a TSDB/alertmanagerem; rotacja certyfikatów automatycznie (ACME/step-ca). Wyłącz TLS 1.0/1.1, wymuś nowoczesne szyfry.
• RBAC w UI: role „view”, „edit”, „admin” z podziałem na foldery/działy. Edycja dashboardów tylko z kont zespołowych, nie osobistych.

Dane wrażliwe

• Redakcja w źródle: maskuj PII w logach (regex/processor w agentach), nie wysyłaj payloadów żądań jako metryk (tylko agregaty).
• Ogranicz etykiety: usuń user_id, session_id, pełne ścieżki; jeśli potrzebny kontekst, hashuj i utrzymuj słownik poza TSDB.
• Retencja: krócej dla logów aplikacyjnych (np. 7–14 dni), dłużej dla metryk zagregowanych. Szyfruj dyski TSDB (dm-crypt/BitLocker/FileVault) oraz backupy.

Kryteria zgodności: ekspozycje tylko po TLS, audyt dostępu włączony, brak PII w 100 losowych próbkach logów/metryk, polityka retencji udokumentowana.

Ostrzeżenie: single shared token w agentach = jednokrotne włamanie, pełny dostęp. Użyj krótkich, per‑agentowych creds z rotacją.

Krok 9: Testy ciągłe i utrzymanie bez zaskoczeń

Higiena czasu i zdrowia łańcucha

• NTP/chrony health: alert na drift >100 ms i brak peerów. Raz w tygodniu porównaj czas z zewnętrznym źródłem.
• Test alertów syntetycznych: co godzinę generuj kontrolowany event (np. blackbox HTTP 599 na dedykowanym endpointcie) i sprawdzaj, czy dotarł do kanału on‑call.
• Watchdog: stały alert „I’m alive” tłumiony w normalnym stanie. Jego brak = problem z pipeline/Alertmanagerem.

Konfiguracja pod kontrolą

• GitOps: reguły alertów, scrape jobs, dashboardy jako kod; PR = przegląd przez drugą osobę; tagi wersji na release.
• Backup: snapshot TSDB (lub eksport reguł/konfiguracji) codziennie, test odtwarzania co miesiąc. Trzy kopie, dwie różne nośniki, jedna offline.
• Drift detection: porównuj aktualne configi agentów z repo (sha256), alert na odchył.

Checklist miesięczny: test 3 głównych alertów, rotacja tokenów/certyfikatów, przegląd etykiet wysokiej krotności, weryfikacja retencji i zajętości dysku TSDB.

Ostrzeżenie: dashboard bez właściciela gnije. Każdy folder musi mieć maintainerów i datę przeglądu.

Krok 10: Przejście na platformę centralną — kiedy i jak

Sygnały, że pora na centralizację

• Więcej niż 20–30 hostów lub kilka lokalizacji; korelacja problemów między usługami jest trudna w narzędziach lokalnych.
• Potrzeba SSO, podziału ról, dzielenia dashboardów między zespołami i jednego źródła prawdy dla alertów.
• Chęć łączenia metryk z logami/trace’ami i długiej retencji zagregowanej.

Plan migracji bez bólu

• Inwentarz: lista metryk i etykiet, które realnie są używane w dashboardach/alertach. Resztę wygaszaj.
• Taksonomia etykiet: ujednolić environment, service, instance, region. Zrób mapę relabeling przed remote_write.
• Topologia: lokacje zbierają w wysokiej rozdzielczości, do centrali idą agregaty i reguły alertów. Ustal retencję per poziom.
• Cutover: najpierw sklonuj dashboardy i reguły w nowej platformie, włącz podwójne alertowanie na 48 h, porównaj trafność i objętość szumu, dopiero potem wyłącz stare.

Kryteria sukcesu: ten sam incydent widoczny w jednym miejscu z linkami do logów/trace’ów, redukcja liczby agentów o duplikującej funkcji, brak wzrostu kosztu >10% względem lokalnych instalacji przy tej samej retencji.

Ostrzeżenie: nie migruj „as‑is”. Bez porządków w etykietach i retencji centralny klaster „zapchasz” w tydzień.

Krok 11: Lista kontrolna „przed wdrożeniem na produkcję”

• Cel i zakres: zdefiniowane 3–5 pytań operacyjnych, na które dashboard odpowiada w 30 s.
• Agenci: uruchomieni z minimalnym zestawem kolektorów; CPU agenta <3%, czas scrape <200 ms.
• Interwały i retencja: 15–30 s dla hostów, 30–60 s dla aplikacji; retencja i downsampling ustawione.
• Alerty: mają warunek czasu i kontekstu, test syntetyczny przechodzą, eskalacja działa.
• Bezpieczeństwo: TLS/mTLS, RBAC, brak PII w próbkach, backup i rotacja sekretów działają.
• Runbooki: link w treści alertu do kroku „co sprawdzić” i do konkretnego dashboardu.
• Koszt i narzut: porównanie przed/po; wzrost zasobów monitoringu ≤5%; limit dysku TSDB włączony.

Najczęstszy błąd na końcu: włączenie „wszystkiego” i brak właściciela zestawu metryk. Zatrzymaj się na potrzebach operacyjnych dziś, resztę dołóż po pierwszym tygodniu realnych obserwacji.

Krok 12: Szybki start lokalny — minimalny zestaw narzędzi per OS

Linux — 5‑minutowy setup diagnostyczny

• Instalacja podstaw: htop, sysstat (iostat, sar, pidstat), iproute2, procps, smartmontools; opcjonalnie bcc/bpftrace na jądrach z BPF.
• Sekwencja 60 s na żywo:
  • CPU/kolejki: top lub htop; vmstat 1 (kolumny r, b, wa); pidstat -u 1 (winowajcy CPU).
  • I/O: iostat -xz 1 (await, svctm, util); smartctl -H /dev/sdX (stan dysku).
  • Pamięć: free -h; vmstat 1 (si/so); grep -i oom /var/log/* lub dmesg -T.
  • Sieć: ss -s; sar -n DEV 1 5; ethtool -S eth0 (błędy/drops jeśli dostępne).
• Exportery „na start”: node_exporter (z wyłączonymi kolektorami wysokiej krotności: processes, systemd jeśli niepotrzebne), optional: process-exporter do top‑N procesów.

Kryterium gotowości: potrafisz wskazać 1) proces z najwyższym CPU, 2) czy wąskie gardło to storage (wysokie await/util), 3) czy pamięć jest pod presją (swapin/out, OOM).

Minitest: odpal stress-ng na 1 rdzeniu na 60 s i potwierdź w pidstat/top, że CPU rośnie i wraca do normy po zakończeniu.

Ostrzeżenie: bpftrace/perf zostaw na krótkie okna diagnostyczne; długie sesje potrafią dodać zauważalny narzut na jądrze.

Windows — szybkie metryki bez instalacji ciężkich agentów

• Na żywo: Resource Monitor (CPU, Disk, Network) i Performance Monitor (PerfMon) z podstawowymi licznikami:
  • Processor(_Total)% Processor Time, SystemProcessor Queue Length.
  • MemoryAvailable MBytes, MemoryPages/sec.
  • PhysicalDiskAvg. Disk sec/Read|Write, Disk Queue Length.
  • Network InterfaceBytes Total/sec, TCPv4Connections Established.
• PowerShell do szybkich próbek: Get-Counter z interwałem 1 s dla kilku liczników (10–20 próbek) — bez odpalania długich sesji logujących.
• Eksporter: windows_exporter (Prometheus). Na start wyłącz procesy WMI o wysokim koszcie i kolektory per‑proces, włączysz je selektywnie później.

Kryterium gotowości: wiesz, jak odczytać średnie opóźnienie dysku (Avg. Disk sec/*), kolejkę procesora i szybki spadek Available MBytes przy memory leak.

Ostrzeżenie: długotrwałe sesje ETW i zbyt szerokie kolekcje WMI potrafią podbić CPU — ogranicz zakres i czas.

macOS — wbudowane podglądy bez „przegrzania” laptopa

• Na żywo: Activity Monitor (CPU, Memory, Energy), top -l 0 -stats pid,cpu,mem,command; iostat -w 1; nettop -m route.
• Termika i throttling: powermetrics (sudo) dla pakietów CPU/GPU; log stream –predicate 'eventMessage CONTAINS „Thermal”’ do szybkiego wykrycia zbijania taktowania.
• Lekki eksport: glances lokalnie lub prosty telegraf z minimalnym zestawem inputów; nie wystawiaj portów na zewnątrz.

Kryterium gotowości: potrafisz sprawdzić, czy spadki wydajności biorą się z throttlingu (temperatury) czy z I/O (iostat opóźnienia).

Ostrzeżenie: powermetrics i intensywne próbkowanie skracają czas pracy na baterii — uruchamiaj tylko podczas diagnozy.

Krok 13: Widok „na żywo” połączony z historią i alertami

• Rozdzielczość: dla hostów ustaw scrape 15–30 s; dla aplikacji 30–60 s. Dla „trybu incydentu” przygotuj profile tymczasowe 5–10 s dla wybranych celów (feature‑flag/parametr).
• Historia: włącz reguły recordingu dla metryk kosztownych i histogramów (np. p95/p99 latency per service) — dashboard korzysta z agregatów, a nie surowych szeregów.
• Alerty: każdy warunek ma okno „for” i kontekst (tag service/env, link do runbooka). Dodaj alert „absent” dla krytycznych metryk (brak danych to też awaria).
• Anotacje: automatycznie zapisuj zdarzenia typu deploy/feature‑flag/awaria zależności, żeby korelować skoki opóźnień.
• Łączenie z trace’ami/logami: włącz exemplars w histogramach opóźnień i linkowanie do logów z tym samym trace_id (bez dorzucania user_id do metryk).

Krok 14: Błyskawiczna diagnoza typowych symptomów (na żywo)

Gdy coś „muli”, przejdź sekwencję objaw → szybkie metryki → decyzja. Krótko, bez zgadywania.

• Wysokie iowait (storage wąskie gardło):
  • Linux: iostat -xz 1 (await, r/s, w/s, %util), vmstat 1 (wa); Prometheus: node_disk_io_time_seconds_total rate 1m, node_disk_read/write_time_seconds_total rate 1m.
  • Sygnatura: %util > 80% przez ≥1 min, await rośnie kilkukrotnie, rośnie r lub w kolejce.
  • Działanie: sprawdź procesy robiące I/O (pidstat -d 1); ogranicz backupy/skany AV; przenieś katalogi tymczasowe na szybszy wolumen.
  • Kryterium potwierdzenia: po zdjęciu obciążenia await i %util wracają do poziomu bazowego.
• Throttling CPU (host lub kontenery):
  • Linux: mpstat 1 (steal), dmesg „throttle”, powermetrics (macOS) – termika; K8s/containers: container_cpu_cfs_throttled_seconds_total rate 1m, container_spec_cpu_quota vs usage.
  • Sygnatura: throttle ratio > 0.2 przez ≥2 min lub steal > 5% na VM; temperatury wysokie i zbijanie taktowania.
  • Działanie: zwiększ CPU limit/zmień QoS w K8s; obniż limity turbo/odłącz zbędny autoscaling batch; sprawdź przypięcie CPU (numa/irqbalance).
  • Ostrzeżenie: podnoszenie request/limit bez profilowania tylko przesuwa problem.
• Memory leak / presja pamięci:
  • Linux: vmstat 1 (si/so), free -h, dmesg „OOM”; Prometheus: node_memory_MemAvailable_bytes, container_memory_working_set_bytes, oom_kills_total.
  • Sygnatura: spadek MemAvailable w czasie bez powrotu, rosnący working_set procesu/poda, sporadyczne OOMKill/RestartCount.
  • Działanie: zrzut heap (jeśli aplikacja wspiera), restart z limitem memory i limitem p95; włącz liveness tylko po naprawie przyczyny.
  • Kryterium potwierdzenia: po restarcie trend working_set jest płaski, brak OOM przez 24 h.
• Dropy/opóźnienia w sieci:
  • Linux: sar -n DEV 1 5, ethtool -S, ss -s; Prometheus: node_network_receive/transmit_drop_total rate 1m, TCP retransmissions (node_netstat_Tcp_RetransSegs).
  • Sygnatura: wzrost drops/retrans, rosnące RTT w blackbox_exporter, wzrost SYN backlog.
  • Działanie: sprawdź MTU/mis-match, QoS/policing na brzegu, saturację łącza (Bytes/sec ~ link rate).
  • Ostrzeżenie: TLS handshake błędy potrafią maskować problem z retransmisją – koreluj oba.
• GC/latencje aplikacji (JVM/Go/.NET):
  • JVM: jvm_gc_pause_seconds_sum/count rate, heap_used vs max; Go: go_gc_duration_seconds_bucket, go_goroutines; .NET: dotnet_collection_count_total.
  • Sygnatura: skoki p99 latencji w tym samym oknie co długie pauzy GC lub wzrost goroutines bez spadku.
  • Działanie: tuning rozmiaru heap/GC, ograniczenie alokacji w hot path, zwiększenie concurrency workerów ostrożnie.

Mini‑checklista: 1) Czy bottleneck jest w zasobie (CPU/Mem/IO/Net), czy w samej aplikacji (GC/locki)? 2) Czy symptom występuje równolegle na kilku hostach (sieć/zasób wspólny), czy pojedynczo (lokalny)? 3) Czy są anotacje deploy/feature w tym samym czasie?

Krok 15: Ochrona metryk i logów – bezpieczny pipeline

Załóż, że metryki też mogą zawierać dane wrażliwe. Zabezpiecz transport, dostęp i treść.

• Transport i tożsamość:
  • TLS/mTLS między agentem a scraperem oraz remote_write; krótka rotacja certyfikatów (≤90 dni).
  • Network: allowlista egress do endpointów monitoringu; brak otwartych portów z eksportera na internet.
• Dostęp i uprawnienia:
  • RBAC per folder/namespace; osobne role do odczytu dashboardów i do edycji reguł.
  • SSO z MFA; tokeny krótkotrwałe, audyt logowań i zmian konfiguracji.
• Treść i prywatność:
  • Drop PII na krawędzi: write_relabel_configs usuwa labelki typu user, email, session, ip_private (jeśli niepotrzebne); hashuj identyfikatory gdy musisz korelować.
  • Sampling logów na brzegu i redakcja wzorców (np. numery kart, tokeny) – testuj na danych syntetycznych.
• Składowanie:
  • Szyfrowanie at rest (dyski/obiekty); osobne retention dla metryk o wysokiej wrażliwości.
  • Backup z szyfrowaniem i kontrolą dostępu; test odtworzenia cyklicznie.

Kryteria sprawdzenia: port skrapera nieosiągalny spoza zaufnej sieci; każdy dashboard ma przypisaną grupę ról; test „sekret w logu” jest wycinany; rotacja certyfikatów nie przerywa przepływu danych.

Ostrzeżenie: eksportery aplikacyjne często dorzucają wysokokardynalne tagi (np. userId). Zatrzymaj to na poziomie kodu lub relabel – inaczej zniszczysz wydajność TSDB i naruszysz prywatność.

Krok 16: Użyteczne dashboardy i progi – układ, który prowadzi do decyzji

Jeden ekran powinien odpowiedzieć w 30 sekund: działa czy nie, gdzie boli i co dalej sprawdzić.

• Układ ekranu serwisu:
  • Rząd 1: SLO/SLA – p95/p99 latency, error rate, QPS; adnotacje deploy.
  • Rząd 2: Saturacja zasobów – CPU usage/limit, memory working_set/limit, I/O util/await, network throughput/drops.
  • Rząd 3: Backpressure – kolejki, liczba wątków/goroutines, connection pool usage.
  • Rząd 4: Top‑N – endpointy/pod/host; linki do logów/trace’ów (trace_id).
• Jednostki i skale:
  • Stosuj te same jednostki na całym ekranie (ms, req/s, %). Histogramy – percentyle, nie średnie.
  • Ogranicz panele do 12–16 na ekran; reszta w zakładkach „diagnoza”.
• Progi alarmowe – punkty startowe (koryguj po 1–2 tygodniach):
  • CPU: sustained > 90% przez 5 min lub throttle ratio > 0.2 przez 2 min; steal > 5% na VM.
  • Pamięć: MemAvailable 0.9 przez 3 min; pojedynczy OOM = natychmiastowy alert.
  • Storage: %util > 80% i p99 await > 2× baseline przez 5 min.
  • Sieć: retrans rate > 1% przez 3 min; jakiekolwiek drops > 0 rosnące przez 5 min.
  • HTTP: error rate > 2× baseline przez 2 min, p99 > SLO przez 5 min.
• Higiena etykiet:
  • Wymuszaj environment, service, instance, region; unikaj free‑text w labelach.
  • Top‑N licz p95 po service, nie po pod UID – mniej szumu, więcej sensu.

Kryteria sprawdzenia: nowa osoba z on‑call wskazuje w 30 s, czy problem jest w aplikacji czy w zasobie; kliknięcie w panel prowadzi do konkretnego log/trace; panele ładują się <2 s dzięki record rules.

Ostrzeżenie: dashboard z 50 panelami bez kontekstu to brak dashboardu. Odetnij „ładne, ale nieużywane” na podstawie realnych sesji on‑call.

Aby s