Fluent Bit 5.2 / performance benchmarks

Measured performance.
See the complete picture.

Explore Fluent Bit v5.2 throughput, CPU, memory, and buffering measurements under documented workload conditions.

Workload-specific results under the conditions described with each comparison. Compare throughput, CPU, and memory together.

7.2×JSON transformation throughput versus Fluent Bit 5.1, with memory buffering. 2.0×JSON transformation throughput versus Collector 0.163 in the same benchmark. 18–45%Less CPU for FTS than equivalent Lua log policies on Fluent Bit 5.1.0.

Highlights describe specific measured workloads. Results depend on the pipeline, buffering, and hardware. CPU and memory tradeoffs are included below.

OpenTelemetry log ingestion and transformation

Fluent Bit 5.2 reaches 1.50 million JSON records/s and 1.43 million Protobuf records/s when adding one log attribute with memory buffering. It has the highest throughput in all eight measured ingestion and transformation cases.

The transformation is the same across systems: set bench.added = "yes" on every log. Both Fluent Bit versions use content_modifier; Collector 0.163 uses its transform processor / OTTL. This comparison does not use FTS. All systems complete 30 million records per run with null outputs.

Memory buffering

million records / s

Higher is better. Median of five runs; 30M completed records/run, including sending and final drain. Both buffering panels use the same scale. Bars start at zero.

Fluent Bit 5.2Fluent Bit 5.1OpenTelemetry Collector 0.163

JSON · add an attribute

JSON · add an attribute — Memory buffering 5.2 Fluent Bit 5.2: 1.500 million records / s 1.500 5.1 Fluent Bit 5.1: 0.207 million records / s 0.207 OTel OpenTelemetry Collector 0.163: 0.759 million records / s 0.759

Protobuf · add an attribute

Protobuf · add an attribute — Memory buffering 5.2 Fluent Bit 5.2: 1.430 million records / s 1.430 5.1 Fluent Bit 5.1: 0.203 million records / s 0.203 OTel OpenTelemetry Collector 0.163: 1.120 million records / s 1.120

JSON · ingest only

JSON · ingest only — Memory buffering 5.2 Fluent Bit 5.2: 1.670 million records / s 1.670 5.1 Fluent Bit 5.1: 0.732 million records / s 0.732 OTel OpenTelemetry Collector 0.163: 0.786 million records / s 0.786

Protobuf · ingest only

Protobuf · ingest only — Memory buffering 5.2 Fluent Bit 5.2: 1.670 million records / s 1.670 5.1 Fluent Bit 5.1: 1.580 million records / s 1.580 OTel OpenTelemetry Collector 0.163: 1.160 million records / s 1.160

Filesystem buffering

million records / s

Higher is better. Median of five runs; 30M completed records/run, including sending and final drain. Both buffering panels use the same scale. Bars start at zero.

Fluent Bit 5.2Fluent Bit 5.1OpenTelemetry Collector 0.163

JSON · add an attribute

JSON · add an attribute — Filesystem buffering 5.2 Fluent Bit 5.2: 0.968 million records / s 0.968 5.1 Fluent Bit 5.1: 0.203 million records / s 0.203 OTel OpenTelemetry Collector 0.163: 0.190 million records / s 0.190

Protobuf · add an attribute

Protobuf · add an attribute — Filesystem buffering 5.2 Fluent Bit 5.2: 0.968 million records / s 0.968 5.1 Fluent Bit 5.1: 0.201 million records / s 0.201 OTel OpenTelemetry Collector 0.163: 0.206 million records / s 0.206

JSON · ingest only

JSON · ingest only — Filesystem buffering 5.2 Fluent Bit 5.2: 0.909 million records / s 0.909 5.1 Fluent Bit 5.1: 0.638 million records / s 0.638 OTel OpenTelemetry Collector 0.163: 0.202 million records / s 0.202

Protobuf · ingest only

Protobuf · ingest only — Filesystem buffering 5.2 Fluent Bit 5.2: 0.937 million records / s 0.937 5.1 Fluent Bit 5.1: 0.909 million records / s 0.909 OTel OpenTelemetry Collector 0.163: 0.217 million records / s 0.217

