Fluent Bit is an open source telemetry agent specifically designed to efficiently handle the challenges of collecting and processing telemetry data across a wide range of environments, from constrained systems to complex cloud infrastructures. Managing telemetry data from various sources and formats can be a constant challenge, particularly when performance is a critical factor.

Rather than serving as a drop-in replacement, Fluent Bit enhances the observability strategy for your infrastructure by adapting and optimizing your existing logging layer, and adding metrics and traces processing. Fluent Bit supports a vendor-neutral approach, seamlessly integrating with other ecosystems such as Prometheus and OpenTelemetry. Trusted by major cloud providers, banks, and companies in need of a ready-to-use telemetry agent solution, Fluent Bit effectively manages diverse data sources and formats while maintaining optimal performance and keeping resource consumption low.

Fluent Bit can be deployed as an edge agent for localized telemetry data handling or utilized as a central aggregator/collector for managing telemetry data across multiple sources and environments.

is a fast and lightweight telemetry agent for logs, metrics, and traces for Linux, macOS, Windows, and BSD family operating systems. Fluent Bit has been made with a strong focus on performance to allow the collection and processing of telemetry data from different sources without complexity.

Features

• High performance: High throughput with low resources consumption

• Data parsing

  • Convert your unstructured messages using Fluent Bit parsers: , , and

• Metrics support: Prometheus and OpenTelemetry compatible

• Reliability and data integrity

  • handling

  • in memory and file system

• Networking

  • Security: Built-in TLS/SSL support

  • Asynchronous I/O

• Pluggable architecture and : Inputs, Filters and Outputs:

  • Connect nearly any source to nearly any destination using preexisting plugins

  • Extensibility:

    • Write input, filter, or output plugins in the C language

    • WASM: or

    • Write or

• : Expose internal metrics over HTTP in JSON and format

• : Perform data selection and transformation using simple SQL queries

  • Create new streams of data using query results

  • Aggregation windows

  • Data analysis and prediction: Time series forecasting

• Portable: Runs on Linux, macOS, Windows and BSD systems

Release notes

For more details about changes in each release, refer to the .

Fluent Bit, Fluentd, and CNCF

is a graduated sub-project under the umbrella of . Fluent Bit is licensed under the terms of the .

Fluent Bit was originally created by and is now sponsored by . As a CNCF-hosted project, it's a fully vendor-neutral and community-driven project.

provides input plugins to gather information from different sources. Some plugins collect data from log files, while others can gather metrics information from the operating system. There are many plugins to suit different needs.

When an input plugin loads, an internal instance is created. Each instance has its own independent configuration. Configuration keys are often called properties.

Every input plugin has its own documentation section that specifies how to use it and what properties are available.

For more details, see .

You can download the most recent stable or development source code.

Stable

For production systems, it's strongly suggested that you get the latest stable release of the source code in either zip file or tarball file format from GitHub using the following link pattern:

https://github.com/fluent/fluent-bit/archive/refs/tags/v<release version>.tar.gz
https://github.com/fluent/fluent-bit/archive/refs/tags/v<release version>.zip

For example, for version 1.8.12 the link is: https://github.com/fluent/fluent-bit/archive/refs/tags/v1.8.12.tar.gz

Development

If you want to contribute to Fluent Bit, you should use the most recent code. You can get the development version from the Git repository:

git clone https://github.com/fluent/fluent-bit

The master branch is where the development of Fluent Bit happens. Development version users should expect issues when compiling or at run time.

Fluent Bit users are encouraged to help test every development version to ensure a stable release.

The buffer phase in the pipeline aims to provide a unified and persistent mechanism to store your data, using the primary in-memory model or the file system-based mode.

The buffer phase contains the data in an immutable state, meaning that no other filter can be applied.

Buffered data uses the Fluent Bit internal binary representation, which isn't raw text.

Fluent Bit offers a buffering mechanism in the file system that acts as a backup system to avoid data loss in case of system failures.

In 2014, the team at was forecasting the need for a lightweight log processor for constraint environments like embedded Linux and gateways. The project aimed to be part of the Fluentd ecosystem. At that moment, Eduardo Silva created , a new open source solution, written from scratch and available under the terms of the.

After the project matured, it gained traction for normal Linux systems. With the new containerized world, the Cloud Native community asked to extend the project scope to support more sources, filters, and destinations. Not long after, Fluent Bit became one of the preferred solutions to solve the logging challenges in Cloud environments.

In production environments you need full control of the data you're collecting. Filtering lets you alter the collected data before delivering it to a destination.

Filtering is implemented through plugins. Each available filter can be used to match, exclude, or enrich your logs with specific metadata.

Fluent Bit support many filters. A common use case for filtering is Kubernetes deployments. Every pod log needs the proper metadata associated with it.

Like input plugins, filters run in an instance context, which has its own independent configuration. Configuration keys are often called properties.

For more details about the Filters available and their usage, see.

The most secure option is to create the repositories according to the instructions for your specific OS.

An installation script is provided for use with most Linux targets. This will by default install the most recent version released.

This is a helper and should always be validated prior to use.

GPG key updates

For the 1.9.0 and 1.8.15 releases and later, the GPG key. Ensure the new key is added.

The GPG Key fingerprint of the new key is:

The previous key is and might be required to install previous versions.

The GPG Key fingerprint of the old key is:

Refer to the to see which platforms are supported in each release.

Migration to Fluent Bit

For version 1.9 and later, td-agent-bit is a deprecated package and is removed after 1.9.9. The correct package name to use now is fluent-bit.

You might need to estimate how much memory Fluent Bit could be using in scenarios like containerized environments where memory limits are essential.

To make an estimate, in-use input plugins must set the Mem_Buf_Limitoption. Learn more about it in .

Estimating

Input plugins append data independently. To make an estimation, impose a limit with the Mem_Buf_Limit option. If the limit was set to 10MB, you can estimate that in the worst case, the output plugin likely could use 20MB.

Fluent Bit has an internal binary representation for the data being processed. When this data reaches an output plugin, it can create its own representation in a new memory buffer for processing. The best examples are the and output plugins, which need to convert the binary representation to their respective custom JSON formats before sending data to the backend servers.

When imposing a limit of 10MB for the input plugins, and a worst case scenario of the output plugin consuming 20MB, you need to allocate a minimum (30MB x 1.2) =36MB.

Glibc and memory fragmentation

In intensive environments where memory allocations happen in the orders of magnitude, the default memory allocator provided by Glibc could lead to high fragmentation, reporting a high memory usage by the service.

It's strongly suggested that in any production environment, Fluent Bit should be built with enabled (-DFLB_JEMALLOC=On). The jemalloc implementation of malloc is an alternative memory allocator that can reduce fragmentation, resulting in better performance.

Use the following command to determine if Fluent Bit has been built with jemalloc:

The output should look like:

If the FLB_HAVE_JEMALLOC option is listed in Build Flags, jemalloc is enabled.

Fluent Bit might optionally use a configuration file to define how the service will behave.

The schema is defined by three concepts:

• Sections

• Entries: key/value

• Indented Configuration Mode

An example of a configuration file is as follows:

Sections

A section is defined by a name or title inside brackets. Using the previous example, a Service section has been set using [SERVICE] definition. The following rules apply:

• All section content must be indented (four spaces ideally).

• Multiple sections can exist on the same file.

• A section must have comments and entries.

• Any commented line under a section must be indented too.

• End-of-line comments aren't supported, only full-line comments.

Entries: key/value

A section can contain entries. An entry is defined by a line of text that contains a Key and a Value. Using the previous example, the [SERVICE] section contains two entries: one is the key Daemon with value off and the other is the key Log_Level with the value debug. The following rules apply:

• An entry is defined by a key and a value.

• A key must be indented.

• A key must contain a value which ends in the breakline.

• Multiple keys with the same name can exist.

Commented lines are set prefixing the # character. Commented lines aren't processed but they must be indented.

Indented configuration mode

Fluent Bit configuration files are based in a strict indented mode. Each configuration file must follow the same pattern of alignment from left to right when writing text. By default, an indentation level of four spaces from left to right is suggested. Example:

This example shows two sections with multiple entries and comments. Empty lines are allowed.

has very low CPU and memory consumption. It's compatible with most x86-, x86_64-, arm32v7-, and arm64v8-based platforms.

The build process requires the following components:

• Compiler: GCC or clang

• CMake

• Flex and Bison: Required for or

• Libyaml development headers and libraries

Core has no other dependencies. Some features depend on third-party components. For example, output plugins with special backend libraries like Kafka include those libraries in the main source code repository.

Fluent Bit is supported on Linux on IBM Z(s390x), but the WASM and LUA filter plugins aren't.

The includes section lets you specify additional YAML configuration files to be merged into the current configuration. These files are identified as a list of filenames and can include relative or absolute paths. If no absolute path is provided, the file is assumed to be located in a directory relative to the file that references it.

