Migrate from Cribl Stream to Fluent Bit

Migrate from Cribl Stream to Fluent Bit: what the move involves

A security or platform team with a Cribl Stream renewal, licensing change or data residency requirement in front of it needs to know one thing first: Fluent Bit replaces the collection and routing layer, but the filters, parsers, routes and buffering behavior must be rebuilt by hand. The work is usually led by platform engineers who run the log pipeline, with SIEM engineers validating that each destination still receives the fields its detections depend on. Effort and risk concentrate in the Cribl pipelines that reshape events, not in the agents that forward them, so the inventory is the decision point. This section does not assume any fee-based feature list, and it does not treat Cribl's processing as a defect; it treats it as logic your team must now own in configuration files. Start by exporting every Cribl source, destination, pipeline and route, then mapping each one to an input, filter, parser and output in Fluent Bit. Record which pipelines drop events, mask fields, enrich with lookups or split traffic by severity, because those are the behaviors most likely to be missed. Confirm with your own engineers which Fluent Bit version and packaging channel your environment will standardize on, and check the current release notes for each plugin you depend on, since plugin availability and option names differ across releases. Ask Cribl support or your account team for the export format of your configuration, and confirm whether any Cribl-specific functions have no direct equivalent in Fluent Bit.

Replay and buffering need separate planning. Cribl can hold and route data through its own worker-side mechanisms, while Fluent Bit uses its own storage and buffering settings on each agent, and a host that loses its destination can only retain what its local buffer allows. Decide in advance how you will handle a backlog during cutover, which events must be replayed from the source rather than the pipeline, and how you will prove that no records were lost in the transition. A parallel run, where both pipelines feed the SIEM for a defined window and event counts are compared per source, is the most direct check. Document the parser output for each log type so detection content can be tested against it. Cut over one worker group or source family at a time, and keep the Cribl route in place until counts and key fields match. Plan the rollback path before you start, and treat configuration as code under version control so each change is reviewed. The engagement is usually a fixed-scope project, and its cost is driven by the number of pipelines, the complexity of their transformations, the number of destinations and the testing your SIEM team requires. Ask any implementation partner to price these components separately in a written scope, and confirm the ongoing owner for Fluent Bit upgrades and parser maintenance after go-live.

Which Cribl Stream capabilities map to Fluent Bit, and which need rework

This table maps each Cribl Stream capability to its closest Fluent Bit equivalent and labels it clean, needs rework or gap. Read the rows as a planning checklist: confirm each function against your own routes and pipelines before you commit to a cutover. Fluent Bit is Apache-2.0 licensed with more than 100 built-in plugins, but replay and fleet-level management are not supplied as direct Cribl equivalents.

Cribl Stream capability	Fluent Bit equivalent	Status
Sources (inputs)	Inputs for files, syslog, TCP, HTTP, journald and OpenTelemetry (OTLP) ingestion, covering most common log sources	Clean for standard sources; confirm any vendor-specific source
Destinations (outputs)	Output plugins for SIEM, object storage and OpenSearch-type backends; confirm the exact output for your SIEM	Needs rework where the SIEM format differs
Routes and tag-based routing	Tags and match rules send records to outputs; Cribl route filter expressions must be rewritten as tag and match patterns	Needs rework
Pipelines and functions (parse, mask, enrich)	Filters such as parser, modify, record_modifier, grep and lua cover common transforms; complex Cribl functions may need Lua or a custom step	Needs rework
Parsers and field normalization	Parser definitions in configuration files; event schema mapping to your SIEM fields must be rebuilt and tested	Needs rework
Sampling and volume reduction	Achievable with grep and conditional filters; confirm how each reduction rule maps to your SIEM retention goals	Needs rework
Replay of past data	No direct equivalent supplied; plan replay from source or archive storage and confirm with your own environment	Gap
Buffering and backpressure	Storage buffering with filesystem or memory options; tuning differs from Cribl's buffering, so test under peak load	Needs rework
Worker groups and fleet management	No Cribl equivalent supplied for central fleet control; configuration is managed through your own tooling	Gap

