Sběr a analýza logů v IT systémech

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 apod.) 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:

Emise – aplikace zapisuje strukturovaný JSON na stdout.
Agent/sidecar – Fluent Bit, Vector, Filebeat snímají logy (tail), přidávají metadata (host, pod, namespace) a odesílají dál.
Transportní vrstva – přímé HTTP/gRPC do úložiště nebo přes buffer (např. Kafka/NATS) pro odolnost a škálování.
Zpracování – obohacení (geoIP, uživatel, release), maskování PII, deduplikace, normalizace schématu.
Úložiště a indexace – sloupcové TS úložiště, fulltextový 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 těla požadavků.
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 pouze to, co má diagnostickou hodnotu.

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

Head-based sampling – rozhodnutí v místě emise (levné, ale bez znalosti pozdějšího dopadu).
Tail-based sampling – rozhodnutí po vyhodnocení (např. preferovat chyby a výjimky).
Dynamic sampling – adaptivně podle SLA, latence, místa incidentu či tenantu (férové sdílení kapacity).

Odolnost pipeline a ztrátovost

Agenti s diskovým bufferem (filesystem) pro případ přerušení sítě.
Backpressure – regulace rychlosti při zahlcení úložiště; preferujte „fail-open“ pro nekritické logy a „fail-closed“ pro auditní záznamy.
Idempotentní ingest a deduplikace pomocí event.id a časového okna pro opakování.

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

Fulltext + inverzní index – flexibilní dotazy, vyšší náklady na zápis a paměť (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 – fulltextové vyhledávání, filtry, agregace (terms, date histogram), pipeline procesory.
LogQL – výběr podle štítků + 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 časovém okně, výskyt konkrétního kódu/hlášky) a zónové prahy (pro službu/tenanta).
Watchlisty/IOC (bezpečnost) – 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 propojením na logy při anomálii.

Auditní a forenzní logy

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

Retence, tiering a náklady

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

Bezpečnost přístupu a compliance

RBAC/ABAC – přístup podle 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, pravidelná 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/entropii).

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

Standard logů: JSON, UTC, povinná pole (čas, level, service, env, trace_id, message), mapování na ECS/OTel.
Emise: knihovna loggeru s middlewarem, který propisuje trace_id z HTTP hlaviček (např. traceparent).
Agent: DaemonSet (K8s) s Fluent Bit/Vector, parsování JSON, obohacení o kubernetes.* metadata, maskování PII.
Transport: OTLP/HTTP → broker (Kafka) s retencí 24–72 h; témata podle služby a úrovně.
Zpracování: stream procesor (Flink/KStreams) – obohacení, deduplikace, validace schématu, směrování do úložišť.
Úložiště: hot index (7 dní) + cold objektové úložiště (90 dní) + dlouhodobý lake (12 měsíců).
Observabilita: dashboardy, alerty na derived metrics, propojení s tracingem (zpětné odkazy).
Governance: ILM, RBAC, audity, náklady, pravidelné čištění a revize 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","