Technologie

Centralizované logování pomocí ELK stacku: Metodika a architektura

Ján Gašparík 0

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ě uchovávat, 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 troubleshootingu přes bezpečnostní dohled až po proaktivní alertová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, container stdout) a odesílá je do Logstash nebo přímo do ingest uzlů Elasticsearch.
  2. Logstash provádí složitější parsování, obohacení a směrování (pipeline input → filter → output).
  3. Elasticsearch ukládá a indexuje dokumenty, aplikuje ingest pipeline, Index Lifecycle Management (ILM) a poskytuje rozhraní pro vyhledávání a agregace.
  4. Kibana vizualizuje data (Lens, Dashboards, Canvas, Maps), spravuje alerty a bezpečnostní spaces.

Pro vysokou zátěž se role uzlů rozdělují na: hot ingest uzly (ingest pipeline, indexování), coordinating (zpracování dotazů), master (správa metadat) a úložišťově orientované warm/cold/frozen uzly.

ECS a datové modely: základ pro interoperabilitu

Elastic Common Schema (ECS) sjednocuje pojmenování polí (např. @timestamp, event.dataset, host.name, log.file.path, trace.id, http.response.status_code), což umožňuje opakované využití dashboardů, korelaci a sdílené detekce. Doporučení: logujte strukturovaně (JSON) a mapujte data do ECS již na okraji (moduly Beats, integrace agentů) nebo v ingest pipeline.

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

Nestrukturovaný text je křehký. Zavádějte JSON se stabilními klíči, úrovněmi (log.level) a korelačními ID (trace.id, transaction.id, session.id) napříč službami. Tím získáte možnost click-through 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 přes Fleet (Kibana). Pro kontejnery se používá DaemonSet na Kubernetes, čtení ze /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í, obohacení, směrování

Logstash exceluje u komplexních transformací (stateful, enrich filtry, 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}"
  }
}

Indexovací strategie: data streams, aliasy, vzory a šablony

Doporučený moderní přístup představují 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átory, 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 teplotní tiering

Index Lifecycle Management (ILM) automatizuje rollover (např. po 30 GB/1 dnu), přesun do warm/cold/frozen tierů, shrink, forcemerge a mazání po uplynutí retenční doby. Tím výrazně snižujete náklady bez ztráty možností 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 málem (např. 1–2 shardů na index) a řiďte se pravidlem cca 20–50 GB/shard. Repliky ≥1 pro dostupnost a zrychlení čtení.
  • Refresh interval: pro ingest navyšte (např. na 5–30 s), abyste snížili fragmentaci segmentů a I/O zátěž.
  • Heap: přidělte ~50 % RAM (maximálně cca 31 GB na JVM kvůli compressed OOPs), zbytek ponechte pro FS cache.
  • Doc values používejte pro agregovaná pole, deaktivujte _all a nepotřebná stored fields.
  • Profilování pipeline: sledujte pomalé procesory (simulate, ingest node stats), optimalizujte grok regexy.

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

Základ představuje TLS všude (shipper → Logstash/Elasticsearch, Elasticsearch ↔ Kibana, komunikace mezi uzly), Role-Based Access Control (role pro čtení/psaní/administraci), API klíče pro integrace a Spaces v Kibana pro logické oddělení týmů. Provádějte audit administrativních akcí a přístupů, logy ukládejte do samostatného tenancy.

Vizualizace a explorace v Kibana

Kibana poskytuje Discover pro ad-hoc vyhledávání, Lens pro tvorbu vizualizací, Dashboardy a Canvas pro vyprávění příběhů. Data Views mapují aliasy a datastreamy na UI. Pro geografická data využívejte Maps se geo_point a geo_shape. Udržujte saved searches a sdílené filtry (kupony) pro týmy.

Alerting a detekce anomálií

V Kibana definujete pravidla na základě dotazů (KQL/Lucene) nebo metrik (agregace). Notifikace lze zasílat e-mailem, webhookem, Slackem, PagerDuty apod. Pro behaviorální detekci použijte anomaly detection (strojové učení) nad časovými řadami (např. odchylky chybovosti HTTP 5xx, latence). Kritické alerty musí mít runbook a tlačítko pro tlumení šumu.

APM a OpenTelemetry: logy, metriky a trace dohromady

Pro hlubší korelaci integrujte Elastic APM nebo OpenTelemetry Collector, který směruje trace a metriky do Elasticsearch. Zachyťte trace.id v logu (MDC/strukturované logování) a v Kibana propojte vzájemně Logs <→ APM. Získáte tak cestu „od 5xx v logu“ až po konkrétní span s pomalou SQL nebo HTTP operací.

Kubernetes a ECK: provoz ELK v cloudu

Pro nasazení na Kubernetes využijte ECK (Elastic Cloud on Kubernetes) operátor, který spravuje ES/Kibana/Beats custom resources, certifikáty a škálování. Sběr logů zajišťuje Filebeat/Agent DaemonSet, modul kubernetes přidává metadata (namespace, pod, kontejner), hints umožňují automatickou detekci.

Governance, náklady a retence

  • Retenční politika separátně pro jednotlivé datasety (produkce, non-produkce, bezpečnost).
  • Filtrace u zdroje: eliminujte šum, debug logy v produkci povolujte jen s samplingem.
  • Deduplikace (hash fingerprint), komprese na transportu, optimalizujte 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 přes aliasy a zero-downtime přepnutí write_index. Využijte _reindex do nového datastreamu, validujte dotazy a dashboardy v paralelním shadow prostředí. Při sjednocování historických dat mějte na paměti rozdíly analyzérů a typů keyword vs. text.

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

  • Příliš mnoho shardů (over-sharding) → nízký výkon a zvýšené nároky na paměť. Začínejte konzervativně a řiďte se ILM.
  • Nestrukturované texty bez kontextu → investujte do ECS a JSON logů.
  • Debug logy bez retence → filtrujte u zdroje, zavádějte sampling a krátkou retenci.
  • Chybějící TLS/RBAC → implementujte bezpečnost od prvního dne, auditujte přístupy.
  • Příliš komplexní grok regexy v ingest pipeline → preferujte dissect a stabilní formáty.

Minimalistický referenční design

  1. 3× ES hot ingest uzly (data_hot, coordinating), 3× master, 2× warm, 1× cold; snapshot repo v objektovém úložišti.
  2. 2× Logstash s vysokou dostupností za load balancerem (nebo čisté ingest pipelines).
  3. Filebeat/Agent na každém hostiteli/podu, s TLS mutual auth.
  4. ILM: rollover 30 GB/1d, warm 7d, cold 30d, delete 180d; dashboardy a alerty v Kibana Spaces per tým.

Checklist pro produkční ELK

  • Strukturované logy v ECS + korelační ID.
  • Data streams, index templates, ILM + tiering.
  • TLS všude, RBAC, audit logy, API klíče pro integrace.
  • Observabilita stacku: _cluster/health, _nodes/stats, metriky ingest uzlů, metriky Logstash pipeline.
  • Alerty na ingest backlog, diskové prahy, chybovost, pomalé dotazy.
  • Snapshoty a pravidelné restore testy.

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

ELK stack je prověř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ý poskytuje rychlou diagnostiku i strategické vhledy. Propojením s APM a OpenTelemetry sjednotíte logy, metriky a trace do jediné reality a posunete se od reaktivního řešení incidentů k proaktivnímu řízení spolehlivosti a nákladů.

Ján Gašparík

Website:

Related Story