Fluentd vs Fluent Bit

Running cost splits across four payers: your infrastructure team (aggregator capacity and the per-node footprint of every forwarder), your engineers (writing and maintaining Fluentd Ruby plugins or Fluent Bit configuration), your support budget (if you buy commercial support, which the fluent-package download page says several companies offer for Fluentd, including help upgrading from end-of-life versions), and your upgrade effort. Fluent Bit's footprint is the main infrastructure lever. The Fluent Bit documentation's comparison table lists Fluentd at more than 60 MB of memory and Fluent Bit at about 450 KB, so a fleet of thousands of small nodes or embedded devices is where that gap shows up in the bill. Confirm the figures against your own workload, since the table describes the agents, not your pipeline.

Costs fall into two groups. One-time costs include the migration itself, rebuilding pipelines in a new configuration model, re-testing parsers and destinations, and moving off td-agent v4 or fluent-package v5, both past end of life. Recurring costs include patching, keeping plugin versions aligned with your Fluentd release line (v1.19.4 was published on September 28, 2026), monitoring the aggregator tier, and capacity growth as log volume rises. Plugin maintenance is the recurring cost most often underestimated in Fluentd estates, because the Ruby plugin ecosystem is large and each plugin can have its own upkeep. Running both agents adds a second set of packages, configurations and runbooks, which is a recurring cost even when each agent is individually cheap to run.

When you request a quote, DeployOpen does not publish prices, and a quote follows from the written scope. Ask the vendor or partner to price against: the node count split by forwarder and aggregator role, the list of log sources and their formats, every destination, the full plugin list with versions, and the upgrade path from any td-agent or fluent-package estate, including whether you move to fluent-package v6 LTS (supported until December 2027) or another agent. Ask for the one-time and recurring items separately, and state which support window you are buying. Those inputs determine whether the cost of Fluentd's plugin coverage or Fluent Bit's lower footprint is the larger line item in your case.

If your Fluentd estate still runs td-agent v4 or fluent-package v5, you are already past end of life. td-agent v4 reached end of life in December 2023 and fluent-package v5 in December 2025, and neither line receives further releases or security updates. The first decision is to move to fluent-package v6 LTS, which is supported until December 2027, or to choose another agent. Waiting for a vendor patch is not an option on the ended lines, so treat the move as a current security item rather than a routine refresh.

The LTS channel is the right default for enterprise services because it receives only security and bug fixes and adds no new features. For a Fluentd estate, moving to fluent-package v6 LTS is a package upgrade: the td-agent.conf configuration and the Ruby plugins you depend on must be checked against the new package before cutover. Moving to Fluent Bit is a different kind of change. Fluent Bit uses its own configuration format and its own plugin set, so the move is a pipeline rewrite, with each input, filter and output re-expressed and tested, not a package swap. Ask your team to inventory every plugin in use and to mark which ones have a Fluent Bit equivalent before choosing a path.

fluent-package v6 is published for RHEL 8, 9 and 10, Amazon Linux 2023, Ubuntu 22.04, 24.04 and 26.04, Debian 12 and 13, and 64-bit Windows Server 2016 or later and Windows 10 or later. Confirm that each host's exact OS version appears on the fluent-package download page before you schedule the upgrade, including older hosts and images that have not been rebuilt. Hosts outside that list need an OS upgrade or a different agent. The same page says commercial support is available from several companies, including help upgrading from end-of-life versions, so ask any provider for a written scope that covers your plugin inventory, test plan and rollback path.

Fluentd projects usually run long on plugin selection and aggregator sizing. Fluentd's value comes from its plugin ecosystem, but every output and filter you rely on is a Ruby gem with its own dependencies, so the first task is mapping each source and destination to a plugin, a maintainer and a version that installs cleanly on your target operating system. Pin gem versions in the build, record which gems are dependencies of others, and test them on the same package baseline you will run in production. On the aggregator side, sizing depends on buffer paths, chunk limits and the number of forwarders feeding it, so expect a load test before you commit to a topology. Confirm the Fluentd release line and package channel first, because fluent-package LTS is the supported path for enterprise services.

Fluent Bit projects usually run long on configuration migration and OTLP mapping. Most of the effort sits in translating existing Fluentd match and filter logic into Fluent Bit's classic or YAML configuration, then checking that parsers still extract the same fields. Custom Ruby plugins are the usual surprise: if no built-in input, filter or output covers them, the replacement is a Lua filter, an external process or a change of design, and that decision should be made before the schedule is set. Map OpenTelemetry attributes deliberately, since OTLP output and input can rename or nest fields your dashboards and alert rules depend on. Test edge buffering under a network outage with filesystem or memory limits matching the device, because backpressure behavior is where edge agents most often fail quietly.

Across both agents, the reader's team must supply the inputs that stall projects. Provide a source inventory with log formats and volumes, named owners for every destination, and written retention and access requirements, including which fields may never leave the source host. Auditing retained fields is a separate workstream: a redaction rule that is missing at the forwarder is harder to fix after data reaches a backend. Agree a test window with production-like traffic and a rollback path, and ask your vendor or partner to state in writing which tasks are fixed scope and which depend on your environment. Where the effort is uncertain, confirm it with the maintainers' documentation and a pilot rather than assuming it.