5 Outputting events

 

This chapter covers

  • Examining the common characteristics of output plugins
  • Generating logs for the console, files, and other local outputs
  • Storing logs and metrics with Prometheus and PostgreSQL
  • Forwarding signals to an OpenTelemetry or Fluent Bit node
  • Exploring other monitoring tools using HTTP and hyperscaler endpoints

We’ve explored capturing events (logs, traces, and metrics) from various sources, such as files, OS data, and network-based events, using OpenTelemetry and different plugins. Having captured these events, we need to put them somewhere so that the data can be visualized, analyzed, and communicated to those who need it, from SecOps to developers running regression tests. We should start this activity by understanding the components of Fluent Bit that are involved.

5.1 Architectural context

Figure 5.1 shows the part of the architecture we’ll be looking at in this chapter. Although it may look like we’re jumping a lot of steps, as with mastering any programming language, we start with I/O before mastering the clever constructs. But we will touch on some basic details, such as filters.

Figure 5.1 Fluent Bit architecture and which areas will be covered by this chapter
figure

5.2 Common characteristics of Fluent Bit output plugins

5.2.1 Output resilience through retries

5.2.2 Network controls

5.2.3 Worker threads

5.2.4 Considerations for using threads

5.3 Null output

5.3.1 Monitoring with Fluent Bit

5.3.2 Configuring null output

5.4 Sending log events to the console

5.4.1 Formatting outputs

5.4.2 Seeing matching at work

5.5 Writing to files

5.6 Prometheus outputs

5.6.1 Prometheus Node Exporter

Summary

sitemap