is an open source telemetry agent that processes logs, metrics, traces, and profiles. It's 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. It adapts and optimizes your existing logging layer, and adds metrics and traces processing. Fluent Bit supports a vendor-neutral approach, with native OpenTelemetry (OTLP) ingestion and delivery and seamless integration with ecosystems such as Prometheus. Trusted by major cloud providers, banks, and companies that need a ready-to-use telemetry agent, Fluent Bit effectively manages diverse data sources and formats. It maintains optimal performance while 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.

In 2014, the team at was forecasting the need for a lightweight log processor for constraint environments like embedded Linux and gateways. To meet this need, Eduardo Silva created Fluent Bit, a new open source solution and part of the Fluentd ecosystem.

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.

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.

Next step

After downloading Fluent Bit, install it using one of the following methods:

in normal operation mode is configurable through text 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.

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

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, called fluent-bit.conf, that contains the required , , and sections.

As an example, create a new fluent-bit.yaml file or fluent-bit.conf

Telemetry data processing can be complex, especially at scale. That's why was created. Fluentd is more than a basic tool. It's grown into a full-scale ecosystem that contains SDKs for different languages and sub-projects, like .

The Fluentd and Fluent Bit projects are both:

• Licensed under the terms of Apache License v2.0.

• Graduated hosted projects by the .

The includes section of YAML configuration files lets you specify additional YAML files to be merged into the current configuration. This lets you organize complex configurations into smaller, manageable files and include them as needed.

These files are identified as a list of filenames and can include relative or absolute paths. If a path isn't specified as absolute, it will be treated as relative to the file that includes it.

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

You can reference these files in fluent-bit.yaml as follows:

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

Input plugins gather information from different sources. Some plugins collect data from log files, and others gather metrics information from the operating system. There are many different plugins, and they let you handle many 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.

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:

Fluent Bit is started by the S99fluent-bit script.

Support

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

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:

• Standard: ${MY_VARIABLE}

• With Default Value: ${MY_VARIABLE:-default_value} (v5.0.6+)

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.

If the ${VARIABLE:-DEFAULT} syntax is used, Fluent Bit will use the DEFAULT value if the variable meets either of the following conditions:

1. The variable isn't defined (unset).

2. The variable is defined but set to an empty string ('').

Nesting isn't supported. You can't use the ${} syntax within another ${} definition. ${MY_VAR:-${OTHER_VAR}} would be invalid.

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 Raspberry Pi. 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:

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.

Now let your system update the apt database:

1. Ensure your is up to date.

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

3. 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

From CentOS 9 Stream and later, the CentOS dependencies will update more often than downstream usage. This might mean that incompatible (more recent) versions are provided of certain dependencies (for example, OpenSSL). For OSS, there are RockyLinux and AlmaLinux repositories. This might 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.

The fluent-bit package 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

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 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 1.1.x and later fully supports x86_64, x86, arm32v7, and arm64v8.

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:

service:
  http_server: on

[SERVICE]
  HTTP_Server  On
  HTTP_Listen  0.0.0.0
  HTTP_PORT    2020
  Hot_Reload   On

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:

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.

Hot reloading can be used with SIGHUP.

SIGHUP signal isn't supported on Windows.

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

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 the Fluent Bit docs or the Plugin repository.

• Amazon Kinesis Data Firehose as kinesis_firehose. See the Fluent Bit docs or the Plugin repository.

• Amazon Kinesis Data Streams as kinesis_streams. See the or the .

These plugins are higher performance than Go plugins.

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

AWS vends their container image using , and a set of highly available regional Amazon ECR repositories. For more information, see the .

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

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:

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

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

You can define custom multiline parsers in the multiline_parsers section of YAML configuration files.

Syntax

To define custom parsers in the multiline_parsers section of a YAML configuration file, use the following syntax:

multiline_parsers:
  - name: multiline-regex-test

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 information about supported configuration options for custom multiline parsers, see configuring multiline parsers.

Classic mode is a custom configuration model for Fluent Bit. It's more limited than the YAML configuration mode, and doesn't have the more extensive feature support the YAML configuration has. Classic mode basic design only supports grouping sections with key-value pairs and lacks the ability to handle sub-sections or complex data structures like lists.

Learn more about classic mode:

• Format and schema

• Variables

Fluent Bit 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
• : Expose internal metrics over HTTP in JSON and format

• : Perform data selection and transformation using basic 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

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

If you are upgrading from the Fluent Bit 4.2 series, start with and .

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

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.

Fluent Bit, including its core, plugins, and tools, is distributed under the terms of the .

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

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:

Each node in the upstream_servers group must specify a

You can define customer in the parsers section of YAML configuration files.

