Monitoring vs observabilita

Proč rozlišovat monitoring a observabilitu

Monitoring a observabilita jsou příbuzné, ale odlišné disciplíny. Monitoring je schopnost sledovat předem známé signály a upozornit na odchylky od očekávaného stavu. Observabilita je vlastnost systému, která umožňuje odvodit vnitřní stav z vnějších výstupů – i při neočekávaných poruchách. Jinými slovy: monitoring odpovídá na otázku „funguje to?“, observabilita na otázku „proč to nefunguje?“ a „co přesně se děje?“.

Formální definice a vztah

• Monitoring: sběr a vyhodnocování metrik a událostí podle předem definovaných pravidel. Zaměřuje se na známé selhání a prahy.
• Observabilita: schopnost vést nepředskriptované vyšetřování („unknown unknowns“). Vychází z bohatých dat (metriky, logy, trasy, události, profily) a z nástrojů pro ad-hoc dotazování, korelaci a kontext.
• Vztah: monitoring je podmnožina užití observability; bez observability je monitoring slepý pro nové poruchy, bez monitoringu je observabilita neakční.

Dimenze srovnání

Pilíře observability a jejich role

• Metriky: časové řady pro kvantifikaci chování (latence, chybovost, propustnost, saturace). Klíčové metody: RED (Rate, Errors, Duration) pro služby a USE (Utilization, Saturation, Errors) pro infrastrukturu.
• Logy: strukturované události s kontextem. Důležitá je korelace ID (trace_id, span_id, user_id) a řízená retence.
• Trasování (distributed tracing): příběh jednoho požadavku napříč službami. Umožňuje lokalizovat kritickou cestu a horké úseky.
• Události a profily: release eventy, feature flagy, škálování, CPU/heap profiling, eBPF sondy – doplňují kauzální kontext.

Kontext a korelace: od alertu k pochopení

Samotný alert je pouze spouštěč. Observabilita přidává kontextové dimenze (tenant, endpoint, verze, region, instance, AZ), automatické připnutí událostí (release, migrace DB, feature flag) a propojení signálů (span → logy → metriky). Cílem je zkrátit MTTR konverzí „co se stalo“ → „kde se to stalo“ → „proč se to stalo“.

Architektura dat pro observabilitu

• OpenTelemetry (OTel): jednotné SDK/agent pro metriky, logy a trasy; export do backendů (Prometheus, Tempo, Loki, Jaeger, OTEL collector → různé cíle).
• Vysoká kardinalita: práce s dimenzemi (labels) jako user_id, build_sha, feature_flag. Nutná je limitační a sampling strategie (tail-based sampling, exemplars).
• Úložiště a dotazování: TSDB pro metriky, sloupcové/objemné úložiště pro logy, DAG pro trasy; důraz na levný přístup k detailu u recentních dat a archiv pro dlouhou retenci.

Monitoringové use-casy (baseline)

• Životní funkce: uptime služby, chybovost nad prahem, heartbeat jobů, využití zdrojů.
• Bezpečnostní sentinel: anomálie v 4xx/5xx, nárůst chyb přihlášení, neúspěšné buildy/deploye.
• SLA/SLO hlídání: alerty na porušení SLO (např. latence P99 nad limitem, vyčerpání error budgetu).

Observabilitní use-casy (diagnostika a průzkum)

• Vyšetřování incidentu: segmentace dopadu podle regionu/tenanta/verze; nalezení problematického spanu a jeho logů.
• Výkonové úzké hrdlo: rozpad latence (server timing, DB, cache, síť), identifikace regresí po release.
• Produktové otázky: které akce uživatelů korelují s chybami nebo timeouty; vliv feature flagu na konverzi.

Praktiky návrhu observabilních služeb

• Standardizace telemetrie: konzistentní názvy metrik, tagy, jednotky, stavové kódy; knihovny s middleware pro auto-instrumentaci.
• Trace context všude: propagace traceparent (W3C) přes HTTP, messaging i cron; log correlation s trace_id/span_id.
• Exemplars: prolinkování metrik (např. histogram bucket) na konkrétní trasy pro rychlý drill-down.
• Blackbox & synthetics: uživatelská perspektiva mimo cluster (syntetické testy, RUM) pro zachycení edge případů.

Alerting: od prahů k SLO a anomáliím

• Symptom vs. příčina: alerty na dopady (zhoršené SLI), ne na jednotlivé metriky infrastruktury.
• Okna a odolnost: for/group_by, deduplikace, silencing, automatická eskalace s runbookem.
• Anomálie a predikce: statistické modely a sezónnost; pozor na falešně pozitivní signály.

Role service mesh a eBPF v observabilitě

• Service mesh: jednotné mTLS, retries, timeouts, traffic policy; sidecar/ambient telemetrie bez změny aplikačního kódu.
• eBPF sondy: nízkonákladový sběr na kernel úrovni (síť, I/O, CPU) s mapováním na procesy/pody; užitečné pro korelaci aplikačního a infra pohledu.

