Monitorování výkonu a vytížení serveru: odhalování problémů

Servery, operační systémy a správa IT
P. Varga
Monitorování výkonu a vytížení serveru: Detekce problémů

Cíle monitorování

Monitorování výkonu a vytížení serveru je systematický proces sběru, korelace a vyhodnocování metrik, logů a trasování, který umožňuje průběžně řídit kapacitu, plnit SLO/SLA, předcházet incidentům a urychlovat jejich řešení. Správně navržený monitoring poskytuje nejen telemetrii, ale i akční vhled – tedy informace, které přímo vedou ke konkrétním zásahům nebo úpravám konfigurace.

Klíčové metodiky: USE a RED

  • USE (Utilization, Saturation, Errors) – aplikujte na každý zdroj (CPU, paměť, disk, síť): sledujte využití, známky zahlcení (fronty, čekání) a chybovost.
  • RED (Rate, Errors, Duration) – pro aplikační endpointy a služby: rychlost požadavků, počet chyb a latenci obsluhy.

Kombinací obou metodik získáte vyvážený pohled na infrastrukturu i aplikace a předejdete „metrické slepotě“.

Základní metriky serveru

  • CPU – využití jednotlivých jader, steal time (na hypervizoru/cloudu), run queue, přepínání kontextu, frekvence, teplota a throttling.
  • Paměť – využití RAM, page cache, slab/slub, page faults, swap in/out, NUMA locality a transparentní hugepages.
  • Úložiště – IOPS, propustnost, latence (p50/p95/p99), hloubka fronty, rozlišení čtení/zápisu, TRIM/GC u SSD, stav SMART a chybovost.
  • Souborový systém – zaplnění, využití inode, fragmentace, zámky, latence operací s metadaty.
  • Síť – propustnost, ztrátovost paketů, retransmise, latence, saturace bufferů, přetečení front a zatížení IRQ/softirq.
  • Procesy a služby – čas CPU, RSS, otevřené deskriptory, vlákna, throttling cgroups, chybové návratové kódy.
  • Napájení a termika – teploty CPU/GPU, power cap, ventilátory; důležité pro stabilitu a výkon serveru pod zátěží.

Interpretace a úzká hrdla

Úzké hrdlo identifikujte podle saturace a front: vysoké využití CPU bez fronty může být v pořádku, ale dlouhá run queue značí omezení výkonu procesorem. V diskové vrstvě sledujte latenci při rostoucí hloubce fronty – nelineární nárůst latence signalizuje přetížení. V síti je varovným signálem nárůst retransmisí a bufferbloatu.

Linux: systémové zdroje a nástroje

  • Okamžitý přehled – top, htop, uptime, vmstat, iostat, mpstat, free, sar.
  • Disky a FS – lsblk, blkid, smartctl, iostat -x, fio pro syntetické testy, df -i, mountstats.
  • Síť – ss, ethtool, nstat, tc, ip -s, mtr a ping pro měření latence a ztrátovosti.
  • Observabilita eBPF – skripty bcc/bpftrace (runqlat, biolatency, tcplife, offcputime) pro detailní měření latencí a profilů bez zásahu do aplikace.
  • Jádro a plánovač – metriky procfs/sysfs, audit throttlingu a IRQ affinity (NUMA, irqbalance).

Windows Server: monitorovací přehled

  • Performance Monitor (PerfMon) – čítače CPU (% Processor Time), paměti (Available MBytes, Pages/sec), disku (Avg. Disk sec/Read/Write), sítě (Bytes Total/sec).
  • Resource Monitor – korelace procesů s využitím zdrojů, čekání na I/O.
  • Windows Event Log a ETW – korelace incidentů, WPA/WPR pro detailní trasování.

Virtualizace a cloud: specifika interpretace

  • CPU hypervizoru/cloudu – sledujte steal time a overcommit hostitele; vysoké hodnoty znamenají, že o CPU soupeříte s jinými tenanty.
  • Virtuální disk – sdílené datové úložiště může maskovat latence; porovnávejte metriky na úrovni hostitele a virtuálního počítače.
  • Síť – tunelování/enkapsulace (VXLAN/GRE) přidává režii; měřte MTU a funkce offload síťové karty.

Kontejnery a cgroups

V prostředích Docker/Kubernetes sledujte limity a throttling cgroups (CPU quota/period, memory limit, OOM kills), zásady restartování podů, readiness/liveness sondy a evictions. Metriky agregujte podle namespace, deploymentu i node, jinak snadno přehlédnete lokální saturaci uzlu.

Golden Signals a SLI/SLO

  • Dostupnost – chybovost endpointů, úspěšnost health-checků.
  • Latence – percentily p50/p95/p99; aritmetický průměr je zavádějící.
  • Propustnost – požadavky/s, IOPS, průchodnost.
  • Nasycení – run queue, disková fronta, využití socketů, zaplnění connection poolů.

SLI operacionalizujte jako přesnou metriku (např. „latence p95 < 200 ms v pětiminutovém okně“) a na jejím základě stanovte SLO a chybový rozpočet.

Telemetrický stack: metriky, logy, trasování

  • Metriky – časové řady s nízkou datovou náročností (Prometheus/OpenMetrics, Influx). Vhodné pro alerting a sledování kapacitních trendů.
  • Logy – strukturované (JSON) s korelačními ID; pipeline (Fluent Bit/Vector) → úložiště (ELK/OpenSearch).
  • Trasování – distribuované trasování (OpenTelemetry) pro analýzu latencí mezi službami.

