Monitoring a škálování kontejnerových aplikací: metriky

Kontejnerizace (Docker, Kubernetes)
P. Varga
Monitoring a škálování kontejnerových aplikací: Metriky

Proč monitorovat a škálovat kontejnerové aplikace

Kontejnerizace (Docker) a orchestrace (Kubernetes) zásadně zrychlily dodávání softwaru, ale současně zvýšily komplexitu provozu. Úspěšný běh aplikací v kontejnerech vyžaduje disciplinovanou observabilitu (metriky, logy, trasy, události) a promyšlené škálování (horizontální/vertikální i na úrovni clusteru). Cílem je dosáhnout předvídatelné latence, nízké chybovosti, efektivního využití zdrojů a automatické reakce na změny zátěže při zachování nákladové efektivity a spolehlivosti.

Pilíře observability: metriky, logy, trasování a události

  • Metriky: číselné časové řady pro SLI (latence, chybovost, propustnost, saturace). Standardem je Prometheus/OpenMetrics.
  • Logy: podrobná diagnostika, audit a forenzní data. Sběr přes Fluent Bit/Vector → úložiště (Loki/Elastic/Cloud Logging).
  • Trasy: distribuované trasování (OpenTelemetry → Jaeger/Tempo/DataDog) pro pochopení závislostí služeb a latencí.
  • Události: události Kubernetes (evikce, restart), vlastní doménové události, upozornění CI/CD.

Referenční architektura monitoringu v Kubernetes

  • cAdvisor a kubelet poskytují základní metriky kontejnerů a podů (CPU, paměť, I/O).
  • Prometheus stahuje metriky z exportérů (node-exporter, kube-state-metrics, aplikační metriky) a ukládá je do TSDB.
  • Grafana vizualizuje SLI, SLO a umožňuje vytvářet dashboardy pro týmy (služby, infrastruktura, DB, síť, mesh).
  • Loki s promyšlenou retencí pro logy, TEMPO/Jaeger pro trasy, alertmanager pro notifikace.
  • SDK/collector OpenTelemetry sjednocuje příjem metrik, logů a tras do standardních backendů.

SLI, SLO a rozpočet chyb: řízení rizik a škálování

Definujte SLI (např. latence p95 < 300 ms, chybovost < 0,5 %, dostupnost > 99,9 %) a odvoďte z nich SLO. Rozpočet chyb (1–SLO) určuje toleranci porušení; jeho vyčerpání spouští opatření: zpomalení vydávání verzí, navýšení kapacity, optimalizaci kódu, změnu prahů automatického škálování. Upozornění by se měla vztahovat k porušení SLO (dopadu na uživatele), ne pouze k nízkoúrovňovým metrikám.

Základní metriky: zlaté signály a specifika kontejnerů

  • Latence (p50/p95/p99) a propustnost (RPS) z aplikačních metrik.
  • Chybovost (4xx/5xx, doménové chyby) a míra vytížení (omezování CPU, paměť blížící se limitu, délka front v DB/frontě).
  • Specifika kontejnerů: requests/limits, třídy QoS (Guaranteed/Burstable/BestEffort), evikce z důvodu nedostatku paměti (memory pressure), zásady restartování.

Požadavky na zdroje a limity: prevence omezování výkonu a evikcí

Správné nastavení resources.requests a limits je základem škálování. Příliš nízké hodnoty requests vedou k přetížení uzlů; příliš nízké hodnoty limits způsobují omezování CPU a OOMKill. Doporučení:

  • Vycházejte z naměřeného využití p95 a přidejte rezervu (např. 20–30 %).
  • U služeb citlivých na latenci upřednostněte CPU limit = žádný (místo toho nastavte vyšší hodnotu request), jinak riskujete omezování výkonu při krátkodobých špičkách.
  • U paměti nastavte limit = request pro předvídatelné chování GC a evikcí (QoS Guaranteed) tam, kde to dává smysl.

Probes: liveness, readiness, startup

  • Readiness určuje, kdy může pod přijímat provoz; sledujte závislosti (DB, cache, externí API).
  • Liveness restartuje zamrzlý proces; nastavte velkorysý initialDelay a opatrný timeout, aby nedocházelo k restart loops.
  • Startup je určen pro pomalé studené starty – chrání před falešným selháním liveness.

Horizontální škálování: HPA a metriky

Horizontal Pod Autoscaler škáluje počet replik podle metrik (CPU, paměť, vlastní metriky z Promethea). Typické signály: latence p95, délka fronty (RabbitMQ/Kafka), využití CPU, aktivní relace. Příklad HPA založeného na vlastní metrice z Promethea:

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: webapp-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: webapp minReplicas: 3 maxReplicas: 50 metrics: - type: Pods pods: metric: name: http_requests_inflight target: type: AverageValue averageValue: "50"

