Monitoring vs. observabilita: rozdíly v přístupu

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 upozorňovat 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ázky „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 prahové hodnoty.
Observabilita: schopnost provádět nepředem připravené vyšetřování („unknown unknowns“). Vychází z bohatých dat (metriky, logy, trasy, události, profily) a nástrojů pro ad hoc dotazování, korelaci a doplnění kontextu.
Vztah: monitoring je jedním ze způsobů využití observability; bez observability je monitoring slepý vůči novým poruchám, bez monitoringu je observabilita neakční.

Dimenze srovnání

Oblast	Monitoring	Observabilita
Cíl	Odhalovat známé problémy a upozorňovat na ně	Pochopit neznámé stavy a jejich příčiny
Data	Agregované metriky, kontroly stavu	Data s vysokou kardinalitou a mnoha dimenzemi (metriky, logy, trasy, události, profily)
Přístup	Dashboardy, prahové hodnoty, pravidla	Explorační dotazy, korelace, kontext, statistika
Otázky	„Překračuje chybovost služby stanovenou hranici?“	„Který tenant/endpoint/region způsobuje nárůst a proč?“
Horizont	Reaktivní	Diagnostický a prediktivní

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á doba uchovávání.
Trasování (distributed tracing): průběh jednoho požadavku napříč službami. Umožňuje lokalizovat kritickou cestu a úzká místa.
Události a profily: události při vydání nové verze, příznaky funkcí, škálování, profilování CPU/heap, sondy eBPF – 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řipínání událostí (vydání nové verze, migrace DB, příznak funkce) a propojení signálů (span → logy → metriky). Cílem je zkrátit MTTR tím, že se od otázky „co se stalo“ přejde k otázce „kde se to stalo“ a následně „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 jsou user_id, build_sha, feature_flag. Nutná je strategie omezení a vzorkování (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 detailním datům u nedávných dat a archiv pro dlouhou dobu uchovávání.

Případy použití monitoringu (základní úroveň)

Základní provozní ukazatele: dostupnost služby, chybovost nad prahem, heartbeat úloh, využití zdrojů.
Bezpečnostní sentinel: anomálie v odpovědích 4xx/5xx, nárůst počtu chyb při přihlašování, neúspěšná sestavení/deploymenty.
Hlídání SLA/SLO: upozornění na porušení SLO (např. latence P99 nad limitem, vyčerpání rozpočtu chyb).

Případy použití observability (diagnostika a průzkum)

Vyšetřování incidentu: segmentace dopadu podle regionu/tenanta/verze; nalezení problematického spanu a jeho logů.
Výkonnostní úzké místo: rozklad latence (časování serveru, DB, cache, síť), identifikace regresí po vydání nové verze.
Produktové otázky: které akce uživatelů korelují s chybami nebo vypršením časového limitu; vliv příznaku funkce na konverzi.

Praktiky návrhu observabilních služeb

Standardizace telemetrie: konzistentní názvy metrik, tagy, jednotky, stavové kódy; knihovny s middlewarem pro automatickou instrumentaci.
Kontext trasování všude: propagace traceparent (W3C) přes HTTP, zasílání zpráv i cron; korelace logů pomocí trace_id/span_id.
Exemplars: propojení metrik (např. bucketu histogramu) s konkrétními trasami pro rychlý přechod k detailům.
Blackbox a syntetické testy: uživatelská perspektiva mimo cluster (syntetické testy, RUM) pro zachycení okrajových případů.

Alerting: od prahových hodnot k SLO a anomáliím

Příznak vs. příčina: upozornění na dopady (zhoršené SLI), nikoli na jednotlivé infrastrukturní metriky.
Časová okna a odolnost: for/group_by, deduplikace, potlačení upozornění, automatická eskalace s provozním postupem.
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, opakování požadavků, časové limity, zásady směrování provozu; telemetrie sidecar/ambient bez změny aplikačního kódu.
Sondy eBPF: nízkonákladový sběr dat na úrovni jádra (síť, I/O, CPU) s mapováním na procesy/pody; užitečné pro korelaci aplikačního a infrastrukturního pohledu.

Nákladový model a uchovávání dat

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

Observabilita a SRE: SLI/SLO/SLA

Observabilita poskytuje data pro SLI (měřené ukazatele kvality), na jejichž základě se stanoví SLO (cíle) a sjednají SLA (externí závazky). Rozpočet chyb pak řídí tempo změn: při jeho čerpání se upřednostňují stabilizační práce před novými funkcemi.

Proces řízení incidentů v éře observability

Detekce: upozornění na příznak na základě SLI nebo syntetického testu; automatická korelace s vydáním nové verze/příznakem funkce.
Triáž: segmentace dopadu (kolik uživatelů, které regiony), rozhodnutí o zmírňujících opatřeních (rollback, kill-switch, rate-limit).
Diagnóza: analýza založená na trasách, podrobnější rozbor logů, porovnání zdravé a postižené kohorty.
Obnova: provedení provozního postupu, ověření pomocí SLI a syntetického testu.
Post-mortem: bez hledání viníka, opatření na úrovni kódu, testů, alertů i telemetrie.

Model vyspělosti: od monitoringu k observabilitě

Úroveň 1 – Monitoring: dostupnost, několik metrik, ručně vytvářené dashboardy, základní alerty.
Úroveň 2 – Integrované signály: metriky + logy + trasy, sjednocený kontext, standardizované názvosloví.
Úroveň 3 – Provoz řízený pomocí SLO: upozornění na základě SLI, rozpočet chyb, automatizace provozních postupů.
Úroveň 4 – Proaktivní observabilita: anomálie, profilování, eBPF, propojení s příznaky funkcí a CI/CD, validace „shift-left“.

Praktické vzory instrumentace

Server Timing: přenášejte dílčí fáze do HTTP hlaviček pro korelaci FE/BE.
Obchodní metriky: sledujte i doménové SLI (např. úspěšně dokončené objednávky), nejen CPU a paměť.
Strukturované logování: JSON, pevně dané klíče, kontext trasování, žádná volná textová pole bez schématu pro klíčové události.
Signály zpětného tlaku: metriky hloubky fronty, míry opakování požadavků, stavy jističe.

Antivzory a jak se jim vyhnout

Zoologická zahrada dashboardů: mnoho ručně vytvářených dashboardů bez správy a nekonzistentní názvy; řešení: systém návrhu observability a kurátorované „zlaté dashboardy“.
Únava z alertů: upozornění na každou metriku, chybějící závažnost a odpovědnost; řešení: alerting řízený SLO, deduplikace, filtry šumu.
Logy bez kontextu: logy bez trace_id/request_id; řešení: povinné korelační klíče v loggeru.
Přílišná agregace: průměry maskují odlehlé hodnoty; řešení: percentily (P90/P95/P99), histogramy s exemplars.
Slepé místo FE/RUM: pouze backendové metriky; řešení: Real User Monitoring a syntetické testy.

Příklad scénáře: náhlé zpomalení dokončení objednávky

Monitoring ohlásí nárůst latence P99 nad SLO. Observabilita umožní rozpad podle endpointu a tenanta a ukáže, že problém se vyskytuje v regionu eu-central-1 a pouze u verze build_sha=abcd. Trasování odhalí nárůst čekání na zámek databáze (DB lock wait) u konkrétní tabulky po nasazení nové migrace. Logy potvrzují zvýšenou četnost událostí deadlock_retry. Zmírňující opatření: návrat k předchozí verzi migrace, omezení souběžnosti, vytvoření nového indexu. Poučení: přidat před nasazením kontrolu dlouhotrvajících transakcí a syntetický test se souběžnou zátěží.

Bezpečnost a compliance v observabilitě

Ochrana osobních údajů: zákaz ukládání osobních údajů do logů; tokenizace/maskování, minimalizace dat.
Přístup a audit: RBAC/ABAC v nástrojích, audit dotazů a exportů, zásady uchovávání dat podle regulací.
Integrita: podepisování agentů/konfigurací, řízení sběru dat (policy-as-code).

Integrace s CI/CD a přístup „shift-left“

Kontrolní brány: testy metrik a tras v předprodukčním prostředí, upozornění na vizuální regrese, chaos experimenty v pipeline.
Události při vydání nové verze: automatické anotace časových řad a tras podle verze/příznaku funkce.
Ochranné mechanismy: automatické pozastavení postupného nasazování 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, alertingu řízeného SLO, kontextových korelací a ekonomického modelu dat, dosahují nižšího MTTR, vyšší spolehlivosti a lepšího rozhodování o produktu. Rozdíl mezi monitoringem a observabilitou nespočívá v nástrojích, ale v hloubce otázek, které si dokážeme položit – a zodpovědět.