Use this section to organize complex configurations into smaller, manageable files and include them as needed.

Usage

The following example demonstrates how to include additional YAML files using relative path references. This is the file system path structure:

The content of fluent-bit.yaml:

Ensure that the included files are formatted correctly and contain valid YAML configurations for seamless integration.

If a path isn't specified as absolute, it will be treated as relative to the file that includes it.

Install on Amazon Linux

Fluent Bit is distributed as the fluent-bit package and is available for the latest Amazon Linux 2 and Amazon Linux 2023. The following architectures are supported

• x86_64

• aarch64 / arm64v8

Amazon Linux 2022 is no longer supported.

Single line install

Fluent Bit provides an installation script to use for most Linux targets. This will always install the most recently released version.

curl https://raw.githubusercontent.com/fluent/fluent-bit/master/install.sh | sh

This is a convenience helper and should always be validated prior to use. The recommended secure deployment approach is to use the following instructions:

Configure Yum

The fluent-bit is provided through a Yum repository. To add the repository reference to your system, add a new file called fluent-bit.repo in/etc/yum.repos.d/ with the following content:

Amazon Linux 2

[fluent-bit]
name = Fluent Bit
baseurl = https://packages.fluentbit.io/amazonlinux/2/
gpgcheck=1
gpgkey=https://packages.fluentbit.io/fluentbit.key
enabled=1

Amazon Linux 2023

[fluent-bit]
name = Fluent Bit
baseurl = https://packages.fluentbit.io/amazonlinux/2023/
gpgcheck=1
gpgkey=https://packages.fluentbit.io/fluentbit.key
enabled=1

You should always enable gpgcheck for security reasons. All Fluent Bit packages are signed.

Updated key from March 2022

For the 1.9.0 and 1.8.15 and later releases, theGPG key has been updated. Ensure this new one is added.

The GPG Key fingerprint of the new key is:

C3C0 A285 34B9 293E AF51  FABD 9F9D DC08 3888 C1CD
Fluentbit releases (Releases signing key) <[email protected]>

The previous key is still available and might be required to install previous versions.

The GPG Key fingerprint of the old key is:

F209 D876 2A60 CD49 E680 633B 4FF8 368B 6EA0 722A

Refer to the supported platform documentation to see which platforms are supported in each release.

Install

1. After your repository is configured, run the following command to install it:

   Copy

   sudo yum install fluent-bit

2. Instruct systemd to enable the service:

sudo systemctl start fluent-bit

If you do a status check, you should see a similar output like this:

$ systemctl status fluent-bit
● fluent-bit.service - Fluent Bit
   Loaded: loaded (/usr/lib/systemd/system/fluent-bit.service; disabled; vendor preset: disabled)
   Active: active (running) since Thu 2016-07-07 02:08:01 BST; 9s ago
 Main PID: 3820 (fluent-bit)
   CGroup: /system.slice/fluent-bit.service
           └─3820 /opt/fluent-bit/bin/fluent-bit -c /etc/fluent-bit/fluent-bit.conf
...

The default Fluent Bit configuration collect metrics of CPU usage and sends the records to the standard output. You can see the outgoing data in your/var/log/messages file.

Learn how to install Fluent Bit and the AWS output plugins on Amazon Linux 2 usingAWS Systems Manager.

Fluent Bit has one event loop to handle critical operations, like managing timers, receiving internal messages, scheduling flushes, and handling retries. This event loop runs in the main Fluent Bit thread.

To free up resources in the main thread, you can configureinputs and outputs to run in their own self-contained threads. However, inputs and outputs implement multithreading in distinct ways: inputs can run in threaded mode, and outputs can use one or more workers.

Threading also affects certain processes related to inputs and outputs. For example,filters always run in the main thread, butprocessors run in the self-contained threads of their respective inputs or outputs, if applicable.

Inputs

When inputs collect telemetry data, they can either perform this process inside the main Fluent Bit thread or inside a separate dedicated thread. You can configure this behavior by enabling or disabling the threaded setting.

All inputs are capable of running in threaded mode, but certain inputs always run in threaded mode regardless of configuration. These always-threaded inputs are:

• Kubernetes Events

• Node Exporter Metrics

• Process Exporter Metrics

• Windows Exporter Metrics

Inputs aren't internally aware of multithreading. If an input runs in threaded mode, Fluent Bit manages the logistics of that input's thread.

Outputs

When outputs flush data, they can either perform this operation inside Fluent Bit's main thread or inside a separate dedicated thread called a worker. Each output can have one or more workers running in parallel, and each worker can handle multiple concurrent flushes. You can configure this behavior by changing the value of theworkers setting.

All outputs are capable of running in multiple workers, and each output has a default value of 0, 1, or 2 workers. However, even if an output uses workers by default, you can safely reduce the number of workers below the default or disable workers entirely.

AWS maintains a distribution of Fluent Bit that combines the latest official release with a set of Go Plugins for sending logs to AWS services. AWS and Fluent Bit are working together to rewrite their plugins for inclusion in the official Fluent Bit distribution.

Plugins

The AWS for Fluent Bit image contains Go Plugins for:

• Amazon CloudWatch as cloudwatch_logs. See theFluent Bit docs or thePlugin repository.

• Amazon Kinesis Data Firehose as kinesis_firehose. See theFluent Bit docs or thePlugin repository.

• Amazon Kinesis Data Streams as kinesis_streams. See theFluent Bit docs or thePlugin repository.

These plugins are higher performance than Go plugins.

Also, Fluent Bit includes an S3 output plugin named s3.

• Amazon S3

Versions and Regional Repositories

AWS vends their container image usingDocker Hub, and a set of highly available regional Amazon ECR repositories. For more information, see theAWS for Fluent Bit GitHub repository.

The AWS for Fluent Bit image uses a custom versioning scheme because it contains multiple projects. To see what each release contains, see the release notes on GitHub.

SSM Public Parameters

AWS vends SSM public parameters with the regional repository link for each image. These parameters can be queried by any AWS account.

To see a list of available version tags in a given region, run the following command:

aws ssm get-parameters-by-path --region eu-central-1 --path /aws/service/aws-for-fluent-bit/ --query 'Parameters[*].Name'

To see the ECR repository URI for a given image tag in a given region, run the following:

aws ssm get-parameter --region ap-northeast-1 --name /aws/service/aws-for-fluent-bit/2.0.0

You can use these SSM public parameters as parameters in your CloudFormation templates:

Parameters:
  FireLensImage:
    Description: Fluent Bit image for the FireLens Container
    Type: AWS::SSM::Parameter::Value<String>
    Default: /aws/service/aws-for-fluent-bit/latest

Fluent Bit is designed for high performance and minimal resource usage. Depending on your use case, you can optimize further using specific configuration options to achieve faster performance or reduce resource consumption.

Reading Files with Tail

The Tail input plugin is used to read data from files on the filesystem. By default, it uses a small memory buffer of 32KB per monitored file. While this is sufficient for most generic use cases and helps keep memory usage low when monitoring many files, there are scenarios where you may want to increase performance by using more memory.

If your files are typically larger than 32KB, consider increasing the buffer size to speed up file reading. For example, you can experiment with a buffer size of 128KB:

pipeline:
  inputs:
    - name: tail
      path: '/var/log/containers/*.log'
      buffer_chunk_size: 128kb
      buffer_max_size: 128kb

By increasing the buffer size, Fluent Bit will make fewer system calls (read(2)) to read the data, reducing CPU usage and improving performance.

Fluent Bit and SIMD for JSON Encoding

Starting in Fluent Bit v3.2, performance improvements have been introduced for JSON encoding. Plugins that convert logs from Fluent Bit's internal binary representation to JSON can now do so up to 30% faster using SIMD (Single Instruction, Multiple Data) optimizations.

Enabling SIMD Support

Ensure that your Fluent Bit binary is built with SIMD support. This feature is available for architectures such as x86_64, amd64, aarch64, and arm64. As of now, SIMD is only enabled by default in Fluent Bit container images.

You can check if SIMD is enabled by looking for the following log entry when Fluent Bit starts:

[2024/11/10 22:25:53] [ info] [fluent bit] version=3.2.0, commit=12cb22e0e9, pid=74359
[2024/11/10 22:25:53] [ info] [storage] ver=1.5.2, type=memory, sync=normal, checksum=off, max_chunks_up=128
[2024/11/10 22:25:53] [ info] [simd    ] SSE2
[2024/11/10 22:25:53] [ info] [cmetrics] version=0.9.8
[2024/11/10 22:25:53] [ info] [ctraces ] version=0.5.7
[2024/11/10 22:25:53] [ info] [sp] stream processor started

Look for the simd entry, which will indicate the SIMD support type, such as SSE2, NEON, or none.

