Fluentd hat einen leichteren Bruder: Fluent Bit, von einem Mitglied des Fluentd-Teams speziell für Umgebungen geschaffen, in denen Fluentds Fußabdruck zu schwer ist. Beide sind graduierte CNCF-Projekte unter demselben Fluent-Dach, und beide folgen derselben tag-basierten Input/Filter/Output-Architektur, die in dieser Reihe an anderer Stelle behandelt wird. Diese Anleitung behandelt, worin sie sich tatsächlich unterscheiden, und die Architektur, die beide zusammen nutzt.

Der zentrale Kompromiss: Fußabdruck vs. Ökosystem

	Fluentd	Fluent Bit
Sprache	Ruby, mit performancekritischen Teilen in C	C
Typischer Speicherbedarf	Zehn bis einige zehn Megabyte	In der Größenordnung von Hunderten Kilobyte
Plugin-Ökosystem	Groß; breites Spektrum ausgereifter Input-/Filter-/Output-Plugins	Kleiner, aber umfangreich und wachsend; über 100 eingebaute Plugins
Am besten geeignet für	Zentrale Aggregation, aufwendigere Verarbeitung	Hochvolumige Sammlung, Edge- und ressourcenbeschränkte Umgebungen

Fluent Bits reine C-Implementierung und minimale Abhängigkeiten machen seinen Fußabdruck klein genug für den Einsatz im echten Edge-Maßstab: eingebettete Linux-Geräte, IoT-Hardware, überall dort, wo ein Ruby-Prozess mit vielen Megabyte keine vernünftige Wahl ist. Fluentds größerer Fußabdruck erkauft ein entsprechend größeres und ausgereifteres Plugin-Ökosystem, was mehr zählt, wenn du aufwendigere Transformationen durchführst oder an ein weniger gängiges Ziel schreibst.

Gleiche Architektur, andere Implementierung

Beide Werkzeuge bauen auf denselben Konzepten auf, die diese Reihe durchzieht: Input-Plugins definieren Sources, Filter-Plugins transformieren Daten im Flug, Output-Plugins definieren Ziele, und Tags routen Daten dazwischen. Wer eines konfiguriert hat, kann die Konfiguration des anderen lesen und sofort die Form erkennen, auch wenn sich die Syntax im Detail unterscheidet. Fluent Bit geht außerdem über reine Log-Sammlung hinaus: Es unterstützt nativ das Sammeln von Host- und Container-Metriken (CPU, Speicher, Disk) neben Logs, was in Fluentds Welt typischerweise ein separates Werkzeug wie Prometheus’ Exporter bedeuten würde statt eines einheitlichen Agents.

Die kombinierte Architektur: Fluent Bit leitet weiter, Fluentd aggregiert

Beide Werkzeuge können entweder als Forwarder (sammelt und sendet Daten weiter) oder als Aggregator (empfängt von vielen Forwardern, erledigt aufwendigere Verarbeitung und sendet an den endgültigen Speicher) agieren, und nichts verlangt, für ein ganzes Deployment nur ein Werkzeug zu wählen. Ein gängiges Muster speziell in Kubernetes nutzt die Stärken beider:

┌────────────┐  ┌────────────┐  ┌────────────┐
│  Knoten 1   │  │  Knoten 2   │  │  Knoten 3   │
│ Fluent Bit  │  │ Fluent Bit  │  │ Fluent Bit  │   ← einer pro Knoten (DaemonSet),
│ (DaemonSet) │  │ (DaemonSet) │  │ (DaemonSet) │     leichtgewichtig, leitet nur weiter
└──────┬─────┘  └──────┬─────┘  └──────┬─────┘
       │                │                │
       └────────────────┼────────────────┘
                         ▼
                 ┌───────────────┐
                 │    Fluentd     │   ← zentraler Aggregator,
                 │  (Aggregator)  │     aufwendigeres Parsing/Anreichern,
                 └───────┬───────┘     breiterer Plugin-Zugriff
                         ▼
               Elasticsearch / S3 / Kafka / ...

Fluent Bit läuft als DaemonSet, eine leichtgewichtige Instanz pro Knoten, die das Minimum zum Sammeln und Weiterleiten von Logs erledigt, ohne nennenswert mit den eigentlichen Workloads des Knotens um CPU oder Speicher zu konkurrieren. Fluentd läuft zentral, in kleinerer Zahl, und übernimmt die schwere Arbeit: komplexes Parsing, Anreicherung und Routing zu jedem Ziel, das ein Plugin braucht, das Fluent Bit nicht hat. Jedes Werkzeug erledigt den Teil, für den es tatsächlich gebaut ist, statt dass ein Werkzeug alles nur ausreichend erledigt.

Eines wählen, wenn du nur eines brauchst

• Fluent Bit allein passt, wenn das Deployment ressourcenbeschränkt ist (Edge-Geräte, hohe Pod-Dichte, kostensensibel im großen Maßstab) und Ziel- und Verarbeitungsanforderungen gut innerhalb dessen liegen, was sein Plugin-Set abdeckt.
• Fluentd allein passt, wenn das Deployment nicht besonders ressourcenbeschränkt ist und ein Plugin oder ein Maß an Konfigurationsflexibilität braucht, das in Fluentds länger etabliertem Ökosystem ausgereifter ist.
• Beide zusammen passt genau zum obigen Muster: hochvolumige Sammlung pro Knoten, bei der der Fußabdruck zählt, die in zentralisierte, aufwendigere Verarbeitung mündet, bei der der Fußabdruck weniger zählt.

Die eigenen verwalteten Kubernetes-Logging-Add-ons von Cloud-Anbietern haben sich über die Jahre zunehmend aus genau den Performance- und Fußabdruck-Gründen der obigen Tabelle auf Fluent Bit statt Fluentd als Standard festgelegt. Das ist gut zu wissen, wenn du einen verwalteten Cluster untersuchst und erwartet hast, dort Fluentd zu finden: Prüfe, welches der beiden tatsächlich bereitgestellt ist, bevor du etwas annimmst.