What data and integrations move, and what you rebuild

Migrating off Cribl Stream means inventorying every source, destination and route, then rebuilding each one as Fluent Bit configuration and checking it against the downstream SIEM. The cards below separate what carries over as data from what must be re-authored by hand.

Source definitions and listeners

Each Cribl source (syslog listeners, HTTP inputs, object store pulls, agent connections) needs a matching Fluent Bit input with the same port, protocol and framing. Record the listening address, port, protocol and any enabled authentication for each one. Confirm that every sending device or agent still points at a port Fluent Bit will hold, because a silent mismatch shows up as missing events rather than an error.

SIEM destination endpoints

Write down every SIEM endpoint Cribl sends to, including hostnames, ports, index or token names, and the protocol used for each. Fluent Bit output plugins must be chosen for each target, and an output that works in a lab may still differ in batching or retry behavior from the Cribl destination it replaces. Ask the SIEM owner to confirm which endpoints are production and which are retired.

Route rules and filter logic

Cribl routes often combine conditions on source, sourcetype and field values with drop and reduction steps. Each condition has to be rewritten as a Fluent Bit Match pattern with rewrite_tag or filter stages, and the order of evaluation must be preserved. Test each rule with sample events from production to confirm the same events reach the same destination.

Parsers and field mappings

Parsing is the piece most likely to change shape. Cribl parser functions and field renames need equivalent Fluent Bit Parser definitions, modify or record_modifier filters, and any lookup logic moved to a separate file. Compare field names in the SIEM before and after cutover, because a renamed field can break detection content without any ingestion error.

OTLP and downstream paths

Fluent Bit provides native OpenTelemetry (OTLP) ingestion and delivery, and Grafana Loki and VictoriaLogs both list it among supported clients. If any downstream store is one of these, check the documented path for that store rather than assuming the mapping. Where the SIEM does not accept OTLP directly, confirm the format it expects and test that path end to end.

TLS settings and certificates

Record the TLS version, cipher configuration, client certificate requirements and certificate trust chain for each source and destination. Fluent Bit uses its own TLS keys in the output and input sections, so certificates and private keys must be moved through your secrets process, not copied into shared files. Plan for certificate renewal dates, which tend to be missed when routing moves to a new tool.

Archiving Cribl configuration

No conversion tool is supplied for Cribl exports, so route and pipeline configurations are read and rewritten by hand. Before decommission, archive the exported Cribl configuration, pipeline and route definitions, saved samples and worker group settings in version control with a retention decision recorded. This preserves the rule history auditors and incident responders may ask about after the Cribl license ends.

Migration sequence from inventory to decommission

This sequence moves Cribl Stream routes to Fluent Bit one source group at a time, keeping Cribl delivering to the SIEM until the Fluent Bit output matches it. Each step produces a record that the next step depends on, so the SIEM never loses a source without a tested fallback.

