Fluent Bit: a C telemetry agent for logs, metrics and traces

The problem Fluent Bit solves for log and metric pipelines

Most systems produce telemetry in a shape the destination does not accept. A container writes JSON lines to stdout, an application writes plain text to a file, a host exposes a metrics endpoint, and somewhere downstream a service expects a specific protocol over TLS. Fluent Bit exists to sit in that gap. The README describes it as a lightweight and high-performance telemetry agent designed to collect, process and forward logs, metrics and traces from any source to any destination. It is part of the Fluentd ecosystem and a CNCF graduated project, and it targets Linux, Windows, macOS, BSD and embedded environments. The stated design goal is maximum efficiency with minimal CPU and memory footprint, which is why the implementation language is C rather than a managed runtime. The audience is platform and infrastructure engineers who deploy agents on every node and cannot afford a large per-node footprint, and who would rather declare a pipeline in a config file than write and maintain a custom shipper.

Inputs, filters and outputs: the pipeline model

Fluent Bit is fully modular. The README splits the plugin surface into three groups: input plugins that collect logs, metrics and traces, filter plugins that enrich and transform data, and output plugins that deliver data to external services. A running instance is a pipeline built from those three stages, and the config file wires them together. Data moves from an input tag through zero or more filters and then to one or more outputs that match the tag. The README states there are 70+ built-in plugins, and the repository layout backs that up: there is a top-level plugins/ directory, a conf/ directory for configuration, and an include/ directory for headers. Two capabilities are worth calling out because they change what the pipeline can do. First, SQL stream processing: the README lists performing analytics and transformations with SQL queries as a key feature, so a filter stage can run SQL over the stream rather than only rewriting fields. Second, extensibility beyond C: the README says you can write plugins in C, filters in Lua, and outputs in Go. The examples/ directory contains filter_rust/, filter_wasm_c/, filter_wasm_go/, filter_rust_clib/, filter_rust_msgpack/ and a kafka_filter/, so the extension story is broader than the three languages the README names. On the networking side, the README lists built-in TLS/SSL support and async I/O, and for observability it exposes internal metrics over HTTP and Prometheus.

Installing Fluent Bit and running a first pipeline

The README points to platform-specific installation pages for Linux packages (Debian, Ubuntu, RHEL and others), Docker images, and Windows binaries, all under docs.fluentbit.io. If you build from source, the README gives a short sequence: change into build, run cmake, run make, then run the binary. The requirements listed are CMake >= 3.0, Flex and Bison, and the YAML and OpenSSL headers. The example below is copied from the README and starts a CPU input with a one-second flush interval, writing to standard output. You should see a stream of records printed to your terminal once per second.

cd build
cmake ..
make
bin/fluent-bit -i cpu -o stdout -f 1

That command line is the fastest way to confirm the binary works, but real deployments use a config file. The repository root contains x.conf, and there is a conf/ directory for configuration. The command-line flags map onto the same three pipeline stages: -i selects the input, -o selects the output, and -f sets the flush interval in seconds. Once the CPU-to-stdout path prints records, the next step is to replace the input with the one you actually need, such as a file tail or a socket listener, and replace stdout with a real destination, then run the same binary with -c pointing at your config file. Because the pipeline stages are independent plugins, swapping either end does not require touching the other.

Where Fluent Bit is the wrong tool

The SQL stream processing feature is easy to over-read. It is described as a way to perform analytics and transformations with SQL queries inside the pipeline, which is useful for filtering and reshaping records as they pass through. It is not the same thing as a database. If your requirement is joining a live log stream against a dimension table, running windowed aggregations across long time ranges, or querying months of stored telemetry interactively, a pipeline agent is the wrong layer; you want a store that can hold the data and answer those questions. The README does not claim otherwise, and the feature list is careful to call it stream processing. A second boundary is configuration complexity. A pipeline is declarative, which is a strength until you need logic that does not fit an existing filter. At that point you are writing a plugin, and the README's own split (C for plugins, Lua for filters, Go for outputs) means the language you write in depends on which stage you are extending. That is a real constraint, not a footnote. Finally, the README's claim of a minimal footprint is a design goal, and footprint depends on which plugins you compile in; a build that includes many inputs and outputs is not the same artifact as a minimal one.

Fluent Bit compared with Fluentd

The most common comparison is with Fluentd, and the relationship is stated in the README: Fluent Bit is part of the Graduated Fluentd Ecosystem. The difference in approach is the implementation and the resulting resource profile. Fluentd is the older, larger member of the family; Fluent Bit is written in C and the README frames it around maximum efficiency with minimal CPU and memory footprint. That framing is the whole reason the two coexist rather than one replacing the other. If you are already running Fluentd and it meets your throughput and memory budget, switching buys you a smaller agent but also a different plugin set and a different config surface, and the README does not promise drop-in compatibility with Fluentd configuration. The comparison to reach for is therefore not which one is better but which one fits the node. On a large host with spare memory, Fluentd's broader ecosystem is a reasonable default. On an edge device, a sidecar, or a node where every megabyte is accounted for, the C implementation is the argument for Fluent Bit. The README also lists Filebeat and Vector as comparisons people search for, but it does not discuss either, so any claim about how Fluent Bit differs from them would have to come from their documentation, not this one.

Maintenance cadence, licensing and upgrade cost

The README states the project follows a fast-paced development cycle with major releases every 3 to 4 months, and that the master branch tracks v5.1, the current stable release series. The most recent push to the repository was on 2026-08-16, the same date as the v5.1.1 release, and v5.1.0 landed on 2026-08-06. A patch release in the 4.2.x line, v4.2.8, was published on 2026-08-04, so more than one series is receiving maintenance. The README points to MAINTENANCE.md for version-specific maintenance timelines and policies, and that file is the authority on how long a given series stays supported; the README itself does not state an end-of-life date for any series. The practical upgrade cost follows from the cadence: if a major release arrives every 3 to 4 months, you should expect to test plugin behaviour on that rhythm rather than treating the agent as install-and-forget. The repository also ships packaging/ and cpack/ directories and a set of distribution recipes including debian.sh, snap/, and two BitBake recipes (fluent-bit-5.1.3.bb and fluent-bit_git.bb), which means the project maintains its own packaging paths rather than relying only on downstream distributions. On licensing, the project is Apache License v2.0, a permissive licence that does not require you to publish modifications; the repository carries a LICENSE file and a SECURITY.md. That is a description of the licence text, not legal advice, and if you redistribute a modified build you should read the licence and your own obligations.

Editorial conclusion

Adopt Fluent Bit when you need one small binary that tails files, listens on a socket, and ships to many destinations through a config file, and when the plugin you need already exists in the 70+ built-in set. Do not adopt it if you need a full SQL analytics engine with joins and window functions, or if your team wants to write business logic in a general-purpose language rather than configure a pipeline. Before committing, verify three things: that the specific input, filter and output plugins you need are documented for your platform, that the release series you install matches the maintenance policy in MAINTENANCE.md, and that your build environment has CMake >= 3.0 plus Flex, Bison, and the YAML and OpenSSL headers if you compile from source.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes