Monitoring mikroservis

Proč je monitorování a správa mikroservis jiné než u monolitu

Mikroservisní architektura přináší škálovatelnost, nezávislé releasy a menší doménové celky, ale současně exponenciálně zvyšuje počet běžících procesů, síťových skoků a míst, kde se může něco pokazit. Úspěch proto stojí na disciplinované observabilitě (metriky, logy, trasování) a na řízené správě životního cyklu služeb (konfigurace, nasazení, škálování, odolnost, bezpečnost a nákladovost). Cílem je krátký MTTD/MTTR, stabilní SLO a předvídatelný provoz i při rychlém tempu změn.

SLI, SLO, SLA a error budget: rámec pro řízení spolehlivosti

• SLI (Service Level Indicator): měřitelný ukazatel kvality (p95/p99 latence, chybovost, dostupnost, střední doba zpracování).
• SLO (Service Level Objective): cílová hodnota SLI v čase (např. p95 < 300 ms a dostupnost ≥ 99,9 % za měsíc).
• SLA: smluvní závazek vůči zákazníkovi vycházející z SLO.
• Error budget: 1 − SLO; „rozpočet“ na porušení. Je podkladem pro rozhodování o tempu releasů, refaktoringu či škálování.

Pilíře observability: metriky, logy, trasy a eventy

• Metriky: numerické časové řady (RPS, latence, chybovost, saturace CPU/RAM/IO). Export ve formátu OpenMetrics/Prometheus.
• Logy: strukturované JSON, korelované přes trace_id/span_id a correlation_id. Rotace, filtr, retence.
• Distribuované trasování: OpenTelemetry SDK → kolektor → backend (Jaeger, Tempo, Datadog). Zobrazuje kritickou cestu požadavku napříč službami.
• Eventy: Kubernetes eventy, releasy, feature-flag přepnutí, škálovací akce – nutné pro kauzální diagnostiku.

Kritické metriky pro mikroservisy („golden signals“ + kontext)

• Latence: p50/p95/p99 na endpoint, na klienta a na závislosti (DB, cache, fronty).
• Chybovost: poměr 5xx/4xx, doménové chyby (např. odmítnuté platby), error budget burn rate.
• Propustnost: RPS/eps, délka front/lag (Kafka), počet rozpracovaných úloh.
• Saturace: CPU throttling, využití heapu, GC pauzy, limity file descriptorů, spojení do DB.

Standardizace telemetrie: OpenTelemetry a konvence

• Implementujte OTel (traces, metrics, logs) a jednotný resource model (service.name, service.version, deployment.environment).
• Korelujte vše trace-id → logy, metriky i auditní záznamy.
• Definujte společné názvy metrik (např. http_server_requests_seconds histogram) a štítky (metoda, route, status).
• Pro klienty používejte instrumentované SDK (HTTP gRPC, DB, messaging), aby vznikaly spany na každém skoku.

API gateway a service mesh: řízení provozu a pozorovatelnost

• API gateway: autentizace/autorizace, rate limiting, request shaping, transformace payloadů, centralizované audity.
• Service mesh (Istio/Linkerd): mTLS, outlier detection, retry, timeouts, circuit breaking, traffic shifting (canary). Sidecary sbírají síťové metriky bez úprav kódu.

Health-checky a graceful životní cyklus

• /live (liveness): proces běží a není zaseknutý (ne restart-loop).
• /ready (readiness): připraven obsluhovat požadavky (závislosti OK, warm cache).
• Startup probe: pro pomalé starty – brání falešným restartům.
• Implementujte graceful shutdown: zavřít listener, dokončit rozpracované požadavky, uvolnit pooly.

Odolnost: timeouts, retry, backoff, circuit breaker, bulkhead

• Nastavujte timeouts na všech voláních; bez nich vznikají „visící“ požadavky a lavinové efekty.
• Retry používejte selektivně (idempotentní operace), s exponential backoff + jitter. Vyvarujte se retry-stormům.
• Circuit breaker chrání závislosti: při chybovosti/latenci se okruh otevře a krátce odmítá požadavky.
• Bulkhead: oddělení thread/poolů pro různé typy provozu, aby kolaps jedné třídy nestrhl ostatní.

Konfigurace, tajemství a feature flags

• 12-Factor: konfigurace přes ENV, šablonování pro více prostředí, validace schématem (Zod/Joi).
• Secrets v secret manageru (KMS/HSM, rotations), nikdy v repozitáři ani v logu.
• Feature flagy: bezpečné zapínání funkcí (canary, percentage rollout), možnost okamžitého vypnutí.

CI/CD a strategie nasazení

• Canary: postupné navyšování provozu na novou verzi, sledování SLO a rollback při degradaci.
• Blue/Green: paralelní prostředí, rychlé přepnutí a návrat.
• Rolling: plynulá obměna replik s readiness a PDB (PodDisruptionBudget) v Kubernetes.
• Automatizujte verzování (SemVer), SBOM, skeny závislostí/image a podpisy artefaktů.

Alerting: od symptomů ke kauzální diagnostice

• Primárně alertujte porušení SLO a burn rate error budgetu (např. 2h i 24h okna).
• Doplňte symptom-based alerty: p95 latence, chybovost 5xx, lag fronty, readiness selhání, HPA saturace.
• Každý alert má runbook: popis, kroky, vlastníka, escalation policy.

Logování a korelace: od události k příčině

• Strukturované logy (JSON), korelační identifikátory (trace_id, span_id, correlation_id), žádné PII bez maskování.
• Centralizace přes Fluent Bit/Vector → Loki/Elastic/Cloud. Retenční politiku dělte podle třídy logů (audit/app/debug).
• Prohledávání přes dotazy navázané na trasy: od trace otevřít související logy repliky.

Datové závislosti: DB, cache a messaging

• DB: měřte latenci dotazů, pool saturaci, počet připojení, deadlocky. Zvažte read replicas a connection pooling proxy.
• Cache (Redis): hit ratio, velikost, evikace. Sledujte thundering herd a používejte dogpile ochranu.
• Messaging: Kafka lag, throughput, Consumer Group rebalance, dead-letter fronty, idempotence.

Správa schémat a verzí API

• Backward kompatibilní změny (additive), kontraktové testy (Pact), consumer-driven contracts.
• Schema registry (Avro/Protobuf/JSON Schema) s verzemi a pravidly kompatibility.
• Deprekace s harmonogramem a telemetrií využití verze.

Testování: od jednotek k testům v produkci

• Contract testy mezi službami, integrační testy s lokálními kontejnery (Testcontainers).
• Chaos engineering: síťové latence, výpadky uzlů, škrcení zdrojů, failure modes (Chaos Mesh, Litmus).
• Shadow traffic a syntetické testy pro validaci po release.

Škálování a kapacitní plánování

• HPA (CPU/RAM + vlastní metriky – p95 latency, inflight requests, lag fronty).
• VPA pro návrh/úpravu requests/limits; Cluster Autoscaler pro uzly.
• Plánujte na základě trendů SLI, sezónnosti a marketingových špiček. Mějte load test profily.

Nákladovost a FinOps v mikroservisním světě

• Tagujte náklady na úrovni služeb (náklady/RPS, náklady/událost). Vizualizujte cost per SLO.
• Řiďte retence logů/tras, sampling, úrovně metrik (high/low cardinality).
• Optimalizujte requests (omezení headroomu), využívejte spot/preemptible pooly pro ne-kritické služby.

Bezpečnost: zero trust, IAM a compliance

• mTLS mezi službami, rotace certifikátů, policy enforcement v meshi.
• Least privilege pro služby (service accounts, krátkodobé tokeny), tajemství v KMS.
• Auditní logy odolné proti manipulaci, WAF/rate limit na API gateway, detekce anomálií.
• Compliance (GDPR, PCI DSS, SOC 2) → důsledná observabilita přístupů a incident plán.

Incident management a postmortem kultura

• On-call s jasnou eskalací, paging policy a runbooky pro hlavní poruchové módy.
• Postmortem bez obviňování: kořenová příčina, akční body, zlepšení detekce a obrany.
• Blameless kultura zvyšuje rychlost učení a snižuje skryté chyby.

Dashboardy pro různé role

• Byznys: konverze, transakce/min, doba zpracování objednávky.
• Provoz: p95/p99, chybovost, RPS, zdraví replik, HPA/VPA stavy, fronty.
• Vývoj: chyby podle verze release, rozpad endpointů, N+1 dotazy, saturace DB/Cache.

Referenční implementační vzor (HTTP služba)

// Pseudokód (Node/Express styl) se standardní telemetrií initOpenTelemetry({ serviceName: "orders", serviceVersion: process.env.VERSION }); const app = express(); app.use(requestId()); // X-Request-ID -> correlation_id app.use(otelHttpInstrumentation()); // spany pro HTTP app.use(rateLimit()); app.use(timeout("5s")); app.get("/health/ready", checkDeps); // DB/cache ping app.get("/orders/:id", async (req, res) => { const span = startSpan("load_order"); try { const order = await db.get(req.params.id, { timeout: 200 }); // klient s timeouts res.json(order); } catch (e) { span.recordException(e); res.status(503).json({ error: "temporarily_unavailable" }); } finally { span.end(); } }); app.listen(process.env.PORT); 

Checklist zavedení monitoringu a správy mikroservis

• Definovaná SLI/SLO + alerty na burn rate.
• OpenTelemetry pro traces/metrics/logs, jednotné štítky, korelace trace_id.
• Health-checky (live/ready/startup) + graceful shutdown.
• Time-outy, retry s jitterem, circuit breaker a bulkhead vzory.
• API gateway + (volitelně) service mesh pro síťovou spolehlivost a mTLS.
• CI/CD se strategií canary/rolling, automatický rollback, SBOM a skeny.
• Správa konfigurace/secretů, feature flagy a audit změn.
• Kapacitní plánování, HPA/VPA/CA, load testy a chaos testy.
• FinOps: metriky nákladů a řízení retencí/samplingu telemetrie.
• Incident proces, runbooky a blameless postmortems.

Závěr

Monitorování a správa mikroservis není jednorázový projekt, ale průběžná praxe. Standardizujte telemetrii, řiďte spolehlivost přes SLO a error budgety, automatizujte nasazování a škálování a budujte kulturu rychlé detekce a nápravy. Kombinace dobře nastavené observability, provozních vzorů odolnosti a disciplinovaného CI/CD zkracuje dobu výpadků, snižuje náklady a umožňuje týmům bezpečně inovovat.