Collector has the lowest peak RSS in these tests. Saturation RSS includes queued records and is not an equal-rate memory-efficiency measurement. Compare memory alongside throughput and CPU.

All OTLP results: throughput, CPU, memory, and latency
OTLP results: medians of five runs. Observed min–max values are rounded ranges, not confidence intervals.
WorkloadSystemM records/sObserved min–max M/sCPU s/MSteady / peak MiBHTTP p50 / p99 µs
Memory · JSON, ingestFluent Bit 5.21.6701.43–1.672.20365 / 441819 / 3007
Memory · JSON, ingestFluent Bit 5.10.7320.63–0.943.62111 / 2771519 / 4581
Memory · JSON, ingestOpenTelemetry Collector 0.1630.7860.78–0.794.8382 / 1121428 / 8288
Memory · Protobuf, ingestFluent Bit 5.21.6701.58–1.771.881197 / 1548623 / 3752
Memory · Protobuf, ingestFluent Bit 5.11.5801.36–1.582.06227 / 513862 / 3067
Memory · Protobuf, ingestOpenTelemetry Collector 0.1631.1601.15–1.173.2581 / 108904 / 5778
Memory · JSON, modifiedFluent Bit 5.21.5001.31–1.582.45240 / 418872 / 3413
Memory · JSON, modifiedFluent Bit 5.10.2070.20–0.218.07627 / 7461575 / 4953
Memory · JSON, modifiedOpenTelemetry Collector 0.1630.7590.75–0.765.0384 / 1111481 / 8574
Memory · Protobuf, modifiedFluent Bit 5.21.4301.31–1.432.69230 / 404980 / 3159
Memory · Protobuf, modifiedFluent Bit 5.10.2030.20–0.206.93696 / 863744 / 4115
Memory · Protobuf, modifiedOpenTelemetry Collector 0.1631.1201.11–1.123.3984 / 109942 / 6087
Filesystem · JSON, ingestFluent Bit 5.20.9090.88–0.912.80778 / 974768 / 3934
Filesystem · JSON, ingestFluent Bit 5.10.6380.57–0.754.42488 / 8381478 / 4754
Filesystem · JSON, ingestOpenTelemetry Collector 0.1630.2020.20–0.2016.36529 / 5504570 / 34198
Filesystem · Protobuf, ingestFluent Bit 5.20.9370.91–0.942.511098 / 1380627 / 3753
Filesystem · Protobuf, ingestFluent Bit 5.10.9090.88–0.942.80768 / 987757 / 4112
Filesystem · Protobuf, ingestOpenTelemetry Collector 0.1630.2170.21–0.2213.91528 / 5474136 / 30529
Filesystem · JSON, modifiedFluent Bit 5.20.9680.97–0.973.031169 / 1620822 / 4984
Filesystem · JSON, modifiedFluent Bit 5.10.2030.20–0.218.79601 / 7391293 / 5003
Filesystem · JSON, modifiedOpenTelemetry Collector 0.1630.1900.19–0.1917.43556 / 5764846 / 35501
Filesystem · Protobuf, modifiedFluent Bit 5.20.9680.88–0.973.34831 / 1090958 / 5078
Filesystem · Protobuf, modifiedFluent Bit 5.10.2010.19–0.207.66696 / 889745 / 4123
Filesystem · Protobuf, modifiedOpenTelemetry Collector 0.1630.2060.20–0.2114.82554 / 5724405 / 31830
How the OTLP comparison was measured

Each case uses 100 logs/request, 16 persistent HTTP clients, 320,000 warmup records, and 30M measured records. Product order rotates across five fresh runs. The Linux host uses an AMD Ryzen 9 7940HS, with four server CPUs and separate generator cores.

Fluent Bit uses four HTTP workers, a 0.5s flush interval, and null output. Collector Contrib 0.163 uses an instrumented counting null exporter, one sending-queue consumer, and 8,192-record batching. Filesystem tests use Fluent Bit filesystem buffering and Collector file_storage; their persistence semantics are not equivalent.

Throughput includes sending and final drain. Fluent Bit completion counters update about once per second. Clients retry refusals, and every run completes all 30M records. Latency is the HTTP batch round trip, not per-record delivery latency. Results depend on the tested workload, buffering configuration, and hardware.

Lower CPU for programmable log transformations

In nine equivalent-policy tests, FTS uses 18–45% less CPU than Lua on Fluent Bit 5.1.0. The comparison includes Lua on 5.1.0, Lua on 5.2, and FTS on 5.2.

These are log-policy measurements. They do not include a Collector or standalone content modifier baseline, and do not establish performance for metrics or traces.

Equivalent log policies

CPU seconds / run

Lower is better. Published median user + system CPU and peak RSS. Tail → null; 1M flat records or 300k Kubernetes records per run. Compare systems within each policy; record budgets differ between policies. The repeat count is not stated. Bars start at zero.

Fluent Bit 5.2 · FTSFluent Bit 5.2 · LuaFluent Bit 5.1.0 · Lua

No-op policy

No-op policy — Equivalent log policies 5.2 FTS Fluent Bit 5.2 · FTS: 2.20 CPU seconds / run 2.20 5.2 Lua Fluent Bit 5.2 · Lua: 2.81 CPU seconds / run 2.81 5.1 Lua Fluent Bit 5.1.0 · Lua: 3.13 CPU seconds / run 3.13

Drop all

Drop all — Equivalent log policies 5.2 FTS Fluent Bit 5.2 · FTS: 1.72 CPU seconds / run 1.72 5.2 Lua Fluent Bit 5.2 · Lua: 2.16 CPU seconds / run 2.16 5.1 Lua Fluent Bit 5.1.0 · Lua: 2.29 CPU seconds / run 2.29

Edit (remove + set)

Edit (remove + set) — Equivalent log policies 5.2 FTS Fluent Bit 5.2 · FTS: 2.33 CPU seconds / run 2.33 5.2 Lua Fluent Bit 5.2 · Lua: 3.23 CPU seconds / run 3.23 5.1 Lua Fluent Bit 5.1.0 · Lua: 3.53 CPU seconds / run 3.53

Read 5 fields + edit

Read 5 fields + edit — Equivalent log policies 5.2 FTS Fluent Bit 5.2 · FTS: 2.90 CPU seconds / run 2.90 5.2 Lua Fluent Bit 5.2 · Lua: 3.27 CPU seconds / run 3.27 5.1 Lua Fluent Bit 5.1.0 · Lua: 3.55 CPU seconds / run 3.55

Kubernetes record edit

Kubernetes record edit — Equivalent log policies 5.2 FTS Fluent Bit 5.2 · FTS: 2.05 CPU seconds / run 2.05 5.2 Lua Fluent Bit 5.2 · Lua: 3.12 CPU seconds / run 3.12 5.1 Lua Fluent Bit 5.1.0 · Lua: 3.20 CPU seconds / run 3.20

Kubernetes nested field lift

Kubernetes nested field lift — Equivalent log policies 5.2 FTS Fluent Bit 5.2 · FTS: 2.20 CPU seconds / run 2.20 5.2 Lua Fluent Bit 5.2 · Lua: 3.12 CPU seconds / run 3.12 5.1 Lua Fluent Bit 5.1.0 · Lua: 3.20 CPU seconds / run 3.20

Policy + content_modifier

Policy + content_modifier — Equivalent log policies 5.2 FTS Fluent Bit 5.2 · FTS: 2.98 CPU seconds / run 2.98 5.2 Lua Fluent Bit 5.2 · Lua: 3.88 CPU seconds / run 3.88 5.1 Lua Fluent Bit 5.1.0 · Lua: 5.24 CPU seconds / run 5.24

content_modifier + policy

content_modifier + policy — Equivalent log policies 5.2 FTS Fluent Bit 5.2 · FTS: 2.98 CPU seconds / run 2.98 5.2 Lua Fluent Bit 5.2 · Lua: 4.43 CPU seconds / run 4.43 5.1 Lua Fluent Bit 5.1.0 · Lua: 5.37 CPU seconds / run 5.37

Output processor edit

Output processor edit — Equivalent log policies 5.2 FTS Fluent Bit 5.2 · FTS: 3.04 CPU seconds / run 3.04 5.2 Lua Fluent Bit 5.2 · Lua: 3.81 CPU seconds / run 3.81 5.1 Lua Fluent Bit 5.1.0 · Lua: 3.85 CPU seconds / run 3.85
FTS versus equivalent Lua log policies: CPU seconds/run and peak RSS as published.
PolicyRecords/run5.2 FTS CPU s5.2 Lua CPU s5.1.0 Lua CPU sLess CPU vs 5.1.0 Lua5.2 FTS / 5.1.0 Lua RSS MB
No-op policy1,000,0002.202.813.1329.7%24.7 / 22.4
Drop all1,000,0001.722.162.2924.9%17.9 / 17.5
Edit (remove + set)1,000,0002.333.233.5334.0%23.4 / 21.5
Read 5 fields + edit1,000,0002.903.273.5518.3%23.1 / 21.6
Kubernetes record edit300,0002.053.123.2035.9%28.7 / 25.5
Kubernetes nested field lift300,0002.203.123.2031.2%28.9 / 25.6
Policy + content_modifier1,000,0002.983.885.2443.1%23.4 / 21.5
content_modifier + policy1,000,0002.984.435.3744.5%23.4 / 21.4
Output processor edit1,000,0003.043.813.8521.0%60.2 / 75.7

Memory and flush-interval tradeoffs

At the tested 0.2s flush interval, FTS generally uses slightly more peak RSS for input policies. Output processing uses less: 60.2 MB versus 75.7 MB for Lua on 5.1.0.

At a 0.02s flush interval, CPU remains within 2% of the reported results and input-policy peak RSS stays within 1.5 MB of Lua. Output-side memory is 52 MB versus 67 MB for Lua in that configuration. The source reports medians but does not state the repeat count.

Explore Fluent Typed Scripting and see how to write typed telemetry policies in Lua.

Make multiple content modifier edits in one pass

Compatible content modifier chains combine their work into one decode/edit/encode pass. Six upserts reduce CPU by 15.7% on 12-field records and 19.4% on 128-field records in the final confirmation. Wide-record throughput improves 20.0%; narrow-record throughput remains approximately flat.

CPU cost of a content modifier chain

CPU s / million records

Lower is better. Five paired runs/case; 800k records for 12 fields, 200k for 128 fields. Both builds are 5.2 revisions. Bars start at zero.

Fluent Bit 5.2 · chain fusionBefore chain fusion

12 fields · no edits

12 fields · no edits — CPU cost of a content modifier chain After Fluent Bit 5.2 · chain fusion: 0.8250 CPU s / million records 0.8250 Before Before chain fusion: 0.8375 CPU s / million records 0.8375

12 fields · 6 upserts

12 fields · 6 upserts — CPU cost of a content modifier chain After Fluent Bit 5.2 · chain fusion: 3.1500 CPU s / million records 3.1500 Before Before chain fusion: 3.7375 CPU s / million records 3.7375

128 fields · no edits

128 fields · no edits — CPU cost of a content modifier chain After Fluent Bit 5.2 · chain fusion: 6.8000 CPU s / million records 6.8000 Before Before chain fusion: 7.0000 CPU s / million records 7.0000

128 fields · 6 upserts

128 fields · 6 upserts — CPU cost of a content modifier chain After Fluent Bit 5.2 · chain fusion: 21.2000 CPU s / million records 21.2000 Before Before chain fusion: 26.3000 CPU s / million records 26.3000
Final five-pair confirmation of chain fusion; both revisions are 5.2 builds.
Fields / upsertsBefore CPU s/MAfter CPU s/MCPU reductionThroughput change
12 / 00.83750.82501.5%+0.1%
12 / 63.73753.150015.7%-0.0%
128 / 07.00006.80002.9%-0.1%
128 / 626.300021.200019.4%+20.0%

