Centralizované logování pomocí ELK stacku: analýza

DevOps, automatizace a observabilita
Natália Šimková
Centralizované logování pomocí ELK stacku: Analýza

Proč centralizovat logy pomocí ELK

Centralizované logování konsoliduje aplikační, systémové a síťové záznamy na jedno místo, kde je lze bezpečně ukládat, vyhledávat, vizualizovat a automaticky vyhodnocovat. ELK stack (Elasticsearch, Logstash, Kibana) doplněný o Beats/Elastic Agent tvoří škálovatelnou platformu pro observabilitu: od ad hoc řešení problémů přes bezpečnostní dohled až po proaktivní upozorňování a dlouhodobou analytiku.

Architektura ELK: role komponent a datové toky

Typický tok dat:

  1. Shipper (Filebeat/Elastic Agent/Fluent Bit) čte logy (soubor, journald, stdout kontejneru) a posílá je do Logstash nebo přímo do ingest uzlů Elasticsearch.
  2. Logstash provádí složitější parsování, obohacování a směrování (pipeline input → filter → output).
  3. Elasticsearch ukládá a indexuje dokumenty, aplikuje ingest pipeline a ILM a poskytuje rozhraní pro vyhledávání a agregace.
  4. Kibana vizualizuje data (Lens, Dashboards, Canvas, Maps), spravuje upozornění a bezpečnostní spaces.

Při vysokém zatížení se oddělují role uzlů: uzly hot ingest (ingest pipeline, indexování), coordinating (dotazy), master (metadata) a uzly zaměřené na úložiště warm/cold/frozen.

ECS a datové modely: základ interoperability

Elastic Common Schema (ECS) sjednocuje názvosloví polí (např. @timestamp, event.dataset, host.name, log.file.path, trace.id, http.response.status_code), což umožňuje opakovaně používat dashboardy, korelovat data a sdílet detekční pravidla. Doporučení: zaznamenávejte data strukturovaně (JSON) a mapujte je do ECS již na okraji (moduly Beats, integrace agenta) nebo v ingest pipeline.

Strukturované logování a korelační identifikátory

Nestrukturovaný text je křehký. Zaveďte JSON se stabilními klíči, úrovněmi (log.level) a korelačními ID (trace.id, transaction.id, session.id) napříč službami. Získáte tak možnost přejít kliknutím z logu na trace a naopak (propojení s APM/OpenTelemetry).

Shippery: Filebeat, Elastic Agent a sběr v kontejnerech

Filebeat je lehký agent s moduly pro běžné technologie (nginx, system, mysql). Elastic Agent sjednocuje sběr logů, metrik a APM a centrálně se spravuje prostřednictvím Fleet (Kibana). Pro kontejnery se používá DaemonSet v Kubernetes, čtení z /var/log/containers a hints z anotací podů.

# Filebeat: základní prospector filebeat.inputs: - type: filestream id: app-json paths: [/var/log/app/*.log] parsers: - ndjson: target: "" add_error_key: true setup.template.enabled: false output.elasticsearch: hosts: ["https://es-hot-1:9200","https://es-hot-2:9200"] ssl.certificate_authorities: ["/etc/filebeat/ca.crt"] indices: - index: logs-app-%{+yyyy.MM.dd}

Logstash a ingest pipeline: parsování, obohacování, směrování

Logstash vyniká při komplexních transformacích (stavové zpracování, filtry pro obohacování, agregace), zatímco ingest pipeline v Elasticsearch je rychlá a škálovatelná pro běžné procesory (grok, dissect, geoip, user_agent, set, rename, date, fingerprint).

# Logstash pipeline (zkráceně) input { beats { port => 5044 ssl => true } } filter { json { source => "message" target => "@" skip_on_invalid_json => true } mutate { rename => ["@.level","log.level"] remove_field => ["message","@"] } date { match => ["@timestamp","ISO8601"] } fingerprint { source => ["log.file.path","log.offset"] target => "event.hash" method => "SHA1" } } output { elasticsearch { hosts => ["https://es-hot-1:9200"] index => "logs-app-%{+yyyy.MM.dd}" } }

Strategie indexování: data streams, aliasy, vzory a šablony

Doporučeným moderním přístupem jsou data streams pro časové řady logů. Každý stream má backing indices a alias s write_index. Používejte component templates pro mapování a nastavení (analyzéry, dynamic_templates, routing) a index template pro nasazení.

{ "index_patterns": ["logs-app-*"], "data_stream": { }, "composed_of": ["comp-mappings-ecs","comp-settings-logs"], "priority": 200 }

ILM: životní cyklus indexů a tiering podle teplotních úrovní

Index Lifecycle Management (ILM) automatizuje rollover (např. po 30 GB/1 dnu), přesun do úrovní warm/cold/frozen, shrink, forcemerge a mazání po uplynutí retenční doby. Tím výrazně omezíte náklady, aniž byste přišli o možnosti forenzní analýzy.

{ "policy": { "phases": { "hot": { "actions": { "rollover": { "max_size": "30gb", "max_age": "1d" } } }, "warm": { "min_age": "7d", "actions": { "allocate": {"include": {"_tier_preference": "data_warm"}}, "shrink": { "number_of_shards": 1 }, "forcemerge": { "max_num_segments": 1 } } }, "cold": { "min_age": "30d", "actions": { "allocate": {"include": {"_tier_preference": "data_cold"}} } }, "delete":{ "min_age": "180d","actions": { "delete": {} } } }}}

Škálování a ladění výkonu

  • Shardování: začínejte s malým počtem shardů (např. 1–2 shards/index) a řiďte se pravidlem přibližně 20–50 GB/shard. Pro dostupnost a čtení nastavte alespoň 1 repliku.
  • Refresh interval: pro ingest jej prodlužte (např. na 5–30 s), abyste omezili fragmentaci segmentů a I/O.
  • Heap: přibližně 50 % RAM (max. přibližně 31 GB na JVM kvůli compressed OOPs), zbytek ponechte pro FS cache.
  • Doc values používejte pro agregovaná pole, vypněte _all a nepotřebné stored fields.
  • Profilování pipeline: sledujte pomalé procesory (simulate, ingest node stats) a optimalizujte regulární výrazy grok.

Bezpečnost: šifrování, RBAC, izolace tenantů

Základem je TLS všude (shipper → Logstash/ES, ES ↔ Kibana, mezi uzly), řízení přístupu na základě rolí (role pro čtení/zápis/administraci), klíče API pro integrace a Spaces v Kibana pro logické oddělení týmů. Provádějte audit administrativních akcí a přístupů a ukládejte logy do samostatného tenanta.

Vizualizace a prozkoumávání dat v Kibana

Kibana nabízí Discover pro ad hoc vyhledávání, Lens pro vizualizace, Dashboards a Canvas pro storytelling. Data Views mapují aliasy/datastreamy do uživatelského rozhraní. Pro geografická data využijte Maps s geo_point/geo_shape. Udržujte saved searches a sdílené filtry pro týmy.

Upozorňování a detekce anomálií

V Kibana definujete pravidla nad dotazy (KQL/Lucene) nebo metrikami (agregace). Oznámení lze posílat e-mailem, webhookem, přes Slack, PagerDuty apod. Pro behaviorální detekci použijte anomaly detection (ML) nad časovými řadami (např. odchylky v chybovosti HTTP 5xx nebo latenci). Kritická upozornění musí mít runbook a tlačítko pro potlačení šumu.

APM a OpenTelemetry: logy, metriky a trace dohromady

Pro hlubší korelaci zapojte Elastic APM nebo OpenTelemetry Collector, který odesílá trace a metriky do Elasticsearch. Zaznamenávejte trace.id v logu (MDC/strukturované logování) a v Kibana propojte Logs <→ APM. Získáte cestu od chyby 5xx v logu až ke konkrétnímu spanu s pomalou operací SQL/HTTP.

Kubernetes a ECK: provoz ELK v cloudu

Pro nasazení v Kubernetes využijte operátor ECK (Elastic Cloud on Kubernetes), který spravuje vlastní prostředky ES/Kibana/Beats, certifikáty a škálování. Sběr logů zajišťuje Filebeat/Agent DaemonSet; modul kubernetes přidává metadata (namespace, pod, container) a hints umožňují automatické vyhledávání služeb.

Správa, náklady a retence

  • Retenční politika pro každý dataset (prod, non-prod, security).
  • Filtrování u zdroje: odstraňte šum, debug logy v produkci používejte jen se samplingem.
  • Deduplikace (hash fingerprint), komprese při přenosu, optimalizace pipeline.batch.size.
  • Tiering a snapshot/restore (S3/objektové úložiště) pro dlouhodobý archiv a forenzní obnovu.

Migrace, reindexace a změny schématu

Při změně mapování nebo ILM postupujte prostřednictvím aliasů a přepnutí write_index bez odstávky (zero-downtime). Pomocí _reindex přesuňte data do nového datastreamu a ověřte dotazy a dashboardy v paralelním prostoru shadow. Při sjednocování historických dat mějte na paměti rozdíly mezi analyzéry a poli keyword a text.

Nejčastější chyby a jak se jim vyhnout

  • Příliš mnoho shardů (nadměrné shardování) → nízký výkon a vysoké nároky na paměť. Začínejte konzervativně a řiďte se ILM.
  • Nestrukturovaný text bez kontextu → investujte do ECS a JSON logů.
  • Debug logy bez retenční politiky → filtrujte u zdroje, zaveďte sampling a krátkou retenční dobu.
  • Chybějící TLS/RBAC → zaveďte bezpečnost od prvního dne a auditujte přístup.
  • Příliš komplexní výrazy grok při ingestu → upřednostňujte dissect a stabilní formáty.

Minimalistický referenční návrh

  1. 3× ES hot ingest uzly (data_hot, coordinating), 3× master, 2× warm, 1× cold; repozitář snapshotů v objektovém úložišti.
  2. 2× Logstash s vysokou dostupností za load balancerem (nebo pouze ingest pipelines).
  3. Filebeat/Agent na každém hostiteli/podu, vzájemné ověřování TLS.
  4. ILM: rollover 30 GB/1d, warm 7d, cold 30d, delete 180d; dashboardy a upozornění v Kibana Spaces pro jednotlivé týmy.

Kontrolní seznam pro produkční ELK

  • Strukturované logy v ECS + korelační ID.
  • Data streams, index templates, ILM + tiering.
  • TLS všude, RBAC, auditní logy, API keys pro integrace.
  • Observabilita stacku: _cluster/health, _nodes/stats, metriky ingest uzlů, metriky pipeline Logstash.
  • Upozornění na zpoždění ingestu, diskové limity, míru chyb a pomalé dotazy.
  • Snapshoty a pravidelné testy obnovy.

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

ELK stack je osvědčená platforma pro centralizované logování: kombinací strukturovaných logů, ECS, ingest pipeline, ILM a bezpečnosti získáte škálovatelný a ekonomický systém, který umožňuje rychlou diagnostiku i strategické vhledy. Propojením s APM a OpenTelemetry sjednotíte logy, metriky a trace do jednoho celku a posunete se od reaktivního řešení incidentů k proaktivnímu řízení spolehlivosti a nákladů.