5 Fluentd alternatives for security operations in 2026

Throughput runs out first. Fluentd’s own performance tuning guide states that single-process techniques are enough "if your traffic is up to 5,000 messages/sec," and points anything beyond that to the multi-process workers feature, which splits the workload across separate Ruby processes you size and configure yourself.

Independent testing lands on the same number. In a March 2026 benchmark by VictoriaMetrics, nine log collectors ran simultaneously in a single-node Kubernetes cluster on a GCP n2-highcpu-32 VM, each deployed from its official Helm chart with identical limits (1 CPU core, 1 GiB memory) and no tuning, tailing JSON logs from 100 pods. Fluentd v1.19.1 plateaued at 5,100 logs per second — last place — while Fluent Bit reached 31,300, Vector 25,000, and OpenTelemetry Collector 20,500. Fluentd was already dropping logs at 10,000 logs per second, so it was excluded from the CPU and memory comparisons entirely. Two caveats: VictoriaMetrics built the benchmark to showcase its own vlagent collector, and default configurations understate what a tuned multi-worker Fluentd can do. The configurations and source code are public if you want to reproduce the results.

The plugin model carries its own risk. Fluentd’s plugin registry is large and decentralized, and quality varies by maintainer. The project’s own plugin management documentation is direct about the risk: "Any fluentd plugin can unknowingly break fluentd completely," and the stated mitigation is "Do not use unreliable plugins." For a security pipeline, that puts plugin vetting on your team.

The last gap is operational. Fluentd ships no fleet management layer, so configuration changes and upgrades happen per host or through outside tooling, and on Windows it reads the Windows Event Log through a plugin without reaching deeper sources like ETW. For a SecOps team running collectors on thousands of mixed endpoints, those two gaps usually matter more than raw throughput.

NXLog Platform is the one option on this list that replaces more than the shipper. It combines a C-based collection agent (NXLog Agent) with centralized fleet management and built-in log storage and search, so agent enrollment and configuration pushes happen from one console instead of per host.

The Windows coverage is the sharpest contrast with Fluentd. The agent reads Windows events through the native Windows Event Log API with XPath filtering, captures Event Tracing for Windows (ETW) providers — including the Debug and Analytical channels that the API cannot read — and acts as a Windows Event Collector over WEF for agentless sources. Inputs for packet capture and file integrity monitoring cover adjacent SecOps needs without a second agent.

Here is what collecting the Security channel and shipping it to a SIEM as JSON over TLS looks like:

If you are coming from Fluentd, the concepts carry over directly. An in_tail source with a JSON parser and a <match> block becomes:

Pricing is per source rather than per gigabyte, with a free plan covering up to 10 sources at full functionality. It is a commercial product with its own configuration language to learn, and if your only job is shipping container stdout to one backend, the open-source tools below do that at no license cost.

Fluent Bit is where most Fluentd migration energy goes first: it comes from the same project family, is written in C rather than Ruby, and was the fastest collector after vlagent in the VictoriaMetrics benchmark at 31,300 logs per second — six times Fluentd’s ceiling under identical constraints. On Windows it reads the Windows Event Log through the winevtlog input, which supports XPath queries and remote collection, with the documented requirement that reading the Security channel means running as administrator.

The same benchmark surfaced its weak spots. Fluent Bit’s memory exceeded the 1 GiB container limit under peak load and was OOM-killed, and it produced 34 malformed records per hour during containerd file rotation at 10,000 logs per second — fragments of split log lines forwarded as separate records, which matters if your pipeline routes on specific fields. Like Fluentd, the open-source project includes no fleet management layer.

Pick Fluent Bit when your Fluentd deployment lives in Kubernetes DaemonSets and you want the smallest change with the largest performance gain. Our Fluent Bit vs. Logstash comparison covers its resource profile in more depth.

Vector is a Rust pipeline owned by Datadog, and its case against Fluentd is transformation power at speed. Its remap language, VRL, handles parsing, enrichment, and routing logic in one place, and the project ships frequent releases with a wide catalog of sources and sinks — including a fluent source that speaks Fluentd’s forward protocol, which makes side-by-side migration straightforward.

In the VictoriaMetrics test, Vector reached 25,000 logs per second, though its 153.5 MiB mean memory at the 10,000 logs-per-second checkpoint was the highest of the collectors that were not losing data. It also produced 2 malformed records per hour during file rotation, far fewer than Fluent Bit but not zero.

A native windows_event_log source arrived in v0.55.0 (April 2026) with pull-mode subscriptions and bookmark checkpointing. It is early code: a bug where the source froze after a few minutes of channel inactivity shipped in the first release and was fixed in v0.56.0. Pick Vector for high-volume Linux and container pipelines with heavy transformation; treat its Windows collection as maturing.

The OpenTelemetry Collector is the vendor-neutral answer: one CNCF-governed agent that receives, processes, and exports logs, metrics, and traces over OTLP, so you are never coupled to a single vendor’s format. If your organization is standardizing on OpenTelemetry for application telemetry, extending the same collector to logs removes an entire agent from your fleet.

Windows Event Log collection exists, but it lives in the contrib distribution rather than the core binary, with XPath-based XML query support and bookmark-based resumption; plan on the contrib build or a custom one. On fleet management, the Collector is the only open-source entry here with a standardized path: the Open Agent Management Protocol (OpAMP), currently in Beta, defines remote configuration, status reporting, and package updates, with supervisor and extension implementations available today. OpAMP is a protocol plus building blocks, not a finished console, so budget engineering time if you want push-button configuration management.

Performance sat mid-pack in the VictoriaMetrics benchmark at 20,500 logs per second, four times Fluentd’s rate and below Fluent Bit and Vector. Pick the Collector when protocol neutrality and a unified telemetry agent outweigh raw per-node throughput.

Logstash is the incumbent aggregator, at version 9.4.4 as of July 2026, and the strongest transformation engine on this list — Grok, conditionals, and a mature filter catalog built for pulling structure out of messy text. If your backend is Elasticsearch and your SIEM is Elastic Security, it remains the path of least resistance. We compared the two head-to-head in Fluentd vs. Logstash.

The costs are weight and defaults. Since 9.4.0, Logstash runs on JRuby 10 and requires Java 21 or later, shipping with a bundled JDK. That is a heavier per-node footprint than any C or Rust collector here. Its durability features also need deliberate enablement: persistent queues and dead letter queues are disabled by default, and the DLQ only covers the Elasticsearch output for 400/404 responses plus conditional-evaluation errors. Windows Event Log collection arrives through Beats or Elastic Agent feeding Logstash rather than a Logstash input. Pick it when you are committed to the Elastic Stack and run it as a central tier, not on endpoints.

Throughput and resource numbers for the open-source tools above come from the VictoriaMetrics benchmark (March 2026) described earlier.

Match the tool to the shape of your estate. Kubernetes-heavy with modest transformation needs: Fluent Bit gets you the biggest gain for the smallest migration. High-volume pipelines with complex parsing and routing: Vector. Standardizing on OTLP across logs, metrics, and traces: OpenTelemetry Collector. Committed to Elasticsearch with a central aggregation tier: Logstash. If your estate is Windows-heavy, your auditors expect ETW and Security-channel coverage, and nobody on the team wants to hand-manage collector configs on thousands of endpoints, the first option on this list is the one built for that job.