v5.2.0

KNOWLEDGE BASE

Release Notes v5.2.0

Fluent Bit is a Fast and Lightweight Telemetry Agent for Linux, BSD, macOS and Windows. We are proud to announce the availability of Fluent Bit v5.2.0.

Fluent Bit 5.2 brings typed, programmable processing to logs, metrics, and traces with Fluent Typed Scripting (FTS). It accelerates OpenTelemetry log pipelines, improves buffering efficiency, adds journald-to-OpenTelemetry mapping, and makes delivery more responsive to destination backpressure.

What’s new ?

FTS: a native telemetry processor, scripted with Lua

Fluent Typed Scripting is a new native Fluent Bit processor for logs, metrics, and traces. Lua expresses your policy; FTS manages typed telemetry values, OpenTelemetry context, and how changes are committed or rolled back.

Unlike the existing Lua log filter, FTS processes all three signals and exposes typed values directly. Large integer IDs, nulls, and binary data retain their meaning when a policy changes another field. Resource and instrumentation context are available as named properties.

Use FTS to redact known fields, normalize telemetry, or reduce unwanted events and metric dimensions. Existing Lua filter scripts remain supported; migrating to FTS requires adapting their API.

Faster pipelines, with measurements you can inspect

In the published memory-buffered OTLP/HTTP JSON transformation benchmark, Fluent Bit 5.2 reaches 1.50 million records/s: 7.2× the throughput of 5.1 and 2.0× Collector 0.163 for the same log-attribute update. These comparisons use native content modifier processing in Fluent Bit.

The separate FTS scripting benchmarks show 18–45% less CPU than equivalent Lua log policies on 5.1.0. Compatible content modifier chains also benefit from performing multiple edits in one pass.

The 5.2 benchmark report includes CPU, memory, latency, buffering conditions, and tradeoffs. These figures describe specific workloads, not a guaranteed production rate.

System logs ready for OpenTelemetry

The new journald_otel processor maps journal records into OpenTelemetry logs, including severity, host and process information. This makes system logs easier to query alongside application telemetry without building a custom field-mapping script.

Destination-aware output throttling

When a backend asks Fluent Bit to slow down, the new output throttling mechanism pauses delivery to that destination and resumes after a cooldown. HTTP, OpenTelemetry, Elasticsearch, and OpenSearch outputs recognize supported throttling responses and server retry-delay hints, including HTTP Retry-After and supported gRPC retry information.

Waiting for an active cooldown does not consume retry attempts. Elasticsearch and OpenSearch bulk retries retain unresolved records without replaying items already acknowledged as successful.

Cooldowns are configurable per output, giving operators control over how Fluent Bit responds to busy destinations. This helps pipelines avoid repeated delivery attempts while a backend is asking for time to recover.

Core

• Processing: accelerate eligible OTLP log pipelines and compatible content modifier chains, while preserving grouped telemetry and exact record accounting.
• Buffering: improve filesystem allocation for low-volume streams and process large log buffers in bounded windows. The sparse-stream benchmark reduces allocated disk by 92.2%; busy-stream results and tradeoffs are included in the benchmark report.
• Delivery: coordinate output cooldowns, queued work, and shutdown more reliably, and keep outputs making progress during heavy threaded ingestion.
• Configuration: prefer paths relative to the configuration file for includes, parsers, scripts, and auxiliary files; add YAML configuration generation from command-line options.
• Networking: apply configured connection timeouts to TCP DNS resolution and identify destination endpoints in timeout messages, making connection failures easier to diagnose.
• Reliability: improve HTTP resource controls, regular-expression handling, and TLS configuration consistency.
• Validation: expand integration coverage for typed processing, backpressure, configuration portability, protocol handling, and cloud delivery.

Libraries

• Update CFL to v1.1.0, CMetrics to v2.3.1, and CTraces to v0.8.0.
• Update ChunkIO to v1.5.5 and yyjson to v0.13.0.
• Refresh LuaJIT, Onigmo, and SQLite for compatibility, portability, and more predictable resource use.

Plugins

Inputs

• OpenTelemetry: accelerate JSON and Protobuf log processing across eligible native processor chains and improve connection distribution across HTTP workers.
• Node Exporter Metrics: add an optional immediate scrape at startup and improve textfile metric collection.
• Prometheus Textfile: emit each scrape as one metrics payload, keeping metrics collected from multiple files together.
• Tail, Forward, Syslog, and Unix Socket: improve recovery, shutdown, grouped-log handling, and local socket lifecycle behavior.

Processors & Filters

• FTS: introduce typed policies for all three telemetry signals, OpenTelemetry-aware helpers, JSON decoding, and configurable error handling.
• Journald OpenTelemetry: add native journal-to-OpenTelemetry field mapping.
• Content Modifier and SQL: improve native processing efficiency and preserve telemetry grouping through transformations.
• WebAssembly: add the v2 value-length interface, with C, Rust, and TinyGo filter examples.
• Rewrite Tag: add experimental, opt-in batching for input processor callbacks. Eligible records sharing a destination tag can be emitted together; batching is disabled by default.

Outputs

• HTTP, OpenTelemetry, Elasticsearch, and OpenSearch: honor supported throttling responses and retry hints.
• VIVO: expand live telemetry inspection with versioned OTLP JSON streams, bounded retention, and gzip responses. Retained inspection data is temporary.
• Kafka and File: improve serialization validation and output correctness for Avro, Protobuf, CSV, and LTSV.
• Prometheus Exporter: group repeated metric families consistently.
• NATS: optionally encode tags that are not valid NATS publish subjects. Subscribers and publish permissions must use the encoded subject when this option is enabled.

Experimental browser SDK

An embeddable JavaScript SDK runs the Fluent Bit engine in a browser through WebAssembly. It provides configuration, JSON log ingestion, and lifecycle controls for browser applications. This is a separate, experimental build profile with its own deployment requirements and support limits.

Platform compatibility

• Windows: resolve wildcard configuration includes relative to the configuration file, support Windows drive paths in file-backed environment variables, and correct Blob input wildcard matching and directory detection.
• macOS: improve graceful shutdown when Fluent Bit runs as an embedded library, so callers wait for engine cleanup to finish.
• Custom builds: support disabling SQLite with the default plugin selection and improve libyaml discovery without pkg-config, including Homebrew and MacPorts installations on macOS. MSVC builds continue to require an explicit libyaml location.

Upgrading

• Review relative file paths: configuration-directory paths now take precedence for supported configuration assets.
• VIVO listens on 127.0.0.1 by default. Set an explicit listener address if remote access is required, and protect remote access appropriately.
• Existing Lua filter policies continue to work. Choose FTS for typed, multi-signal processing and adapt scripts to its callback and value model when migrating.

Join us

Share your experience in GitHub Discussions or join the Fluent Bit community on CNCF Slack, channel #fluent-bit.