If your Fluent Bit binary was not built with SIMD enabled and you are using a supported platform, you can build Fluent Bit from source using the CMake option -DFLB_SIMD=On.

Run input plugins in threaded mode

By default, most of input plugins runs in the same system thread than the main event loop, however by configuration you can instruct them to run in a separate thread which will allow you to take advantage of other CPU cores in your system.

To run an input plugin in threaded mode, just add threaded: true as in the example below:

pipeline:
  inputs:
    - name: tail
      path: '/var/log/containers/*.log'
      threaded: true

Some configuration directives in Fluent Bit refer to unit sizes such as when defining the size of a buffer or specific limits. Plugins like Tail Input, Forward Input or generic properties like Mem_Buf_Limit use unit sizes.

Fluent Bit v0.11.10 standardized unit sizes across the core and plugins. The following table describes the options that can be used and what they mean:

Multiline parsers are used to combine logs that span multiple events into a single, cohesive message. This is particularly useful for handling stack traces, error logs, or any log entry that contains multiple lines of information.

In YAML configuration, the syntax for defining multiline parsers differs slightly from the classic configuration format introducing minor breaking changes, specifically on how the rules are defined.

The following example demonstrates how to define a multiline parser directly in the main configuration file, and how to include additional definitions from external files:

multiline_parsers:
  - name: multiline-regex-test
    type: regex
    flush_timeout: 1000
    rules:
      - state: start_state
        regex: '/([a-zA-Z]+ \d+ \d+:\d+:\d+)(.*)/'
        next_state: cont
      - state: cont
        regex: '/^\s+at.*/'
        next_state: cont

This example defines a multiline parser named multiline-regex-test that uses regular expressions to handle multi-event logs. The parser contains two rules: the first rule transitions from start_state to cont when a matching log entry is detected, and the second rule continues to match subsequent lines.

For more detailed information on configuring multiline parsers, including advanced options and use cases, refer to the Configuring Multiline Parsers documentation.

The upstream_servers section defines a group of endpoints, referred to as nodes. Nodes are used by output plugins to distribute data in a round-robin fashion. This is useful for plugins that require load balancing when sending data. Examples of plugins that support this capability include Forward and Elasticsearch.

The upstream_servers section require specifying a name for the group and a list of nodes. The following example defines two upstream server groups, forward-balancing and forward-balancing-2:

upstream_servers:
  - name: forward-balancing
    nodes:
      - name: node-1
        host: 127.0.0.1
        port: 43000

      - name: node-2
        host: 127.0.0.1
        port: 44000

      - name: node-3
        host: 127.0.0.1
        port: 45000
        tls: true
        tls_verify: false
        shared_key: secret

  - name: forward-balancing-2
    nodes:
      - name: node-A
        host: 192.168.1.10
        port: 50000

      - name: node-B
        host: 192.168.1.11
        port: 51000

Each node in the upstream_servers group must specify a name, host, and port. Additional settings like tls, tls_verify, and shared_key can be configured for secure communication.

While the upstream_servers section can be defined globally, some output plugins might require the configuration to be specified in a separate YAML file. Consult the documentation for each specific output plugin to understand its requirements.

Install Fluent Bit in your embedded Linux system.

Install

To install, select Fluent Bit in your defconfig. See the Config.in file for all configuration options.

BR2_PACKAGE_FLUENT_BIT=y

Run

The default configuration file is written to:

/etc/fluent-bit/fluent-bit.conf

Fluent Bit is started by the S99fluent-bit script.

Support

All configurations with a toolchain that supports threads and dynamic library linking are supported.

Parsers enable Fluent Bit components to transform unstructured data into a structured internal representation. You can define parsers either directly in the main configuration file or in separate external files for better organization.

This page provides a general overview of how to declare parsers.

The main section name is parsers, and it lets you define a list of parser configurations. The following example demonstrates how to set up two basic parsers:

parsers:
  - name: json
    format: json

  - name: docker
    format: json
    time_key: time
    time_format: "%Y-%m-%dT%H:%M:%S.%L"
    time_keep: true

You can define multiple parsers sections, either within the main configuration file or distributed across included files.

For more detailed information on parser options and advanced configurations, refer to the Configuring Parsers documentation.

A Data Pipeline represents a flow of data that goes through the inputs (sources), filters, and output (sinks). The following sections contain information and steps to get started monitoring the pipeline.

• HTTP Server: JSON and Prometheus Exporter-style metrics

• Grafana Dashboards and Alerts

• Health Checks

• Telemetry Pipeline: hosted service to monitor and visualize your pipelines

Fluent Bit Sandbox - sign-up required

The following are labs that can run in your browser however require email sign-up

• Fluent Bit 101 Sandbox - Getting Started with configuration and routing

Open Source Labs - environment required

The following are open source labs where you will need to spin up resources to run through the lab in details

O11y Workshops by Chronosphere

These workshops, open source, provided by Chronosphere can be found here: https://o11y-workshops.gitlab.io/. The OSS repository can be found here: https://gitlab.com/o11y-workshops/workshop-fluentbit

The cards below include links to each of the labs in the workshop

1. Lab 1 - Introduction to Fluent Bit

2. Lab 2 - Installing Fluent Bit

3. Lab 3 - Exploring First Pipelines

4. Lab 4 - Exploring More Pipelines

5. Lab 5 - Understanding Backpressure

6. Lab 6 - Avoid Telemetry Data Loss

7. Lab 7 - Pipeline Integration with OpenTelemetry

Logging with Fluent Bit and Amazon OpenSearch workshop by Amazon

This workshop by Amazon goes through common Kubernetes logging patterns and routing data to OpenSearch and visualizing with OpenSearch dashboards

Dealing with raw strings or unstructured messages is difficult. Having a structure makes data more usable. Set a structure to the incoming data by using input plugins as data is collected:

The parser converts unstructured data to structured data. As an example, consider the following Apache (HTTP Server) log entry:

192.168.2.20 - - [28/Jul/2006:10:27:10 -0300] "GET /cgi-bin/try/ HTTP/1.0" 200 3395

This log line is a raw string without format. Structuring the log makes it easier to process the data later. If theregular expression parser is used, the log entry could be converted to:

{
  "host":    "192.168.2.20",
  "user":    "-",
  "method":  "GET",
  "path":    "/cgi-bin/try/",
  "code":    "200",
  "size":    "3395",
  "referer": "",
  "agent":   ""
 }

Parsers are fully configurable and are independently and optionally handled by each input plugin. For more details, seeParsers.

The output interface lets you define destinations for your data. Common destinations are remote services, local file systems, or other standard interfaces. Outputs are implemented as plugins.

When an output plugin is loaded, an internal instance is created. Every instance has its own independent configuration. Configuration keys are often calledproperties.

Every output plugin has its own documentation section specifying how it can be used and what properties are available.

For more details, see Output Plugins.

Fluent Bit is distributed as the fluent-bit package and is available for the Raspberry, specifically for distribution. The following versions are supported:

• Raspbian Bookworm (12)

• Raspbian Bullseye (11)

• Raspbian Buster (10)

Server GPG key

The first step is to add the Fluent Bit server GPG key to your keyring so you can get FLuent Bit signed packages:

Updated key from March 2022

For the 1.9.0 and 1.8.15 and later releases, the. Ensure this new one is added.

The GPG Key fingerprint of the new key is:

The previous key is and might be required to install previous versions.

The GPG Key fingerprint of the old key is:

Refer to the to see which platforms are supported in each release.

Update your sources lists

On Debian and derivative systems such as Raspbian, you need to add the Fluent Bit APT server entry to your sources lists.

Add the following content at bottom of your /etc/apt/sources.list file.

Raspbian 12 (Bookworm)

Raspbian 11 (Bullseye)

Raspbian 10 (Buster)

Update your repositories database

Now let your system update the apt database:

Install Fluent Bit

1. Use the following apt-get command to install the latest Fluent Bit:

2. Instruct systemd to enable the service:

If you do a status check, you should see a similar output like this:

The default configuration of Fluent Bit collects metrics for CPU usage and sends the records to the standard output. You can see the outgoing data in your/var/log/syslog file.

Fluent Bit is distributed as the fluent-bit package and is available for the latest versions of Rocky or Alma Linux now that CentOS Stream is tracking more recent dependencies.

Fluent Bit supports the following architectures:

• x86_64

• aarch64

• arm64v8

Single line install

Fluent Bit provides an installation script to use for most Linux targets. This will always install the most recently released version.

This is a convenience helper and should always be validated prior to use. Older versions of this install script will not support auto-detecting Rocky or Alma Linux. The recommended secure deployment approach is to use the following instructions:

RHEL 9

From CentOS 9 Stream onwards, the CentOS dependencies will update more often than downstream usage. This may mean that incompatible (more recent) versions are provided of certain dependencies (e.g. OpenSSL). For OSS, we also provide RockyLinux and AlmaLinux repositories. This may be required for RHEL 9 as well which will no longer track equivalent CentOS 9 stream dependencies. No RHEL 9 build is provided, it is expected to use one of the OSS variants listed.

