4 Inputs from Containers and Kubernetes

 

This chapter covers

  • Running different ways we can capture events from containerized apps
  • Investigating how we can observe containers and Kubernetes itself
  • Discussing deployment patterns and tools to power our monitoring.
  • Evaluating techniques for enriching the captured events to offer context to logs.

In the last chapter, we looked at a variety of input plugins that can be used in cloud native and traditional deployments. These inputs have provided insights into applications and the environments in which they are deployed, whether bare metal, virtual machine, or container. We haven’t considered until now how the software and infrastructure in which we deploy containers and orchestrate them with Kubernetes can be a source of signals (logs, metrics, and traces).

Let’s use our architecture diagram to orient ourselves. As Figure 4.1 shows, we’re still on the top layer of our diagram. This reflects the importance of the ability to ingest events. Without that, Fluent Bit’s value becomes rather limited.

Figure 4.1 Logical architecture of Fluent Bit, with this chapter's focus highlighted.

Containerized environments and container orchestration need us to consider several different perspectives:

4.1 Fluent Bit capturing Docker Events and Metrics

4.1.1 Docker Events

4.1.2 Docker Metrics

4.2 Using Podman as a Docker alternative

4.3 Container Log Drivers

4.4 Application Direct to Fluent Bit

4.4.1 OpenTelemetry’s approach to containerized applications

4.4.2 Deploying for application direct logging

4.4.3 Enriching log events with Pod context

4.5 Kubernetes and observability

4.5.1 Understanding Kubernetes' position on logging

4.5.2 The many parts of the Kubernetes ecosystem

4.5.3 Kubernetes events input

4.5.4 Container Images

4.5.5 Helm charts

4.6 Kubernetes Operator

4.6.1 Competing Operator Option

4.7 Observations on Fluent Bit with Kubernetes

4.7.1 The next possible frontier of observability with Fluent Bit - eBPF

4.8 Summary

sitemap