Inventory sources, destinations and functions
Export the Cribl configuration for every worker group and list each source, destination, pipeline, route and function, including its filters, field rewrites, lookups and drop rules. Record the owner of each source, its daily volume, and the SIEM index or table it feeds. The output is an inventory register with one row per route. The step is done when the platform team and the SIEM owners both sign off that no active route is missing from the register.
Rebuild and pilot on one non-critical source
Choose one worker group and a low-impact, non-critical source, then rebuild its filters, parsers and routing rules as Fluent Bit configuration. Test the configuration on a non-production host first, then run it beside the existing Cribl path. Review the pilot results with the source owner. The output is a pilot report that lists each rule, its test input, the observed output, and any behavior that could not be reproduced exactly.
Run in parallel and compare event parity
Keep Cribl delivering to the SIEM while Fluent Bit sends to a separate test index or a staging destination. Compare event counts per source and time window, then sample events and check field names, types, timestamps and values. Document each difference and decide whether it is an accepted change or a defect to fix. The output is a parity evidence file showing counts, sampled field comparisons, and signed decisions on every difference.
Confirm buffering and replay behavior
Cribl offers its own replay and buffering features, so confirm how Fluent Bit handles a SIEM outage on each route. Set storage limits and the filesystem buffer location, then test a deliberate destination outage and measure whether events are retained and delivered in order after recovery. Record any gap that cannot be closed, such as events held in memory during a restart. The output is a buffering test record that the SIEM owner accepts before cutover.
Write the staged cutover runbook
Group sources by risk and SIEM dependency, then write a cutover runbook for each group. Each runbook lists the change window approvers, the configuration files to deploy, the health checks, the event count thresholds that count as success, and the rollback steps that re-point the source to the Cribl worker group. Keep the Cribl route in place until the group is confirmed stable. The output is an approved runbook for each source group.
Cut over source groups and roll back if needed
Move one source group at a time from Cribl to Fluent Bit, starting with the lowest-risk group. After each change, compare event counts and check for dropped or duplicated events against the runbook thresholds. If a threshold fails, execute the rollback steps and record the cause before retrying. The output is a cutover log for each group showing the change time, the checks run, the result, and any rollback.
Decommission Cribl after a stable window
Once every source group has run on Fluent Bit through an agreed stable period, disable the Cribl routes, then shut down the worker groups and stop license use. Retain Cribl configuration exports and the parity and cutover records for the period your audit and retention policies require. Confirm the license terms and notice requirements with Cribl before ending the subscription. The output is a decommission record listing removed workers, archived configurations, and the date the license ended.

How to run both pipelines in parallel and handle buffering differently

Do not cut over a Cribl Stream route to Fluent Bit until you have designed its buffering and replay behavior, because Fluent Bit does not inherit the queueing that your Cribl worker groups provide today. Fluent Bit buffers at two points that you configure yourself: the input, through settings such as storage.type and storage.max_chunks_up in the service section, and each output, through its own buffering and retry options. When a destination slows or refuses data, the outcome depends on which of these limits you set, and whether the buffer lives in memory or on disk. Write down the expected backpressure behavior for every output before the parallel window starts, including what happens when the buffer fills and which events are dropped first.

During the parallel window, run the old Cribl route and the new Fluent Bit pipeline against the same source, with the Fluent Bit output pointed at a separate index or test stream in the SIEM so the two copies can be told apart. Compare event counts per source and per sourcetype over identical time ranges, and track dropped events, retry counts and buffer usage on the Fluent Bit side, since Cribl's own monitoring will not show them. Expect some difference at the edges of the window, because both pipelines have their own retry timing. Agree in advance on the tolerance you will accept and on who signs off the comparison.

Duplicates are expected during the window, so confirm that nothing downstream treats them as new events. Check SIEM correlation rules, alert thresholds and any deduplication logic for assumptions that each event arrives once, and either scope the duplicate output to a non-alerting index or disable the alerts that would fire twice. Test buffer limits in your own environment by simulating a slow or unavailable destination with realistic event rates, rather than relying on any figure published for another deployment. Confirm the retry and replay behavior of each Fluent Bit output with your SIEM vendor and your own test results before you remove the Cribl route.

What drives migration cost and duration

This table lists the factors that set the effort of moving Cribl Stream pipelines to Fluent Bit, with the reason each one matters and how to keep it under control. Read it before requesting a quote, because the same rows form the scope document a fixed-scope engagement depends on.