Nákladový model a retence dat

• Ekonomika dat: metriky jsou levné a agregované, logy dražší, trasy nákladné při vysokém provozu.
• Sampling a třídění: tail-based sampling pro chyby a outliery, rules-based priorita (např. placený tenant, kritické endpointy).
• Retence: horká data (hodiny/dny) v rychlém úložišti, teplá (týdny) pro vyšetřování, studená (měsíce) pro compliance/reporting.

Observabilita a SRE: SLI/SLO/SLA

Observabilita poskytuje data pro SLI (měřené indikátory kvality), na jejichž základě se stanoví SLO (cíle) a vyjedná SLA (externí závazky). Error budget pak řídí tempo změn: při čerpání se preferují stabilizační práce nad novými funkcemi.

Proces incident managementu v éře observability

1. Detekce: symptom-alert na SLI nebo syntetiku; automatická korelace s releasem/feature flagem.
2. Triáž: segmentace dopadu (kolik uživatelů, které regiony), rozhodnutí o mitigaci (rollback, kill-switch, rate-limit).
3. Diagnóza: trace-driven analýza, drill-down do logů, porovnání zdravé vs. postižené kohorty.
4. Obnova: exekuce runbooku, ověření přes SLI a syntetiku.
5. Post-mortem: bez hledání viníka, opatření na úrovni kódu, testů, alertů i telemetrie.

Maturity model: od monitoringu k observabilitě

• Level 1 – Monitoring: uptime, pár metrik, ruční dashboardy, základní alerty.
• Level 2 – Integrované signály: metriky + logy + trasy, sjednocený kontext, standardizované názvosloví.
• Level 3 – SLO-driven provoz: alerty na SLI, error budget, automatizace runbooků.
• Level 4 – Proaktivní observabilita: anomálie, profilování, eBPF, propojení s feature flagy a CI/CD, „shift-left“ validace.

Praktické vzory instrumentace

• Server Timing: přenášejte sub-stages do HTTP hlaviček pro korelaci FE/BE.
• Business metriky: sledujte i doménové SLI (např. úspěšné checkouty), ne pouze CPU a paměť.
• Structured logging: JSON, pevné klíče, trace kontext, žádná volná textová pole bez schématu pro klíčové události.
• Back-pressure signály: metriky queue depth, retry rate, circuit-breaker stavy.

Antipatterny a jak se jim vyhnout

• Dashboard zoo: mnoho manuálních dashboardů bez kurátorství, nekonzistence názvů; řešení: design system pro observabilitu, kurátorské „golden dashboards“.
• Alert fatigue: alerty na každou metriku, chybějící severity a ownership; řešení: SLO-driven alerting, deduplikace, šumové filtry.
• Bezkontekstové logy: logy bez trace_id/request_id; řešení: povinné korelační klíče v loggeru.
• Over-aggregation: průměry maskují outliery; řešení: percentily (P90/P95/P99), histrogramy s exemplars.
• Slepé místo FE/RUM: pouze backendové metriky; řešení: Real User Monitoring a syntetika.

Příklad scénáře: náhlé zpomalení checkoutu

Monitoring zahlásí růst latence P99 nad SLO. Observabilita umožní rozpad podle endpointu a tenanta, ukáže, že problém je v regionu eu-central-1 a pouze pro verzi build_sha=abcd. Trace odhalí nárůst DB lock wait u konkrétní tabulky po nasazení nové migrace. Logy potvrzují zvýšenou frekvenci deadlock_retry. Mitigace: rollback migrace, omezení concurrency, reindex. Poučení: přidat pre-deployment kontrolu na dlouhé transakce a synthetic test s konkurenční zátěží.

Bezpečnost a compliance v observabilitě

• PII hygiene: zákaz ukládání osobních údajů do logů; tokenizace/maskování, data minimization.
• Přístup a audit: RBAC/ABAC v nástrojích, audit dotazů a exportů, retenční politiky dle regulací.
• Integrita: podepisování agentů/konfigurací, kontrola sběru (policy-as-code).

Integrace s CI/CD a „shift-left“

• Kontrolní brány: testy metrik a tras v pre-prod, vizuální regresní alerty, chaos experimenty v pipeline.
• Release události: automatické anotace časových řad a tras releasem/feature flagem.
• Guardraily: automatické pozastavení rolloutů při porušení SLO nebo prudké anomálii.

Závěr: komplementární přístupy

Monitoring je nezbytný pro rychlé zjištění poruch, observabilita pro rychlé pochopení a nápravu. Organizace, které investují do standardizované telemetrie, SLO-řízeného alertingu, kontextuálních korelací a ekonomického modelu dat, dosahují nižšího MTTR, vyšší spolehlivosti a lepšího produktového rozhodování. Rozdíl mezi monitoringem a observabilitou není v nástrojích, ale v hloubce otázek, které si umíme položit – a zodpovědět.