Which open-source log shipper fits your environment
For lightweight collection on constrained hosts such as servers, containers and edge devices, Fluent Bit is the usual first choice in this group. Fluentd fits when a large plugin ecosystem or a separate aggregation tier matters more than footprint, and the OpenTelemetry Collector fits when your team is standardizing on OTLP across traces, metrics and logs. Vector, Grafana Alloy and Logstash are credible alternatives that need their own evaluation; this page compares only the three options above in depth.
Start with the host, not the tool. List where logs originate (bare metal, VMs, Kubernetes nodes, edge hosts), which backend already receives them, and whether that backend accepts OTLP or specific shipper protocols. Fluent Bit's documentation describes it as suited to resource-constrained and embedded environments, and it lists more than 100 built-in plugins, while the same comparison table puts Fluentd's memory use above 60 MB and notes it ships as a Ruby gem with dependencies. Confirm footprint on your own hardware under your real log volume, because published figures describe defaults, not your workload.
Plan for the second decision as well: whether you need an aggregation tier. Fluentd and Fluent Bit can each act as a forwarder or an aggregator, and the Collector can run as an agent beside services or as a gateway. Check which fluent-package build you would deploy, since the LTS channel receives only security and bug fixes and the v5 line has reached end of life. Confirm vendor support terms and plugin coverage for your sources with each project before you commit.
Which log shipper suits which scenario
This table maps common log collection scenarios to the agent most likely to fit, with the condition that makes each choice hold. Read each row as a starting point: the condition column tells you what must be true in your environment before the recommendation applies.
| Scenario | Best fit | Why and the condition it depends on |
|---|---|---|
| Edge or embedded Linux hosts with tight memory | Fluent Bit | The Fluent Bit documentation describes it as suited to resource-constrained and embedded environments and lists its memory use at about 450 KB. This holds when the host has little spare memory and you need a single native binary with few dependencies. |
| Kubernetes nodes shipping to Loki or VictoriaLogs | Fluent Bit | Loki's documentation lists Fluent Bit among its supported clients, and VictoriaLogs lists it among supported shippers. Confirm the output plugin and label mapping you need for your log schema before committing. |
| Legacy estate already running Fluentd or td-agent | Fluentd (fluent-package) | Keeping Fluentd avoids rewriting existing plugins and configuration. Note that td-agent v4 is past end of life, and fluent-package LTS v6.0.5 is supported until December 2027, so plan the move to a supported package line. |
| Team standardizing on OpenTelemetry pipelines | OpenTelemetry Collector | The Collector is vendor-agnostic, runs as an agent or gateway, and is Apache-2.0 licensed. This fits when traces, metrics and logs share one pipeline; confirm the stability level of each log component in its README first. |
| Team that needs a large set of community plugins | Fluentd | Fluentd cites more than 500 plugins on its site, and the Fluent Bit documentation says Fluentd suits cases that need its large plugin ecosystem. Verify that each plugin you need is maintained and compatible with your version. |
| Evaluating a single agent for mixed workloads and sinks | Vector, Grafana Alloy or Logstash (confirm fit first) | This page does not compare these tools in depth, so confirm whether your sinks, transforms and fleet management needs fit them before choosing one of the three listed agents. |
Fluent Bit, Fluentd and the OpenTelemetry Collector in brief
All three options are Apache-2.0 licensed, so the choice turns on runtime footprint, plugin reach and how much of your pipeline you want to standardize on OpenTelemetry. Each card below names the release line we could verify, the trade-off that matters most, and the check to run before you commit.
Fluent Bit
Fluent Bit is a lightweight telemetry agent written in C that processes logs, metrics, traces and profiles. Its documentation lists about 450 KB of memory and more than 100 built-in plugins, and it offers native OTLP ingestion and delivery. The latest maintained release we could verify is v5.1.4, published October 16, 2026. Check that the plugins you need, such as your specific output or parser, are built in rather than requiring a custom build.
Fluentd
Fluentd is a unified logging layer written in C and Ruby, shipped as a Ruby gem with external plugins. Its documentation cites more than 1,000 external plugins, and fluentd.org describes it as a CNCF graduated project. The trade-off is memory and dependencies: the documentation lists more than 60 MB of memory, so it fits aggregator roles better than small hosts. Confirm current CNCF status directly with the CNCF before citing it in a design document.
OpenTelemetry Collector
The OpenTelemetry Collector is a vendor-agnostic pipeline that receives, processes and exports telemetry, and it can run as an agent beside services or as a gateway. It is Apache-2.0 licensed and ships contrib builds with signed artifacts, SHA256 checksums and SBOM files. Its trade-off is maturity variance: core components have mixed stability levels, so check each component's README before you depend on it for logs.
Choosing between the three
These options overlap, and Fluent Bit and Fluentd can be used together or alone, with Fluentd suited to cases that need its large plugin ecosystem. Teams often treat the Collector as the standard for traces and metrics while keeping a log agent for file tailing on hosts. Decide which layer owns each signal before choosing a binary, because that decision drives configuration effort more than license does.
How the three agents compare on footprint, plugins and OpenTelemetry
This table sets Fluent Bit, Fluentd and the OpenTelemetry Collector side by side on language, memory, plugins, scope, OpenTelemetry support, packaging and license. Read the cells as a starting point: where a cell says to confirm, the supplied research does not settle the point, so check the vendor documentation before you decide. The main takeaway is that Fluent Bit and Fluentd are log-focused agents with different footprints, while the Collector is a general telemetry pipeline.
| Capability | Fluent Bit | Fluentd | OpenTelemetry Collector |
|---|---|---|---|
| Implementation language | C | C and Ruby | Confirm in the OpenTelemetry Collector repository |
| Memory footprint | About 450 KB, per the Fluent Bit comparison table | More than 60 MB, per the Fluent Bit comparison table | Confirm for your chosen distribution and components |
| Plugin count | More than 100 built-in plugins | More than 1,000 external plugins, per the Fluent Bit comparison table | Receivers, processors and exporters; confirm component counts in the contrib distribution |
| Scope | Embedded Linux, containers and servers | Containers and servers | Agent next to services or gateway accepting data from many sources |
| OpenTelemetry support | Native OTLP ingestion and delivery | OpenTelemetry through plugins | Vendor-agnostic core for receiving, processing and exporting telemetry |
| Packaging | Confirm in the Fluent Bit documentation for each platform | Shipped as a Ruby gem with dependencies; fluent-package for supported Linux and Windows hosts | Contrib distribution with signed artifacts, SHA256 checksums and SBOM files |
| License | Apache-2.0 | Apache-2.0 | Apache-2.0 |
What running each agent asks of your team
The main operating cost of a log shipper is who owns its configuration. Whichever agent you choose, your team keeps the pipeline files, parsers, filters and output settings under version control, tests them against sample logs, and reviews every change before it reaches production. Fluent Bit keeps this surface small because it is a single binary with its own configuration format. Fluentd adds a Ruby plugin layer that someone must track: each plugin version, gem dependency and Ruby runtime needs an owner. The OpenTelemetry Collector moves the work into a YAML pipeline of receivers, processors and exporters, and you decide which components go into your build. Confirm with each vendor which configuration keys and plugin names are stable before you write your runbook.
Upgrades differ mostly in what they pull in. A Fluentd upgrade is a chain: the core gem, the plugins you installed, and their dependencies must all be tested together, which is why fluent-package LTS is the usual path for enterprise services. Fluent Bit ships as one compiled binary, so an upgrade replaces one artifact, although you still test your parsers against the new version. The Collector is distributed as the contrib distribution and can be assembled with its builder, so your team may maintain a custom build that must be rebuilt for each release. Check whether your chosen distribution suits your component list before you commit to a build pipeline.
Collector components do not share one stability level. The OpenTelemetry status page says core components have mixed stability levels, and each component's README documents its own level, while log SDK maturity also varies by language. Treat a component marked as development or alpha as something you test and monitor, not something you rely on for compliance-relevant log delivery. Build a short acceptance test for each receiver and exporter you use: send known log lines, confirm they arrive intact at the backend, and record what happens during a backend outage.
Choosing an agent by environment
Where memory and disk are tight, the agent's footprint decides most of the comparison. The Fluent Bit documentation describes it as suited to resource-constrained and embedded environments, is written in C, and lists its memory use at about 450 KB in its comparison table. Fluentd is written in C and Ruby and is listed at more than 60 MB, so it is a poor fit for small devices unless you have memory to spare.
- Footprint: Fluent Bit's documented scope includes embedded Linux, containers and servers, while Fluentd's documented scope is containers and servers.
- Plugins: Fluent Bit lists more than 100 built-in plugins with no dependencies beyond what each plugin needs, which keeps the install small.
- OpenTelemetry: Fluent Bit offers native OTLP ingestion and delivery, which helps when the backend already speaks OTLP.
- Licensing: Fluent Bit is Apache-2.0 licensed, so embedding it in a device image is a licensing review rather than a new commercial agreement.
- Version line: Fluent Bit v5.1.4 was published on October 16, 2026, with v5.0.11 released for the previous line on October 9, 2026.
Confirm the exact memory and CPU budget on your device, test the build for your architecture, and check the Fluent Bit release notes for the version you plan to ship.
In Kubernetes, the choice is usually between a node-level agent that reads container logs and a gateway that receives telemetry from many sources. Fluent Bit runs well as a lightweight node agent, and the OpenTelemetry Collector can run either as an agent beside services or as a gateway that accepts data from many sources. Fluentd can fill the aggregator role when its plugin ecosystem is needed.
- Node agent: Fluent Bit is documented as able to act as a forwarder or an aggregator, which makes it a common choice for a per-node collector.
- Gateway tier: The OpenTelemetry Collector can receive, process and export telemetry from many sources, and its contrib distribution ships with signed artifacts, SHA256 checksums and SBOM files.
- Authentication: Collector authenticator extensions can authenticate incoming connections, for example with OIDC, and add credentials to outgoing exporter requests.
- Component stability: Core Collector components have mixed stability levels, documented in each component's README, so check each receiver and exporter you deploy.
- Fluentd in clusters: Fluentd suits cases that need its large plugin ecosystem, which is a reason to keep it in a cluster only if a required plugin exists.
Confirm which receivers, processors and exporters you need, check the stability level of each component, and pin the Collector distribution version you test.
Mixed fleets need an agent that installs cleanly on each operating system you run. For Fluentd on Windows, the supported platform list comes from the fluent-package v6 download page, which lists 64-bit Windows Server 2016 or later and Windows 10 or later. Fluent Bit is described as running on Linux, BSD, macOS and Windows, and the Collector is distributed as a binary for hosts that run it outside containers.
- Windows support: fluent-package v6 is published for 64-bit Windows Server 2016 or later and Windows 10 or later, and no other Windows versions are listed in the supplied sources.
- Linux families: fluent-package v6 is also published for RHEL 8, 9 and 10, Amazon Linux 2023, Ubuntu 22.04, 24.04 and 26.04, and Debian 12 and 13.
- Single agent or two: Running one agent across all hosts simplifies configuration, while separate agents for Windows and Linux can fit teams that already manage each platform differently.
- Operating effort: Each agent version needs its own patch cycle, so count the packages and repositories you must track on each host family.
- Version pinning: Fluent Bit and the Collector both publish frequent releases, so set an update window for each.
Confirm support for your exact Windows and Linux versions with the vendor before you build images, because the supported lists above are the ones named in the supplied sources.
If you already run Fluentd or td-agent, the first task is to check where each package sits in its lifecycle. fluent-package is the successor to Treasure Agent (td-agent), and its LTS channel gets only security and bug fixes, with no new features. Fluentd.org recommends LTS for enterprise services. Older packages have already left support, so an estate on them needs a plan before any migration decision.
- Current LTS: fluent-package LTS v6.0.5 is supported until December 2027, per the fluent-package download page.
- End of life: fluent-package v5 reached end of life in December 2025, and td-agent v4 reached end of life in December 2023.
- No further fixes: The download page says the end-of-life versions receive no further releases or security updates, so they carry unpatched exposure.
- Commercial help: The download page says several companies offer commercial support for Fluentd, including help upgrading from end-of-life versions.
- Migration choice: Upgrading to fluent-package LTS keeps your Fluentd configuration and plugins, while moving to Fluent Bit or the Collector requires a configuration and plugin review first.
Inventory every host still running td-agent or fluent-package v5, confirm which plugins each pipeline depends on, and ask any commercial support provider to quote the upgrade from your exact version.
Licensing, release lines and paid support for log shippers
All three agents covered here are Apache-2.0 licensed: Fluent Bit, Fluentd and the OpenTelemetry Collector repository. Apache-2.0 is an OSI-approved license, so the source and binaries can be used, modified and redistributed without a license fee. None of the supplied sources shows a paid edition of the agents themselves. Cost therefore comes from three separate layers: the upstream open-source release, a packaged distribution you choose to run, and commercial support from a third party. Decide which layers you need before comparing offers, because each one has different terms and different owners.
For Fluentd, the enterprise channel is fluent-package, which replaced Treasure Agent (td-agent). Its LTS line, fluent-package LTS v6.0.5, is supported until December 2027 and receives only security and bug fixes, with no new features. fluentd.org recommends LTS for enterprise services, and that recommendation applies to fluent-package, not to the upstream gem. fluent-package v5 reached end of life in December 2025 and td-agent v4 in December 2023, with no further releases or security updates. Check that your operating systems appear in the fluent-package v6 platform list before you standardize. The OpenTelemetry Collector takes a different route: its releases ship the contrib distribution with signed artifacts, SHA256 checksums and SBOM files, alongside the Collector builder and OpAMP supervisor. Those artifacts help with verification and software inventory, but they are not a support commitment. The supplied facts do not describe an equivalent enterprise channel for Fluent Bit, so confirm that with its maintainers.
Commercial support for Fluentd comes from several companies, according to the fluent-package download page, and that page notes that some of them help upgrade from end-of-life versions. Ask each provider which Fluentd or fluent-package versions it covers and the end date for each, whether it ships fixes for LTS between upstream releases, and what response times are written into the agreement. Ask which operating systems it supports, how it handles upgrades from td-agent or fluent-package v5, who verifies the artifacts and SBOMs it delivers, and how it protects log content it can see during support sessions. Confirm exit terms and how the agreement ends if the version you run leaves support. DeployOpen scopes implementation and upgrade work in writing before it starts, so ask for the same level of written detail from any provider, whoever it is.
How to choose and pilot a log shipper
This sequence moves from your own log sources and host limits to a tested shortlist and a decided aggregation design, so you can pick between Fluent Bit, Fluentd and the OpenTelemetry Collector on evidence from your environment rather than from a feature table.
Inventory log sources and host constraints
Platform, security or operations staff list every system that produces logs, including the format of each source (syslog, JSON, application text, Windows event logs, container stdout), the hosts that will run the agent, and the limits on those hosts such as memory, CPU, OS versions and whether embedded or constrained machines are included. The output is a written inventory with one row per source and one row per host class. You know this step is done when every host class has a named owner and a stated operating system and memory ceiling that the pilot must respect.
List the backend and its supported shippers
Identify where logs will be stored or searched, such as a log store, a SIEM or an object-store-backed system, and check its documentation for the shippers and protocols it accepts. Some backends document specific agents, so confirm this with the vendor or in its current docs rather than assuming. The output is a shortlist of shippers that the backend accepts directly, plus any that would need an intermediate hop. You know this step is done when each candidate shipper has a documented path into the backend that your team has verified.
Decide whether OTLP is a requirement
Security architects and telemetry owners decide whether logs must travel over OpenTelemetry Protocol (OTLP) or whether a vendor-specific or syslog path is acceptable. If OTLP is required across traces, metrics and logs, the Collector and Fluent Bit both have documented OTLP support, and Fluentd reaches OpenTelemetry through plugins. If it is optional, record that decision and why. The output is a yes or no requirement with an owner. You know this step is done when the requirement is written into the pilot criteria and approved by the team that will run the pipeline.
Check plugin coverage for each source format
Map each source format from the inventory to a plugin or receiver in every candidate shipper, and mark whether the component is built in, community maintained or needs custom work. Fluentd has a large plugin ecosystem that suits uncommon formats, while Fluent Bit's built-in set covers common cases with a smaller footprint. The output is a coverage matrix showing gaps. You know this step is done when every source has at least one confirmed path or a documented gap that someone has accepted as work to build.
Measure resource use on a representative host
Install each shortlisted agent on a host from the inventory that matches your production class, using the same configuration, and run it against realistic log volume replayed or captured from your environment. Record CPU, memory and disk buffer behavior, along with what happens when the backend is slow or unreachable. Set your own pilot criteria before testing so the results are judged against thresholds your operators agreed on. The output is a comparison sheet of measured results. You know this step is done when each candidate has been measured under the same load and failure conditions, and the criteria have been applied without changing them after the results arrived.
Test upgrades and configuration rollout
Confirm which release line you would deploy and its support window in the project's own release documentation, then test an upgrade from the version you plan to start with to a newer one, and roll out a configuration change across a sample of hosts using your normal tooling. Check that the agent keeps its position in log files, that buffers survive restarts, and that rollback works. The output is a documented upgrade and rollout procedure with observed results. You know this step is done when the upgrade and rollback have been run end to end on the pilot hosts and the team has written down what it had to change.
Decide the aggregation tier
Decide whether each shipper runs only as a node agent, only as a central aggregator, or in both roles with a forwarding and aggregating split. Use the results from the earlier steps to decide where parsing, enrichment and routing happen, and who owns each tier. The output is a written topology diagram with the agent and aggregator roles named, along with the ownership and change process for each. You know this step is done when the chosen topology has passed the resource and upgrade tests and every route from source to backend is traceable to a named component.
Common questions before choosing a log shipper
How much does it cost to run Fluent Bit or Fluentd?
The software itself is open source, so the license fee is zero, but running it is not free. Cost comes from staff time to write, test and upgrade pipeline configuration, from packaging and OS support if you use a supported package, from any commercial support contract you choose, and from the infrastructure that hosts the agents and the backend that receives their output. Fluentd's packaged LTS channel is maintained by a separate project, and the fluent-package download page notes that commercial support is available from several companies. Ask each vendor for a written scope covering support hours, supported OS versions and upgrade help before you compare totals.
How long does a log shipper pilot take?
The duration depends on your scope, not on the tool alone. Set the length from the number of log sources, the parsing and filtering rules you need, the destinations you must test, and the change approval steps in your environment. A useful pilot covers one representative host group, measures dropped or duplicated records, and checks the agent's resource use under peak load. Write the success criteria before work starts, and agree the timeline in a written, fixed scope if you engage an outside partner.
Can our team run a log shipper without outside help?
Often yes, if you already run Linux fleets and have someone who can read and test configuration files. Fluent Bit and the OpenTelemetry Collector both use declarative configuration that can be kept in version control. The harder work is ongoing: owning parser rules, reviewing plugin changes, scheduling upgrades before a version leaves support, and testing that logs still arrive after each change. Judge your readiness by whether a named team owns those tasks today, and use a pilot to confirm the skills before you commit.
Can Fluent Bit replace Fluentd?
For many collection and forwarding jobs, yes, but not for every job. The Fluent Bit documentation describes it as suited to resource-constrained and high-performance collection, while Fluentd is suited to cases that need its large plugin ecosystem. Before you migrate, list every input, filter and output you use in Fluentd, then confirm each one has a Fluent Bit equivalent in the version you plan to run. Fluent Bit and Fluentd can also run together, so a staged move is an option. Check the Fluent Bit comparison with Fluentd for the current scope.
Does the OpenTelemetry Collector replace Fluent Bit and Fluentd?
Not automatically. The OpenTelemetry Collector is a vendor-neutral way to receive, process and export telemetry, and it can run as an agent next to services or as a gateway. It fits well when you want one pipeline for traces, metrics and logs and you need OpenTelemetry-native formats. Its stability levels vary by component, which is documented in each component's README, so check the specific receivers and processors you need. If your current pipeline depends on a Fluentd plugin or a Fluent Bit input with no Collector equivalent, keep that agent until the gap is closed.
What does running a log shipper ask of our team?
Three ongoing responsibilities matter most. First, configuration ownership: someone must own parsing rules, routing and the mapping of fields to your backend schema. Second, upgrades: the Fluent Bit and Collector projects publish frequent releases, and fluent-package LTS and similar channels have their own end dates, so track each support window. Third, testing: every configuration change should be checked against sample logs, and the team should watch for dropped records, buffer growth and authentication failures after each deployment. Write these duties into a runbook before rollout.
Should we evaluate Vector, Grafana Alloy or Logstash too?
Yes, if your constraints point to them. Vector, Grafana Alloy and Logstash are common alternatives and this page does not score them in detail. Evaluate them on the same criteria you use for the three agents: license, plugin coverage for your sources and destinations, OpenTelemetry support, resource use, and the effort to upgrade. If your backend is Grafana Loki, check how each agent sends data to it, since the Loki documentation lists Fluent Bit among its supported clients. Confirm current versions and licenses directly with each project before you shortlist.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For log shippers, that means choosing the agent against your sources, destinations and team skills, then rolling it out in your environment with written scope and handover.
How we scope
- Inventory log sources, hosts, containers and network devices before naming any agent
- Record destinations such as Loki, OpenSearch or a SIEM, and their ingestion requirements
- Agree in writing which agents, plugins and OpenTelemetry signals are in and out of scope
How we build
- Deploy the chosen agent as forwarder, aggregator or both, matching your topology
- Configure parsing, filtering and TLS settings, and test each pipeline against real sample logs
- Confirm plugin stability and version pins for each component before production use
How we hand over
- Deliver configuration files, deployment definitions and a runbook for your operators
- Document how to add a source, change a destination and roll back a pipeline change
- Provide evidence of tests run and the controls configured, ready for your own auditors
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer
- Ask for upgrade and end-of-life planning for each agent version in the written quote
