Monitorování a správa mikroslužeb: sledování

Cloud, virtualizace a architektury
Natália Šimková
Monitorování a správa mikroservis: Sledování

Proč se monitorování a správa mikroslužeb liší od monolitu

Mikroslužební architektura přináší škálovatelnost, nezávislá nasazení 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 řízené správě životního cyklu služeb (konfigurace, nasazení, škálování, odolnost, bezpečnost a náklady). Cílem je krátká doba detekce a obnovy (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 (latence p95/p99, chybovost, dostupnost, průměrná 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, který vychází ze SLO.
  • Error budget: 1 − SLO; „rozpočet“ na porušení. Slouží jako podklad pro rozhodování o tempu nasazování, refaktoringu či škálování.

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

  • Metriky: číselné časové řady (RPS, latence, chybovost, vytížení CPU/RAM/IO). Export ve formátu OpenMetrics/Prometheus.
  • Logy: strukturované JSON, korelované pomocí trace_id/span_id a correlation_id. Rotace, filtrování, doba uchovávání.
  • Distribuované trasování: OpenTelemetry SDK → kolektor → backend (Jaeger, Tempo, Datadog). Zobrazuje kritickou cestu požadavku napříč službami.
  • Události: události Kubernetes, nasazení, přepínání příznaků funkcí, akce škálování – nezbytné pro kauzální diagnostiku.

Klíčové metriky pro mikroslužby („golden signals“ + kontext)

  • Latence: p50/p95/p99 pro endpoint, klienta i závislosti (DB, cache, fronty).
  • Chybovost: poměr chyb 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.
  • Vytížení: omezování CPU, využití heapu, pauzy GC, limity deskriptorů souborů, počet spojení do DB.

Standardizace telemetrie: OpenTelemetry a konvence

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

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

  • API gateway: autentizace/autorizace, omezování rychlosti požadavků, úprava jejich parametrů, transformace payloadů, centralizované audity.
  • Service mesh (Istio/Linkerd): mTLS, outlier detection, opakování požadavků, časové limity, circuit breaking, traffic shifting (canary). Sidecary sbírají síťové metriky bez úprav kódu.

Kontroly stavu a graceful životní cyklus

  • /live (liveness): proces běží a není zaseknutý (nedochází k opakovaným restartům).
  • /ready (readiness): služba je připravena obsluhovat požadavky (závislosti jsou v pořádku, cache je zahřátá).
  • Startup probe: pro pomalé starty – předchází falešným restartům.
  • Implementujte graceful shutdown: zavřete listener, dokončete rozpracované požadavky a uvolněte pooly.

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

  • Nastavujte timeouts pro všechna volání; bez nich vznikají „visící“ požadavky a lavinové efekty.
  • Retry používejte selektivně (u idempotentních operací), s exponential backoff + jitterem. Vyvarujte se bouřím opakovaných požadavků.
  • Circuit breaker chrání závislosti: při chybovosti nebo vysoké latenci se okruh otevře a na krátkou dobu odmítá požadavky.
  • Bulkhead: oddělení vláken/poolů pro různé typy provozu, aby kolaps jedné třídy neovlivnil ostatní.

Konfigurace, tajemství a feature flags

  • 12-Factor: konfigurace prostřednictvím ENV, šablony pro více prostředí, validace podle schématu (Zod/Joi).
  • Secrets ukládejte do secret manageru (KMS/HSM, rotace), nikdy do repozitáře ani logu.
  • Feature flagy: bezpečné zapínání funkcí (canary, percentage rollout) s možností okamžitého vypnutí.

CI/CD a strategie nasazení

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

Alerting: od příznaků ke kauzální diagnostice

  • Primárně upozorňujte na porušení SLO a burn rate error budgetu (např. v oknech 2 h i 24 h).
  • Doplňte upozornění založená na příznacích: latence p95, chybovost 5xx, lag fronty, selhání readiness, vytížení HPA.
  • Každé upozornění musí mít runbook: popis, postup, odpovědnou osobu, 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é osobní údaje bez maskování.
  • Centralizujte logy prostřednictvím Fluent Bit/Vector → Loki/Elastic/Cloud. Politiku uchovávání rozdělte podle třídy logů (audit/app/debug).
  • Vyhledávání pomocí dotazů propojených s trasami: ze záznamu trace otevřete související logy repliky.

Datové závislosti: DB, cache a messaging

  • DB: měřte latenci dotazů, vytížení poolu, počet připojení a deadlocky. Zvažte read replicas a connection pooling proxy.
  • Cache (Redis): hit ratio, velikost, evikce. Sledujte efekt thundering herd a používejte ochranu dogpile.
  • Messaging: lag Kafky, propustnost, opětovné vyvažování skupiny konzumentů, fronty dead-letter, idempotence.

Správa schémat a verzí API

  • Změny zpětně kompatibilní (aditivní), kontraktové testy (Pact), consumer-driven contracts.
  • Schema registry (Avro/Protobuf/JSON Schema) s verzemi a pravidly kompatibility.
  • Deprecaci doplňte harmonogramem a telemetrií využití verzí.

Testování: od jednotkových testů po testy v produkci

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

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

  • HPA (CPU/RAM + vlastní metriky – latence p95, počet požadavků v průběhu zpracování, 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. Připravte profily load testů.

Náklady a FinOps v mikroslužbovém prostředí

  • Označujte náklady na úrovni služeb (náklady/RPS, náklady/událost). Vizualizujte cost per SLO.
  • Řiďte dobu uchovávání logů a tras, sampling a úrovně metrik (vysoká/nízká kardinalita).
  • Optimalizujte requests (omezujte rezervní kapacitu), pro nekritické služby využívejte pooly spot/preemptible.

Bezpečnost: zero trust, IAM a compliance

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

Řízení incidentů a kultura postmortemů

  • On-call s jasným eskalačním procesem, paging policy a runbooky pro hlavní režimy selhání.
  • Postmortem bez obviňování: kořenová příčina, akční body, zlepšení detekce a obrany.
  • Kultura blameless podporuje rychlejší učení a snižuje počet skrytých chyb.

Dashboardy pro různé role

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

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

// Pseudokód (styl Node/Express) 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); // ping DB/cache 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 časovými limity res.json(order); } catch (e) { span.recordException(e); res.status(503).json({ error: "temporarily_unavailable" }); } finally { span.end(); } }); app.listen(process.env.PORT);

Kontrolní seznam pro zavedení monitoringu a správy mikroslužeb

  • Definované SLI/SLO + upozornění na burn rate.
  • OpenTelemetry pro traces/metrics/logs, jednotné štítky, korelace pomocí trace_id.
  • Kontroly stavu (live/ready/startup) + graceful shutdown.
  • Časové limity, retry s jitterem, vzory circuit breaker a bulkhead.
  • API gateway + (volitelně) service mesh pro spolehlivost sítě a mTLS.
  • CI/CD se strategií canary/rolling, automatický rollback, SBOM a skenování.
  • Správa konfigurace/tajemství, feature flagy a audit změn.
  • Kapacitní plánování, HPA/VPA/CA, zátěžové testy a chaos testy.
  • FinOps: metriky nákladů a řízení doby uchovávání/samplingu telemetrie.
  • Proces řešení incidentů, runbooky a postmortemy bez obviňování.

Závěr

Monitorování a správa mikroslužeb nejsou jednorázovým projektem, ale průběžnou praxí. Standardizujte telemetrii, řiďte spolehlivost prostřednictvím SLO a error budgetů, 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.