Which open-source collector replaces the Splunk Universal Forwarder
No single open collector is a direct equivalent of the Splunk Universal Forwarder. The forwarder does two jobs for most teams: it ships logs for search and analytics, and it carries security telemetry for detections. In open source, those jobs usually split. Fluent Bit or Fluentd handles log shipping, the Wazuh agent handles security monitoring on endpoints, and the OpenTelemetry Collector handles telemetry pipelines where traces and metrics are also in scope. If your Splunk renewal or a residency requirement touches ingestion, start by mapping each forwarder you run to one of those roles, not by searching for a one-to-one swap.
The forwarder is also more than a file shipper. Splunk forwarders carry their configuration in inputs.conf and outputs.conf, receive app bundles and server classes from a deployment server, and route events to specific indexes and sourcetypes. Each of those behaviors must be re-created in the new collector: parsing, tagging, index routing and the fleet-level policy that tells agents what to collect. Inventory the forwarder apps you actually use, and record which indexes, sourcetypes and destinations each one feeds, before you choose tooling. Confirm the exact versions and packaging for each collector in its own release channel, because support windows differ.
To avoid an outage, run the new collector beside the existing forwarder on the same hosts, sending to a parallel destination first. Splunk can keep receiving the original stream while the open collector feeds your new store, so you can compare event counts and field mappings for the same source. Plan for the period when both agents consume CPU, disk and network on each endpoint, and check the resource limits on your smallest hosts before you start. Cut over one source group at a time, keep the Splunk path until detections and dashboards match, and agree the rollback steps in writing before the first host changes.
How forwarder capabilities map to open-source collectors
This table maps the main functions of the Splunk Universal Forwarder to Fluent Bit, Fluentd, the Wazuh agent and the OpenTelemetry Collector. Read each row as a question: which tool covers this function, and where does a gap need a second component or a design decision. Confirm specific capabilities against each project's current documentation before you commit to a design.
| Forwarder function | Fluent Bit or Fluentd | Wazuh agent | OpenTelemetry Collector |
|---|---|---|---|
| File and log monitoring | Tails files and ships them with parsers and filters; both are built for this | Collects log files and events for analysis, but is built for security events rather than general log shipping | Collects file logs through a receiver; confirm the receiver and parser set for your formats |
| Forwarding to indexers or backends | Sends to Splunk HEC, OpenSearch, Loki and other outputs; confirm the Splunk output plugin in your version | Forwards to the Wazuh server, not to Splunk or OpenSearch directly | Exports via OTLP and many exporters; confirm the exporter for your SIEM |
| Windows event logs | Fluent Bit has a Windows event log input; confirm channel coverage on your Windows versions | Strong native coverage of Windows event channels for security analysis | Windows event log receiver is available; confirm it in your collector distribution |
| Metrics collection | Fluent Bit can collect host metrics; Fluentd relies on plugins | Limited to security-relevant inventory and state, not general performance metrics | Strong, through host and scraper receivers |
| Deployment management | No central management server; use configuration management such as Ansible or Puppet | Central configuration and upgrades from the Wazuh server, the closest match to the forwarder deployment server | No built-in fleet manager in the core project; OpAMP-based managers exist, so confirm their maturity |
| Load balancing and acknowledgements | Retries and buffering exist; confirm delivery guarantees for your output and failure modes | Agent-to-server delivery is managed by Wazuh; confirm behavior during server outages | Batching, retry and queueing options; confirm settings for your exporter |
| File integrity and inventory | Not a function of either project | File integrity monitoring and software inventory feed vulnerability detection | Not a native function; use dedicated tools for file integrity |
| Compliance-oriented monitoring | Not a function; rules and dashboards come from the SIEM | Includes prebuilt compliance views for frameworks such as PCI DSS and GDPR; assess coverage against your controls | Not a function; compliance evidence depends on your SIEM |
Which collector fits which forwarder role
A Splunk Universal Forwarder does two jobs: it ships logs and it can feed security monitoring. Open-source replacements split those jobs across different collectors, so the first decision is which role each host plays. The four options below cover log shipping, endpoint security, and a vendor-neutral pipeline, and they can run side by side while Splunk keeps receiving data.
Fluent Bit for log shipping
Fluent Bit is a lightweight C agent licensed under Apache-2.0 that collects, parses and forwards logs, metrics and traces. Its documentation describes it as suited to resource-constrained and embedded environments, and it offers native OpenTelemetry (OTLP) ingestion and delivery. Check that the plugins you need for your log sources exist in the version you pin, and test parsing against real samples from each source before cutover. Fluent Bit ships logs but does not monitor endpoint integrity.
Fluentd for plugin-heavy pipelines
Fluentd is an Apache-2.0 project under the Cloud Native Computing Foundation and is described as a CNCF graduated project. It has a large plugin ecosystem, which suits sources and destinations that Fluent Bit does not cover. The trade-off is weight: Fluentd runs on a Ruby runtime and needs more memory than Fluent Bit on small hosts. For enterprise use, fluent-package LTS is the packaged channel that receives security and bug fixes, so confirm its support window before you standardize on it.
Wazuh agent for security monitoring
The Wazuh agent is licensed under GPLv2 and covers the security side of a forwarder role: log analysis, file integrity monitoring, software inventory and vulnerability detection. Agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and the Wazuh server can push configuration and upgrades to them. Agents do not replace a general log shipper for application logs, so most estates run the Wazuh agent alongside Fluent Bit or Fluentd. Confirm which Wazuh release line your agents and server share before rollout.
OpenTelemetry Collector for vendor-neutral pipelines
The OpenTelemetry Collector is a vendor-neutral pipeline for logs, metrics and traces, and it fits teams that want one telemetry standard across services. Fluent Bit's documentation notes native OTLP support, so the two can cooperate. Ask your team whether the receivers and processors you need exist in the distribution you deploy, and whether it will feed Splunk through the exporters your Splunk setup accepts. Treat it as a candidate for application telemetry first, not a direct replacement for every Universal Forwarder.
How the open collectors route data to Splunk during the move
The safest way to move off the Splunk Universal Forwarder is to keep Splunk as the receiver of record while open collectors take over one source at a time. Fluent Bit and Fluentd can each act as a forwarder on the host or as an aggregator in the middle tier, and they can run together, so a common pattern is Fluent Bit on endpoints feeding a Fluentd aggregator that holds the Splunk output. Splunk keeps receiving events through an HTTP Event Collector endpoint or a syslog input, and the switch happens per source. The Fluent Bit documentation on Fluentd and Fluent Bit describes the forwarder and aggregator roles and when each collector suits the job.
Map the trust boundaries before you change any route. There are three: the agent on the host, the aggregator, and the Splunk indexers or HEC endpoint. Each hop needs a decision on TLS, certificate validation, and client authentication. Confirm in your own environment whether your HEC tokens are scoped to a single index and sourcetype, whether the aggregator holds a token that can write to production indexes, and whether the aggregator's buffers are encrypted at rest if they hold events during an outage. Keep the tokens per source so that revoking one route does not stop the others.
Move one source at a time and leave indexing and detections unchanged until parity is confirmed. For each source, run the open collector and the Universal Forwarder in parallel, compare event counts, timestamps, field names and sourcetype assignment in Splunk, and only then stop the forwarder. Keep existing correlation searches and alerts pointed at the same indexes so that any difference shows up as a data difference, not a rule change. Stop the forwarder only after the comparison has been signed off by the team that owns the detections.
Migrating forwarder by forwarder without losing events
This sequence moves log and security collection off Splunk forwarders one host group at a time, with the open collector and the forwarder reporting in parallel until event counts and field mappings match, so Splunk keeps receiving every event until the cutover is confirmed.
Inventory every forwarder and its configuration
The Splunk administrator exports the configuration that defines each forwarder's behavior: inputs.conf for monitored files, ports and scripted inputs, outputs.conf for receiving indexers, and any apps delivered through the deployment server. Record the host, operating system, sourcetype, target index and owning team for each input. Ask the platform team which hosts sit on networks without internet access, since those change the installation route. The step is done when every input maps to a named owner and a target destination, and nothing is left undocumented in a local configuration file on a single host.
Select a low-risk source for the first move
Choose a host group that produces a steady, well-understood stream, such as a set of Linux application servers, and avoid a source that feeds a live detection or a regulated report. Confirm with the detection owners which Splunk searches depend on that source. Decide which open collector fits the job: Fluent Bit or Fluentd for log shipping, the Wazuh agent where endpoint security monitoring is the goal, or the OpenTelemetry Collector for telemetry pipelines. The step is done when the source, the collector and the rollback owner are written down and approved.
Prepare the collector and its install route
The platform team installs the chosen collector on the pilot hosts alongside the existing Splunk Universal Forwarder, without stopping the forwarder. For Wazuh agents, the Wazuh documentation lists several deployment options, including Ansible, Puppet and Docker. Hosts without internet access need the offline installation route described in the Wazuh documentation, and vulnerability detection there can use an offline repository in place of the Wazuh Cyber Threat Intelligence platform. Confirm with the vendor or your own package mirror which versions you are allowed to use. The step is done when the collector process runs and its configuration is version-controlled.
Run both paths in parallel
Configure the open collector to send the same source to its new destination while the forwarder continues to send to Splunk. Keep the forwarder's outputs unchanged during this period so Splunk stays the system of record. Watch host resource use and network throughput on the pilot hosts, and confirm that the collector's buffering and retry settings match what your network can absorb during an outage. The step is done when both paths are confirmed to run without errors for a period your change board has agreed in writing.
Compare event counts and field mappings in Splunk
The analyst runs the same time-bounded searches against both paths and compares event counts per host, sourcetype and index, then checks that key fields such as timestamp, host, source, severity and user match. Mismatches usually come from multiline parsing, timezone handling or field extraction differences, so test those first. Where a Splunk correlation search depends on a specific field, confirm the value appears in the new pipeline. The step is done when counts agree within a tolerance the detection owner has signed off and every dependent field is mapped.
Reroute indexes and sourcetypes
Once the comparison passes, the platform team points the open collector's destination at the production store, such as OpenSearch or the Wazuh indexer, and maps each Splunk index and sourcetype to an equivalent index or rule set there. Update the dashboards and saved searches that read the source so they query the new location. Keep the forwarder in place as a fallback. The step is done when production consumers read the source from the new destination and the old Splunk index receives no new data from that host group.
Retire the forwarder after a confirmed window
Stop the Splunk Universal Forwarder on the pilot hosts, remove it from the deployment server's app list, and disable the matching outputs.conf entry, but only after the agreed observation window has passed without a missed event or a broken detection. Document the change, the rollback steps and the final event comparison as evidence for your change record. Repeat the same sequence for the next host group. The step is done when the forwarder is removed, the deployment server no longer serves it, and the signed-off comparison is filed with the change.
Coexistence paths for Linux, Windows and air-gapped hosts
On Linux servers and containers, the usual pattern is to keep log shipping and security monitoring as separate lanes. Fluent Bit is a lightweight log, metrics and trace processor that runs on Linux, BSD, macOS and Windows, and it is licensed under Apache-2.0. Its documentation says it suits resource-constrained hosts and high-performance collection, and it offers native OpenTelemetry (OTLP) ingestion and delivery. The OpenTelemetry Collector is the other common choice where traces and metrics share the pipeline with logs. Wazuh agents run on Linux as well, so file integrity monitoring and vulnerability detection can stay on the same host.
- Log shipping: Run Fluent Bit as a DaemonSet or systemd service, and send a copy of each stream to Splunk while the new destination is built.
- Security lane: Keep the Wazuh agent on the host so existing Splunk detections keep their input until rules are rebuilt.
- Supported Linux: Wazuh agents support Linux, and fluent-package v6 targets RHEL 8, 9 and 10, Ubuntu 22.04, 24.04 and 26.04, and Debian 12 and 13.
- Plugin needs: Fluentd has a larger plugin ecosystem, so choose it only when a source requires a plugin Fluent Bit lacks.
- Container logs: Confirm which container runtime and log path your platform uses before you point the collector at it.
Before cutover, check each collector's version against the release notes and confirm the Splunk receiving port and TLS settings with the platform team.
Windows endpoints usually need two agents: one for event log shipping and one for security monitoring. For shipping, fluent-package v6 is the current Fluentd distribution for Windows, and it is the successor to Treasure Agent. Its LTS channel receives only security and bug fixes, and fluentd.org recommends LTS for enterprise services. For security monitoring, the Wazuh agent is the open-source counterpart to the Splunk forwarder's role in collecting Windows event data, and it adds file integrity monitoring and inventory for vulnerability detection.
- Supported Windows: The fluent-package v6 download page lists 64-bit Windows Server 2016 or later and Windows 10 or later. Check your build against that list before you plan rollout.
- Channel choice: Use the LTS channel for shipping agents, and note that fluent-package LTS v6.0.5 is supported until December 2027.
- Retired agents: fluent-package v5 reached end of life in December 2025 and td-agent v4 in December 2023, so any host still running them has no further security updates.
- Wazuh agent: Wazuh agents run on Windows and can be configured and upgraded from the Wazuh server.
- Commercial support: The fluent-package page says several companies offer Fluentd support, including help upgrading from end-of-life versions.
Confirm with your Windows team whether group policy or endpoint management tooling will deploy both agents, and test on one host group first.
Air-gapped networks change two things: how software reaches the hosts, and where vulnerability data comes from. Wazuh publishes an offline installation guide for systems without internet connectivity. For vulnerability detection, Wazuh correlates the software inventory that agents collect with data from either the Wazuh Cyber Threat Intelligence platform or an offline vulnerability repository. On an isolated network, the offline repository is the option that keeps the feed under your control, so the approach depends on your own update process.
- Offline Wazuh: Use the offline installation guide, and stage every package and dependency on the isolated side before installation.
- Offline vulnerability repository: Plan how the vulnerability data is imported and refreshed, because detection quality depends on the age of the data.
- Collector packages: Mirror the Fluent Bit, fluent-package and Wazuh agent packages into an internal repository, and verify checksums before import.
- Release tracking: Wazuh's 4.14 patch cadence is roughly every one to two months, so schedule transfers around those releases.
- Ownership: Name who signs off on each transfer across the air gap and keep a record of each import.
Ask the Wazuh and Fluentd vendors, or your implementation partner, to confirm which packages and update methods they support for your specific isolation model before you commit to a design.
What does replacing the Splunk forwarder cost and take?
What drives the total cost of replacing Splunk forwarders?
The total is driven mostly by staff time, not by software fees, because Fluent Bit, Fluentd, the Wazuh agent and the OpenTelemetry Collector carry no license charge. Cost components are the engineering time to write and test pipeline configuration for each source, the compute to run collectors and any aggregation tier, the time to run Splunk and the replacement in parallel, and any paid support contract you choose. Costs recur in staff time for maintaining pipelines and upgrading agents. Ask any vendor or partner for a written breakdown of these components against your source count and daily volume.
Is Fluentd or Fluent Bit cheaper to run on each host?
Fluent Bit is generally the lighter choice on each host. The Fluent Bit documentation's comparison table lists it at about 450 KB of memory with no dependencies beyond its plugins, while Fluentd is listed at more than 60 MB and ships as a Ruby gem with its own dependencies. Fluentd's advantage is its plugin ecosystem, which the documentation lists at more than 1,000 external plugins, so teams with unusual sources may need it. Many teams run Fluent Bit on endpoints and servers and Fluentd as an aggregator where the plugins are needed. Measure memory and CPU under your own log volume before choosing.
Can our own team replace the Splunk forwarders without an outside partner?
A team with Linux and Windows administration experience and someone who knows Splunk inputs can usually do the work internally, provided it has time set aside for it. The tools are open source and documented, so the main gap is usually capacity and the test plan rather than tooling. Teams without that capacity often use a fixed-scope engagement for the pipeline build and then keep the work in-house. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure under a written scope, and that scope can cover only the collector layer if you prefer.
How long does the parallel run last during a forwarder migration?
The parallel run ends when the new collectors deliver the same events and alerts that Splunk receives, and that depends on your sources and detections, not a fixed period. Duration is set by how many source types you have, how many correlation searches need matching, and how long you need to compare alert output across a full business cycle. Keep Splunk receiving data from the existing forwarders until each source is verified, then switch that source over. Ask for the exit criteria in writing before the work starts so the parallel period is bounded by tests rather than by calendar.
What skills and test plan does a forwarder replacement need?
The work needs a Splunk administrator who knows inputs, indexes and sourcetypes, Linux and Windows administrators who can deploy and service agents, and a security engineer who owns detection content. The test plan should list every source, the expected event count and format, the destination index or data stream, and a pass condition. Include tests for dropped events during restarts, for timestamp and field parsing, and for alerts that fire in both systems. Keep the plan in version control so it can be rerun after every agent upgrade.
Does Wazuh or Fluent Bit need an agent upgrade schedule, and how often?
Yes, both need a planned upgrade schedule, and the schedule should match each product's support window. Fluent Bit's current line moves quickly, with v5.1.4 published on October 16, 2026, so pin a version and test each upgrade. For Fluentd, the fluent-package LTS channel is supported until December 2027 and receives only security and bug fixes, which suits enterprise services. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so plan for regular patch cycles. Confirm support dates with each vendor before you commit to a version.
Can a deployment server and forwarder management be replaced?
Yes, but the replacement is a set of tools rather than one drop-in server. Splunk's deployment server pushes forwarder configuration and app bundles to clients, and open alternatives cover this with configuration management such as Ansible or Puppet, which Wazuh's deployment options also list. Wazuh's server can manage agent configuration and upgrades remotely, which covers the security agent fleet. Fluent Bit and Fluentd configurations are plain files that can be templated and distributed through your existing tooling. Confirm the fleet size, change approval steps and rollback needs before choosing the mechanism.
What support contracts exist for Fluentd and what do they cost?
Commercial support for Fluentd is available from several companies, and fluentd.org recommends the LTS channel for enterprise services. Support contracts are a recurring cost that depends on the vendor, the number of agents, the response levels and whether help with upgrades from end-of-life versions is included. The fluent-package download page notes that v5 reached end of life in December 2025 and td-agent v4 in December 2023, so an older install may need an upgrade project first. Request a quote that lists covered versions, response times and upgrade assistance in writing.
What changes for Splunk users, admins and analysts
Configuration ownership moves from the Splunk admin to the platform team that owns the collectors. Today a Splunk admin typically manages forwarder inputs and outputs through deployment server apps, and the indexer decides how events are parsed. After the switch, Fluent Bit or Fluentd pipelines are defined in files you version and deploy yourselves, and a Wazuh agent's behavior is set in its configuration and managed remotely from the Wazuh server. Confirm which team will own each collector, who approves changes, and where configuration lives before the first agent is installed. Splunk's own apps and props.conf settings do not carry over, so inventory every inputs.conf and props.conf entry in use today.
Analysts will notice two changes that affect searches and alerts. Field names and sourcetypes will not match: a Splunk sourcetype such as linux:secure has no automatic equivalent, and the Wazuh decoders and Fluent Bit parsers produce their own field names. Plan a field mapping table and rewrite saved searches against it. Alert timing also changes, because events reach the detection layer through a different path. Wazuh rules run in the Wazuh server as events arrive, so detections for endpoint events stop depending on Splunk's scheduled searches. Measure the delay between an event and its alert in both systems during the parallel run, rather than assuming they match.
On licensing, Fluent Bit is published under the Apache-2.0 license and Fluentd is also Apache-2.0, while Wazuh is distributed under GPLv2 with an OpenSSL linking exception. These are facts to record in your software inventory and procurement file, and they carry obligations that your legal team should read directly from each project's license text. Splunk remains licensed under your existing agreement until your team decides otherwise, so keep forwarders and indexers running and confirm the contract end date with Splunk before you retire anything.
How DeployOpen scopes and delivers a forwarder migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a forwarder migration, we agree the collector scope in writing first, then build and test the collectors alongside Splunk until the data paths match.
How we scope
- Inventory every Universal Forwarder host, its inputs and the Splunk indexes each one feeds
- Decide per source whether Fluent Bit, Fluentd, the Wazuh agent or the OpenTelemetry Collector fits
- Agree deliverables, timelines and responsibilities in a fixed-scope written statement of work
How we build
- Deploy collectors in your cloud accounts, data centers or air-gapped networks with documented configuration
- Run new pipelines beside existing forwarders so Splunk keeps receiving data throughout
- Test event parity, field mapping and alert behavior against Splunk before any cutover
How we hand over
- Deliver configuration files, runbooks and a source-to-collector inventory your team can maintain
- Walk operators through collector upgrades, health checks and troubleshooting on your own systems
- Document the decommissioning steps for each forwarder and the evidence of each cutover
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Track collector releases and plan upgrades that match your change control windows
- Prepare controls and evidence for compliance assessments, while independent auditors issue any formal reports