Configure Yum

The fluent-bit is provided through a Yum repository. To add the repository reference to your system:

1. In /etc/yum.repos.d/, add a new file called fluent-bit.repo.

2. Add the following content to the file - replace almalinux with rockylinux if required:

3. As a best practice, enable gpgcheck and repo_gpgcheck for security reasons. Fluent Bit signs its repository metadata and all Fluent Bit packages.

Install

1. After your repository is configured, run the following command to install it:

2. Instruct Systemd to enable the service:

If you do a status check, you should see a similar output like this:

The default Fluent Bit configuration collect metrics of CPU usage and sends the records to the standard output. You can see the outgoing data in your/var/log/messages file.

Fluent Bit supports the usage of environment variables in any value associated to a key when using a configuration file.

The variables are case sensitive and can be used in the following format:

When Fluent Bit starts, the configuration reader will detect any request for ${MY_VARIABLE} and will try to resolve its value.

When Fluent Bit is running under (using the official packages), environment variables can be set in the following files:

• /etc/default/fluent-bit (Debian based system)

• /etc/sysconfig/fluent-bit (Others)

These files are ignored if they don't exist.

Example

Create the following configuration file (fluent-bit.conf):

Open a terminal and set the environment variable:

The previous command sets the stdout value to the variable MY_OUTPUT.

Run Fluent Bit with the recently created configuration file:

Fluent Bit is distributed as the fluent-bit package and is available for long-term support releases of Ubuntu. The latest officially supported version is Noble Numbat (24.04).

Single line install

An installation script is provided for most Linux targets. This will always install the most recent version released.

This is purely a convenience helper and should always be validated prior to use. The recommended secure deployment approach is to use the following instructions.

Server GPG key

The first step is to add the Fluent Bit server GPG key to your keyring to ensure you can get the correct signed packages.

Follow the official.

Updated key from March 2022

For releases 1.9.0 and 1.8.15 and later, the. Ensure the new key is added.

The GPG Key fingerprint of the new key is:

The previous key is and might be required to install previous versions.

The GPG Key fingerprint of the old key is:

Refer to the to see which platforms are supported in each release.

Update your sources lists

On Ubuntu, you need to add the Fluent Bit APT server entry to your sources lists. Add the following content at bottom of your /etc/apt/sources.list file. EnsureCODENAME is set to your specific . For example, focal for Ubuntu 20.04.

Update your repositories database

Update the apt database on your system:

Install Fluent Bit

1. Use the following apt-get command to install the latest Fluent Bit:

2. Instruct systemd to enable the service:

If you do a status check, you should see a similar output like this:

The default configuration of fluent-bit is collecting metrics of CPU usage and sending the records to the standard output. You can see the outgoing data in your/var/log/syslog file.

Plugins that interact with AWS services fetch credentials from the following providers in order. Only the first provider that provides credentials is used.

All AWS plugins additionally support a role_arn (or AWS_ROLE_ARN, for) configuration parameter. If specified, the fetched credentials are used to assume the given role.

Environment variables

Plugins use the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (and optionallyAWS_SESSION_TOKEN) environment variables if set.

Shared configuration and credentials files

Plugins read the shared config file at $AWS_CONFIG_FILE (or $HOME/.aws/config), and the shared credentials file at $AWS_SHARED_CREDENTIALS_FILE (or$HOME/.aws/credentials) to fetch the credentials for the profile named$AWS_PROFILE or $AWS_DEFAULT_PROFILE (or "default"). See.

The shared settings evaluate in the following order:

No other settings are supported.

EKS Web Identity Token (OIDC)

Credentials are fetched using a signed web identity token for a Kubernetes service account. See .

ECS HTTP credentials endpoint

Credentials are fetched for the ECS task's role. See.

EKS Pod Identity credentials

Credentials are fetched using a pod identity endpoint. See.

EC2 instance profile credentials (IMDS)

Fetches credentials for the EC2 instance profile's role. See. As of Fluent Bit version 1.8.8, IMDSv2 is used by default and IMDSv1 might be disabled. Prior versions of Fluent Bit require enabling IMDSv1 on EC2.

The Docker events input plugin uses the Docker API to capture server events. A complete list of possible events returned by this plugin can be found .

Configuration parameters

This plugin supports the following configuration parameters:

Command line

You can run this plugin from the command line:

Configuration file

In your main configuration file append the following:

You can test logging pipelines locally to observe how they handles log messages. This guide explains how to use to run Fluent Bit and Elasticsearch locally, but you can use the same principles to test other plugins.

Create a configuration file

Start by creating one of the corresponding Fluent Bit configuration files to start testing.

Use Docker Compose

Use to run Fluent Bit (with the configuration file mounted) and Elasticsearch.

View indexed logs

To view indexed logs, run the following command:

Reset index

To reset your index, run the following command:

source code provides BitBake recipes to configure, build, and package the software for a Yocto-based image. Specific steps in the usage of these recipes in your Yocto environment (Poky) is out of the scope of this documentation.

Fluent Bit distributes two main recipes, one for testing/dev purposes and one with the latest stable release.

It's strongly recommended to always use the stable release of the Fluent Bit recipe and not the one from Git master for production deployments.

Fluent Bit and other architectures

Fluent Bit >= v1.1.x fully supports x86_64, x86, arm32v7, and arm64v8.

The Memory (mem) input plugin gathers information about the memory and swap usage of the running system every certain interval of time and reports the total amount of memory and the amount of free available.

Get started

To get memory and swap usage from your system, you can run the plugin from the command line or through the configuration file:

Command line

Run the following command from the command line, noting this is for a Linux machine:

Which outputs information similar to:

Threading

You can enable the threaded setting to run this input in its own .

Configuration file

In your main configuration file append the following:

Fluent Bit supports the reloading feature when enabled in the configuration file or on the command line with -Y or --enable-hot-reload option.

Hot reloading is supported on Linux, macOS, and Windows operating systems.

Update the configuration

To get started with reloading over HTTP, enable the HTTP Server in the configuration file:

How to reload

After updating the configuration, use one of the following methods to perform a hot reload:

HTTP

Use the following HTTP endpoints to perform a hot reload:

• PUT /api/v2/reload

• POST /api/v2/reload

For using curl to reload Fluent Bit, users must specify an empty request body as:

Signal

Hot reloading can be used with SIGHUP.

SIGHUP signal isn't supported on Windows.

Confirm a reload

Use one of the following methods to confirm the reload occurred.

HTTP

Obtain a count of hot reload using the HTTP endpoint:

• GET /api/v2/reload

The endpoint returns hot_reload_count as follows:

The default value of the counter is 0.

Fluent Bit comes with a variety of built-in plugins, and also supports loading external plugins at runtime. This feature is especially useful for loading Go or WebAssembly (Wasm) plugins that are built as shared object files (.so). Fluent Bit YAML configuration provides the following ways to load these external plugins:

Inline YAML

You can specify external plugins directly within your main YAML configuration file using the plugins section. Here's an example:

YAML plugins file included using the plugins_file option

You can load external plugins from a separate YAML file by specifying the plugins_file option in the service section for better modularity.

To configure this:

In this setup, the extra_plugins.yaml file might contain the following plugins section:

The env section lets you define environment variables directly within the configuration file. These variables can then be used to dynamically replace values throughout your configuration using the ${VARIABLE_NAME} syntax.

Variables set in this section cannot be overridden by system environment variables.

Values set in the env section are case-sensitive. However, as a best practice, Fluent Bit recommends using uppercase names for environment variables. The following example defines two variables, FLUSH_INTERVAL and STDOUT_FMT, which can be accessed in the configuration using ${FLUSH_INTERVAL} and ${STDOUT_FMT}:

Predefined variables

Fluent Bit provides a set of predefined environment variables that can be used in your configuration:

External variables

In addition to variables defined in the configuration file or the predefined ones, Fluent Bit can access system environment variables set in the user space. These external variables can be referenced in the configuration using the same ${VARIABLE_NAME} pattern.

Variables set in the env section cannot be overridden by system environment variables.

For example, to set the FLUSH_INTERVAL system environment variable to 2 and use it in your configuration:

In the configuration file, you can then access this value as follows:

This approach lets you manage and override configuration values using environment variables, providing flexibility in various deployment environments.

The following article covers the relevant compatibility changes for users upgrading from previous Fluent Bit versions.

For more details about changes on each release, refer to the Official Release Notes.

Release notes will be prepared in advance of a Git tag for a release. An official release should provide both a tag and a release note together to allow users to verify and understand the release contents.

The tag drives the binary release process. Release binaries (containers and packages) will appear after a tag and its associated release note. This lets users to expect the new release binary to appear and allow/deny/update it as appropriate in their infrastructure.

