Monitoring serveru

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í tak, aby bylo možné průběžně řídit kapacitu, plnit SLO/SLA, předcházet incidentům a urychlit 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 latence 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í po jádrech, steal time (na hypervizoru/cloudu), run queue, kontextové přepínání, 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í read/write, TRIM/GC u SSD, SMART stav a chybovost.
• Souborový systém – zaplnění, inode usage, fragmentace, zámky, latence metadatových operací.
• Síť – propustnost, paketová ztrátovost, retransmise, latence, saturace bufferů, přetečení front a IRQ/softirq zatížení.
• Procesy a služby – CPU time, 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čí CPU-bound. V diskové vrstvě sledujte latenci při stoupající hloubce fronty – nelineární nárůst latence indikuje přetížení. V síti je varovným signálem 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 latenci a ztrátovost.
• eBPF observabilita – bcc/bpftrace skripty (runqlat, biolatency, tcplife, offcputime) pro detailní latence a profily bez zásahu do aplikace.
• Jádro a plánovač – procfs/sysfs metriky, audit throttlingu a IRQ affinity (NUMA, irqbalance).

Windows Server: monitorovací přehled

• Performance Monitor (PerfMon) – čítače CPU (% Processor Time), paměť (Available MBytes, Pages/sec), disk (Avg. Disk sec/Read/Write), síť (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í trace.

Virtualizace a cloud: specifika interpretace

• Hypervizor/Cloud CPU – sledujte steal time a overcommit hostitele; vysoké hodnoty znamenají soutěž o CPU s jinými tenanty.
• Virtuální disk – sdílené datové pole může maskovat latence; porovnávejte host-level a guest-level metriky.
• Síť – tunneling/encapsulation (VXLAN/GRE) přidává overhead; měřte MTU a offload funkce NIC.

Kontejnery a cgroups

V prostředích Docker/Kubernetes sledujte limity a throttle cgroups (CPU quota/period, memory limit, OOM kills), pod restart policy, readiness/liveness proby a evictions. Metriky agregujte po namespace, deployment 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, throughput.
• Nasycení – run queue, disková fronta, využití socketů, zaplnění connection poolů.

SLI operacionalizujte jako přesnou metriku (např. „p95 latence < 200 ms za 5min okno“) a z ní odvoďte SLO a chybový rozpočet.

Telemetrický stack: metriky, logy, trace

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

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

• Pravidla – kombinujte absolutní prahy (např. disk p95 latence) s odchylkami od baseline (anomaly detection).
• Hystereze a trvání – omezte flapping: upozorňujte po trvání stavu (např. 5 minut nad prahem).
• Škálování závažnosti – page jen to, co vyžaduje okamžitou reakci; ostatní jako ticket/report.
• Runbooky – každý alert musí mít krokový postup, kontakty a zpětnou vazbu pro ladění pravidla.

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

Pro predikci potřeb kombinujte sezónnost, release kalendář a marketingové akce. Základ tvoří trend metrik (CPU busy, disk p95, síť p95) a jejich korelace s byznys metrikami. Vysokou predikční hodnotu mají leading indicators, např. počet aktivních session vs. budoucí latence.

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í obslužné doby (optimalizace I/O, cache) snižuje frontu i latenci.

Benchmarking, syntetika a baseline

• Syntetické testy – periodické HTTP/DNS/DB testy mimo reálný provoz odhalí degradace dříve, než se projeví u uživatelů.
• Benchmarky – fio, iperf, sysbench pro ověření výkonových charakteristik HW/VM.
• Baseline – historické profily metrik (per hodina/den/týden) pro detekci anomálií a kapacitní projekce.

Profily, sampling a náklad telemetrie

Profilování CPU (např. přes eBPF/pprof) a alokací paměti přináší hluboký vhled, ale s režijní cenou. Používejte sampling a cílené doby sběru. Metriky agregujte, logy limitujte (rate-limit, drop nevýznamných událostí), trace ukládejte selektivně (tail-based sampling).

Bezpečnost a integrita monitoringu

• Oddělení roli – read-only přístup pro provoz, write pro administrátory systému monitoringu.
• Integrita – podepsané agenty, TLS šifrování, autentizace exportérů, oddělené síťové segmenty.
• Dostupnost – HA topologie (replikace TSDB, federace), zálohy konfigurací a dashboardů.

Příklady praktických dashboardů

• CPU panel – celkové a per-core využití, run queue, ctxt/s, steal time, p95 load; korelace s aplikačním throughputem.
• Paměťový panel – RAM vs. cache, major/minor faults, swap in/out, OOM count; NUMA locality a slab miss rate.
• Disk I/O panel – p50/p95/p99 latence, IOPS, queue depth, split IO, SMART varování.
• Network panel – Rx/Tx, dropped/err, retransmise, RTT, saturace front na NIC, IRQ load.
• Process/Service – top N procesů dle CPU/RSS/I/O, restart count, exit codes, cgroups throttling.

Typické anti-patterny a jak se jim vyhnout

• Monitoring bez cílů – definujte SLI/SLO dříve než grafy; jinak skončíte metrickým „sběratelstvím“.
• Alerty na průměry – používejte percentily a saturaci; vyhnete se slepým místům.
• Jedna metrika k rozhodnutí – vždy korigujte pohled (CPU vs. run queue, IOPS vs. latence, síť vs. retransmise).
• Bez runbooků – každý alert bez postupu prodlužuje MTTR.

Integrace s provozními procesy

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

Checklist minimálních opatření

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

Závěr

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