Alerting: od šumu k užitečným notifikacím

  • Pravidla – kombinujte absolutní prahové hodnoty (např. latence disku p95) s odchylkami od baseline (detekce anomálií).
  • Hystereze a trvání – omezte flapping: upozorňujte až po určité době trvání stavu (např. 5 minut nad prahem).
  • Stupňování závažnosti – page použijte jen u toho, co vyžaduje okamžitou reakci; ostatní řešte jako ticket/report.
  • Runbooky – každý alert musí mít postup krok za krokem, kontakty a zpětnou vazbu pro ladění pravidla.

Kapacitní plánování a modelování

Při předpovídání potřeb kombinujte sezónnost, kalendář vydání a marketingové akce. Základ tvoří trendy metrik (CPU busy, disk p95, síť p95) a jejich korelace s obchodními metrikami. Vysokou predikční hodnotu mají leading indicators, například počet aktivních relací ve vztahu k budoucí latenci.

Littleův zákon a fronty

Littleův zákon (L = λ × W) pomáhá interpretovat čekací doby: při dané rychlosti příchodu požadavků λ roste průměrný počet požadavků ve frontě L lineárně s průměrnou čekací dobou W. Prakticky: zkrácení doby obsluhy (optimalizací I/O nebo využití cache) snižuje délku fronty i latenci.

Benchmarking, syntetické testy a baseline

  • Syntetické testy – pravidelné testy HTTP/DNS/DB mimo skutečný provoz odhalí zhoršení výkonu dříve, než se projeví u uživatelů.
  • Benchmarky – fio, iperf, sysbench pro ověření výkonnostních charakteristik HW/VM.
  • Baseline – historické profily metrik (po hodinách/dnech/týdnech) pro detekci anomálií a kapacitní projekce.

Profily, sampling a náklady na telemetrii

Profilování CPU (např. pomocí eBPF/pprof) a alokací paměti poskytuje hluboký vhled, ale je spojeno s režijními náklady. Používejte sampling a cíleně vymezené doby sběru. Metriky agregujte, logy omezujte (rate-limit, zahazujte nevýznamné události), trasování ukládejte selektivně (tail-based sampling).

Bezpečnost a integrita monitoringu

  • Oddělení rolí – přístup pouze pro čtení pro provoz, oprávnění k zápisu pro správce monitorovacího systému.
  • Integrita – podepsaní agenti, šifrování TLS, autentizace exportérů, oddělené síťové segmenty.
  • Dostupnost – topologie HA (replikace TSDB, federace), zálohy konfigurací a dashboardů.

Příklady praktických dashboardů

  • Panel CPU – celkové a využití jednotlivých jader, run queue, ctxt/s, steal time, load p95; korelace s aplikační propustností.
  • Panel paměti – RAM vs. cache, major/minor faults, swap in/out, počet OOM; NUMA locality a slab miss rate.
  • Panel diskového I/O – latence p50/p95/p99, IOPS, hloubka fronty, split IO, varování SMART.
  • Síťový panel – Rx/Tx, dropped/err, retransmise, RTT, saturace front na NIC, zatížení IRQ.
  • Procesy/služby – prvních N procesů podle CPU/RSS/I/O, počet restartů, exit codes, throttling cgroups.

Typické anti-patterny a jak se jim vyhnout

  • Monitoring bez cílů – definujte SLI/SLO dříve než grafy; jinak skončíte u metrického „sběratelství“.
  • Alerty založené na průměrech – používejte percentily a saturaci; vyhnete se slepým místům.
  • Rozhodování podle jediné metriky – vždy svůj pohled ověřte i dalšími ukazateli (CPU vs. run queue, IOPS vs. latence, síť vs. retransmise).
  • Chybějící runbooky – každý alert bez postupu prodlužuje MTTR.

Integrace s provozními procesy

Monitoring musí průběžně odrážet změny: pipeline CI/CD generuje a verzově spravuje konfigurace alertů a dashboardů, ChatOps přináší kontext přímo do komunikačních kanálů a analýzy post-mortem vracejí poznatky zpět do pravidel a kapacitních plánů.

Checklist minimálních opatření

  • Nasadit metriky, logy a trasování s jednotnou korelační identitou.
  • Definovat SLI/SLO a chybový rozpočet pro klíčové služby.
  • Nastavit alerty na latenci p95/p99, saturaci front a chybovost.
  • Zajistit HA a zálohování telemetrického stacku, včetně testu obnovy.
  • Zavést runbooky a pravidelná cvičení game-day cvičení.
  • Provádět kapacitní projekce a pravidelné hodnocení výkonu.

Závěr

Monitorování výkonu a vytížení serveru je disciplína, která propojuje měření, statistiku, architekturu i procesní řízení. Díky metodikám USE/RED, kvalitní telemetrii a promyšlenému alertingu lze data přetavit v rozhodnutí, která zvyšují spolehlivost, zkracují MTTR a optimalizují náklady na infrastrukturu. Klíčové je průběžné ladění – s rostoucí složitostí systémů roste i význam měřitelných cílů a automatizace.