1 Introduction to Fluentd

Before getting into the details of Fluentd, we should first focus on the motivations for using a tool such as Fluentd. How can logging help us? What are log analytics, and why is log unification necessary? These are among the questions we will work to answer in this chapter. We’ll highlight the kinds of activities logging can help or enable us to achieve.

Let’s also take a step back and understand some contemporary thinking around how systems are measured and monitored; understanding these ideas will mean we can use our tools more effectively. After all, a tool is only as good as the user creating the configuration or generating log events to be used.

As we do this, it is worth exploring how Fluentd has evolved and understanding why it holds its position within the industry. If you are considering Fluentd as a possible tool or looking to make a case for its adoption, then it is helpful to understand its “origin story,” as this will inform how Fluentd may be perceived.

1.1 Elevator pitch for Fluentd

Given that you’re looking at this book, we presume you have at least heard of Fluentd and probably have a vague sense of what it is. Let’s start with the “elevator pitch” as to what Fluentd and Fluent Bit are.

1.1.1 What is a log event?

1.1.2 Fluentd compared to middleware

1.2 Why do we produce logs?

1.3 Evolving ideas

1.3.1 Four golden signals

1.3.2 Three pillars of observability

1.4 Log unification

1.4.1 Unifying logs vs. log analytics

1.5 Software stacks

1.5.1 ELK stack

1.5.2 Comparing Fluentd and Logstash