Driver	Why it changes effort	How to keep it down
Number of sources and destinations	Each Cribl source and destination pair needs its own input, output, tag and test. Syslog, HEC, object storage and SIEM index targets each carry different delivery semantics.	Export the Cribl configuration and group routes by source type and destination. Retire stale routes before migrating so only live flows are rebuilt.
Count and complexity of Cribl functions	Parsing, field reduction, sampling, enrichment lookups and event breaking each map to a different Fluent Bit filter or Lua script. Complex expressions that Cribl evaluates in JavaScript may need rewriting by hand.	Classify functions as simple (rename, drop, mask), moderate (regex parse, lookup) or custom. Move simple ones first and keep custom logic in a small, tested set of scripts.
Number of worker groups and regions	Each worker group becomes a separately managed Fluent Bit deployment with its own configuration, certificates and rollout. Regional routing rules add latency and failover questions.	Consolidate worker groups where the data flows allow it. Standardize one configuration template with per-region variables managed in version control.
Depth of SIEM-side rule dependencies on field names	Detection rules, dashboards and correlation searches that reference field names set by Cribl's reshaping must be matched exactly. A renamed field can silently stop an alert from firing.	Inventory every field used by SIEM content before rebuilding filters. Build a field mapping table and run old and new pipelines in parallel to compare event output.
Need for replay and buffering	Cribl's replay and persistent queue behavior does not map one-to-one to Fluent Bit. Fluent Bit uses filesystem buffering and retry settings per output, so recovery after an outage must be designed and tested.	Define the loss tolerance per source. Configure storage buffering limits and retry behavior, then test an outage of each destination before cutover.
Change control and evidence requirements	Regulated environments usually need approved change records, peer-reviewed configuration, test evidence and a rollback plan. Each cutover step adds documentation work.	Keep configuration in Git with reviewed merges. Capture before-and-after event counts and field samples as test evidence for each worker group.
In-house skills with Fluent Bit configuration	Teams familiar with Cribl's graphical pipelines need time to learn classic configuration, the Lua and parser syntax, and troubleshooting with logs and metrics. Gaps extend testing and increase vendor or partner hours.	Train two or three engineers early, pair them with the migration work and document the common patterns. Ask any implementation partner to hand over runbooks.
Parallel infrastructure during overlap	Running Cribl and Fluent Bit side by side for validation means two sets of compute, storage and network paths carry the same events for a period. This cost is temporary but real.	Overlap per worker group rather than for the whole estate. Confirm with the Cribl account team which license terms apply while both pipelines run.
Recurring costs after cutover	Fluent Bit itself is licensed under Apache-2.0 with no license fee. Recurring costs are the compute and storage that run it, the staff who maintain configuration and upgrades, and any support retainer you choose to buy.	Ask any partner to separate one-time migration work from ongoing support in the written scope. Confirm how upgrades to new Fluent Bit releases will be tested and who owns them.

What goes wrong in a Cribl to Fluent Bit cutover and how to prevent it

Most failed cutovers lose data or change meaning quietly rather than fail loudly. The six risks below share one root cause: the Cribl pipeline did work that nobody wrote down, and Fluent Bit will not repeat it unless someone rebuilds it on purpose.

Silent field renames break correlation

A parser or modify filter that emits src_ip where Cribl previously emitted source.ip can leave every event flowing while SIEM correlation rules, dashboards and enrichment lookups match nothing. Fluent Bit's record_modifier and modify filters are easy to write but do not warn when a key disappears. Before cutover, export a sample of each source from both pipelines, diff the field names and value types, and require the SIEM team to sign off on the schema for each index. Run a rule-hit comparison over at least one full business cycle.

Dropped events during restarts and overflow

Fluent Bit buffers in memory by default, so a restart, crash or sustained destination outage can discard events that were in flight. Filesystem buffering with the storage settings must be configured per output, and the buffer limit must be sized against your worst realistic outage window. Test this deliberately: stop the destination, generate known volumes, restart the agent, then count events at the SIEM against the source count. Do not accept a pilot that only tested happy-path delivery.

Duplicate events during parallel runs

Running Cribl and Fluent Bit side by side is the safest way to validate, but it doubles every event unless the two paths are separated by destination or index. Duplicates inflate event counts, distort alert thresholds and can trigger duplicate tickets in SOAR playbooks. Use a separate test index or tag for the parallel path, keep SIEM alert actions disabled on it, and set a fixed end date after which only one path writes to production.

Timestamp and multiline parser differences

