Fluentd vs Fluent Bit: Log Collection in Kubernetes verstehen

In einer Kubernetes-Umgebung produzieren Dutzende oder Hunderte Pods kontinuierlich Log-Daten. Diese Logs müssen gesammelt, transformiert und an zentrale Systeme wie Elasticsearch, Loki oder S3 weitergeleitet werden. Fluentd und Fluent Bit sind die zwei meistgenutzten Open-Source-Log-Collectoren – entwickelt vom selben Anbieter (Fluentbit.io / CNCF), aber für unterschiedliche Anwendungsfälle optimiert.

Was ist Fluentd?

Fluentd ist ein reifer Log-Kollektor, der 2011 entwickelt wurde und seit 2016 ein CNCF Graduated Project ist. Er läuft als Ruby-basierter Daemon und zeichnet sich durch sein umfangreiches Plugin-Ökosystem aus.

Kernmerkmale:

  • 1000+ Plugins (Input, Filter, Output, Buffer)
  • Starke Routing-Logik mit Tags
  • Zuverlässige Pufferung (on-disk und in-memory)
  • Hervorragende Transformationsfähigkeiten
  • Breite Community und Enterprise-Support durch Calyptia/Chronosphere

Ressourcenverbrauch: ~40–60 MB RAM im Ruhezustand (ohne Plugins), mit vielen Plugins 150–400 MB.

Was ist Fluent Bit?

Fluent Bit wurde 2015 als leichtgewichtige Alternative zu Fluentd entwickelt. Es ist in C geschrieben und auf Performance sowie geringen Ressourcenverbrauch optimiert – ideal als DaemonSet-Agent auf jedem Kubernetes-Node.

Kernmerkmale:

  • Nur ~1 MB Binary-Größe, ~5–15 MB RAM im Betrieb
  • Nativer Kubernetes-Metadata-Enrichment
  • OpenTelemetry-native Unterstützung (seit v2.0)
  • Schneller Parser (Loki/Elasticsearch/S3/Kafka)
  • Ebenfalls CNCF Graduated Project

Kubernetes-Deployment im Vergleich

Fluent Bit DaemonSet (Helm):

helm repo add fluent https://fluent.github.io/helm-charts
helm install fluent-bit fluent/fluent-bit   --namespace logging   --set config.outputs="[OUTPUT]
    Name loki
    Match kube.*
    Host loki.monitoring.svc.cluster.local
    Port 3100
    Labels job=fluentbit"

Fluentd DaemonSet (Helm):

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install fluentd bitnami/fluentd   --namespace logging   --set aggregator.enabled=true   --set forwarder.enabled=true

Fluent Bit wird typischerweise als DaemonSet auf jedem Node deployed (sammelt Container-Logs direkt von /var/log/containers/), während Fluentd oft als Aggregator in der Mitte sitzt und Logs von Fluent Bit-Forwardern empfängt.

Architektur-Muster

1. Fluent Bit only (einfach, leichtgewichtig)

Pod → stdout/stderr → /var/log → Fluent Bit DaemonSet → Loki/Elasticsearch

Geeignet für: Kleine bis mittelgroße Cluster mit einfachen Routing-Anforderungen.

2. Fluent Bit + Fluentd (empfohlen für Enterprise)

Pod → /var/log → Fluent Bit (Forwarder) → Fluentd (Aggregator) → Multiple Outputs
                                                ↓
                                    Elasticsearch + S3 + Slack-Alerts

Fluent Bit übernimmt die ressourcenkritische Kollektion auf jedem Node, Fluentd die komplexe Transformation und das Routing an verschiedene Backends.

3. OpenTelemetry Collector (moderne Alternative)

Pod → OTLP → OTel Collector → Loki + Tempo + Prometheus

Für neue Deployments ab 2024/2025 zunehmend relevant – OTel Collector kann Fluent Bit/Fluentd in vielen Szenarien ersetzen.

Konfigurationsvergleich

Fluent Bit Konfiguration (fluent-bit.conf):

[SERVICE]
    Flush        5
    Log_Level    info
    Parsers_File parsers.conf

[INPUT]
    Name   tail
    Path   /var/log/containers/*.log
    Parser cri
    Tag    kube.*

[FILTER]
    Name                kubernetes
    Match               kube.*
    Kube_URL            https://kubernetes.default.svc:443
    Merge_Log           On
    Keep_Log            Off

[OUTPUT]
    Name   loki
    Match  kube.*
    Host   loki.monitoring.svc.cluster.local
    Port   3100
    Labels job=fluentbit,namespace=$kubernetes['namespace_name']

Fluentd Konfiguration (fluent.conf):

<source>
  @type forward
  port 24224
  bind 0.0.0.0
</source>

<filter kube.**>
  @type record_transformer
  <record>
    cluster_name my-cluster
    environment production
  </record>
</filter>

<match kube.**>
  @type elasticsearch
  host elasticsearch.logging.svc.cluster.local
  port 9200
  logstash_format true
  logstash_prefix kubernetes
  <buffer>
    @type file
    path /var/log/fluentd-buffers/kubernetes.*.buffer
    flush_mode interval
    flush_interval 5s
    chunk_limit_size 2M
    total_limit_size 500M
    overflow_action block
  </buffer>
</match>

Die Fluentd-Konfiguration ist ausdrucksstärker – Buffer-Management, komplexe Routing-Logik – aber auch komplexer.

Performance-Vergleich

Metrik Fluent Bit Fluentd
RAM (idle) 5–15 MB 40–60 MB
RAM (last) 15–40 MB 150–400 MB
CPU (idle) <1% 1–3%
Throughput ~200K logs/s ~30K logs/s
Plugins ~100 1000+
Sprache C Ruby
Startup-Zeit <1s 3–8s

Fluent Bit ist deutlich effizienter – ideal für ressourcenbeschränkte Umgebungen wie Edge-Cluster, ARM-Nodes oder viele kleine Nodes.

Direkter Vergleich: Stärken und Schwächen

Fluent Bit — ideal wenn:

  • Geringer Ressourcenverbrauch auf Node-Ebene wichtig ist
  • Kubernetes-native Enrichment gebraucht wird
  • OpenTelemetry eine Rolle spielt
  • Ein einfaches Weiterleitungsmodell reicht

Fluentd — ideal wenn:

  • Komplexe Log-Transformationen nötig sind
  • Viele verschiedene Output-Targets gebraucht werden
  • Ein ausgereiftes Plugin-Ökosystem wichtig ist
  • Enterprise-Funktionen wie On-Disk-Buffering kritisch sind

Empfehlung für 2026

Für neue Kubernetes-Deployments ist Fluent Bit die erste Wahl – leichtgewichtig, CNCF-erstklassig und zunehmend feature-reichhaltig durch v3.x Updates. Für komplexe Multi-Output-Pipelines mit starker Transformation empfiehlt sich die Kombination: Fluent Bit als Forwarder + Fluentd als Aggregator.

Wer OpenTelemetry vollständig adoptierten will, kann den OpenTelemetry Collector in Betracht ziehen, der beide Tools in einfacheren Szenarien ersetzen kann.

Weiterführende Artikel

Verwandte Technologien im Techradar