ELK Stack – Elasticsearch, Logstash i Kibana
ELK Stack to jeden z najbardziej znanych stosów do centralnego zbierania, przetwarzania, indeksowania i wizualizacji logów.
Nazwa pochodzi od trzech podstawowych komponentów:
E → Elasticsearch
L → Logstash
K → Kibana
Architektura:
Servers
Firewalls
Applications
Containers
|
v
Logstash
|
v
Elasticsearch
|
v
Kibana
W nowoczesnych wdrożeniach Elastic Stack jest jednak większym ekosystemem niż samo ELK.
Elasticsearch
Elasticsearch jest silnikiem wyszukiwania i analizy danych.
To tutaj trafiają dane po przetworzeniu.
Elasticsearch
|
+------------+------------+
| | |
Search Analytics Aggregations
Przykładowo możemy przechowywać:
timestamp
hostname
source_ip
destination_ip
username
event
severity
message
i błyskawicznie wyszukiwać interesujące zdarzenia.
Logstash
Logstash odpowiada przede wszystkim za pobieranie i przetwarzanie danych.
Schemat:
Input
|
v
Filter
|
v
Output
Przykład:
Firewall Log
|
v
Logstash
|
+--> Parse
+--> Normalize
+--> Enrich
+--> Filter
|
v
Elasticsearch
Kibana
Kibana jest interfejsem umożliwiającym analizę i wizualizację danych przechowywanych w Elasticsearch.
Możemy tworzyć:
- dashboardy,
- wykresy,
- wyszukiwania,
- alerty,
- analizy logów.
Schemat:
Elasticsearch
|
v
Kibana
|
+----+----+
| |
Charts Search
ELK w praktyce
Załóżmy, że mamy:
10 Linux servers
5 Windows servers
2 Firewalls
1 VPN
20 Applications
Każdy system generuje logi.
Bez centralizacji:
Server 1 → logs
Server 2 → logs
Server 3 → logs
...
Z ELK:
Servers
|
v
Logstash
|
v
Elasticsearch
|
v
Kibana
Administrator otrzymuje jedno miejsce do analizy całej infrastruktury.
Logi Linux
Możemy zbierać:
/var/log/auth.log
/var/log/syslog
/var/log/messages
/var/log/nginx/*
Przykład:
Failed password for invalid user admin
Logstash może przekształcić go w strukturę:
event.type = authentication_failure
user = admin
source.ip = 10.10.10.50
service = ssh
Dzięki temu wyszukiwanie staje się znacznie prostsze.
Logi Windows
W środowisku Windows interesujące są przede wszystkim:
Windows Event Logs
Security Events
System Events
Application Events
Możemy mieć:
Windows
|
Elastic Agent / Beats
|
v
Elasticsearch
|
v
Kibana
Filebeat
W praktycznych wdrożeniach często zamiast wysyłania wszystkiego bezpośrednio przez Logstash wykorzystuje się Beats, np. Filebeat.
Schemat:
Linux
|
Filebeat
|
v
Logstash
|
v
Elasticsearch
Filebeat jest lekkim agentem przeznaczonym do zbierania i przesyłania danych.
Elastic Agent
W nowszym ekosystemie Elastic dużą rolę odgrywa Elastic Agent, który może zastępować wiele osobnych agentów i integrować różne źródła danych.
Schemat:
Elastic Agent
|
+-------------+-------------+
| | |
Logs Metrics Security
Dlatego przy projektowaniu nowego środowiska warto patrzeć na cały Elastic Stack, a nie tylko historyczny model ELK.
ELK i Docker
W środowisku Docker:
Docker Host
|
+--+--+--+--+
| | | | |
API DB Web Redis
| | | |
+--+--+--+--+
|
Logs
|
v
Elastic Agent
|
v
Elasticsearch
|
v
Kibana
Możemy analizować logi kontenerów w jednym miejscu.
ELK i Kubernetes
ELK jest również często wykorzystywany w Kubernetes.
Kubernetes
|
+-------------+-------------+
| | |
Pod Pod Pod
| | |
Logs Logs Logs
+-------------+-------------+
|
Elastic Agent
|
v
Elasticsearch
|
v
Kibana
Możemy filtrować dane według:
namespace
pod
container
node
application
environment
ELK i firewall
To jeden z klasycznych przypadków użycia.
Firewall
|
| Syslog
v
Logstash
|
v
Elasticsearch
|
v
Kibana
Możemy analizować:
source.ip
destination.ip
destination.port
protocol
action
timestamp
ELK + Suricata
Możemy przesyłać zdarzenia Suricaty:
Network
|
Suricata
|
eve.json
|
v
Elastic Agent
|
v
Elasticsearch
|
v
Kibana
Dashboard może pokazywać:
IDS Alerts
-------------------------
Critical 12
High 57
Medium 321
Low 812
ELK + Zeek
Podobnie z Zeekiem:
Zeek
|
+--> conn.log
+--> dns.log
+--> http.log
+--> ssl.log
+--> ssh.log
|
v
Elastic
|
v
Kibana
Daje to bardzo dobre możliwości analizy ruchu sieciowego.
ELK + Wazuh
Tutaj zaczyna się ciekawa część.
Wazuh może pełnić funkcję warstwy security monitoring, natomiast Elastic może być wykorzystywany do centralnego przechowywania i analizy danych.
Schemat koncepcyjny:
Infrastructure
|
+---------------+---------------+
| | |
Logs Security Network
| | |
v v v
Elastic Wazuh Suricata/Zeek
| | |
+---------------+---------------+
|
Analysis
Trzeba jednak uważać na wersje, kompatybilność i konkretną architekturę wdrożenia. Wazuh rozwija własny stos komponentów, więc nie należy zakładać, że dowolne wersje Elasticsearch/Kibana można po prostu podmienić bez sprawdzenia dokumentacji.
ELK vs Graylog
To jedno z ciekawszych porównań.
| Cecha | ELK / Elastic | Graylog |
|---|---|---|
| Log management | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Search | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Analiza danych | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Log processing | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Dashboardy | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Skalowanie | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Ecosystem | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Prostota wdrożenia | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| SIEM | ⭐⭐⭐⭐⭐* | ⭐⭐⭐⭐ |
* zależnie od używanych komponentów i licencji/funkcji Elastic.
Najprościej:
ELK/Elastic → potężny ekosystem wyszukiwania i analizy
Graylog → bardzo wygodne centralne log management
ELK vs Loki
Tutaj różnica jest jeszcze bardziej interesująca.
Loki
Applications
|
Alloy
|
Loki
|
Grafana
Jest bardzo naturalnym wyborem dla środowiska:
Prometheus + Grafana + Kubernetes
Elastic
Applications
|
Elastic Agent
|
Elasticsearch
|
Kibana
Elastic jest bardziej rozbudowaną platformą do wyszukiwania, analizy danych i security.
Loki vs Elastic
| Loki | Elastic | |
|---|---|---|
| Logi | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Observability | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Search | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Full-text analysis | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Kubernetes | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Grafana integration | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Security analytics | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Ekosystem | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Prostota | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
ELK i SIEM
Elastic ma również rozbudowane możliwości bezpieczeństwa.
Architektura może wyglądać tak:
Security Data
|
+-------------+-------------+
| | |
Endpoints Network Cloud
| | |
+-------------+-------------+
|
Elastic Platform
|
+----------+----------+
| |
Detection Analytics
| |
+----------+----------+
|
Kibana
W tym miejscu Elastic przestaje być tylko systemem do logów.
ELK i threat hunting
Dzięki dużym możliwościom wyszukiwania można analizować potencjalne ślady ataku.
Przykładowo:
Source IP
|
v
Authentication failures
|
v
Successful login
|
v
Privilege escalation
|
v
Suspicious process
Analityk może próbować połączyć te wydarzenia w jeden scenariusz.

Przykład ataku
Załóżmy:
10:00
大量 SSH failures
10:04
Successful SSH login
10:06
sudo command executed
10:07
New process started
10:08
Sensitive file modified
W systemie centralnego logowania możemy zobaczyć cały łańcuch:
Brute Force
↓
Successful Access
↓
Privilege Escalation
↓
Execution
↓
File Modification
To właśnie możliwość korelacji zdarzeń jest jedną z największych wartości Elastic/SIEM.
Elasticsearch i indeksy
Elasticsearch organizuje dane w indeksach.
Przykładowo:
logs-linux-2026.08.03
logs-windows-2026.08.03
logs-firewall-2026.08.03
logs-app-2026.08.03
W dużych środowiskach właściwe zarządzanie indeksami, retencją i storage’em jest bardzo ważne.
Retencja danych
Logi mogą rosnąć bardzo szybko:
100 GB/day
|
v
3 TB/month
|
v
36 TB/year
Dlatego trzeba planować:
Retention
Storage
Compression
Index Lifecycle
Hot/Warm/Cold
W przeciwnym przypadku rachunek za storage może szybko stać się problemem.
Hot / Warm / Cold
W większych instalacjach dane mogą być przechowywane w różnych warstwach:
HOT
|
| recent data
v
WARM
|
| older data
v
COLD
|
| archive
v
Long-term storage
Nie wszystkie logi wymagają takiej samej wydajności wyszukiwania.
ELK – mocne strony
Największe zalety:
- ogromne możliwości wyszukiwania,
- bardzo rozbudowany ekosystem,
- skalowanie,
- analiza dużych zbiorów danych,
- rozbudowane dashboardy,
- security analytics,
- wiele gotowych integracji.
ELK – słabe strony
Największe wyzwania:
- większa złożoność,
- wymagania sprzętowe,
- administracja Elasticsearch,
- zarządzanie storage,
- tuning,
- koszt przy dużych ilościach danych,
- konieczność świadomego projektowania retencji.
To nie jest system, który stawiałbym bez potrzeby na małym serwerze tylko dlatego, że „ELK jest popularny”.
Gdzie ELK ma największy sens?
Szczególnie tam, gdzie mamy:
Dużo serwerów
Dużo logów
Dużo źródeł danych
Rozbudowany search
Security analytics
Threat hunting
SIEM
Przy małej infrastrukturze:
3 Linux servers
1 firewall
1 application
Loki lub Graylog może być znacznie prostszy.
Przy:
100+ servers
Kubernetes
Firewalls
Cloud
Applications
Security telemetry
Elastic zaczyna być bardzo interesujący.
Pełna architektura
Łącząc wszystkie omawiane wcześniej elementy:
INTERNET
|
Firewall
|
+----------+----------+
| |
Suricata Zeek
| |
+----------+----------+
|
Network Security
|
+-----------------------+-----------------------+
| | |
Linux Windows Kubernetes
| | |
Elastic Agent Elastic Agent Elastic Agent
| | |
+-----------------------+-----------------------+
|
Elastic Platform
|
+-------------+-------------+
| |
Elasticsearch Kibana
| |
+-------------+-------------+
|
Security Analytics
A obok:
OBSERVABILITY
|
+---------+---------+
| |
Prometheus Loki
| |
+---------+---------+
|
Grafana
oraz:
SECURITY
|
Wazuh
|
Security Events
Najważniejsze rozróżnienie
W całej naszej układance można to zapamiętać tak:
Prometheus → METRICS
Loki → LOGS / OBSERVABILITY
Grafana → VISUALIZATION
Graylog → LOG MANAGEMENT
Elastic → SEARCH / ANALYTICS / SIEM
Wazuh → ENDPOINT SECURITY
Suricata → IDS/IPS
Zeek → NETWORK VISIBILITY
ELK jest więc znacznie więcej niż „kolejnym systemem do logów”. Jego największa siła pojawia się wtedy, gdy ilość i różnorodność danych jest na tyle duża, że potrzebujemy zaawansowanego wyszukiwania, korelacji, analityki bezpieczeństwa i threat huntingu.