Timestamp parsing and multiline joining are where pipelines most often disagree. A Cribl function that reads a timezone-less timestamp may assume the host's zone, while a Fluent Bit parser may assume UTC, shifting events across time windows and breaking time-based detections. Multiline stack traces and firewall records split differently under different rules. Build a fixture set of hard samples from each source, run both parsers, and compare the parsed _time or timestamp fields and event boundaries before any routing change.

Forgotten sources stop reporting

A source that was routed through Cribl only as a side effect, such as a legacy syslog listener, a cloud export or a seldom-used appliance, will stop reporting silently when its Cribl worker group is decommissioned. Silence is hard to notice because no error is raised. Compare the list of active sources in the SIEM for the last 30 days against the Fluent Bit configuration, and alert on any source whose event rate drops to zero after cutover. Check the Cribl source list for disabled or idle sources too.

Undocumented Cribl routing logic is lost

Over time, pipelines accumulate routing decisions that exist only in the Cribl configuration: drop rules added after an incident, sampling for a noisy host, a route that sends regulated data to a second archive. None of these appear in a design document. Export every pipeline, route and function, then have each owning team sign a source-by-source inventory that states what each rule does and why it exists. Treat any rule without an owner as a blocker until someone claims it.

How the migration differs by starting point

A single Cribl worker group feeding one SIEM is the most contained starting point. The inventory is usually short enough to hold in one document: a handful of sources, one or two destinations and a limited set of functions for filtering, field renaming and routing. Because there is one path from source to SIEM, you can compare event counts and field values end to end without building a large test harness. Scope is narrow, so most of the effort goes into rebuilding each function as a Fluent Bit filter or parser and confirming that the SIEM receives the same fields. The parallel run can be short if the SIEM team agrees on the comparison criteria before work starts.

Source list: Confirm every input, including syslog listeners, HTTP sources and any agent-based collection that bypasses the worker group.
Function review: Map each Cribl function to a Fluent Bit filter, parser or Lua script, and mark any that depend on logic Fluent Bit does not offer directly.
Single comparison point: Compare counts and key fields at the SIEM ingest point for each source before and after cutover.
Rollback path: Keep the Cribl route in place and switch the destination back with a configuration change.
Owner sign-off: Have one SIEM owner accept the parity results in writing.

Before cutover, check with the SIEM administrator that the field names and index mappings in the current Cribl output match what Fluent Bit will emit.

Questions buyers ask before moving from Cribl Stream to Fluent Bit

Can our team move from Cribl Stream to Fluent Bit without an outside partner?

Yes, a team with Linux, configuration management and SIEM experience can do it in-house, and Fluent Bit is Apache-2.0 licensed with no license fee to pay. The harder part is inventory and validation: every Cribl source, pack, function and destination has to be mapped, and each route must be proven against what the SIEM receives. Teams that lack this capacity often bring in a partner for a fixed-scope piece, such as rebuilding parsers or writing the cutover test plan, while keeping ownership of the production configuration. DeployOpen plans, implements and documents self-hosted platforms in your own environment, and the division of work is agreed in writing before work starts.

What do we need from internal staff during a Fluent Bit migration?

Internal staff need to supply knowledge that exists only in your environment. The main inputs are:

Owners of each log source who can confirm required fields, retention and timing expectations.
SIEM administrators who can state exactly which fields, index names and parsing rules the detections depend on.
Platform engineers who run the hosts, service management and certificate or secret handling that Fluent Bit will use.
A security or compliance lead who signs off on which data reduction is acceptable.

Without these owners, a migration tends to stall at the point where a dropped field is discovered in a detection that nobody remembered depended on it.

What drives the effort and cost of moving from Cribl to Fluent Bit?

The main drivers are the number of sources and destinations, how many Cribl functions and pipelines carry business logic, and how much of that logic is undocumented. Other drivers include the number of worker groups, the volume and format variety of logs, the number of SIEM detections that depend on specific fields, and how many environments (production, disaster recovery, air-gapped) must match. Costs fall into one-time items such as inventory, rebuild, testing and cutover, and recurring items such as hosting, patching, configuration reviews and on-call coverage. When requesting a quote, ask for the work broken into these components and for the assumptions behind each one. Fluent Bit itself carries no license fee, so the comparison with Cribl's license is about the people and infrastructure that replace it. Confirm the current licensing and contract terms with Cribl directly.