To define custom parsers in the parsers section of a YAML configuration file, use the following syntax.

For information about supported configuration options for custom parsers, see .

In addition to defining parsers in the parsers section of YAML configuration files, you can store parser definitions in standalone files. These standalone files require the same syntax as parsers defined in a standard YAML configuration file.

To add a standalone parsers file to Fluent Bit, use the parsers_file

To use these lab resources to their full extent, you'll need to resources in your local environment to test and run Fluent Bit.

One of the maintainers, , provides several , including a Fluent Bit workshop:

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 configure and 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, always run in the main thread, but run in the self-contained threads of their respective inputs or outputs, if applicable.

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.

In Fluent Bit v3.2 and later, YAML configuration files support all of the settings and features that support, plus additional features that classic configuration files don't support, like processors.

YAML configuration files support the following top-level sections:

• env: Configures .

• includes: Specifies additional YAML configuration files to

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 Ubuntu 26.04. Long-term support releases are also available for Noble Numbat (24.04) and Jammy Jellyfish (22.04).

The recommended secure deployment approach is to use the following instructions.

Add the Fluent Bit server GPG key to your keyring to ensure you can get the correct signed packages.

Follow the official .

On Ubuntu, you need to add the Fluent Bit APT server entry to your sources lists. Ensure codename is set to your specific . For example, focal for Ubuntu 20.04.

Update your source's list:

Update the

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:

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.

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

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

To view indexed logs, run the following command:

To reset your index, run the following command:

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.

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 might 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:

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

The release of Fluent Bit v4.1.0 introduced new performance improvements for JSON encoding using Single Instruction, Multiple Data (SIMD). Plugins that convert logs from the Fluent Bit internal binary representation to JSON can now do so 2.5 times (read) faster. Powered by the

The Fluent Bit data pipeline incorporates several specific concepts. Data processing flows through the pipeline following these concepts in order.

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

are components that modify, transform, or enhance data as it flows through the pipeline. Processors are attached directly to individual input or output plugins rather than defined globally, and they don't use tag matching.

Because processors run in the same thread as their associated plugin, they can reduce performance overhead compared to filters—especially when is enabled.

Processors are configured in only.

convert unstructured data to structured data. Use a parser to set a structure to the incoming data by using input plugins as data is collected.

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

In addition to the plugins that come bundled with Fluent Bit, you can load external plugins. Use this feature for loading Go or WebAssembly (Wasm) plugins that are built as shared object files (.so).

You can specify external plugins in the plugins section of YAML configuration files. For example:

Additionally, you can define external plugins in a separate YAML file, then reference that file in the plugins_file key nested under the of your YAML configuration file. For example:

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

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

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

Fluent Bit uses configuration files to store information about your specified , , , and more. You can write these configuration files in one of these formats:

• are the standard configuration format as of Fluent Bit v3.2. They use the .yaml file extension.

• will be deprecated at the end of 2026. They use the .conf file extension.

Some configuration settings in Fluent Bit use standardized unit sizes to define data and storage limits. For example, the

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

The following architectures are supported

• x86_64

• aarch64

Fluent Bit is compatible with most x86-based, x86_64-based, arm32v7-based, and arm64v8-based systems.

You can . There are also platform-specific guides for building Fluent Bit from source on and .

To install Fluent Bit from one of the available packages, use the installation method for your chosen platform.

Fluent Bit is available for the following container deployments:

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

The plugin supports the following configuration parameters:

The Kernel logs (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.

The plugin supports the following configuration parameters:

The dead letter queue preserves that Fluent Bit fails to deliver to output destinations. Instead of losing this data, Fluent Bit copies the rejected chunks to a dedicated storage location for future analysis and troubleshooting.

To enable the dead letter queue, filesystem storage must be enabled by setting a value for , and must be set to on.

Chunks are copied to the dead letter queue in the following failure scenarios:

• Permanent errors: When an output plugin returns an unrecoverable error (FLB_ERROR).

The Fluent Bit logs input plugin routes Fluent Bit internal log output into the pipeline as structured log records. Each record contains a level field and a message field, which lets you ship, filter, or store Fluent Bit internal diagnostic output using the same pipeline you use for all other data.

This plugin is event-driven: records are delivered immediately as the internal logger emits them, not on a polling interval. Fluent Bit enables internal log mirroring automatically when this input is configured.

Each record contains the following fields:

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.

The plugin supports the following configuration parameters:

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 .

This plugin supports the following configuration parameters:

The Random input plugin generates random value samples using the device interface /dev/urandom. If that interface is unavailable, it uses a Unix timestamp as a value.

The plugin supports the following configuration parameters:

Fluent Bit is available for a variety of Linux distributions and embedded Linux systems.

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.

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.

For version 1.9 and later,

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

• x86_64

• aarch64 / arm64v8

To install Fluent Bit and related AWS output plugins on Amazon Linux 2 on EC2 using AWS Systems Manager, follow .

To install Fluent Bit on any Amazon Linux instance, follow these steps.

Before diving into Fluent Bit 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 Fluent Bit terminology. Reading this document will help you gain a more general understanding of the following topics:

• Event or Record

• Filtering

• Processor

• Tag

• Timestamp

• Match

• Structured Message

Every incoming piece of data that belongs to a log, metric, trace, or profile 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

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.

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.

modify, transform, or enhance data as it moves through the pipeline. Unlike filters, processors are attached directly to individual input or output plugins and don't use tag matching. Each processor operates only on data from its associated plugin.

Processors run in the same thread as their associated plugin, which improves throughput compared to filters—especially when is enabled.

Processors are supported in only, and can act on logs, metrics, traces, and profiles.

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 .

The timestamp represents the time an Event was created. Every Event contains an associated timestamp. 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.

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 .

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 .

The Collectd input plugin lets you receive datagrams from the collectd service over UDP. The plugin listens for collectd network protocol packets and converts them into Fluent Bit records.

Configuration parameters

The plugin supports the following configuration parameters:

To receive collectd datagrams, you can run the plugin from the command line or through the configuration file.

From the command line you can let Fluent Bit listen for collectd datagrams with the following options:

By default, the service listens on all interfaces (0.0.0.0) using UDP port 25826. You can change this directly:

In this example, collectd datagrams will only arrive through the network interface at 192.168.3.2 address and UDP port 9090.

In your main configuration file append the following:

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.

The typesdb parameter supports multiple files separated by commas. When multiple files are specified, later entries take precedence over earlier ones if there are duplicate type definitions. This lets you override default types with custom definitions.

For example:

In this configuration, custom type definitions in /etc/collectd/custom.db override any matching definitions from /usr/share/collectd/types.db.

The Health input plugin lets you check how healthy a TCP server is. It checks by issuing a TCP connection at regular intervals.

Configuration parameters

The plugin supports the following configuration parameters:

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

From the command line you can let Fluent Bit generate the checks with the following options:

In your main configuration file append the following:

Once Fluent Bit is running, you will see health check results in the output interface similar to this:

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.

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:

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.

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 section and can be added to the any Node section.

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.

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.

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

• Environment variables

• Shared configuration and credentials files

• EKS Web Identity Token (OIDC)

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.

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

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.

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

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

Credentials are fetched using a pod identity endpoint. See .

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.

Fluent Bit fetches credentials from a localhost endpoint provided by the AWS IoT Greengrass token exchange service. The token exchange service runs as a local server on Greengrass core devices and provides AWS credentials through the AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN environment variables. For more information, see the AWS documentation about .

The Process metrics input plugin lets you check how healthy a process is. It does so by performing service checks at specified intervals.

This plugin creates metrics that are log-based, such as JSON payloads. For Prometheus-based metrics, see the Node exporter metrics input plugin.

Configuration parameters

The plugin supports the following configuration parameters:

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

The following example checks the health of crond process.

In your main configuration file, append the following sections:

After Fluent Bit starts running, it outputs the health of the process:

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

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 SCHEME://USER:PASS@HOST:PORT, where:

• SCHEME is either http or https

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

Fluent Bit supports the following architectures:

• x86_64

• aarch64

The env section of YAML configuration files lets you define environment variables. These variables can then be used to dynamically replace values throughout your configuration using the ${VARIABLE_NAME} syntax. The env section supports two forms: a map form for static key-value pairs and an extended list form for advanced use cases like file-backed secrets with automatic refresh.

Values set in the env section are case-sensitive. However, as a best practice, Fluent Bit recommends using uppercase names for environment variables.

The map form defines variables as key-value pairs. The following example defines two variables, FLUSH_INTERVAL and STDOUT_FMT, which can be accessed in the configuration using ${FLUSH_INTERVAL}

The Network I/O metrics (netif) input plugin gathers network traffic information of the running system at regular intervals, and reports them. This plugin is available only for Linux.

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

The following table describes the metrics generated by the plugin. Metric names are prefixed with the interface name (for example, eth0):

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

Installation packages can be found .

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

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

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

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

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

The plugin supports the following configuration parameters:

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.

The Dummy input plugin generates dummy events. Use this plugin for testing, debugging, benchmarking and getting started with Fluent Bit.

The plugin supports the following configuration parameters:

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.

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

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

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 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:

The MQTT input plugin retrieves messages and data from MQTT control packets over a TCP connection. The incoming data to receive must be a JSON map.

The plugin supports the following configuration parameters: