Fluentd Fluentd

Fluentd 与 Fluent Bit:选择合适的日志处理器

同样的插件模型、同样的标签系统,资源占用却大不相同 —— 何时用哪个,何时两个一起用。

9 min 中级

Fluentd 有一个更轻量的兄弟:Fluent Bit,由 Fluentd 团队的一名成员创建,专门用于 Fluentd 的资源占用过重的环境。两者都是 Fluent 旗下的 CNCF 毕业项目,并且都遵循本系列其他地方所介绍的同样的输入/过滤/输出、基于标签的架构。本指南介绍两者实际的区别,以及同时使用两者的架构。

核心权衡:占用 vs 生态

FluentdFluent Bit
语言Ruby,对性能敏感的部分用 CC
典型内存占用几十 MB数百 KB 量级
插件生态庞大;有范围广泛的成熟输入/过滤/输出插件较小,但相当可观且在增长;超过 100 个内置插件
最适合集中聚合、较重的处理高吞吐量收集、边缘和资源受限环境

Fluent Bit 纯 C 的实现和极少的依赖,使它的占用小到可以在真正的边缘规模上运行:嵌入式 Linux 设备、IoT 硬件,以及任何不适合运行一个数十 MB 的 Ruby 进程的地方。Fluentd 较大的占用换来了相应更庞大、更成熟的插件生态,当你要做较重的转换,或写入不太常见的目的地时,这一点更为重要。

相同的架构,不同的实现

两个工具都围绕本系列所介绍的相同概念构建:输入插件定义 source,过滤插件在传输途中转换数据,输出插件定义目的地,标签在它们之间路由数据。配置过其中一个的人,看到另一个的配置也能立刻认出它的形态,尽管语法上有具体差异。Fluent Bit 还超出了纯日志收集:它原生支持在日志之外收集主机和容器的指标(CPU、内存、磁盘),而在 Fluentd 的世界里,这通常意味着需要另一个像 Prometheus exporter 这样的工具,而不是一个统一的代理。

组合架构:Fluent Bit 转发,Fluentd 聚合

两个工具都既可以充当转发器(forwarder)(收集并向前发送数据),也可以充当聚合器(aggregator)(从许多转发器接收数据,做较重的处理,并发送到最终存储),而且没有任何要求规定整个部署只能选其一。在 Kubernetes 中,一种常见的模式恰好发挥了各自的长处:

┌────────────┐  ┌────────────┐  ┌────────────┐
│  Node 1     │  │  Node 2     │  │  Node 3     │
│ Fluent Bit  │  │ Fluent Bit  │  │ Fluent Bit  │   ← one per node (DaemonSet),
│ (DaemonSet) │  │ (DaemonSet) │  │ (DaemonSet) │     lightweight, just forwards
└──────┬─────┘  └──────┬─────┘  └──────┬─────┘
       │                │                │
       └────────────────┼────────────────┘
                         ▼
                 ┌───────────────┐
                 │    Fluentd     │   ← central aggregator,
                 │  (aggregator)  │     heavier parsing/enrichment,
                 └───────┬───────┘     broader plugin access
                         ▼
               Elasticsearch / S3 / Kafka / ...

Fluent Bit 作为 DaemonSet 运行,每个节点一个轻量实例,只做收集和转发所必需的最少工作,不会与节点上真正的工作负载争抢 CPU 或内存。Fluentd 则集中运行,数量较少,承担较重的工作:复杂的解析、丰富,以及路由到任何需要 Fluent Bit 所没有的插件的目的地。每个工具各自做它真正擅长的部分,而不是由一个工具勉强胜任所有事情。

如果只需要一个,如何选择

  • 仅用 Fluent Bit,适用于部署资源受限(边缘设备、Pod 密度高、对规模成本敏感),且目的地和处理需求完全在其插件集覆盖范围之内的情况。
  • 仅用 Fluentd,适用于部署资源并不特别受限,并且需要某个在 Fluentd 历史更久的生态中更成熟的插件,或需要更高程度配置灵活性的情况。
  • 两者一起用,正适合上面的模式:占用很重要的、高吞吐量的每节点收集,汇入占用不那么重要的、集中的较重处理。

云服务商自己的托管 Kubernetes 日志插件多年来越来越多地默认使用 Fluent Bit 而不是 Fluentd,正是出于上表中的性能和占用方面的原因。如果你在排查一个托管集群,并期望在上面找到 Fluentd,值得知道这一点:在做出假设之前,先检查到底部署的是两者中的哪一个。

热门指南