How long should a parallel run last, and what sets its length?

The length of a parallel run is set by how long it takes to see every log type your detections and reports depend on, including periodic jobs such as weekly or monthly reports and compliance evidence collection. Running both pipelines side by side lets you compare event counts, field values and alert volumes per source. Length grows with the number of sources that have infrequent events, with the number of detections that fire rarely, and with any reporting cycle that must be reproduced exactly. Ask the team to define the exit criteria in writing before the run starts, such as which comparisons must match and who approves the cutover. The fixed duration is a decision for your change board and not a value to copy from another migration.

Does Fluent Bit replace Cribl's replay and fleet management?

Not as a like-for-like product. Fluent Bit provides buffering, including file-based storage for backpressure, and it can route events to multiple outputs, but it does not ship a graphical replay workflow or a central fleet console like Cribl's. Replay has to be designed: you decide where raw data is retained, how it is re-ingested, and which tooling reads it. Fleet management shifts to your configuration management, such as Git-based pipeline definitions, automated deployment and health monitoring of each agent. Confirm the buffering and retry options, the Fluent Bit version your fleet will use, and the behavior of each output plugin you rely on by testing them in your environment. Fluent Bit's documentation lists native OpenTelemetry (OTLP) ingestion and delivery, which can be part of that design.

What licence or contract timing should we confirm with Cribl?

Confirm the end date, notice period and renewal terms of your current Cribl agreement with Cribl directly, and find out whether the license is cloud or self-managed, how it is measured, and what happens to your data and configurations at termination. Ask whether any usage reporting or true-up is due before you stop routing data through Cribl. Plan the cutover so that the old pipeline remains available until the parallel run has passed its exit criteria, which means the contract end date should not arrive before that point. This page does not state Cribl's pricing or terms, so treat any figure you see elsewhere as something to verify with the vendor.

How do we keep SIEM data complete during cutover?

Keep data complete by making the cutover reversible and by testing it per source before switching. Practical controls include:

Keep the Cribl route active and switch one source group at a time, with the previous path ready to restore.
Compare event counts and key fields between the old and new paths in the SIEM for each source.
Use Fluent Bit buffering with disk storage so events survive a brief SIEM or network outage, and test that behavior deliberately.
Record the routing configuration in version control so every change is traceable and reversible.

Agree on who can roll back and under what conditions before the cutover window opens.

How DeployOpen scopes and runs a Fluent Bit migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For a move off Cribl Stream, that means the Fluent Bit configuration, the Kubernetes or VM deployment, the destination connections to the SIEM and the evidence trail all run in your environment, under your change control and credentials. Most engagements are fixed-scope, so the written scope should name the Cribl worker groups in each cutover wave, the source and destination inventory, the list of functions to rebuild, and the replay and buffering behavior you require before work starts.

A quote follows from that written scope. DeployOpen does not publish a price list, so the cost depends on the number of pipelines and destinations, how many functions must be rebuilt as Fluent Bit filters, parsers and Lua scripts, whether the work includes parallel running and reconciliation, and the testing and documentation expected at the end. Ask for the deliverables and timelines to be listed separately, with acceptance criteria for each cutover wave. Ask whether the quote covers only the migration or also the handover, and whether ongoing support is priced as a separate retainer. Retainers cover upgrades, configuration changes, and continuing testing after the migration, and they recur, while the migration itself is a one-time cost.

Before you sign, confirm three things with any implementation partner, DeployOpen included: who holds the Fluent Bit configuration and runbooks at handover, which named roles approve each cutover, and how the team will prove that SIEM event counts match during parallel running. Confirm the Fluent Bit release line you will standardize on against the fluent/fluent-bit GitHub releases page at the time of contracting. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so any assurance your auditor needs must come from an independent assessor you select.

Migrate from Cribl Stream to Fluent Bit