Fluent Bit – lekki agent do zbierania i przesyłania logów
Fluent Bit to bardzo lekki, open-source’owy agent do zbierania, przetwarzania i przesyłania logów oraz innych danych telemetrycznych.
W naszej dotychczasowej układance najlepiej traktować go jako log/telemetry collector działający blisko źródła danych.
Linux / Docker / Kubernetes
|
Fluent Bit
|
+-----+-----+------+
| | |
Loki Elastic Graylog
Fluent Bit vs Fluentd
To ważne rozróżnienie:
Fluent Bit → lekki, szybki agent
Fluentd → bardziej rozbudowany collector
Fluent Bit jest napisany w C i został zaprojektowany z myślą o niskim zużyciu CPU i RAM, dlatego bardzo dobrze pasuje do kontenerów i Kubernetes.
Podstawowa architektura
Fluent Bit można logicznie podzielić na:
Input
|
v
Parser
|
v
Filter
|
v
Output
Czyli:
Źródło
↓
Zbieranie
↓
Parsowanie
↓
Filtrowanie / modyfikacja
↓
Wysyłka
Input
Input określa, skąd Fluent Bit pobiera dane.
Popularne źródła:
Files
Systemd
Docker
Kubernetes
TCP
UDP
HTTP
Przykład:
/var/log/*.log
|
v
Fluent Bit
Tail
Jednym z najczęściej wykorzystywanych inputów jest Tail.
Fluent Bit może obserwować plik:
/var/log/app.log
i pobierać nowe wpisy w miarę ich pojawiania się.
Application
|
v
app.log
|
v
Fluent Bit
To szczególnie przydatne w środowiskach Linux i kontenerowych.
Kubernetes
Tutaj Fluent Bit jest szczególnie popularny.
Typowa architektura:
Kubernetes
|
+-------------+-------------+
| | |
Pod Pod Pod
| | |
Logs Logs Logs
+-------------+-------------+
|
Fluent Bit
|
v
Log Backend
Najczęściej Fluent Bit uruchamia się jako DaemonSet, dzięki czemu agent działa na każdym węźle klastra.
Node 1 → Fluent Bit
Node 2 → Fluent Bit
Node 3 → Fluent Bit
Node 4 → Fluent Bit
Fluent Bit + Kubernetes metadata
Fluent Bit może wzbogacać logi o informacje dotyczące Kubernetes.
Zamiast:
ERROR database timeout
możemy otrzymać dane zawierające m.in.:
namespace
pod_name
container_name
container_id
node_name
Czyli:
ERROR database timeout
namespace: production
pod: api-7f9d...
container: api
node: worker-03
To ogromnie ułatwia późniejsze wyszukiwanie.

Filter
Po pobraniu danych możemy je przetworzyć.
Input
|
v
Filter
|
v
Output
Filtry mogą m.in.:
- dodawać pola,
- usuwać pola,
- zmieniać dane,
- parsować informacje,
- wzbogacać rekordy.
Parser
Załóżmy, że aplikacja zapisuje:
2026-08-04 12:30:15 ERROR Database timeout
Parser może rozbić wpis na:
timestamp = 2026-08-04 12:30:15
level = ERROR
message = Database timeout
Dzięki temu backend może znacznie łatwiej analizować dane.
Output
Fluent Bit może wysyłać dane do różnych backendów.
Przykładowo:
Fluent Bit
|
+--> Loki
|
+--> Elasticsearch
|
+--> OpenSearch
|
+--> Kafka
|
+--> HTTP
|
+--> stdout
To właśnie sprawia, że Fluent Bit jest bardzo uniwersalny.
Fluent Bit + Loki
Bardzo popularny zestaw:
Kubernetes
|
Fluent Bit
|
v
Loki
|
v
Grafana
Role:
Fluent Bit → zbiera logi
Loki → przechowuje i wyszukuje
Grafana → wizualizuje
Fluent Bit + Elasticsearch
Klasyczny wariant:
Servers
|
Fluent Bit
|
v
Elasticsearch
|
v
Kibana
W takim układzie Fluent Bit może pełnić rolę lekkiego agenta zamiast cięższego Logstasha w części zastosowań.
Fluent Bit + OpenTelemetry
Tutaj robi się ciekawie w kontekście poprzedniego tematu.
Możemy mieć:
Application
|
+---- Metrics
+---- Traces
+---- Logs
|
v
Fluent Bit
|
v
OpenTelemetry
Collector
Albo odwrotnie, zależnie od architektury i potrzeb.
Ważne jest rozróżnienie:
Fluent Bit
→ przede wszystkim lekki collector/log processor
OpenTelemetry
→ standard telemetryki + instrumentacja + collector
Fluent Bit i OTel Collector częściowo się pokrywają, ale nie są tym samym narzędziem.
Fluent Bit vs Logstash
To bardzo częste porównanie.
| Cecha | Fluent Bit | Logstash |
|---|---|---|
| Zużycie RAM | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| Zużycie CPU | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Kubernetes | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Log collection | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Transformacje | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Ekosystem Elastic | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Prostota | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Edge/Agent | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Bardzo duże pipeline’y | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
W praktyce:
Fluent Bit
→ lekki agent na serwerze / nodzie
Logstash
→ cięższe i bardziej rozbudowane przetwarzanie
Fluent Bit vs Fluentd
Fluent Bit
→ C
→ bardzo lekki
→ agent
→ edge
→ Kubernetes
Fluentd
→ Ruby
→ większy
→ bardziej rozbudowane przetwarzanie
→ collector
Często spotkasz architekturę:
Node
|
Fluent Bit
|
v
Fluentd
|
v
Backend
choć w wielu środowiskach Fluent Bit może wysyłać dane bezpośrednio do backendu.
Fluent Bit vs Promtail
W środowisku Loki warto znać tę różnicę.
Historycznie często spotykało się:
Promtail → Loki
Fluent Bit również może wysyłać dane do Loki:
Fluent Bit → Loki
Fluent Bit jest jednak narzędziem bardziej ogólnego przeznaczenia.
Fluent Bit vs Vector
Vector to kolejny bardzo ciekawy konkurent:
Fluent Bit
Vector
OpenTelemetry Collector
Wszystkie mogą pełnić rolę collectorów, ale mają inne filozofie i zakresy funkcji.
Fluent Bit w Dockerze
Przykładowa architektura:
Docker Host
|
+---------------+---------------+
| | |
nginx API Redis
| | |
+---------------+---------------+
|
Fluent Bit
|
v
Loki
Dzięki temu każdy kontener może dostarczać logi do centralnego systemu.
Fluent Bit + Docker + Loki + Grafana
Bardzo lekki stos:
Docker
|
Fluent Bit
|
v
Loki
|
v
Grafana
Dla małego i średniego środowiska może to być znacznie prostsze niż:
Docker
|
Logstash
|
Elasticsearch
|
Kibana
Fluent Bit + Graylog
Możemy również wykorzystać Fluent Bit jako agenta:
Server
|
Fluent Bit
|
v
Graylog
Trzeba tylko dobrać właściwy input/output i format danych.
Fluent Bit + Wazuh
Tutaj trzeba uważać z rolami.
Fluent Bit:
Collect
Process
Forward
Wazuh:
Detect
Correlate
Alert
Security Monitoring
Czyli Fluent Bit nie zastępuje Wazuha.
Może natomiast dostarczać dane do systemu log management, który jest częścią większej architektury bezpieczeństwa.
Fluent Bit + Suricata
Możemy mieć:
Suricata
|
eve.json
|
v
Fluent Bit
|
v
Elastic / Loki / OpenSearch
Suricata generuje zdarzenia bezpieczeństwa, a Fluent Bit zajmuje się transportem i ewentualnym przetwarzaniem.
Buforowanie
Jednym z ważnych elementów produkcyjnej konfiguracji jest buffering.
Co jeśli backend przestanie odpowiadać?
Fluent Bit
|
X
Backend DOWN
Nie chcemy automatycznie utracić wszystkich logów.
Dlatego można wykorzystać mechanizmy buforowania:
Application
|
Fluent Bit
|
Buffer
|
X Backend DOWN
|
|
Backend returns
|
v
Flush
W produkcji jest to bardzo ważny element konfiguracji.
Multi-output
Fluent Bit może być używany do wysyłania danych do więcej niż jednego miejsca.
Na przykład:
Fluent Bit
|
+---------+---------+
| |
v v
Loki Elastic
Ale trzeba uważać, ponieważ oznacza to:
2 × network traffic
2 × processing
2 × storage
Nie ma sensu kopiować wszystkiego wszędzie bez konkretnego powodu.
Routing logów
Możemy też kierować różne typy logów do różnych backendów:
Fluent Bit
|
+-----------+-----------+
| | |
App Security System
| | |
v v v
Loki Elastic Graylog
To jest znacznie ciekawsze niż wysyłanie wszystkiego w jedno miejsce.
Przykład produkcyjny
Załóżmy:
Kubernetes
|
+--> Application logs
+--> Nginx logs
+--> System logs
+--> Security logs
Możemy zrobić:
Fluent Bit
|
+---------------+---------------+
| | |
application security system
| | |
v v v
Loki Elastic Loki
| | |
+---------------+---------------+
|
Grafana
Fluent Bit a bezpieczeństwo
Sam Fluent Bit nie jest systemem bezpieczeństwa.
Nie należy mylić:
Fluent Bit → log collection
z:
Wazuh → security monitoring
Suricata → IDS/IPS
Zeek → network analysis
Fluent Bit może jednak być ważną częścią bezpiecznej architektury, ponieważ dostarcza dane do tych systemów.
Fluent Bit w naszej całej architekturze
Po dodaniu Fluent Bit wygląda to jeszcze ciekawiej:
APPLICATIONS
|
+-----------+-----------+
| | |
Logs Metrics Traces
| | |
v v v
Fluent Bit OTel OTel
| Collector Collector
| | |
v v v
Loki Prometheus Tempo
| | |
+-----------+-----------+
|
Grafana
Monitoring infrastruktury:
Linux / Windows / Network
|
Zabbix
|
v
Infrastructure
Monitoring
Security:
Network
|
+--+--------+
| |
Suricata Zeek
| |
+-----+-----+
|
Security
SIEM / analiza:
Logs
|
+--> Elastic
+--> Graylog
+--> Wazuh
Najważniejsze rozróżnienie
Cały zestaw możemy teraz zapamiętać tak:
Zabbix
→ "Czy infrastruktura działa?"
Prometheus
→ "Jakie mamy metryki?"
OpenTelemetry
→ "Jak zbierać i przenosić telemetrykę?"
Fluent Bit
→ "Jak lekko zbierać i przesyłać logi?"
Loki
→ "Gdzie przechować i przeszukiwać logi?"
Tempo
→ "Gdzie przechować traces?"
Grafana
→ "Jak to wszystko zobaczyć?"
Graylog
→ "Jak centralnie zarządzać i analizować logi?"
Elastic
→ "Jak zaawansowanie wyszukiwać i analizować dane?"
Wazuh
→ "Czy mamy problem bezpieczeństwa?"
Suricata
→ "Czy wykryliśmy podejrzany ruch?"
Zeek
→ "Co dokładnie dzieje się w sieci?"
Fluent Bit jest więc przede wszystkim lekką warstwą transportową na brzegu infrastruktury. Szczególnie dobrze pasuje do Kubernetes, Docker, Linux i dużych środowisk z wieloma źródłami logów, gdzie nie chcemy instalować ciężkiego collectora na każdym hoście.






