Fluentd vs Fluentbit vs Vector: how to choose
All three collect logs, transform them and forward them somewhere. The differences are resource footprint, where the processing happens, and how you express that processing.
Fluent Bit is the lightweight one, written in C with a small memory footprint, and it is the default log agent on most Kubernetes distributions for that reason. Fluentd is its older, heavier sibling — Ruby-based, with a far larger plugin ecosystem, and typically deployed as an aggregator rather than on every node. Vector is the newest, written in Rust, and aims to be fast enough to run as an agent while capable enough to run as an aggregator.
The common architecture is a light agent on every node forwarding to a smaller number of aggregators that do the expensive work. That shape matters more than the tool: parsing and enrichment on a thousand nodes costs a thousand times more than on ten aggregators.
Decision matrix: which one fits your situation
| Your situation | Use | Why |
|---|---|---|
| Node agent on a large Kubernetes cluster | Fluent Bit | Smallest footprint per node, and the default in most distributions. |
| Aggregator doing heavy transformation | Vector or Fluentd | Both handle complex processing; Vector uses far less CPU for the same work. |
| Need an obscure source or sink | Fluentd | The largest plugin ecosystem by a wide margin. |
| Want one tool for logs and metrics | Vector | Handles both in one pipeline with one configuration language. |
| Testable, version-controlled pipelines | Vector | VRL is a real language with a unit-testing story for transformations. |
| Already running one that works | Keep it | Log pipelines are undifferentiated infrastructure. Replace for a specific reason. |
Backpressure is the thing to test
The behaviour that will matter in production is what happens when the destination is unavailable. Buffering to memory is fast and loses data if the agent restarts; buffering to disk survives restarts and costs I/O and space you must budget for. All three support both, and the defaults are not necessarily what you want.
Test this deliberately before you need it: stop the destination, watch memory and disk on the nodes, and confirm the agent recovers without losing or duplicating everything. A log pipeline that silently drops during an outage is worst-case behaviour, because outages are when you most want the logs.
Frequently asked questions
Can Fluent Bit replace Fluentd entirely?
For most Kubernetes log shipping, yes — it has grown well beyond its original scope and handles parsing, filtering and the common outputs. Fluentd remains preferable when you need a plugin that only exists there, or when an aggregator does transformation complex enough that the ecosystem matters more than the footprint.
Is Vector meaningfully faster?
In published benchmarks and in practice it uses notably less CPU per event than Fluentd for equivalent processing, which is the main argument for it at aggregator scale. Against Fluent Bit as a node agent the gap is smaller and the calculation is different — Fluent Bit's ubiquity as a distribution default has real operational value. Benchmark with your own log shapes; performance depends heavily on the parsing you do.
Should the agent parse logs or the aggregator?
The aggregator, in almost all cases. Parsing is the expensive part, and doing it on every node multiplies that cost by your node count while making a parsing change a fleet-wide rollout. Keep node agents to tailing, light enrichment with Kubernetes metadata, and forwarding.
What about OpenTelemetry Collector for logs?
It is a credible fourth option, especially if you already run it for traces and metrics — one agent for all three signals is a real simplification. Its log maturity has improved substantially. If logs are your only signal, the dedicated tools remain more featureful; if you are already running the collector, consolidating is worth evaluating.
