Estimate the log throughput Fluent Bit can process given CPU and memory allocation.
Fluent Bit's maximum sustained throughput scales with the number of output worker threads: max_throughput = workers × per_worker_MBps. Comparing this against your actual required ingestion rate identifies whether the pipeline is bottlenecked — if required throughput exceeds capacity, logs will queue and eventually be dropped or cause backpressure upstream, and more workers (or a faster per-worker configuration) are needed.
max_throughput_MBps = workers × per_worker_MBps
Benchmark a single Fluent Bit output worker against your actual destination (e.g. OpenSearch, Kafka, S3) under sustained load — network latency, destination-side indexing speed, and payload size all affect this figure, so generic defaults are only a starting estimate.
Only up to a point — beyond a certain worker count, CPU contention, network saturation, or backend-side throttling (e.g. Elasticsearch bulk queue limits) will cap further gains, so linear scaling assumptions should be validated with real load tests.
Add more output workers, batch/compress payloads more aggressively, scale out to multiple Fluent Bit instances, or address destination-side throughput limits (e.g. more Elasticsearch ingest nodes) — whichever is cheaper for your bottleneck.
Fluent Bit is written in C with a much smaller memory/CPU footprint than Ruby-based Fluentd, so its per-worker throughput is typically several times higher — but the same workers × per-worker-throughput model applies to both.