Logování a observabilita

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 prahy, 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 cenu (objem, uložení).
• Metriky: číselné časové řady s nízkou kardinalitou (QPS, latence p50/p95/p99, chybovost). Ideální pro SLO/alerting a trendy.
• Trace: graf průchodu požadavku napříč službami, rozpad na spany s časovými razítky. Odpovídají na „kde jsme čas ztratili“.
• Události: méně časté, semanticky bohaté signály (nasazení, feature flag změny, failover, škálování), které dá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í 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…), udržujte schema registry.
• Správné úrovně: DEBUG (vývoj/diagnostika), INFO (běžné dění), WARN (degradace), ERROR (pád dílčí operace), FATAL (kolaps služby). Eliminujte „log spam“.
• Kontext vs. obsah: krátké, srozumitelné msg + bohatý kontext v polích. Vyhněte se vytváření parsovatelných textů v msg.
• Čas a časová zóna: logujte v UTC s ISO 8601, synchronizujte čas (NTP/PTP).

Minimalizace šumu a nákladů

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

OpenTelemetry a standardizace

OpenTelemetry (OTel) sjednocuje tracing, metrics, logs přes SDK/auto-instrumentaci a OTLP protokol. 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 transport

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

Observabilita v cloudu a Kubernetes

• K8s kontext: enrichujte logy o namespace, pod, container, node, image, deployment, revision.
• Podmíněná verbóznost: dynamické přepínání úrovní logování přes config map či feature flag bez redeploye.
• HPA a autoscaling: metriky (CPU, paměť, aplikační QPS/latence) jako signály pro škálování; pozor na metric lag.
• eBPF a network observability: bez-invazivní sběr síťových toků, latencí a chyb TCP/HTTP na úrovni kernelu.

SLI/SLO/SLAs a error budget

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

Navrhování metrik a dashboardů

• USE & RED metodiky: Utilization, Saturation, Errors (infrastruktura) a Rate, Errors, Duration (služby) jako 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: ke každému panelu přiložte krokovaný postup řešení a kontakty (on-call, eskalace).

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

• Akční a bezpečné: místo „NullPointer“ logujte „Nenačten customer – customer_id chybí“; nikdy nevypisujte tajné hodnoty (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

• Data minimization: logujte jen to, co potřebujete. Zakrývejte PII/PHI (masking, tokenizace) už na agentovi.
• RBAC/ABAC a audit logy: oddělte provozní logy od auditních (nezměnitelnost, retenční a právní požadavky).
• Šifrování: TLS v transportu, šifrování „at rest“, řízená správa klíčů (KMS/HSM).
• Právo na výmaz: u PII mějte proces a indexy pro cílené smazá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, vazba na trace.

Testování a kvalita observability

• Contract & e2e testy: validujte, že instrumentace vzniká ve 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í.
• Load testy: měřte p99/p999, sledujte saturation a kapacitu backendů observability (ingest limity).

Nákladová efektivita (FinOps pro observabilitu)

• Retence a tiering: odlišné doby uchování pro aplikační logy, audit, trace a metriky.
• Selektivní ingest: vypínejte nepotřebné služby, filtrace na kolektoru, drop long-tail klíčů s nízkým přínosem.
• On-demand rehydratace: levný archiv + dočasné 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: u incidentu korelujte nasazení, konfigurace, metriky, trace a logy do jedné osy času.
• 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, limity baterie a dat, privátní údaje – striktní anonymizace.
• 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“ je slepá ulička.
• Debug v produkci „navždy“: vysoké náklady a riziko úniku dat.
• Alert fatigue: stovky pravidel bez vazby na SLO → ignorované alarmy.
• „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řiložte runbooky.
• Upravte sampling (tail-based pro anomálie), nastavte retence a úložišťové tieringy.
• Zabezpečte data (masking PII, RBAC, šifrování, audit), oddělte tenanty.
• Automatizujte dashboardy a testy observability (CI/CD validace instrumentace).
• Propojte události (deploy, feature flags) s metrikami/trace pro rychlé root cause.

Závěr

Logování a observabilita nejsou jen 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, zvyšovat spolehlivost a doručovat lepší uživatelskou zkušenost. Silná observabilita se projeví 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.