Logování a observabilita systémů

Co je observabilita a proč nestačí „jen logovat“

Observabilita je schopnost systému odpovědět na otázku „co se právě děje a proč“ pouze z jeho výstupů. Tradiční monitoring sleduje známé metriky a prahové hodnoty, zatímco observabilita umožňuje zkoumat neznámé problémy (unknown unknowns) napříč vrstvami aplikace, sítí i infrastruktury. Opírá se o systematický sběr, kontextualizaci a korelaci signálů: logy, metriky, trace (rozložené požadavky), často doplněné o události a profilační data.

Pilíře observability: logy, metriky, trace, události

Logy: detailní, často textové záznamy akcí a chyb. Mají vysokou informační hodnotu, ale i náklady (objem, uložení).
Metriky: číselné časové řady s nízkou kardinalitou (QPS, latence p50/p95/p99, chybovost). Ideální pro SLO/alerting a sledování trendů.
Trace: graf průchodu požadavku napříč službami, rozpad na spany s časovými razítky. Odpovídají na otázku „kde jsme čas ztratili“.
Události: méně časté, semanticky bohaté signály (nasazení, změny feature flagů, failover, škálování), které dodávají kontext ostatním datům.

Principy kvalitního logování

Strukturované logy: logujte v JSON ({"timestamp": "...","level":"ERROR","service":"checkout","msg":"Payment failed","orderId":"...","trace_id":"..."}). Umožní to přesné filtry a agregace.
Korelace: propagujte Trace Context (W3C traceparent/tracestate) a přidávejte trace_id/span_id do každého záznamu.
Deterministická schémata: sjednoťte klíče (service, env, version, tenant, http.method, user.id…) a udržujte schema registry.
Správné úrovně: DEBUG (vývoj/diagnostika), INFO (běžné události), WARN (degradace), ERROR (pád dílčí operace), FATAL (kolaps služby). Eliminujte „log spam“.
Kontext vs. obsah: krátké a srozumitelné msg + bohatý kontext v polích. Vyhněte se vytváření parsovatelných textů v msg.
Čas a časové pásmo: logujte v UTC ve formátu ISO 8601, synchronizujte čas (NTP/PTP).

Minimalizace šumu a nákladů

Sampling: u trace použijte tail-based sampling (zachování anomálií), u logů probabilistic sampling na repetitivní záznamy.
Deduplikace a rate limiting: omezte chybové bouře (slučování identických událostí v časovém okně, log coalescing).
Úrovně úložiště: hot (SSD, krátká retence), warm (objektové úložiště), cold (archiv); uplatňujte různé retenční politiky pro různé typy signálů.
Kardinalita: vyhněte se metrikám s vysokou kardinalitou (např. labels=user_id), upřednostňujte exemplarů (exemplars) s trace_id.

OpenTelemetry a standardizace

OpenTelemetry (OTel) sjednocuje tracing, metrics, logs prostřednictvím SDK/auto-instrumentace a OTLP protokolu. Umožňuje vendor-agnostický sběr a export do různých backendů (Grafana, Prometheus, Tempo, Loki, Jaeger, Elastic, Datadog…). Sjednocená schémata (semantic conventions) zlepšují vyhledatelnost a korelaci napříč jazyky a službami.

Architektury pro sběr a přenos dat

Agent/sidecar/daemonset: lokální kolektor (např. OTel Collector, Fluent Bit) přijímá signály, provádí filtry, sampling a export.
Brána (Gateway): centralizovaný příjem se zabezpečením, multi-tenant oddělením a řízením datových toků.
Back pressure: fronty s trvalostí (disk buffer), retry s exponenciálním zpětným offem, ochrana proti ztrátám při výpadcích.

Observabilita v cloudu a Kubernetes

Kubernetes kontext: obohaťte logy o namespace, pod, container, node, image, deployment, revision.
Podmíněná verbóznost: dynamické přepínání úrovní logování prostřednictvím config map či feature flag bez nutnosti redeploye.
HPA a autoscaling: metriky (CPU, paměť, aplikační QPS/latence) jako signály pro škálování; dbejte na metric lag.
eBPF a síťová observabilita: neinvazivní sběr síťových toků, latencí a TCP/HTTP chyb na úrovni jádra.

SLI/SLO/SLAs a error budget

SLI: Service Level Indicators – měřitelné ukazatele (dostupnost, latence, validní odpovědi).
SLO: cíle kvality (např. 99,9 % dostupnost a p99 < 300 ms).
Error budget: povolený prostor pro chyby; při jeho vyčerpání omezte rizikové změny a zaměřte se na stabilitu služby.
Alerting: upozorňujte na porušení SLO (uživatelský dopad), nikoli na interní fluktuace. Používejte multi-window a multi-burn-rate pravidla.

Navrhování metrik a dashboardů

USE & RED metodiky: Utilization, Saturation, Errors (infrastruktura) a Rate, Errors, Duration (služby) tvoří páteř dashboardů.
Golden signals: latence, chybovost, provoz (QPS), nasycení (Saturation).
Exemplars & linking: proklik z píků v metrikách na konkrétní trace; z trace na související logy.
Runbooky: k jednotlivým panelům připojte krokované postupy řešení a kontaktní informace (on-call, eskalace).

Chybové hlášky, které pomáhají

Akční a bezpečné: místo „NullPointer“ logujte „Nenačten customer – chybí customer_id“; nikdy nevypisujte citlivé údaje (Authorization, password).
Kódy a kategorie: interní error codes (PAYMENT_TIMEOUT, INVENTORY_CONFLICT) usnadní analýzu a alerting.
Trace-driven troubleshooting: ID požadavku v odpovědi (Trace-Id) i v zákaznické podpoře.

Bezpečnost, soukromí a compliance

Minimalizace dat: logujte jen nezbytná data. Maskujte nebo tokenizujte PII/PHI již na agentovi.
RBAC/ABAC a auditní logy: oddělte provozní logy od auditních (nezměnitelnost, retenční a právní požadavky).
Šifrování: TLS v přenosu, šifrování „at rest“, řízená správa klíčů (KMS/HSM).
Právo na výmaz: u PII mějte zavedený proces a indexy pro cílené mazání; oddělené tenantní prostory.

Observabilita v mikroservisách a event-driven systémech

Propagace kontextu: přenášejte trace_id i přes message brokery (např. headers u Kafka, AMQP).
Asynchronní latence: měřte end-to-end dobu průchodu (produkce → konzumace → zpracování).
Outbox pattern: logujte business events deterministicky s vazbou na trace.

Testování a kvalita observability

Contract & e2e testy: validujte, že instrumentace vzniká na správných místech a obsahuje povinné klíče.
Chaos engineering: injektujte poruchy (latence, výpadky) a ověřte, že signalizace a alerty fungují.
Zátěžové testy: měřte p99/p999, sledujte saturation a kapacitu backendů observability (limity ingestu).

Nákladová efektivita (FinOps pro observabilitu)

Retence a tiering: nastavte různé doby uchování pro aplikační logy, audit, trace a metriky.
Selektivní ingest: vypínejte nepotřebné služby, používejte filtrace na kolektoru, drop long-tail klíčů s nízkou přidanou hodnotou.
On-demand rehydratace: levný archiv s možností dočasného načtení při incidentu.

Procesy: incident management a post-mortem

On-call a eskalace: jasná vlastnictví služeb, rotace, playbooky a blameless kultura.
Timeline z dat: při incidentu korelujte nasazení, konfigurace, metriky, trace a logy do jedné časové osy.
Post-mortem: měřitelné „action items“, sledování přínosu (snížení MTTR/MTTD, pokles chybovosti).

Frontend, mobil a edge observabilita

RUM (Real User Monitoring): metriky Core Web Vitals (LCP, CLS, INP), chybové události a trace do backendu.
Mobilní specifika: offline fronty, omezení baterie a dat, striktní anonymizace privátních údajů.
Edge & CDN: měřte latenci a chybovost na okraji sítě, propojte request IDs mezi CDN a originem.

Antipatterny a časté chyby

Logování výjimek bez kontextu: „stack trace bez trace_id“ vede do slepé uličky.
Debug v produkci „navždy“: vysoké náklady a riziko úniku dat.
Alert fatigue: stovky pravidel bez vazby na SLO → ignorované upozornění.
„To se nějak najde“: nestrukturované texty, chybějící schéma a standardy pojmenování.

Praktický implementační checklist

Zaveďte OpenTelemetry (tracing, metrics, logs) s jednotným schématem a propagací kontextu.
Logujte strukturovaně v JSON, přidejte trace_id, span_id, service, env, version.
Nastavte SLI/SLO, golden signals a alerty s burn-rate; připojte runbooky.
Upravte sampling (tail-based pro anomálie), nastavte retence a úrovně úložišť.
Zabezpečte data (masking PII, RBAC, šifrování, audit), oddělte tenantní prostory.
Automatizujte dashboardy a testy observability (CI/CD validace instrumentace).
Propojte události (nasazení, feature flags) s metrikami a trace pro rychlé určení příčiny (root cause).

Závěr

Logování a observabilita nejsou pouze nástroje, ale provozní disciplína. Kombinace strukturovaných logů, smysluplných metrik, distribuovaných trace a bohatého kontextu událostí – standardizovaně sbíraných (OTel), bezpečně spravovaných a nákladově řízených – umožňuje zkrátit MTTD/MTTR, zvýšit spolehlivost a doručovat lepší uživatelskou zkušenost. Silná observabilita se projevuje nejen při incidentech, ale i při rychlejším vývoji, bezpečnějších nasazeních a informovaném řízení kvality služby.