Vertikální škálování: VPA a doporučení

Vertical Pod Autoscaler doporučuje nebo mění hodnoty requests/limits na základě historie. V režimu Recommendation generuje návrhy; v režimu Auto pod restartuje a použije nové hodnoty. V praxi se VPA často kombinuje s HPA (HPA podle vlastní metriky, VPA v režimu doporučení pro pravidelné ladění).

Škálování řízené událostmi: KEDA a fronty

KEDA škáluje podle externích signálů (délka fronty, zpoždění v Kafka, počet zpráv v SQS, metrika v Prometheu). Příklad škálování podle metriky latence z Promethea:

apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: webapp-keda spec: scaleTargetRef: name: webapp pollingInterval: 10 cooldownPeriod: 60 minReplicaCount: 2 maxReplicaCount: 100 triggers: - type: prometheus metadata: serverAddress: http://prometheus.monitoring.svc:9090 metricName: http_request_latency_p95_seconds threshold: "0.3" query: | histogram_quantile(0.95,sum(rate(http_request_duration_seconds_bucket{job="webapp"}[2m])) by (le))

Cluster Autoscaler a plánování kapacity

Cluster Autoscaler přidává/odebírá uzly podle nenaplánovaných podů a jejich využití. Oddělte skupiny uzlů (výpočetně optimalizované vs. optimalizované pro paměť, GPU), použijte taints/tolerations pro řízení plánování a priority classes pro přednostní odebrání méně důležitých úloh. Plánování kapacity vychází z dlouhodobých trendů metrik a předvídaných špiček (události, marketingové kampaně).

Topologie a rozmístění: PDB, Pod anti-affinity, topology spread

  • PodDisruptionBudget brání zhoršení dostupnosti při údržbě/aktualizacích (minAvailable/maxUnavailable).
  • Pod anti-affinity a topologySpreadConstraints minimalizují riziko umístění replik na jedné fyzické entitě.
  • Plánování zohledňující zóny zvyšuje odolnost vůči výpadkům AZ.

Řízení nákladů: efektivita a rozpočty

  • Nastavte hodnoty requests blízko skutečnému využití p95, vyhněte se zbytečné rezervě; využijte doporučení VPA.
  • V namespace definujte resource quotas a limit ranges pro správu zdrojů.
  • Měřte náklady ve vztahu k SLI: náklady na RPS, náklady na 1 GB RAM/hod., náklady na úložiště/logy; omezte dobu retence a vzorkování tras.

Upozorňování: od příznaků ke kauzální diagnostice

Notifikace musí být akční a s nízkou mírou šumu. Příklad pravidla (Alertmanager) pro porušení SLO latence:

groups: - name: slo-latency rules: - alert: HighLatencyP95 expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="webapp"}[5m])) by (le)) > 0.3 for: 10m labels: severity: page service: webapp annotations: summary: "p95 latence > 300 ms" description: "SLO porušeno 10 min, zvažte škálování nebo incident."

Logování v kontejnerech: struktura, retence, korelace

  • Zaznamenávejte strukturované logy (JSON) s trace_id/span_id a kubernetes.labels.
  • Předávejte je přes DaemonSet (Fluent Bit/Vector) s TLS; nastavte rate limiting a backpressure.
  • Retenci určujte podle třídy logů; archivujte je do levnějšího objektového úložiště, u debug logů použijte vzorkování.

Distribuované trasování: OTel a service mesh

SDK a Collector OpenTelemetry umožňují jednotné trasování a sběr metrik. V service meshi (Istio/Linkerd) získáte síťové SLI (latence mezi službami, chybovost, opakování požadavků) bez úprav kódu; pozor na režii postranních kontejnerů a plánujte pro ně zdroje.

Škálování stavových služeb a front

  • StatefulSets škálujte obezřetně; sledujte replikaci (zpoždění), latenci disků a IOPS. U DB oddělte čtení/zápis a používejte connection pooling.
  • Fronty (Kafka/RabbitMQ/SQS) škálujte podle zpoždění/délky, nastavte paralelismus consumer group a idempotentní zpracování.
  • Pro náročné úlohy použijte Jobs/CronJobs, Pod Priority pro důležité dávkové úlohy a resource quotas.

Strategie vydávání verzí a dopad na observabilitu

  • Rolling update vyžaduje readiness a graceful shutdown pro minimalizaci chyb.
  • Canary s řízením provozu (service mesh, ingress) a experimentálními SLO (latence, chybovost) pomáhá rozhodnout o pokračování nasazení nebo návratu k předchozí verzi.
  • Blue/Green umožňuje rychlý návrat k předchozí verzi; měřte zahřívání před přepnutím a naplnění cache.

eBPF a pokročilá telemetrie

Nástroje eBPF (Cilium/Tetragon/BCC) umožňují s nízkou režií sbírat síťové a systémové metriky, sledovat systémová volání, provádět bezpečnostní audity a podrobně diagnostikovat anomálie bez zásahů do aplikačního kódu.

Bezpečnost observability a škálování

  • RBAC pro čtení metrik/logů; tajné údaje (tokeny, přihlašovací údaje) maskujte už v agentovi.
  • Pod Security a NetworkPolicies omezují rozsah dopadu; koncové body pro logování/metriky chraňte (TLS, autentizace), nezpřístupňujte je veřejně.
  • Multi-tenancy: oddělení namespaces, resource quotas, samostatné data sources v Grafaně a zásady retence.

Provozní dashboardy: doporučené panely

  • Přehled služby: RPS, p50/p95/p99, 4xx/5xx, vytížení CPU/paměti, počet podů, cíl/aktuální hodnota HPA.
  • Stav podů: restarty, readiness, liveness, OOM, omezování výkonu, GC, zpoždění event loopu (u Node.js), heap/GC (u JVM).
  • Infrastruktura: uzly, dostupné vs. požadované zdroje, čekání podů na plánování, diskové I/O, síťová propustnost.
  • Business SLI: doménové metriky (úspěšnost dokončení objednávky, objednávky/min), navázané na SLO a rozpočet chyb.

Praktický příklad: komplexní telemetrie služby

  1. Aplikace exportuje HTTP metriky (klient Prometheus) a trasy OpenTelemetry.
  2. HPA škáluje podle průměrného počtu požadavků inflight na pod (cílová hodnota 50).
  3. KEDA zvyšuje počet workerů podle zpoždění ve frontě (zpoždění Kafka topic > 10k).
  4. Cluster Autoscaler přidává uzly, pokud HPA naráží na nedostatek zdrojů; VPA doporučuje nové hodnoty requests.
  5. Upozornění navázaná na SLO latence p95 a chybovost s dobou trvání for: 10 minut, propojená s runbookem a podrobnou diagnostikou (dotazy LogQL v Lokim, trasy v Jaegeru).

Konfigurace scrape a zjišťování služeb

Prometheus v Kubernetes používá service discovery a relabeling. Dodržujte konvence: koncový bod /metrics, metriky se štítky namespace, pod, container a štítek service, který sjednocuje názvy napříč prostředími.

Retence, downsampling a škálování observability

  • U metrik používejte downsampling/remote write (Thanos/Cortex/Mimir) a oddělené zásady retence (např. 15 dní plné podrobnosti, 1 rok agregovaných dat).
  • Logy rozdělte do tříd (audit, aplikace, debug) s odlišnou retencí; archivujte je do objektového úložiště.
  • Trasy vzorkujte (tail-based sampling), abyste při nízké režii zachytili odlehlé hodnoty (p99).

Testování škálování: zátěžové testy a chaos

  • Zátěžový test (k6, vegeta, wrk) pro ověření reakcí HPA/KEDA, latence při zátěži a bodů kolapsu.
  • Chaos engineering (chaos mesh, litmus) pro testování evikcí, výpadků uzlů, degradace sítě a latencí závislostí.
  • GameDays se scénáři incidentů a nácvikem runbooků.

Kontrolní seznam zavedení monitoringu a škálování

  • Definované SLI/SLO a rozpočty chyb pro klíčové služby.
  • Export aplikačních metrik (OpenMetrics), strukturované logy s korelací, trasy OTel.
  • HPA založené na relevantním signálu (ne pouze na CPU), KEDA pro škálování řízené událostmi, doporučení VPA.
  • Správně nastavené requests/limits, třídy QoS, probes readiness/liveness/startup.
  • PDB, anti-affinity a topology spread pro odolnost; priority classes pro kritické úlohy.
  • Upozornění navázaná na SLO s nízkou mírou šumu, runbooky, eskalace.
  • Retence a nákladový model pro metriky, logy a trasy; remote-write/dlouhodobé úložiště.
  • Pravidelné zátěžové testy, chaos experimenty a revize prahů automatického škálování.

Závěr

Monitoring a škálování kontejnerových aplikací je kombinací kvalitní telemetrie, jasně definovaných SLO a automatizovaných mechanismů škálování. Klíčem je měřit to, co ovlivňuje uživatelský zážitek, a škálovat podle signálů, které nejlépe korelují s obchodním dopadem. Díky promyšleným hodnotám requests/limits, robustním probes, HPA/VPA/KEDA, cluster autoscaleru a disciplinované observabilitě lze dosáhnout spolehlivého, výkonného a nákladově efektivního provozu v Kubernetes i mimo něj.