The baseline is an earlier 5.2 revision, not 5.1. These percentages must not be added to the OTLP gains. Compatible plain-body insert, upsert, delete, and rename chains benefit; grouped OTLP records, conditions, and unsupported chains take other paths.

Use less disk for many low-volume streams

With 1,000 sparse tags, allocated filesystem space falls from 250 MiB to 19.53 MiB, a 92.2% reduction. The benefit is strongest for sparse streams; busy-stream throughput stays broadly similar.

Filesystem allocation and ingestion

MiB

Lower is better. Three measured repeats after warmup. Both builds use ChunkIO 1.5.5. This isolates allocation integration, not a 5.1-versus-5.2 comparison. Bars start at zero.

Fluent Bit 5.2 · optimized allocationBefore allocation integration

1,000 sparse tags, FS

1,000 sparse tags, FS — Filesystem allocation and ingestion After Fluent Bit 5.2 · optimized allocation: 19.53 MiB 19.53 Before Before allocation integration: 250.00 MiB 250.00

Busy FS, checksum off

Busy FS, checksum off — Filesystem allocation and ingestion After Fluent Bit 5.2 · optimized allocation: 140.55 MiB 140.55 Before Before allocation integration: 144.15 MiB 144.15

Busy FS, checksum on

Busy FS, checksum on — Filesystem allocation and ingestion After Fluent Bit 5.2 · optimized allocation: 140.55 MiB 140.55 Before Before allocation integration: 146.21 MiB 146.21

Memory control

Memory control — Filesystem allocation and ingestion After Fluent Bit 5.2 · optimized allocation: 0.00 MiB 0.00 Before Before allocation integration: 0.00 MiB 0.00
Filesystem allocation: before → after integration, with ChunkIO 1.5.5 on both builds.
WorkloadCPU secondsIngestion MiB/sAllocated MiB
1,000 sparse tags, FS0.356 → 0.32192.30 → 108.08250.00 → 19.53
Busy FS, checksum off0.996 → 1.002126.32 → 126.29144.15 → 140.55
Busy FS, checksum on1.011 → 1.032123.94 → 121.86146.21 → 140.55
Memory control0.925 → 0.938131.10 → 129.910.00 → 0.00

Buffering workload and tradeoffs

Real tail-to-null pipelines use 256-byte source lines: 64,000 records across 1,000 sparse tags, or 1M records for busy-stream and memory controls. Disk figures are sampled allocated blocks, not payload size. CPU includes startup and shutdown; ingestion rate excludes startup and final drain.

Tests use ext4/NVMe, 4 KiB pages, one server CPU, and a shared host. Checksum-enabled busy streams use 2.1% more CPU and have 1.7% lower measured ingestion rate. Busy-stream remaps increase from 1,105 to 1,523. Both builds use ChunkIO 1.5.5, isolating allocation integration.

Smaller in-memory record graphs

Compact CFL arenas reduce reserved memory per decoded record by 27–31%, with 23–26% less CPU time in the measured record-building workloads. These are record-graph measurements, not total process RSS.

Record-building CPU and memory measurements

Decoded-record construction

ns / record

Lower is better. Release x86_64; best of five runs. Reserved arena bytes are not process RSS. These gains are not additive with pipeline results. Bars start at zero.

Compact record arenaPrevious record arena

Referenced values

Referenced values — Decoded-record construction Compact Compact record arena: 245.8 ns / record 245.8 Previous Previous record arena: 321.0 ns / record 321.0

Owned values

Owned values — Decoded-record construction Compact Compact record arena: 294.1 ns / record 294.1 Previous Previous record arena: 396.3 ns / record 396.3

Owned values with edits

Owned values with edits — Decoded-record construction Compact Compact record arena: 361.1 ns / record 361.1 Previous Previous record arena: 484.9 ns / record 484.9
Record construction: before → after compact arenas. Reserved bytes are not process RSS.
Record valuesCPU ns/recordReserved bytes/record
Referenced values321.0 → 245.82118 → 1541
Owned values396.3 → 294.12760 → 1894
Owned values with edits484.9 → 361.12664 → 1829

These microbenchmark gains are not additive with pipeline results. Memory improvements vary by record shape.