Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
High Performance Telemetry Agent for Logs, Metrics and Traces
High Performance: High throughput with low resources consumption
Metrics Support: Prometheus and OpenTelemetry compatible
Reliability and Data Integrity
Backpressure Handling
Data Buffering in memory and file system
Networking
Security: built-in TLS/SSL support
Asynchronous I/O
Pluggable Architecture and Extensibility: Inputs, Filters and Outputs
More than 100 built-in plugins are available
Extensibility
Write any input, filter or output plugin in C language
WASM: WASM Filter Plugins or WASM Input Plugins
Bonus: write Filters in Lua or Output plugins in Golang
Monitoring: expose internal metrics over HTTP in JSON and Prometheus format
Stream Processing: Perform data selection and transformation using simple SQL queries
Create new streams of data using query results
Aggregation Windows
Data analysis and prediction: Timeseries forecasting
Portable: runs on Linux, macOS, Windows and BSD systems
Fluent Bit is a CNCF graduated sub-project under the umbrella of Fluentd. Fluent Bit is licensed under the terms of the Apache License v2.0.
Fluent Bit was originally created by Eduardo Silva. As a CNCF-hosted project, it is a fully vendor-neutral and community-driven project.
The Production Grade Telemetry Ecosystem
Telemetry data processing in general can be complex, and at scale a bit more, that's why Fluentd was born. Fluentd has become more than a simple tool, it has grown into a fullscale ecosystem that contains SDKs for different languages and sub-projects like Fluent Bit.
On this page, we will describe the relationship between the Fluentd and Fluent Bit open source projects, as a summary we can say both are:
Licensed under the terms of Apache License v2.0
Graduated Hosted projects by the Cloud Native Computing Foundation (CNCF)
Production Grade solutions: deployed million of times every single day.
Vendor neutral and community driven projects
Widely Adopted by the Industry: trusted by all major companies like AWS, Microsoft, Google Cloud and hundreds of others.
Both projects share a lot of similarities, Fluent Bit is fully designed and built on top of the best ideas of Fluentd architecture and general design. Choosing which one to use depends on the end-user needs.
The following table describes a comparison of different areas of the projects:
Both Fluentd and Fluent Bit can work as Aggregators or Forwarders, they both can complement each other or use them as standalone solutions. In the recent years, Cloud Providers switched from Fluentd to Fluent Bit for performance and compatibility reasons. Fluent Bit is now considered the next generation solution.
Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
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, as well as metrics and traces processing. Furthermore, 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.
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.
Fluent Bit is a Fast and Lightweight Telemetry Agent for Logs, Metrics, and Traces for Linux, macOS, Windows, and BSD family operating systems. It has been made with a strong focus on performance to allow the collection and processing of telemetry data from different sources without complexity.
Scope
Containers / Servers
Embedded Linux / Containers / Servers
Language
C & Ruby
C
Memory
> 60MB
~1MB
Performance
Medium Performance
High Performance
Dependencies
Built as a Ruby Gem, it requires a certain number of gems.
Zero dependencies, unless some special plugin requires them.
Plugins
More than 1000 external plugins are available
More than 100 built-in plugins are available
License
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.
has been designed with performance and low resource consumption in mind.
Every project has a story
On 2014, the Fluentd team at Treasure Data 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 created Fluent Bit, a new open source solution written from scratch available under the terms of the Apache License v2.0.\
After the project was around for some time, it got more traction for normal Linux systems, also with the new containerized world, the Cloud Native community asked to extend the project scope to support more sources, filters, and destinations. Not so long after, Fluent Bit became one of the preferred solutions to solve the logging challenges in Cloud environments.
Performance and Data Safety
When Fluent Bit processes data, it uses the system memory (heap) as a primary and temporary place to store the record logs before they get delivered, in this private memory area the records are processed.
Buffering refers to the ability to store the records somewhere, and while they are processed and delivered, still be able to store more. Buffering in memory is the fastest mechanism, but there are certain scenarios where it requires special strategies to deal with backpressure, data safety or reduce memory consumption by the service in constrained environments.
Network failures or latency on third party service is pretty common, and on scenarios where we cannot deliver data fast enough as we receive new data to process, we likely will face backpressure.
Our buffering strategies are designed to solve problems associated with backpressure and general delivery failures.
Fluent Bit as buffering strategies go, offers a primary buffering mechanism in memory and an optional secondary one using the file system. With this hybrid solution you can accommodate any use case safely and keep a high performance while processing your data.
Both mechanisms are not mutually exclusive and when the data is ready to be processed or delivered it will always be in memory, while other data in the queue might be in the file system until is ready to be processed and moved up to memory.
To learn more about the buffering configuration in Fluent Bit, please jump to the Buffering & Storage section.
The way to gather data from your sources
Fluent Bit provides different Input Plugins to gather information from different sources, some of them just collect data from log files while others can gather metrics information from the operating system. There are many plugins for different needs.
When an input plugin is loaded, an internal instance is created. Every instance has its own and independent configuration. Configuration keys are often called properties.
Every input plugin has its own documentation section where it's specified how it can be used and what properties are available.
For more details, please refer to the Input Plugins section.
Modify, Enrich or Drop your records
In production environments we want to have full control of the data we are collecting, filtering is an important feature that allows us to alter the data before delivering it to some destination.
Filtering is implemented through plugins, so each filter available could be used to match, exclude or enrich your logs with some specific metadata.
We support many filters, A common use case for filtering is Kubernetes deployments. Every Pod log needs to get the proper metadata associated
Very similar to the 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, please refer to the Filters section.
Create flexible routing rules
There are two important concepts in Routing:
Tag
Match
When the data is generated by the input plugins, it comes with a Tag (most of the time the Tag is configured manually), the Tag is a human-readable indicator that helps to identify the data source.
In order to define where the data should be routed, a Match rule must be specified in the output configuration.
Consider the following configuration example that aims to deliver CPU metrics to an Elasticsearch database and Memory metrics to the standard output interface:
Note: the above is a simple example demonstrating how Routing is configured.
Routing works automatically reading the Input Tags and the Output Match rules. If some data has a Tag that doesn't match upon routing time, the data is deleted.
Routing is flexible enough to support wildcard in the Match pattern. The below example defines a common destination for both sources of data:
The match rule is set to my_* which means it will match any Tag that starts with my_.
Routing is a core feature that allows to route your data through Filters and finally to one or multiple destinations. The router relies on the concept of and rules
Destinations for your data: databases, cloud services and more!
The output interface allows us to define destinations for the data. Common destinations are remote services, local file system or standard interface with others. Outputs are implemented as plugins and there are many available.
When an output plugin is loaded, an internal instance is created. Every instance has its own independent configuration. Configuration keys are often called properties.
Every output plugin has its own documentation section specifying how it can be used and what properties are available.
For more details, please refer to the Output Plugins section.
The most secure option is to create the repositories acccording to the instructions for your specific OS.
A simple installation script is provided to be used for most Linux targets. This will by default install the most recent version released.
This is purely a convenience helper and should always be validated prior to use.
From the 1.9.0 and 1.8.15 releases please note that the GPG key has been updated at https://packages.fluentbit.io/fluentbit.key so ensure this new one is added.
The GPG Key fingerprint of the new key is:
The previous key is still available at https://packages.fluentbit.io/fluentbit-legacy.key and may be required to install previous versions.
The GPG Key fingerprint of the old key is:
Refer to the supported platform documentation to see which platforms are supported in each release.
From version 1.9, td-agent-bit
is a deprecated package and is removed after 1.9.9. The correct package name to use now is fluent-bit
.
The following operating systems and architectures are supported in Fluent Bit.
Linux
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64, Arm64v8
x86_64
Arm32v7
Arm32v7
macOS
*
x86_64, Apple M1
Windows
x86_64, x86
x86_64, x86
From an architecture support perspective, Fluent Bit is fully functional on x86_64, Arm64v8 and Arm32v7 based processors.
Fluent Bit can work also on OSX and *BSD systems, but not all plugins will be available on all platforms. Official support will be expanding based on community demand. Fluent Bit may run on older operating systems though will need to be built from source, or use custom packages from enterprise providers.
Fluent Bit is distributed as fluent-bit package and is available for the latest stable Ubuntu system: Jammy Jellyfish.
A simple installation script is provided to be used 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 follow the instructions below.
The first step is to add our server GPG key to your keyring to ensure you can get our signed packages. Follow the official Debian wiki guidance: https://wiki.debian.org/DebianRepository/UseThirdParty#OpenPGP\_Key\_distribution
From the 1.9.0 and 1.8.15 releases please note that the GPG key has been updated at https://packages.fluentbit.io/fluentbit.key so ensure this new one is added.
The GPG Key fingerprint of the new key is:
The previous key is still available at https://packages.fluentbit.io/fluentbit-legacy.key and may be required to install previous versions.
The GPG Key fingerprint of the old key is:
Refer to the supported platform documentation to see which platforms are supported in each release.
On Ubuntu, you need to add our APT server entry to your sources lists, please add the following content at bottom of your /etc/apt/sources.list file - ensure to set CODENAME
to your specific Ubuntu release name (e.g. focal
for Ubuntu 20.04):
Now let your system update the apt database:
We recommend upgrading your system (sudo apt-get upgrade
). This could avoid potential issues with expired certificates.
If you have the following error "Certificate verification failed", you might want to check if the package ca-certificates
is properly installed (sudo apt-get install ca-certificates
).
Using the following apt-get command you are able now to install the latest fluent-bit:
Now the following step is to 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.
Fluent Bit is distributed as 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
A simple installation script is provided to be used 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 follow the instructions below.
Amazon Linux 2022 was previously supported but is removed since it became GA Amazon Linux 2023
We provide fluent-bit through a Yum repository. In order to add the repository reference to your system, please add a new file called fluent-bit.repo in /etc/yum.repos.d/ with the following content:
Note: we encourage you always enable the gpgcheck for security reasons. All our packages are signed.
From the 1.9.0 and 1.8.15 releases please note that the GPG key has been updated at https://packages.fluentbit.io/fluentbit.key so ensure this new one is added.
The GPG Key fingerprint of the new key is:
The previous key is still available at https://packages.fluentbit.io/fluentbit-legacy.key and may be required to install previous versions.
The GPG Key fingerprint of the old key is:
Refer to the supported platform documentation to see which platforms are supported in each release.
Once your repository is configured, run the following command to install it:
Now the following step is to 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/messages file.
Strong Commitment to the Openness and Collaboration
Fluent Bit, including its core, plugins and tools are distributed under the terms of the Apache License v2.0:
Compiler: GCC or clang
CMake
Flex & Bison: only if you enable the Stream Processor or Record Accessor feature (both enabled by default)
Libyaml development headers and libraries
In the core there are not other dependencies, For certain features that depends on third party components like output plugins with special backend libraries (e.g: kafka), those are included in the main source code repository.
Fluent Bit is distributed as fluent-bit package and is available for the latest (and legacy) stable Debian systems: Bookworm and Bullseye. The following architectures are supported
x86_64
aarch64 / arm64v8
A simple installation script is provided to be used 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 follow the instructions below.
The GPG Key fingerprint of the new key is:
The GPG Key fingerprint of the old key is:
Now let your system update the apt database:
We recommend upgrading your system (sudo apt-get upgrade
). This could avoid potential issues with expired certificates.
Using the following apt-get command you are able now to install the latest fluent-bit:
Now the following step is to 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.
Fluent Bit container images are available on Docker Hub ready for production usage. Current available images can be deployed in multiple architectures.
Get started by simply typing the following command:
It is strongly suggested that you always use the latest image of Fluent Bit.
Windows container images are provided from v2.0.6 for Windows Server 2019 and Windows Server 2022. These can be found as tags on the same Docker Hub registry above.
From a deployment perspective, there is no need to specify an architecture, the container client tool that pulls the image gets the proper layer for the running architecture.
Note: replace cosign
above with the binary installed if it has a different name (e.g. cosign-linux-amd64
).
Keyless signing is also provided but this is still experimental:
Download the last stable image from 2.0 series:
Once the image is in place, now run the following (useless) test which makes Fluent Bit measure CPU usage by the container:
That command will let Fluent Bit measure CPU usage every second and flush the results to the standard output, e.g:
Alpine Linux uses Musl C library instead of Glibc. Musl is not fully compatible with Glibc which generated many issues in the following areas when used with Fluent Bit:
Memory Allocator: to run Fluent Bit properly in high-load environments, we use Jemalloc as a default memory allocator which reduce fragmentation and provides better performance for our needs. Jemalloc cannot run smoothly with Musl and requires extra work.
Alpine Linux Musl functions bootstrap have a compatibility issue when loading Golang shared libraries, this generate problems when trying to load Golang output plugins in Fluent Bit.
Alpine Linux Musl Time format parser does not support Glibc extensions
Maintainers preference in terms of base image due to security and maintenance reasons are Distroless and Debian.
Only include what you need, reduce the attack surface available.
Reduces size so improves perfomance as well.
Reduces false positives on scans (and reduces resources required for scanning).
Reduces supply chain security requirements to just what you need.
Helps prevent unauthorised processes or users interacting with the container.
Less need to harden the container (and container runtime, K8S, etc.).
Faster CICD processes.
With any choice of course there are downsides:
No shell or package manager to update/add things.
Generally though dynamic updating is a bad idea in containers as the time it is done affects the outcome: two containers started at different times using the same base image may perform differently or get different dependencies, etc.
A better approach is to rebuild a new image version but then you can do this with Distroless, however it is harder requiring multistage builds or similar to provide the new dependencies.
Debugging can be harder.
More specifically you need applications set up to properly expose information for debugging rather than rely on traditional debug approaches of connecting to processes or dumping memory. This can be an upfront cost vs a runtime cost but does shift left in the development process so hopefully is a reduction overall.
Assumption that Distroless is secure: nothing is secure (just more or less secure) and there are still exploits so it does not remove the need for securing your system.
Sometimes you need to use a common base image, e.g. with audit/security/health/etc. hooks integrated, or common base tooling (this could still be Distroless though).
One other important thing to note is that exec
'ing into a container will potentially impact resource limits.
This can be a quite different container from the one you want to investigate (e.g. lots of extra tools or even a different base).
No resource limits applied to this container - can be good or bad.
Runs in pod namespaces, just another container that can access everything the others can.
May need architecture of the pod to share volumes, etc.
Requires more recent versions of K8S and the container runtime plus RBAC allowing it.
The following article cover the relevant notes for users upgrading from previous Fluent Bit versions. We aim to cover compatibility changes that you must be aware of.
Note: release notes will be prepared in advance of a Git tag for a release so 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 overall binary release process so release binaries (containers/packages) will appear after a tag and its associated release note. This allows users to expect the new release binary to appear and allow/deny/update it as appropriate in their infrastructure.
The td-agent-bit
package is no longer provided after this release. Users should switch to the fluent-bit
package.
If you are migrating from previous version of Fluent Bit please review the following important changes:
Now by default the plugin follows a file from the end once the service starts (old behavior was always read from the beginning). For every file found at start, its followed from it last position, for new files discovered at runtime or rotated, they are read from the beginning.
If you desire to keep the old behavior you can set the option read_from_head
to true.
If you have any existing queries based on the resource's project_id, please update your query accordingly.
The migration from v1.4 to v1.5 is pretty straightforward.
If you are migrating from Fluent Bit v1.3, there are no breaking changes. Just new exciting features to enjoy :)
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 please review the incremental changes below.
On Fluent Bit v1.2 we have fixed many issues associated with JSON encoding and decoding, for hence when parsing Docker logs is no longer necessary to use decoders. The new Docker parser looks like this:
Note: again, do not use decoders.
We have done improvements also on how Kubernetes Filter handle the stringified log message. If the option Merge_Log 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, we have fixed and improved the option called Merge_Log_Key. If a merge log succeed, all new keys will be packaged under the key specified by this option, a suggested configuration is as follows:
As an example, if the original log content is the following map:
the final record will be composed as follows:
If you are upgrading from Fluent Bit <= 1.0.x you should take in consideration the following relevant changes when switching to Fluent Bit v1.1 series:
We introduced a new configuration property called Kube_Tag_Prefix to help Tag prefix resolution and address an unexpected behavior that landed in previous versions.
During 1.0.x release cycle, a commit in 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:
The expected behavior is that Tag will be expanded to:
but the change introduced in 1.0 series switched from absolute path to the base file name only:
On Fluent Bit v1.1 release we restored to our 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. As you know when the filter is used it needs to perform local metadata lookup that comes from the file names when using Tail as a source. Now with the new Kube_Tag_Prefix option you can specify what's the prefix used in Tail input plugin, for the configuration example above the new configuration will look as follows:
So the proper for Kube_Tag_Prefix value must be composed by Tag prefix set in Tail input plugin plus the converted monitored directory replacing slashes with dots.
uses very low CPU and Memory consumption, it's compatible with most of x86, x86_64, arm32v7 and arm64v8 based platforms. In order to build it you need the following components in your system for the build process:
The first step is to add our server GPG key to your keyring, on that way you can get our signed packages. Follow the official Debian wiki guidance:
From the 1.9.0 and 1.8.15 releases please note that the GPG key has been updated at so ensure this new one is added.
The previous key is still available at and may be required to install previous versions.
Refer to the to see which platforms are supported in each release.
On Debian, you need to add our APT server entry to your sources lists, please add the following content at bottom of your /etc/apt/sources.list file - ensure to set CODENAME
to your specific (e.g. bookworm
for Debian 12):
The following table describes the Linux container tags that are available on Docker Hub repository:
Our production stable images are based on focusing on security containing just the Fluent Bit binary and minimal system libraries and basic configuration. We also provide debug images for all architectures (from 1.9.0+) which contain a full (Debian) shell and package manager that can be used to troubleshoot or for testing purposes.
1.9 and 2.0 container images are signed using Cosign/Sigstore. These signatures can be verified using cosign
():
Note: COSIGN_EXPERIMENTAL=1
is used to allow verification of images signed in KEYLESS mode. To learn more about keyless signing, please refer to .
Briefly tackled in a which links out to the following possibly opposing views:
The reasons for using Distroless are fairly well covered here:
For debugging, debug containers are available now in K8S:
For more details about changes on each release please refer to the .
The project_id of in 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 for more details.
If you enabled keepalive
mode in your configuration, note that this configuration property 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 section.
If you use the Elasticsearch output plugin, note the default value of type
. Many versions of Elasticsearch will tolerate this, but ES v5.6 through v6.1 require a type without a leading underscore. See the for more.
2.1.10-debug
x86_64, arm64v8, arm32v7
Debug images
2.1.10
x86_64, arm64v8, arm32v7
Release v2.1.10
2.1.9-debug
x86_64, arm64v8, arm32v7
Debug images
2.1.9
x86_64, arm64v8, arm32v7
Release v2.1.9
2.1.8-debug
x86_64, arm64v8, arm32v7
Debug images
2.1.8
x86_64, arm64v8, arm32v7
Release v2.1.8
2.1.7-debug
x86_64, arm64v8, arm32v7
Debug images
2.1.7
x86_64, arm64v8, arm32v7
Release v2.1.7
2.1.6-debug
x86_64, arm64v8, arm32v7
Debug images
2.1.6
x86_64, arm64v8, arm32v7
Release v2.1.6
2.1.5
x86_64, arm64v8, arm32v7
Release v2.1.5
2.1.5-debug
x86_64, arm64v8, arm32v7
Debug images
2.1.4
x86_64, arm64v8, arm32v7
Release v2.1.4
2.1.4-debug
x86_64, arm64v8, arm32v7
Debug images
2.1.3
x86_64, arm64v8, arm32v7
Release v2.1.3
2.1.3-debug
x86_64, arm64v8, arm32v7
Debug images
2.1.2
x86_64, arm64v8, arm32v7
Release v2.1.2
2.1.2-debug
x86_64, arm64v8, arm32v7
Debug images
2.1.1
x86_64, arm64v8, arm32v7
Release v2.1.1
2.1.1-debug
x86_64, arm64v8, arm32v7
v2.1.x releases (production + debug)
2.1.0
x86_64, arm64v8, arm32v7
Release v2.1.0
2.1.0-debug
x86_64, arm64v8, arm32v7
v2.1.x releases (production + debug)
2.0.11
x86_64, arm64v8, arm32v7
Release v2.0.11
2.0.11-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.10
x86_64, arm64v8, arm32v7
Release v2.0.10
2.0.10-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.9
x86_64, arm64v8, arm32v7
Release v2.0.9
2.0.9-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.8
x86_64, arm64v8, arm32v7
Release v2.0.8
2.0.8-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.6
x86_64, arm64v8, arm32v7
Release v2.0.6
2.0.6-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.5
x86_64, arm64v8, arm32v7
Release v2.0.5
2.0.5-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.4
x86_64, arm64v8, arm32v7
Release v2.0.4
2.0.4-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.3
x86_64, arm64v8, arm32v7
Release v2.0.3
2.0.3-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.2
x86_64, arm64v8, arm32v7
Release v2.0.2
2.0.2-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.1
x86_64, arm64v8, arm32v7
Release v2.0.1
2.0.1-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
2.0.0
x86_64, arm64v8, arm32v7
Release v2.0.0
2.0.0-debug
x86_64, arm64v8, arm32v7
v2.0.x releases (production + debug)
1.9.9
x86_64, arm64v8, arm32v7
Release v1.9.9
1.9.9-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
1.9.8
x86_64, arm64v8, arm32v7
Release v1.9.8
1.9.8-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
1.9.7
x86_64, arm64v8, arm32v7
Release v1.9.7
1.9.7-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
1.9.6
x86_64, arm64v8, arm32v7
Release v1.9.6
1.9.6-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
1.9.5
x86_64, arm64v8, arm32v7
Release v1.9.5
1.9.5-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
1.9.4
x86_64, arm64v8, arm32v7
Release v1.9.4
1.9.4-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
1.9.3
x86_64, arm64v8, arm32v7
Release v1.9.3
1.9.3-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
1.9.2
x86_64, arm64v8, arm32v7
Release v1.9.2
1.9.2-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
1.9.1
x86_64, arm64v8, arm32v7
Release v1.9.1
1.9.1-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
1.9.0
x86_64, arm64v8, arm32v7
Release v1.9.0
1.9.0-debug
x86_64, arm64v8, arm32v7
v1.9.x releases (production + debug)
Fluent Bit is compatible with latest Apple macOS system on x86_64 and Apple Silicon M1 architectures. At the moment there is only an official supported package on x86_64 but you can build it from source as well by following the instructions below.
The packages can be found here: https://packages.fluentbit.io/macos/
For the next steps, you will need to have Homebrew installed in your system. If is not there, you can install it with the following command:
The Fluent Bit package on Homebrew is not 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:
Grab a fresh copy of the Fluent Bit source code (upstream):
Optionally, if you want to use a specific version, just checkout to the proper tag. If you want to use v1.8.13
just do:
In order to prepare the build system, we need to expose certain environment variables so Fluent Bit CMake build rules can pick the right libraries:
Change to the build/ directory inside the Fluent Bit sources:
Build Fluent Bit. Note that we are indicating to the build system "where" the final binaries and config files should be installed:
Install Fluent Bit to the directory specified above. Note that this requires root privileges due to the directory we will write information to:
The binaries and configuration examples can be located at /opt/fluent-bit/
.
Grab a fresh copy of the Fluent Bit source code (upstream):
Optionally, if you want to use a specific version, just checkout to the proper tag. If you want to use v1.9.2
just do:
In order to prepare the build system, we need to expose certain environment variables so Fluent Bit CMake build rules can pick the right libraries:
And then, creating the specific macOS SDK target (For example, specifying macOS Big Sur (11.3) SDK environment):
Change to the build/ directory inside the Fluent Bit sources:
Build the Fluent Bit macOS installer.
Then, macOS installer will be generated as:
Finally, fluent-bit-<fluent-bit version>
-(intel or apple)
.pkg will be generated.
The created installer will put binaries at /opt/fluent-bit/
.
To make the access path easier to Fluent Bit binary, in your terminal extend the PATH
variable:
Now as a simple test, try Fluent Bit by generating a simple dummy message which will be printed to the standard output interface every 1 second:
You will see an output similar to this:
To halt the process, press ctrl-c
in the terminal.
Currently, Fluent Bit supports two configuration formats:
Yaml. (YAML configuration is production ready since Fluent Bit 2.0.)
Fluent Bit also supports a CLI interface with various flags matching up to the configuration options available.
AWS maintains a distribution of Fluent Bit combining 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.
Currently, the AWS for Fluent Bit image contains Go Plugins for:
Fluent Bit includes Amazon CloudWatch Logs plugin named cloudwatch_logs
, Amazon Kinesis Firehose plugin named kinesis_firehose
and Amazon Kinesis Data Streams plugin named kinesis_streams
which are higher performance than Go plugins.
Also, Fluent Bit includes S3 output plugin named s3
.
AWS vends their container image via Docker Hub, and a set of highly available regional Amazon ECR repositories. For more information, see the AWS for Fluent Bit GitHub repo.
The AWS for Fluent Bit image uses a custom versioning scheme because it contains multiple projects. To see what each release contains, check out the release notes on GitHub.
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: