Monitoring a škálování kontejnerových aplikací: klíčové metriky

Proč monitorovat a škálovat kontejnerové aplikace

Kontejnerizace (Docker) a orchestraci (Kubernetes) zásadně urychlily dodávání softwaru, ale zároveň zvýšily složitost provozu. Úspěšný běh aplikací v kontejnerech vyžaduje důslednou observabilitu (metriky, logy, trasování, eventy) a promyšlené škálování (horizontální/vertikální i na úrovni clusteru). Cílem je dosáhnout prediktivní 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 eventy

Metriky: číselné časové řady pro SLI (latence, chybovost, propustnost, saturace). Standardem je Prometheus/OpenMetrics.
Logy: detailní 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í.
Eventy: Kubernetes události (evikace, 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 sbírá metriky z exporterů (node-exporter, kube-state-metrics, aplikační metriky) a ukládá je do TSDB.
Grafana vizualizuje SLI, SLO a tvorbu dashboardů pro týmy (service, infra, DB, síť, mesh).
Loki s promyšlenou retencí pro logy, TEMPO/Jaeger pro trasování, alertmanager pro notifikace.
OpenTelemetry SDK/collector sjednocuje ingest metrik, logů a tras do standardizovaných backendů.

SLI, SLO a error budget: řízení rizik a škálování

Definujte SLI (např. p95 latence < 300 ms, chybovost < 0,5 %, dostupnost > 99,9 %) a z nich odvoďte SLO. Error budget (1–SLO) určuje toleranci porušení; jeho překročení spouští opatření: zpomalení releasů, navýšení kapacity, optimalizaci kódu či změnu autoscalingových prahů. Alerty by měly být vázány na porušení SLO (uživatelský dopad), nikoli pouze na nízkoúrovňové metriky.

Základní metriky: golden signals a kontejnerové specifikum

Latence (p50/p95/p99) a propustnost (RPS) z aplikačních metrik.
Chybovost (4xx/5xx, doménové chyby) a saturovanost (CPU throttling, paměť blížící se limitu, délka front v DB/queue).
Specifika kontejnerů: requests/limits, QoS třídy (Guaranteed/Burstable/BestEffort), evikace způsobené paměťovým či podtlakovým tlakem (memory pressure), restart policy.

Resource requests a limits: prevence throttlingu a evikací

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

Vycházejte z měřeného p95 využití a přidejte rezervu (např. 20–30 %).
Preferujte nedávání CPU limitu u služeb citlivých na latenci (místo toho nastavte vyšší request), abyste předešli mikro-burst throttlingu.
U paměti nastavte limit = request pro deterministické chování Garbage Collectoru a evikací (QoS Guaranteed) tam, kde to dává smysl.

Probes: liveness, readiness, startup

Readiness určuje, kdy může pod přijímat provoz; měřte závislosti (DB, cache, externí API).
Liveness restartuje zamrzlé procesy; nastavte dostatečně velký initialDelay a opatrný timeout, aby nedocházelo k restart loops.
Startup chrání před falešnými liveness fail při pomalém cold startu.

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 jsou p95 latence, délka fronty (RabbitMQ/Kafka), využití CPU či počet aktivních sessions. Příklad HPA 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 upravuje requests/limits na základě historických dat. V režimu Recommendation generuje návrhy; v režimu Auto restartuje pody a aplikuje nové hodnoty. V praxi se VPA často kombinuje s HPA (HPA podle vlastní metriky, VPA v doporučovacím režimu pro pravidelné ladění).

Event-driven škálování: KEDA a fronty

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

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 kapacitní plánování

Cluster Autoscaler přidává či odebírá nody podle nepřidělených podů a využití. Oddělte node pooly (compute vs. memory-optimized, GPU), použijte tainty/tolerations pro kontrolu schedulingu a priority classes pro preempci méně důležitých workloadů. Kapacitní plánování vychází z dlouhodobých trendů metrik a z předpokládaných špiček (události, marketingové kampaně).

Topologie a rozložení: PDB, Pod anti-affinity, topology spread

PodDisruptionBudget brání degradaci služeb při údržbě či rolloutech (minAvailable/maxUnavailable).
Pod anti-affinity a topologySpreadConstraints minimalizují riziko kolokace replik na jedné fyzické entitě.
Zónově uvědomělý scheduling zvyšuje odolnost vůči výpadkům dostupnostních zón (AZ).

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

Nastavte requests blízko reálnému p95 využití, vyhněte se zbytečnému rezervnímu prostoru; využijte doporučení VPA.
Definujte resource quotas a limit ranges v namespace pro správu spotřeby zdrojů.
Měřte cenu/SLI: náklady na RPS, náklady na 1 GB RAM za hodinu, náklady na storage a logy; omezte retenční dobu a sampling tras.

Alerting: od symptomů ke kauzální diagnostice

Notifikace musí být akční a s nízkým šumem. 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 minut, zvažte škálování nebo incident."

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

Logujte strukturovaně (JSON) s trace_id/span_id a kubernetes.labels.
Přeposílejte logy přes DaemonSet (Fluent Bit/Vector) s TLS; nastavte rate limiting a backpressure.
Retence nastavte podle tříd logů; archivujte do levnějšího objektového úložiště, sampling používejte u debug logů.

Distribuované trasování: OTel a service mesh

OpenTelemetry SDK a Collector umožňují jednotné trasování a metriky. V service meshi (Istio/Linkerd) získáte síťová SLI (latence mezi službami, chybovost, retry) bez zásahů do kódu; pozor na režii sidecarů a plánujte jim zdroje.

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

StatefulSets škálujte konzervativně; sledujte replikaci (lag), latenci disků a IOPS. U databází oddělte read/write a používejte connection pooling.
Fronty (Kafka/RabbitMQ/SQS) škálujte podle lag/délky, nastavte paralelismus consumer group a idempotenci zpracování.
Pro náročné úlohy používejte Jobs/CronJobs, Pod Priority pro důležité dávky a resource quotas.

Release strategie a dopad na observabilitu

Rolling update vyžaduje readiness a graceful shutdown k minimalizaci chyb.
Canary s řízením provozu (service mesh, ingress) a experimentálními SLO (latence, chybovost) rozhoduje o progresi či rollbacku.
Blue/Green umožňuje rychlý rollback; měřte pre-switch warm-up a cache priming.

eBPF a pokročilá telemetrie

eBPF nástroje (Cilium/Tetragon/BCC) poskytují nízko-režijní síťové a systémové metriky, sledování systémových volání, bezpečnostní audit a hloubkovou diagnostiku anomálií bez zásahů do aplikačního kódu.

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

RBAC pro čtení metrik a logů; tajemství (tokeny, credentials) maskujte již u agenta.
Pod Security a NetworkPolicies omezují blast radius; endpointy logování a metrik chraňte (TLS, autentifikace), nezpřístupňujte je veřejně.
Multi-tenancy: separace namespace, resource quotas, samostatné data sources v Grafaně a retenční politiky.

Dashboardy pro provoz: doporučené panely

Service overview: RPS, p50/p95/p99 latence, 4xx/5xx chyby, saturace CPU/paměti, počet podů, cíl a aktuální stav HPA.
Pod health: počet restartů, readiness, liveness, OOM, throttling, GC, event loop lag (u Node.js), heap/GC (u JVM).
Infrastruktura: uzly, allocatable vs. requested zdroje, čekání na scheduler, diskové I/O, síťová propustnost.
Business SLI: doménové metriky (úspěšnost checkoutu, objednávky za minutu), navázané na SLO a error budget.

Praktický příklad: end-to-end telemetrie služby

Aplikace exportuje HTTP metriky (Prometheus klient) a OpenTelemetry trasy.
HPA škáluje podle průměrné hodnoty inflight požadavků na pod (cílová hodnota 50).
KEDA zvětšuje počet workerů podle lag ve frontě (Kafka topic lag > 10 000).
Cluster Autoscaler přidává nody, pokud HPA narazí na limit zdrojů; VPA doporučuje nové requests.
Alerty vázané na SLO p95 latence a chybovost s for: 10 minut, propojené s runbooky a podrobnou diagnostikou (LogQL dotazy v Lokim, trasování v Jaegeru).

Konfigurace scrape a service discovery

Prometheus v Kubernetes používá service discovery a relabeling. Dodržujte konvence: endpoint /metrics, metriky označené štítky namespace, pod, container a sjednocující service label napříč prostředími.