 In this video, we're going to talk about Fluent Bid, which is a LOX and Metrics processor tool. As you know, all applications need logging, and the main use case for logging is data analysis. Something breaks in the application, you check the LOX to see what caused the error, or you're trying to reproduce a bug, and by looking at the application LOX, you can understand what happened, or simply to have an overview of what your application is doing. LOX can come from different places. LOX are produced by applications, but also server processes, and so on. So you have different sources of LOX, and Fluent Bid is actually a general-purpose LOX processor, meaning it can read and process LOX from all these different sources. But note that in addition to collecting LOX, Fluent Bid also has Metrics collection capabilities for embedded Linux systems. For example, it can gather Metrics on CPU, memory, storage, etc. And because it's general purpose, Fluent Bid can be deployed on any environment, like bare metal servers, virtual machines, embedded devices, and containers. However, Fluent Bid is used the most for processing LOX in Kubernetes clusters. Now the challenge of logging in complex environments like Kubernetes is that you have many different applications which produce LOX in different formats. Each application is running in containers, which run in pods, which then run on Kubernetes nodes. So in addition to the LOX message and the application name itself, we have all this additional information about where the LOX is coming from. So if you have five replicas of the same application, you want to know which pod replica on which node produced this LOX. This means the challenge is to collect this data from different sources and then process it, like parse all the values and identify where they are coming from as well as what the actual LOX contents are. And parse them in key-value pairs so that they can eventually be stored in Elastic or Kafka, and finally we can see the LOX and do data analysis on them. So as you see, the LOX processor has a very important but also challenging job. Now, processing the data of course needs resources. The LOX processor needs enough memory, storage, and CPU resources to collect the LOX, then parse the LOX and filter them. And this should all be done as a background task, right? It shouldn't interfere with your main application's performance because then we have compromised the speed and performance of our application for a proper logging mechanism. And of course the requirement for resources increases when you have applications with high throughput, meaning producing high amounts of LOX. So as you see, the LOX processor not only needs to collect and process LOX, but it needs to do it in a performance and resource efficient way. So we need a lightweight and high-performance LOX processor. And one of the most popular ones today happens to be Fluentbit. So how does Fluentbit work? Fluentbit uses input plugins to read the LOX from the data sources. For example, if you need to read LOX files, you need a plugin to read from LOX files. If you're going to receive messages over TCP, you need an input plugin that listens for messages over TCP. And as mentioned at the beginning, Fluentbit supports many different input sources. Fluentbit also has input plugins for metrics data collection. For example, it supports StatsD and CollectD input plugins, but also supports collecting metrics on the host systems, CPU, memory and disk. Once LOX are collected and read, Fluentbit will process them. And of course, depending on the LOX format, we would need to parse them differently. For that, Fluentbit has different filters and parsers. Filters can be used to change the LOX record or even add some additional metadata to it, like pod ID or namespace where the LOX is coming from and so on. You can also use filters to drop or ignore some records. To make the filtering even more flexible, in Fluentbit you can use custom Lua scripts as filters to modify and process the records. In addition to all of this, one unique advanced feature that Fluentbit has is SQL stream processing. This allows users to write SQL queries on the LOX or metrics to do aggregations, calculations, even time series predictions. This is super useful if you need to calculate an average, max or min before sending the data to the storage or count the number of times a message appears or aggregate data to reduce data costs. The best part about the SQL stream processing is that no database is required and no indices are required. Everything runs on the same lightweight high-performance process. So you still keep that high-performance and resource efficiency of Fluentbit. After the LOX are processed, Fluentbit will send them to a storage like Elasticsearch or Splunk where you can then see the LOX in a nice visualized format. Again, Fluentbit supports many different storage backhands and to send the LOX to the storage backhands, Fluentbit uses output plugins. So basically, the input plugin knows how to transform the data of a specific format to what Fluentbit can read and process. So for example, TCP input plugin knows how to parse TCP data into Fluentbit data and output plugin knows how to transform the Fluentbit data into what the output target understands. So Elasticsearch output plugin knows how to translate the Fluentbit data into the format which Elasticsearch can read and save. And in Fluentbit you can send LOX from multiple input sources to multiple output destinations. You can do this log routing pretty easily using tags. You can add tags to LOX and then group them so that you can say parse all the LOX with a tag that starts with Apache with this parser or send all the LOX that match NGINX to Elasticsearch. Now how does Fluentbit actually run in a Kubernetes cluster? Fluentbit gets deployed as a demon set which means it will run on every Kubernetes node. So when a new node gets added to the cluster a Fluentbit pod will start there immediately. So on each node, Fluentbit will gather LOX from all the containers on that node. In addition it will gather metadata for those LOX like pod IP, container IP, namespace and so on from the Kubernetes API. A cool feature of Fluentbit is that we can suggest which parsers to be used on pods using annotations in Kubernetes configuration files. Some other advantages of Fluentbit are that it has a pluggable architecture. As a LOX collector it doesn't try to replace the data sources like systemd or journald. Instead the goal is to integrate with different data sources and to do that Fluentbit needs to be able to talk to TCP, read LOX from a file system, talk to systemd API etc. It also has built-in security because when you are sending LOX from the cluster out to the storage back-hands you are talking to third-party services outside your cluster. So of course you don't want your LOX to be sent in plain text. You want to use HTTPS or TLS for that connection. And it has a simple architecture which makes it easy to scale Fluentbit on hundreds of servers because as I mentioned Fluentbit will run on each node in the cluster. Now Fluentbit works in a very similar way as Fluentd which is another LOX processor from the same company. So if you know Fluentd you may be asking what is the difference between these two? If they work the same way which one should I use in which case? First of all Fluentbit is much more lightweight than Fluentd which means it's highly optimized for performance and low resource consumption compared to Fluentd. And as I mentioned at the beginning if you have a complex application setup which generates a lot of LOX you want your LOX collector to work efficiently. So Fluentbit is designed to run at high scale with low resource usage and it's actually the preferred solution for containerized environments. However Fluentbit follows the similar philosophy as Fluentd as a LOX processor but also as a Metrix processor. Fluentbit is actually a CNCF sub-project under the umbrella of Fluentd and also they're both vendor neutral so they can run on any environment regardless the platform. And also interesting to know that there are even use cases where you can use both Fluentbit and Fluentd together to create a very efficient and high performance LOX processing architecture for your environment. If you're interested in learning more about Fluentbit I recommend checking out the online resources and documentation of Fluentbit.