Sběr a analýza logů

Proč systematicky sbírat a analyzovat logy

Logy jsou nejdostupnějším zdrojem pravdy o chování aplikací a infrastruktury. Slouží k odhalování incidentů, výkonových problémů, bezpečnostních událostí i k produktové analytice. Kvalitní logování vyžaduje promyšlené schéma, pipeline sběru, úložiště, dotazovací jazyk a governance (retence, ochrana dat, náklady). Cílem je pozorovatelnost (observabilita): schopnost porozumět interním stavům systému na základě externích výstupů bez invazivního zásahu do běhu.

Typy logů a použití

• Aplikační logy – události, chyby, business doména (objednávka, platba), metriky v textové podobě.
• Přístupové logy – HTTP reverse proxy, API gateway, WAF; klíčové pro latence, kódy a identitu volajícího.
• Systémové a infrastrukturní logy – kernel, init/servisní manažery, kontejnery, orchestrátory.
• Bezpečnostní logy – autentizace, autorizace, auditní stopy, anomálie.
• Databázové logy – slow query, deadlocky, plánovače; vodítko pro optimalizaci.

Principy dobrého logování

• Strukturované logy – JSON/NDJSON s jasným schématem místo volného textu.
• Stabilní schéma – evoluce přes verzování; pole nemažte, spíše označte jako deprecated.
• Kontext – trace_id, span_id, correlation_id, identita uživatele/tenantu, verze buildů a prostředí.
• Čitelnost vs. strojová zpracovatelnost – lidský message + strukturovaná data pro dotazy.
• Mezinárodní prostředí – ISO 8601 časy v UTC; čitelné klíče v angličtině.

Úrovně závažnosti a kategorizace

• TRACE – detailní diagnostika (vypínatelná na produkci, případně vzorkovaná).
• DEBUG – informace pro vývojáře; vypínatelná dle služby.
• INFO – běžné události („objednávka vytvořena“).
• WARN – neblokující problémy, anomálie.
• ERROR – selhání požadavku/operace.
• FATAL – fatální chybový stav vyžadující restart/eskalaci.

Schéma strukturovaných logů

Doporučené minimální pole:

• timestamp (UTC ISO 8601 s milisekundami), level, message, logger/service, env, version.
• trace_id, span_id, correlation_id pro vazbu na distributed tracing.
• http.method, http.path, http.status_code, latency_ms, client.ip.
• user.id/tenant.id/session.id s ohledem na GDPR/PII.

Využívejte standardizované konvence (např. pole pojmenovaná s tečkovou notací), aby bylo možné logy snadno mapovat do indexů a dotazovacích polí.

Standardy a interoperabilita

• OpenTelemetry (OTel) Logs – jednotná semantika pro logy, metriky a trace včetně přenosu přes OTLP.
• ECS (Elastic Common Schema) – standardizovaná pole (event.*, http.*, user.*, cloud.*), usnadňuje sdílené dotazy a vizualizace.

Emise logů: knihovny, formát a výkon

• Preferujte structured logger (Monolog s JSON procesorem, Serilog/Pino/Bunyan ap.) s asynchronním výstupem.
• Logujte na stdout/stderr u kontejnerů; vyhněte se rotaci uvnitř aplikace.
• Minimalizujte alokace a serializace; používejte message templates (parametrizované zprávy) a lazy-evaluated pole.

Logovací pipeline: sběr, transport, zpracování

Typická topologie:

1. Emise – aplikace zapisuje strukturovaný JSON na stdout.
2. Agent/sidecar – Fluent Bit, Vector, Filebeat snímají logy (tail), přidávají metadata (host, pod, namespace) a odesílají dál.
3. Transportní vrstva – přímé HTTP/gRPC do úložiště nebo přes buffer (např. Kafka/NATS) pro odolnost a škálování.
4. Processing – obohacení (geoIP, uživatel, release), maskování PII, deduplikace, normalizace schématu.
5. Úložiště a indexace – sloupcové TS úložiště, fulltext index, objektové úložiště pro „teplá/studená“ data.

Ochrana dat: PII, maskování a redakce

• Nikdy nelogujte tajemství (tokeny, hesla, API klíče). Zaveďte request/response scrubbery pro citlivé hlavičky a body.
• PII (e-mail, telefon, adresa, IP) maskujte nebo hashujte (HMAC s rotovaným klíčem) dle účelu.
• Udržujte data classification a data minimization – logujte jen to, co má diagnostickou hodnotu.

Vzorkování (sampling) a řízení objemu

• Head-based sampling – rozhodnutí v místě emise (levné, ale bez znalosti dopadu).
• Tail-based sampling – rozhodnutí po vyhodnocení (např. preferovat chyby a outliery).
• Dynamic sampling – adaptivně podle SLA, latence, místa incidentu či tenantu (fair share).

Odolnost pipeline a ztrátovost

• Agenti s disk bufferem (filesystem) pro přerušení sítě.
• Backpressure – regulace rychlosti při zahlcení úložiště; preferujte „fail-open“ pro non-kritické logy a „fail-closed“ pro auditní stopy.
• Idempotentní ingest a deduplikace pomocí event.id a okna pro opakování.

Úložiště a indexace: volby a kompromisy

• Fulltext + inverzní index – flexibilní dotazy, vyšší náklady na zápis a RAM (příklad: ELK, OpenSearch).
• Časové série – optimalizováno na časový rozsah a agregace (např. Loki s indexem štítků + objektové úložiště pro obsah).
• Data lake – dlouhodobá retence v objektovém úložišti (Parquet), nad tím SQL/Trino/BigQuery pro ad-hoc analýzy.

Dotazovací jazyky a analytika

• Lucene/KQL – fulltext, filtry, agregace (terms, date histogram), pipeline procesory.
• LogQL – label-based výběr + regex/line filter, rate a count_over_time funkce.
• SQL nad logy – federované dotazy (externí tabulky, Parquet), spojení s metadaty (tenanti, release).

Propojení s tracingem a metrikami

Logy by měly nést trace/span identifikátory pro pivot mezi vrstvami observability. Umožní to přechod z chybného požadavku (trace) na detailní kontext (log) a zpět. Z logů lze odvozovat „derived metrics“ (počet chyb za minutu, P95 latence) pro alerting.

Alerting a detekce anomálií

• Pravidla nad logy (počet ERROR v okně, výskyt konkrétního kódu/hlášky) a zónové prahy (per service/tenant).
• Watchlisty/IOC (security) – detekce podezřelých IP, user-agentů, signatur útoků.
• Statistické a ML metody – robustní baseline, zjištění odchylek (spikes, změny vzoru hlášení).

Dashboardy a provozní pohledy

• „Golden signals“ – chybovost, latence, propustnost, saturace; drill-down na službu, endpoint, tenant.
• Chybové rozložení dle příčiny (kód, výjimka, downstream služba).
• Mapy toků požadavků (service map) s přechodem do logů při anomálii.

Auditní a forenzní logy

• Imutabilita – WORM úložiště, podpisy, časová razítka.
• Jemnozrnná granularity: kdo, kdy, co, odkud, s jakým výsledkem.
• Oddělené retence a přístupová práva od běžných operativních logů.

Retence, tiering a náklady

• Krátká hot retence (dny) v indexu pro operativu; delší warm/cold v levnějším úložišti.
• Automatické lifecycle policies (rollover, shrink, delete) a ILM joby.
• Cardinality management – rozumný počet štítků/klíčů, omezit unikátní kombinace (např. user.id do pole, ne do labelu).

Bezpečnost přístupu a compliance

• RBAC/ABAC – přístup dle role, týmu, tenantu; row/field level security pro citlivá pole.
• Šifrování v klidu i při přenosu; správa klíčů v KMS, rotace.
• Záznam přístupů a dotazů nad logy pro audit; jasná pravidla pro sdílení dat.

Testování kvality logů

• Contract tests schématu logů (existence povinných polí, typy, rozsahy).
• End-to-end testy pipeline (syntetické události → agent → úložiště → dotaz → alert).
• Validace maskování PII a absence tajemství (skener na regexy/entropy).

Procesy a governance

• „Logging guidelines“ v repozitáři; code review kontroluje úrovně a obsah zpráv.
• „Runbooks“ – jak reagovat na typické chybové vzory, jak provést korelaci.
• Vlastnictví dashboardů a alertů (on-call), pravidelné tuning sessions pro snižování šumu.

Anti-patterny v logování

• „Log spam“ – nadměrné DEBUG/TRACE v produkci bez samplingů.
• Interleaving multiline stack trace bez multiline parseru (řešit jako strukturovaná pole).
• Logování PII/secrets, přístupových tokenů a kompletních payloadů bez filtrace.
• Chybějící korelační identifikátory a kontext; nemožnost propojit požadavky.

Praktický blueprint implementace

1. Standard logů: JSON, UTC, povinná pole (čas, level, service, env, trace_id, message), mapování na ECS/OTel.
2. Emise: knihovna loggeru s middlewarem, který propisuje trace_id z HTTP hlaviček (např. traceparent).
3. Agent: DaemonSet (K8s) s Fluent Bit/Vector, parsování JSON, obohacení o kubernetes.* metadata, maskování PII.
4. Transport: OTLP/HTTP → broker (Kafka) s retencí 24–72 h; témata podle služby a úrovně.
5. Processing: stream procesor (Flink/KStreams) – enrich, dedupe, schema validation, routing do úložišť.
6. Úložiště: hot index (7 dní) + cold objektové úložiště (90 dní) + dlouhodobý lake (12 měsíců).
7. Observabilita: dashboardy, alerty na derived metrics, propojení s tracingem (backlinks).
8. Governance: ILM, RBAC, audity, cost reporty, pravidelné čištění a review pravidel.

Ukázka strukturované log události

Minimalistický příklad (NDJSON):

{ "timestamp":"2025-10-26T21:15:42.137Z", "level":"ERROR", "service":"checkout-api", "env":"prod", "version":"1.42.0", "trace_id":"f9f9a3f2e1a64ea2", "span_id":"9c1b7d0a3c1f4f8e", "correlation_id":"ord-8b2a4", "http":{"method":"POST","path":"/v1/orders","status_code":502,"latency_ms":842}, "user":{"id_hash":"caa1f8..."}, "error":{"type":"UpstreamError","message":"payments timeout","stack":"..."}, "message":"Order submission failed due to upstream timeout" }

Migrace z nestrukturovaných logů

• Zaveďte dual-write (původní i strukturované logy) a testujte dotazy nad oběma formami.
• Postupně přepisujte volání loggeru na message templates + fields; omezte regex parsování v ingest fázi.
• Vybudujte kompatibilní schéma a mapování (aliasy) pro staré klíče.

Měření efektivity logování

• Signal-to-noise ratio – poměr relevantních alertů k celkovému počtu.
• MTTD/MTTR – doba od vzniku chyby k detekci/obnově, před a po zavedení standardu.
• Cena na GB a na užitečný incident – řízení rozpočtu a dopad optimalizací (sampling, tiering).

Závěr: logy jako páteř observability

Systematické logování přináší prediktivní provoz, rychlou diagnózu incidentů a lepší produktová rozhodnutí. Klíčové je strukturovat události, obohacovat je o korelační kontext, bezpečně a efektivně je transportovat a ukládat, a nad nimi vybudovat analýzu, alerting a governance. Logy se tak stávají spolehlivou vrstvou, která propojuje metriky, tracing i bezpečnostní dohled do jednotného, auditovatelného a nákladově udržitelného ekosystému.