Technologie

Centralizace logování pomocí ELK stacku

Daniel 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 možné je bezpečně ukládat, vyhledávat, vizualizovat a automaticky vyhodnocovat. ELK stack (Elasticsearch, Logstash, Kibana) doplněný o Beats/Elastic Agent představuje škálovatelnou platformu pro observabilitu: od ad-hoc řešení problémů přes bezpečnostní dohled až po proaktivní alerting 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 Elasticsearch ingest uzlů.
  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, ILM a poskytuje vyhledávací a agregační rozhraní.
  4. Kibana vizualizuje data (Lens, Dashboardy, Canvas, Maps), spravuje alerty a bezpečnostní spaces.

Pro vysokou zátěž se oddělují role uzlů: hot ingest uzly (ingest pipeline, indexování), coordinating (dotazy), master (metadata) a úložně orientované warm/cold/frozen uzly.

ECS a datové modely: základ pro interoperabilitu

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žití dashboardů, korelaci a sdílené detekce. Doporučení: logujte strukturovaně (JSON) a mapujte do ECS již na okraji (Beats moduly, agent integrace) 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. Tím získáte možnost click-through z logu na trace a opačně (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é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 teplotní tiering

Index Lifecycle Management (ILM) automatizuje rollover (např. po 30 GB nebo 1 dnu), přesun do warm/cold/frozen tierů, shrink, forcemerge a mazání po uplynutí retenční doby. Tím zásadně omezujete 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 malým počtem (např. 1–2 shards na index) a řiďte se pravidlem přibližně 20–50 GB na shard. Repliky ≥1 zajistí dostupnost a rychlost čtení.
  • Refresh interval: při ingest navyšte interval (např. 5–30 s), abyste snížili fragmentaci segmentů a I/O zátěž.
  • Heap: nastavte přibližně 50 % RAM (maximálně cca 31 GB pro JVM kvůli compressed OOPs), zbytek nechte pro FS cache.
  • Doc values používejte pro agregovaná pole, vypněte _all a nepotřebná stored fields.
  • Pipeline profiling: monitorujte pomalé procesory (simulate, ingest node stats), optimalizujte grok regulární výrazy.

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

Základem je TLS všude (shipper → Logstash/ES, ES ↔ Kibana, komunikace mezi uzly), Role-Based Access Control (role pro čtení, zápis, správu), API klíče pro integrace a Spaces v Kibana pro logické oddělení týmů. Auditujte administrativní akce a přístupy, logy ukládejte do separátního tenancy.

Vizualizace a explorace v Kibana

Kibana poskytuje Discover pro ad-hoc vyhledávání, Lens pro vizualizace, Dashboardy a Canvas pro vyprávění příběhů. Data Views mapují aliasy/datastreamy do UI. Pro geodata využijte Maps s geo_point a geo_shape. Udržujte saved searches a sdílené filtry (tzv. kupony) pro týmy.

Alerting a detekce anomálií

V Kibana definujete pravidla založená na dotazech (KQL/Lucene) nebo metrikách (agregace). Notifikace lze zasílat e-mailem, webhookem, Slackem, PagerDuty apod. Pro behaviorální detekci využijte anomaly detection (strojové učení) nad časovými řadami (např. odchylky v chybovosti HTTP 5xx, latenci). Kritické alerty 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ý směruje trace a metriky do Elasticsearch. Zachyťte trace.id v logu (MDC/strukturované logování) a v Kibana propojte Logs <→ APM. Získáte tak celkový pohled od chyby 5xx v logu až po konkrétní span s pomalou SQL či HTTP operací.

Kubernetes a ECK: běh ELK v cloudu

Pro Kubernetes nasazení 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, container) a hints umožňují autodiscovery.

Governance, náklady a retence

  • Retenční politika pro jednotlivé datasety (prod, non-prod, security).
  • Filtrace u zdroje: eliminujte nepodstatný šum, debug logy v produkci sbírejte pouze se samplingem.
  • Deduplikace (hash fingerprint), komprese během přenosu, optimalizace pipeline.batch.size.
  • Tiering a snapshot/restore (S3/objektové úložiště) pro dlouhodobou archivaci 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 prostoru. Při sjednocování historických dat mějte na paměti rozdíly analyzérů a keyword vs. text polí.

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

  • Příliš mnoho shardů (over-sharding) → nízký výkon a vysoké nároky na paměť. Začínejte konzervativně a řiďte se ILM politikou.
  • Nestrukturované texty bez kontextu → investujte do ECS a JSON logů.
  • Debug logy bez retence → filtrujte u zdroje, zaveďte sampling a krátkou retenci.
  • Chybějící TLS nebo RBAC → implementujte bezpečnost od začátku, auditujte přístup.
  • Příliš komplikované 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 do objektového úložiště.
  2. 2× Logstash s vysokou dostupností za load balancerem (nebo čisté ingest pipelines).
  3. Filebeat/Agent na každém hostiteli nebo podu, TLS mutual authentication.
  4. ILM: rollover 30 GB nebo 1 den, warm 7 dní, cold 30 dní, delete 180 dní; dashboardy a alerty v Kibana Spaces podle týmů.

Checklist pro produkční ELK

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

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

Daniel

Website:

Related Story