Fluent Bit v1.9.9

The td-agent-bit package is no longer provided after this release. Users should switch to the fluent-bit package.

Fluent Bit v1.6

If you are migrating from previous version of Fluent Bit, review the following important changes:

Tail Input Plugin

By default, the tail input plugin follows a file from the end after the service starts, instead of reading it from the beginning. Every file found when the plugin starts is followed from it last position. New files discovered at runtime or when files rotate are read from the beginning.

To keep the old behavior, set the option read_from_head to true.

Stackdriver Output Plugin

The project_id of resource in LogEntry sent to Google Cloud Logging would be set to the project_id rather than the project number. To learn the difference between Project ID and project number, see Creating and managing projects.

If you have existing queries based on the resource's project_id, update your query accordingly.

Fluent Bit v1.5

The migration from v1.4 to v1.5 is pretty straightforward.

• The keepalive configuration mode has been renamed to net.keepalive. Now, all Network I/O keepalive is enabled by default. To learn more about this and other associated configuration properties read the Networking Administration section. - If you use the Elasticsearch output plugin, the default value of type changed from flb_type to _doc. Many versions of Elasticsearch tolerate this, but Elasticsearch v5.6 through v6.1 require a type without a leading underscore. See the Elasticsearch output plugin documentation FAQ entry for more.

Fluent Bit v1.4

If you are migrating from Fluent Bit v1.3, there are no breaking changes.

Fluent Bit v1.3

If you are migrating from Fluent Bit v1.2 to v1.3, there are no breaking changes. If you are upgrading from an older version, review the following incremental changes:

Fluent Bit v1.2

Docker, JSON, Parsers and Decoders

Fluent Bit v1.2 fixed many issues associated with JSON encoding and decoding.

For example, when parsing Docker logs, it's no longer necessary to use decoders. The new Docker parser looks like this:

python [PARSER] Name docker Format json Time_Key time Time_Format %Y-%m-%dT%H:%M:%S.%L Time_Keep On

Kubernetes Filter

Fluent Bit made improvements to Kubernetes Filter handling of stringified log messages. If the Merge_Log option is enabled, it will try to handle the log content as a JSON map, if so, it will add the keys to the root map.

In addition, fixes and improvements were made to the Merge_Log_Key option. If a merge log succeed, all new keys will be packaged under the key specified by this option. A suggested configuration is as follows:

python [FILTER] Name Kubernetes Match kube.* Kube_Tag_Prefix kube.var.log.containers. Merge_Log On Merge_Log_Key log_processed

As an example, if the original log content is the following map:

javascript {"key1": "val1", "key2": "val2"}

the final record will be composed as follows:

javascript { "log": "{\"key1\": \"val1\", \"key2\": \"val2\"}", "log_processed": { "key1": "val1", "key2": "val2" } }

Fluent Bit v1.1

If you are upgrading from Fluent Bit 1.0.x or earlier, review the following relevant changes when switching to Fluent Bit v1.1 or later series:

Kubernetes filter

Fluent Bit introduced a new configuration property called Kube_Tag_Prefix to help Tag prefix resolution and address an unexpected behavior in previous versions.

During the 1.0.x release cycle, a commit in the Tail input plugin changed the default behavior on how the Tag was composed when using the wildcard for expansion generating breaking compatibility with other services. Consider the following configuration example:

python [INPUT] Name tail Path /var/log/containers/*.log Tag kube.*

The expected behavior is that Tag will be expanded to:

text kube.var.log.containers.apache.log

The change introduced in the 1.0 series switched from absolute path to the base filename only:

text kube.apache.log

THe Fluent Bit v1.1 release restored the default behavior and now the Tag is composed using the absolute path of the monitored file.

Having absolute path in the Tag is relevant for routing and flexible configuration where it also helps to keep compatibility with Fluentd behavior.

This behavior switch in Tail input plugin affects how Filter Kubernetes operates. When the filter is used it needs to perform local metadata lookup that comes from the file names when using Tail as a source. With the new Kube_Tag_Prefix option you can specify the prefix used in the Tail input plugin. For the previous configuration example the new configuration will look like:

[FILTER] Name kubernetes Match * Kube_Tag_Prefix kube.var.log.containers. ```

The proper value for `Kube_Tag_Prefix` must be composed by Tag prefix set in Tail input plugin plus the converted monitored directory replacing slashes with dots.

Fluent Bit works internally with structured records and it can be composed of an unlimited number of keys and values. Values can be anything like a number, string, array, or a map.

Having a way to select a specific part of the record is critical for certain core functionalities or plugins, this feature is called Record Accessor.

Consider record accessor to be a basic grammar to specify record content and other miscellaneous values.

Format

A record accessor rule starts with the character $. Use the structured content as an example. The following table describes how to access a record:

{
  "log": "some message",
  "stream": "stdout",
  "labels": {
     "color": "blue",
     "unset": null,
     "project": {
         "env": "production"
      }
  }
}

The following table describes some accessing rules and the expected returned value:

If the accessor key doesn't exist in the record like the last example $labels['undefined'], the operation is omitted, and no exception will occur.

Usage

The feature is enabled on a per plugin basis. Not all plugins enable this feature. As an example, consider a configuration that aims to filter records using grep that only matches where labels have a color blue:

[SERVICE]
    flush        1
    log_level    info
    parsers_file parsers.conf

[INPUT]
    name      tail
    path      test.log
    parser    json

[FILTER]
    name      grep
    match     *
    regex     $labels['color'] ^blue$

[OUTPUT]
    name      stdout
    match     *
    format    json_lines

The file content to process in test.log is the following:

{"log": "message 1", "labels": {"color": "blue"}}
{"log": "message 2", "labels": {"color": "red"}}
{"log": "message 3", "labels": {"color": "green"}}
{"log": "message 4", "labels": {"color": "blue"}}

When running Fluent Bit with the previous configuration, the output is:

$ bin/fluent-bit -c fluent-bit.conf
Fluent Bit v1.x.x
* Copyright (C) 2019-2020 The Fluent Bit Authors
* Copyright (C) 2015-2018 Treasure Data
* Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
* https://fluentbit.io

[2020/09/11 16:11:07] [ info] [engine] started (pid=1094177)
[2020/09/11 16:11:07] [ info] [storage] version=1.0.5, initializing...
[2020/09/11 16:11:07] [ info] [storage] in-memory
[2020/09/11 16:11:07] [ info] [storage] normal synchronization mode, checksum disabled, max_chunks_up=128
[2020/09/11 16:11:07] [ info] [sp] stream processor started
[2020/09/11 16:11:07] [ info] inotify_fs_add(): inode=55716713 watch_fd=1 name=test.log
{"date":1599862267.483684,"log":"message 1","labels":{"color":"blue"}}
{"date":1599862267.483692,"log":"message 4","labels":{"color":"blue"}}

Limitations of record_accessor templating

The Fluent Bit record_accessor library has a limitation in the characters that can separate template variables. Only dots and commas (. and ,) can come after a template variable. This is because the templating library must parse the template and determine the end of a variable.

The following templates are invalid because the template variables aren't separated by commas or dots:

• $TaskID-$ECSContainerName

• $TaskID/$ECSContainerName

• $TaskID_$ECSContainerName

• $TaskIDfooo$ECSContainerName

However, the following are valid:

• $TaskID.$ECSContainerName

• $TaskID.ecs_resource.$ECSContainerName

• $TaskID.fooo.$ECSContainerName

And the following are valid since they only contain one template variable with nothing after it:

• fooo$TaskID

• fooo____$TaskID

• fooo/bar$TaskID

The in_ebpf input plugin uses eBPF (extended Berkeley Packet Filter) to capture low-level system events. This plugin lets Fluent Bit monitor kernel-level activities such as process executions, file accesses, memory allocations, network connections, and signal handling. It provides valuable insights into system behavior for debugging, monitoring, and security analysis.

The in_ebpf plugin leverages eBPF to trace kernel events in real-time. By specifying trace points, users can collect targeted system-level metrics and events, giving visibility into operating system interactions and performance characteristics.

System dependencies

To enable in_ebpf, ensure the following dependencies are installed on your system:

• Kernel version: 4.18 or greater, with eBPF support enabled.

• Required packages:

  • bpftool: Used to manage and debug eBPF programs.

  • libbpf-dev: Provides the libbpf library for loading and interacting with eBPF programs.

  • CMake 3.13 or higher: Required for building the plugin.

Installing dependencies on Ubuntu

sudo apt update
sudo apt install libbpf-dev linux-tools-common cmake

Building Fluent Bit with in_ebpf

To enable the in_ebpf plugin, follow these steps to build Fluent Bit from source:

1. Clone the Fluent Bit repository:

   Copy

   git clone https://github.com/fluent/fluent-bit.git
   cd fluent-bit

2. Configure the build with in_ebpf:

   Create a build directory and run cmake with the -DFLB_IN_EBPF=On flag to enable the in_ebpf plugin:

   Copy

   mkdir build
   cd build
   cmake .. -DFLB_IN_EBPF=On

3. Compile the source:

   Copy

   make

4. Run Fluent Bit:

   Run Fluent Bit with elevated permissions (for example, sudo). Loading eBPF programs requires root access or appropriate privileges.

   Copy

   # For YAML configuration.
   sudo ./bin/fluent-bit --config fluent-bit.yaml
   
   # For classic configuration.
   sudo ./bin/fluent-bit --config fluent-bit.conf

Configuration example

Here's a basic example of how to configure the plugin:

pipeline:
    inputs:
      - name: ebpf
        trace: 
          - trace_signal
          - trace_malloc
          - trace_bind

[INPUT]
    Name          ebpf
    Trace         trace_signal
    Trace         trace_malloc
    Trace         trace_bind

The configuration enables tracing for:

• Signal handling events (trace_signal)

• Memory allocation events (trace_malloc)

• Network bind operations (trace_bind)

You can enable multiple traces by adding multiple Trace directives in your configuration. Full list of existing traces can be seen here: Fluent Bit eBPF Traces

Fluent Bit output plugins aim to connect to external services to deliver logs over the network. Being able to connect to one node (host) is normal and enough for more of the use cases, but there are other scenarios where balancing across different nodes is required. The Upstream feature provides this capability.

An Upstream defines a set of nodes that will be targeted by an output plugin, by the nature of the implementation an output plugin must support the Upstream feature. The following plugin has Upstream support:

• Forward

The current balancing mode implemented is round-robin.

Configuration

To define an Upstream you must create an specific configuration file that contains an UPSTREAM and one or multiple NODE sections. The following table describes the properties associated with each section. All properties are mandatory:

Nodes and specific plugin configuration

A Node might contain additional configuration keys required by the plugin, to provide enough flexibility for the output plugin. A common use case is a Forward output where if TLS is enabled, it requires a shared key.

Nodes and TLS (Transport Layer Security)

In addition to the properties defined in the configuration table, the network operations against a defined node can optionally be done through the use of TLS for further encryption and certificates use.

The TLS options available are described in the TLS/SSL section and can be added to the any Node section.

Configuration file example

The following example defines an Upstream called forward-balancing which aims to be used by Forward output plugin, it register three Nodes:

• node-1: connects to 127.0.0.1:43000

• node-2: connects to 127.0.0.1:44000

• node-3: connects to 127.0.0.1:45000 using TLS without verification. It also defines a specific configuration option required by Forward output called shared_key.

[UPSTREAM]
    name       forward-balancing

[NODE]
    name       node-1
    host       127.0.0.1
    port       43000

[NODE]
    name       node-2
    host       127.0.0.1
    port       44000

[NODE]
    name       node-3
    host       127.0.0.1
    port       45000
    tls        on
    tls.verify off
    shared_key secret

Every Upstream definition must exists in its own configuration file in the file system. Adding multiple Upstream configurations in the same file or different files isn't allowed.

Before You Get Started

Fluent Bit traditionally offered a classic configuration mode, a custom configuration format that we are gradually phasing out. While classic mode has served well for many years, it has several limitations. Its basic design only supports grouping sections with key-value pairs and lacks the ability to handle sub-sections or complex data structures like lists.

YAML, now a mainstream configuration format, has become essential in a cloud ecosystem where everything is configured this way. To minimize friction and provide a more intuitive experience for creating data pipelines, we strongly encourage users to transition to YAML. The YAML format enables features, such as processors, that are not possible to configure in classic mode.

As of Fluent Bit v3.2, you can configure everything in YAML.

List of Available Sections

Configuring Fluent Bit with YAML introduces the following root-level sections:

Section Documentation

To access detailed configuration guides for each section, use the following links:

• Service Section documentation

  • Overview of global settings, configuration options, and examples.

• Parsers Section documentation

  • Detailed guide on defining parsers and supported formats.

• Multiline Parsers Section documentation

  • Explanation of multiline parsing configuration.

• Pipeline Section documentation

  • Details on setting up pipelines and using processors.

• Plugins Section documentation

  • How to load external plugins.

• Upstream Servers Section documentation

  • Guide on setting up and using upstream nodes with supported plugins.

• Environment Variables Section documentation

  • Information on setting environment variables and their scope within Fluent Bit.

• Includes Section documentation

  • Description on how to include external YAML files.

Fluent Bit supports configuring an HTTP proxy for all egress HTTP/HTTPS traffic using the HTTP_PROXY or http_proxy environment variable.

The format for the HTTP proxy environment variable is http://USER:PASS@HOST:PORT, where:

• USER is the username when using basic authentication.

• PASS is the password when using basic authentication.

• HOST is the HTTP proxy hostname or IP address.

• PORT is the port the HTTP proxy is listening on.

To use an HTTP proxy with basic authentication, provide the username and password:

HTTP_PROXY='http://example_user:[email protected]:8080'

When no authentication is required, omit the username and password:

HTTP_PROXY='http://proxy.example.com:8080'

The HTTP_PROXY environment variable is a standard way of setting a HTTP proxy in a containerized environment, and it's also natively supported by any application written in Go. Fluent Bit implements the same convention. Thehttp_proxy environment variable is also supported. When both the HTTP_PROXY andhttp_proxy environment variables are provided, HTTP_PROXY will be preferred.

NO_PROXY

Use the NO_PROXY environment variable when traffic shouldn't flow through the HTTP proxy. The no_proxy environment variable is also supported. When both NO_PROXY and no_proxy environment variables are provided, NO_PROXY takes precedence.

The format for the no_proxy environment variable is a comma-separated list of host names or IP addresses.

A domain name matches itself and all of its subdomains (for example, example.com matches both example.com and test.example.com):

NO_PROXY='foo.com,127.0.0.1,localhost'

A domain with a leading dot (.) matches only its subdomains (for example,.example.com matches test.example.com but not example.com):

NO_PROXY='.example.com,127.0.0.1,localhost'

As an example, you might use NO_PROXY when running Fluent Bit in a Kubernetes environment, where and you want:

• All real egress traffic to flow through an HTTP proxy.

• All local Kubernetes traffic to not flow through the HTTP proxy.

In this case, set:

NO_PROXY='127.0.0.1,localhost,kubernetes.default.svc'

Routing is a core feature that lets you route your data through filters and then to one or multiple destinations. The router relies on the concept ofTags and Matching rules.

There are two important concepts in Routing:

• Tag

• Match

When data is generated by an input plugin, it comes with a Tag. A Tag is a human-readable indicator that helps to identify the data source. Tags are usually configured manually.

To define where to route data, specify a Match rule in the output configuration.

Consider the following configuration example that delivers CPU metrics to an Elasticsearch database and Memory (mem) metrics to the standard output interface:

[INPUT]
    Name cpu
    Tag  my_cpu

[INPUT]
    Name mem
    Tag  my_mem

[OUTPUT]
    Name   es
    Match  my_cpu

[OUTPUT]
    Name   stdout
    Match  my_mem

Routing reads the Input Tag and the Output Match rules. If data has a Tag that doesn't match at routing time, the data is deleted.

Routing with Wildcard

Routing is flexible enough to support wildcards in the Match pattern. The following example defines a common destination for both sources of data:

pipeline:
    inputs:
        - name: cpu
          tag: my_cpu

        - name: mem
          tag: my_mem
  
    outputs:
        - name: stdout
          match: 'my_*'

[INPUT]
    Name cpu
    Tag  my_cpu

[INPUT]
    Name mem
    Tag  my_mem

[OUTPUT]
    Name   stdout
    Match  my_*

The match rule is set to my_*, which matches any Tag starting with my_.

Routing with Regex

Routing also provides support for regular expressions with the Match_Regex pattern, allowing for more complex and precise matching criteria. The following example demonstrates how to route data from sources based on a regular expression:

pipeline:
    inputs:
        - name: temperature_sensor
          tag: temp_sensor_A

        - name: humidity_sensor
          tag: humid_sensor_B
 
    outputs:
        - name: stdout
          match: '.*_sensor_[AB]'

[INPUT]
    Name temperature_sensor
    Tag  temp_sensor_A

[INPUT]
    Name humidity_sensor
    Tag  humid_sensor_B

[OUTPUT]
    Name         stdout
    Match_regex  .*_sensor_[AB]

In this configuration, the Match_regex rule is set to .*_sensor_[AB]. This regular expression matches any Tag that ends with _sensor_A or _sensor_B, regardless of what precedes it. This approach provides a more flexible and powerful way to handle different source tags with a single routing rule.

Container deployment

Install on Linux (packages)

Install on Windows (packages)

Install on macOS (packages)

Compile from Source (Linux, Windows, FreeBSD, macOS)

Sandbox Environment

If you are interested in learning about Fluent Bit you can try out the sandbox environment:

Enterprise Packages

Fluent Bit packages are also provided by enterprise providers for older end of life versions, Unix systems, and additional support and features including aspects like CVE backporting.

Fluent Bit supports the following operating systems and architectures:

From an architecture support perspective, Fluent Bit is fully functional on x86_64, Arm64v8, and Arm32v7 based processors.

Fluent Bit can work also on macOS and Berkeley Software Distribution (BSD) systems, but not all plugins will be available on all platforms.

Official support is based on community demand. Fluent Bit might run on older operating systems, but must be built from source, or using custom packages fromenterprise providers.

Fluent Bit is supported for Linux on IBM Z (s390x) environments with some restrictions, but only container images are provided for these targets officially.

The Docker input plugin you collect Docker container metrics, including memory usage and CPU consumption.

Configuration parameters

The plugin supports the following configuration parameters:

If you set neither Include nor Exclude, the plugin will try to get metrics from all running containers.

Configuration file

The following example configuration collects metrics from two docker instances (6bab19c3a0f9 and 14159be4ca2c).

[INPUT]
    Name         docker
    Include      6bab19c3a0f9 14159be4ca2c
[OUTPUT]
    Name   stdout
    Match  *

This configuration will produce records like the following:

[1] docker.0: [1571994772.00555745, {"id"=>"6bab19c3a0f9", "name"=>"postgresql", "cpu_used"=>172102435, "mem_used"=>5693400, "mem_limit"=>4294963200}]

Fluent Bit in normal operation mode is configurable throughtext files or using specific arguments in the command line. Although this is the ideal deployment case, there are scenarios where a more restricted configuration is required. Static configuration mode restricts configuration ability.

Static configuration mode includes a built-in configuration in the final binary of Fluent Bit, disabling the usage of external files or flags at runtime.

Get started

Requirements

The following steps assume you are familiar with configuring Fluent Bit using text files and you have experience building it from scratch as described inBuild and Install.

Configuration Directory

In your file system, prepare a specific directory that will be used as an entry point for the build system to lookup and parse the configuration files. This directory must contain a minimum of one configuration file calledfluent-bit.conf containing the requiredSERVICE,INPUT, and OUTPUT sections.

As an example, create a new fluent-bit.yaml file or fluent-bit.conf file with the corresponding content below:

[SERVICE]
    Flush     1
    Daemon    off
    Log_Level info

[INPUT]
    Name      cpu

[OUTPUT]
    Name      stdout
    Match     *

This configuration calculates CPU metrics from the running system and prints them to the standard output interface.

Build with custom configuration

1. Go to the Fluent Bit source code build directory:

   Copy

   cd fluent-bit/build/

2. Run CMake, appending the FLB_STATIC_CONF option pointing to the configuration directory recently created:

   Copy

   cmake -DFLB_STATIC_CONF=/path/to/my/confdir/

3. Build Fluent Bit:

   Copy

   make

The generated fluent-bit binary is ready to run without additional configuration:

$ bin/fluent-bit
Fluent-Bit v0.15.0
Copyright (C) Treasure Data

[2018/10/19 15:32:31] [ info] [engine] started (pid=15186)
[0] cpu.local: [1539984752.000347547, {"cpu_p"=>0.750000, "user_p"=>0.500000, "system_p"=>0.250000, "cpu0.p_cpu"=>1.000000, "cpu0.p_user"=>1.000000, "cpu0.p_system"=>0.000000, "cpu1.p_cpu"=>0.000000, "cpu1.p_user"=>0.000000, "cpu1.p_system"=>0.000000, "cpu2.p_cpu"=>0.000000, "cpu2.p_user"=>0.000000, "cpu2.p_system"=>0.000000, "cpu3.p_cpu"=>1.000000, "cpu3.p_user"=>1.000000, "cpu3.p_system"=>0.000000}]

The Collectd input plugin lets you receive datagrams from the collectd service.

Configuration parameters

The plugin supports the following configuration parameters:

Configuration examples

Here is a basic configuration example:

[INPUT]
    Name         collectd
    Listen       0.0.0.0
    Port         25826
    TypesDB      /usr/share/collectd/types.db,/etc/collectd/custom.db

[OUTPUT]
    Name   stdout
    Match  *

With this configuration, Fluent Bit listens to 0.0.0.0:25826, and outputs incoming datagram packets to stdout.

You must set the same types.db files that your collectd server uses. Otherwise, Fluent Bit might not be able to interpret the payload properly.

Before diving into you might want to get acquainted with some of the key concepts of the service. This document provides an introduction to those concepts and common terminology. Reading this document will help you gain a more general understanding of the following topics:

• Event or Record

• Filtering

• Tag

• Timestamp

• Match

• Structured Message

Event or Record

Every incoming piece of data that belongs to a log or a metric that's retrieved by Fluent Bit is considered an Event or a Record.

As an example, consider the following content of a Syslog file:

It contains four lines that represent four independent Events.

An Event is comprised of:

• timestamp

• key/value metadata (v2.1.0 and greater)

• payload

Event format

The Fluent Bit wire protocol represents an Event as a two-element array with a nested array as the first element:

where

• TIMESTAMP is a timestamp in seconds as an integer or floating point value (not a string).

• METADATA is an object containing event metadata, and might be empty.

• MESSAGE is an object containing the event body.

Fluent Bit versions prior to v2.1.0 used:

to represent events. This format is still supported for reading input event streams.

Filtering

You might need to perform modifications on an Event's content. The process to alter, append to, or drop Events is called .

Use filtering to:

• Append specific information to the Event like an IP address or metadata.

• Select a specific piece of the Event content.

• Drop Events that match a certain pattern.

Tag

Every Event ingested by Fluent Bit is assigned a Tag. This tag is an internal string used in a later stage by the Router to decide which Filter or phase it must go through.

Most tags are assigned manually in the configuration. If a tag isn't specified, Fluent Bit assigns the name of the plugin instance where that Event was generated from.

A tagged record must always have a Matching rule. To learn more about Tags and Matches, see .

Timestamp

The timestamp represents the time an Event was created. Every Event contains an associated timestamps. All events have timestamps, and they're set by the input plugin or discovered through a data parsing process.

The timestamp is a numeric fractional integer in the format:

where:

• _SECONDS_ is the number of seconds that have elapsed since the Unix epoch.

• _NANOSECONDS_ is a fractional second or one thousand-millionth of a second.

Match

Fluent Bit lets you route your collected and processed Events to one or multiple destinations. A Match represents a rule to select Events where a Tag matches a defined rule.

To learn more about Tags and Matches, see .

Structured messages

Source events can have a structure. A structure defines a set of keys and values inside the Event message to implement faster operations on data modifications. Fluent Bit treats every Event message as a structured message.

Consider the following two messages:

• No structured message

• With a structured message

For performance reasons, Fluent Bit uses a binary serialization data format called.

Fluent Bit is distributed as the fluent-bit package and is available for the latest stable CentOS system.

The following architectures are supported

• x86_64

• aarch64

• arm64v8

Single line install

Fluent Bit provides an installation script to use for most Linux targets. This will always install the most recently released version.

This is a convenience helper and should always be validated prior to use. The recommended secure deployment approach is to use the following instructions:

Server GPG key

The first step is to add the Fluent Bit server GPG key to your keyring to ensure you can get the correct signed packages.

Follow the official.

Updated key from March 2022

For the 1.9.0 and 1.8.15 and later releases, the. Ensure this new one is added.

The GPG Key fingerprint of the new key is:

The previous key is and might be required to install previous versions.

The GPG Key fingerprint of the old key is:

Refer to the to see which platforms are supported in each release.

Update your sources lists

For Debian, you must add the Fluent Bit APT server entry to your sources lists. Add the following content at bottom of your /etc/apt/sources.list file.

Replace CODENAME with your specific (for example: bookworm for Debian 12)

Update your repositories database

Update your system's apt database:

Install Fluent Bit

1. Use the following apt-get command to install the latest Fluent Bit:

2. Instruct systemd to enable the service:

If you do a status check, you should see a similar output similar to:

The default Fluent Bit configuration collect metrics of CPU usage and sends the records to the standard output. You can see the outgoing data in your/var/log/messages file.

Fluent Bit is compatible with the latest Apple macOS software for x86_64 and Apple Silicon architectures.

Installation packages

Installation packages can be found .

Requirements

You must have installed in your system. If it isn't present, install it with the following command:

Installing from Homebrew

The Fluent Bit package on Homebrew isn't officially supported, but should work for basic use cases and testing. It can be installed using:

Compile from source

Install build dependencies

Run the following brew command in your terminal to retrieve the dependencies:

Download and build the source

1. Download a copy of the Fluent Bit source code (upstream):

   If you want to use a specific version, checkout to the proper tag. For example, to use v1.8.13, use the command:

2. To prepare the build system, you must expose certain environment variables so Fluent Bit CMake build rules can pick the right libraries:

3. Change to the build/ directory inside the Fluent Bit sources:

4. Build Fluent Bit. This example indicates to the build system the location the final binaries and config files should be installed:

5. Install Fluent Bit to the previously specified directory. Writing to this directory requires root privileges.

The binaries and configuration examples can be located at /opt/fluent-bit/.

Create macOS installer from source

1. Clone the Fluent Bit source code (upstream):

   If you want to use a specific version, checkout to the proper tag. For example, to use v1.9.2 do:

2. To prepare the build system, you must expose certain environment variables so Fluent Bit CMake build rules can pick the right libraries:

3. Create the specific macOS SDK target. For example, to specify macOS Big Sur (11.3) SDK environment:

4. Change to the build/ directory inside the Fluent Bit sources:

5. Build the Fluent Bit macOS installer:

The macOS installer will be generated as:

Finally, the fluent-bit-<fluent-bit version>-(intel or apple).pkg will be generated.

The created installer will put binaries at /opt/fluent-bit/.

Running Fluent Bit

To make the access path easier to Fluent Bit binary, extend the PATH variable:

To test, try Fluent Bit by generating a test message using the which prints to the standard output interface every one second:

You will see an output similar to this:

To halt the process, press ctrl-c in the terminal.

Fluent Bit exposes to let you monitor the internals of your pipeline. The collected metrics can be processed similarly to those from the . They can be sent to output plugins including , or .

Configuration

Get started

Configuration file

In the following configuration file, the input plugin node_exporter_metrics collects metrics every 2 seconds and exposes them through the output plugin on HTTP/TCP port 2021.

You can test the expose of the metrics by using curl:

has an engine that helps to coordinate the data ingestion from input plugins. The engine calls the scheduler to decide when it's time to flush the data through one or multiple output plugins. The scheduler flushes new data at a fixed number of seconds, and retries when asked.

When an output plugin gets called to flush some data, after processing that data it can notify the engine using these possible return statuses:

• OK: Data successfully processed and flushed.

• Retry: If a retry is requested, the engine asks the scheduler to retry flushing that data. The scheduler decides how many seconds to wait before retry.

• Error: An unrecoverable error occurred and the engine shouldn't try to flush that data again.

Configure wait time for retry

The scheduler provides two configuration options, called scheduler.cap andscheduler.base, which can be set in the Service section. These determine the waiting time before a retry happens.

The scheduler.base determines the lower bound of time and the scheduler.cap determines the upper bound for each retry.

Fluent Bit uses an exponential backoff and jitter algorithm to determine the waiting time before a retry. The waiting time is a random number between a configurable upper and lower bound. For a detailed explanation of the exponential backoff and jitter algorithm, see.

For example:

For the Nth retry, the lower bound of the random number will be:

base

The upper bound will be:

min(base * (Nth power of 2), cap)

For example:

When base is set to 3 and cap is set to 30:

First retry: The lower bound will be 3. The upper bound will be 3 * 2 = 6. The waiting time will be a random number between (3, 6).

Second retry: The lower bound will be 3. The upper bound will be 3 * (2 * 2) = 12. The waiting time will be a random number between (3, 12).

Third retry: The lower bound will be 3. The upper bound will be 3 * (2 * 2 * 2) =24. The waiting time will be a random number between (3, 24).

Fourth retry: The lower bound will be 3, because 3 * (2 * 2 * 2 * 2) = 48 > 30. The upper bound will be 30. The waiting time will be a random number between (3, 30).

Wait time example

The following example configures the scheduler.base as 3 seconds andscheduler.cap as 30 seconds.

The waiting time will be:

Configure retries

The scheduler provides a configuration option called Retry_Limit, which can be set independently for each output section. This option lets you disable retries or impose a limit to try N times and then discard the data after reaching that limit:

Retry example

The following example configures two outputs, where the HTTP plugin has an unlimited number of retries, and the Elasticsearch plugin have a limit of 5 retries:

The Exec Wasi input plugin lets you execute Wasm programs that are WASI targets like external programs and collect event logs from there.

Configuration parameters

The plugin supports the following configuration parameters:

Configuration examples

Here is a configuration example.

in_exec_wasi can handle parsers. To retrieve from structured data from a WASM program, you must create a parser.conf:

The Time_Format should be aligned for the format of your using timestamp.

This example assumes the WASM program writes JSON style strings to stdout.

Then, you can specify the parsers.conf in the main Fluent Bit configuration:

The Elasticsearch input plugin handles both Elasticsearch and OpenSearch Bulk API requests.

Configuration parameters

The plugin supports the following configuration parameters:

The Elasticsearch cluster uses "sniffing" to optimize the connections between its cluster and clients. Elasticsearch can build its cluster and dynamically generate a connection list which is called "sniffing". The hostname will be used for sniffing information and this is handled by the sniffing endpoint.

Get started

In order to start performing the checks, you can run the plugin from the command line or through the configuration file:

Command line

From the command line you can configure Fluent Bit to handle Bulk API requests with the following options:

Configuration file

In your configuration file append the following:

As described previously, the plugin will handle ingested Bulk API requests. For large bulk ingestion, you might have to increase buffer size using the buffer_max_size and buffer_chunk_size parameters:

Ingesting from beats series

Ingesting from beats series agents is also supported. For example, , , and are able to ingest their collected data through this plugin.

The Fluent Bit node information is returning as Elasticsearch 8.0.0.

Users must specify the following configurations on their beats configurations:

For large log ingestion on these beat plugins, users might have to configure rate limiting on those beats plugins when Fluent Bit indicates that the application is exceeding the size limit for HTTP requests:

The CPU input plugin, measures the CPU usage of a process or the whole system by default (considering per CPU core). It reports values in percentage unit for every interval of time set. This plugin is available only for Linux.

The following tables describe the information generated by the plugin. The following keys represent the data used by the overall system, and all values associated to the keys are in a percentage unit (0 to 100%):

The CPU metrics plugin creates metrics that are log-based, such as JSON payload. For Prometheus-based metrics, see the Node Exporter Metrics input plugin.

In addition to the keys reported in the previous table, a similar content is created per CPU core. The cores are listed from 0 to N as the Kernel reports:

Configuration parameters

The plugin supports the following configuration parameters:

Get started

In order to get the statistics of the CPU usage of your system, you can run the plugin from the command line or through the configuration file:

Command line

You can run this filter from the command line using a command like the following:

The command returns results similar to the following:

As described previously, the CPU input plugin gathers the overall usage every one second and flushed the information to the output on the fifth second. This example uses the stdout plugin to demonstrate the output records. In a real use-case you might want to flush this information to some central aggregator such as or .

Configuration file

In your main configuration file append the following:

The Disk input plugin gathers the information about the disk throughput of the running system every certain interval of time and reports them.

The Disk I/O metrics plugin creates metrics that are log-based, such as JSON payload. For Prometheus-based metrics, see the Node Exporter Metrics input plugin.

Configuration parameters

The plugin supports the following configuration parameters:

Get started

In order to get disk usage from your system, you can run the plugin from the command line or through the configuration file:

Command line

You can run the plugin from the command line:

Which returns information like the following:

Configuration file

In your main configuration file append the following:

Total interval (sec) = Interval_Sec + (Interval_Nsec / 1000000000)

For example: 1.5s = 1s + 500000000ns

The kmsg input plugin reads the Linux Kernel log buffer from the beginning. It gets every record and parses fields as priority, sequence, seconds, useconds, and message.

Configuration parameters

Get started

To start getting the Linux Kernel messages, you can run the plugin from the command line or through the configuration file:

Command line

Which returns output similar to:

As described previously, the plugin processed all messages that the Linux Kernel reported. The output has been truncated for clarification.

Configuration file

In your main configuration file append the following:

Configuration files must be flexible enough for any deployment need, but they must keep a clean and readable format.

Fluent Bit Commands extends a configuration file with specific built-in features. The following commands are available:

@INCLUDE

Configuring a logging pipeline might lead to an extensive configuration file. In order to maintain a human-readable configuration, split the configuration in multiple files.

The @INCLUDE command allows the configuration reader to include an external configuration file:

This example defines the main service configuration file and also includes two files to continue the configuration.

Fluent Bit will respects the following order when including:

• Service

• Inputs

• Filters

• Outputs

inputs.conf

The following is an example of an inputs.conf file, like the one called in the previous example.

outputs.conf

The following is an example of an outputs.conf file, like the one called in the previous example.

@SET

Fluent Bit supports . One way to expose this variables to Fluent Bit is through setting a shell environment variable, the other is through the @SET command.

The @SET command can only be used at root level of each line. It can't be used inside a section: