Fluentd 详解：插件生态最丰富的日志收集器

Fluentd 是 CNCF 毕业项目、日志收集器领域的老牌选手：Ruby 编写、插件生态超过 1000 个、久经大规模生产考验。本文讲解其架构、配置实战与适用边界，并从观测云视角给出选型建议。

核心要点速览

• 配置三大指令：<source> 输入 → <filter> 加工 → <match> 输出，靠 tag 串联路由。
• 插件生态是护城河：1000+ 输入/输出/过滤插件，几乎所有数据源与后端都有现成插件。
• 缓冲分内存与文件两种：生产用文件缓冲保证可靠性，配合重试参数抗后端抖动。
• 观测云视角：DataKit 内置同类采集与 Pipeline 处理能力，观测云用户优先 DataKit；存量 Fluentd 可平滑改造外送观测云。

1. 配置结构与 tag 路由

<source>
  @type tail
  path /var/log/nginx/access.log
  pos_file /var/log/fluentd/nginx.pos
  tag access.nginx
  <parse>
    @type nginx
  </parse>
</source>

<filter access.nginx>
  @type record_transformer
  <record>
    hostname "#{Socket.gethostname}"
    env "production"
  </record>
</filter>

<match access.**>
  @type file
  path /var/log/aggregated/nginx
</match>

tag 是 Fluentd 的路由灵魂：source 打 tag，filter/match 按 tag 模式（access.** 通配）订阅——数据流向一目了然。pos_file 记录采集位点，重启断点续采。

2. 核心插件速览

3. 缓冲与可靠性

<match **>
  @type http
  endpoint https://logs.example.com/ingest
  <buffer>
    @type file
    path /var/log/fluentd/buffer
    flush_interval 5s
    retry_max_interval 30s
    retry_forever true
  </buffer>
</match>

文件缓冲 + retry_forever：后端长时间故障也不丢数据。Fluentd 单实例内存约 30-40MB，高可用靠"多实例 + out_forward 轮询"或前置负载均衡。

4. Fluentd vs Fluent Bit 一句话区分

同宗同门（同一团队、forward 协议互通）：Fluentd 功能全（插件多）但重；Fluent Bit 极致轻（内存 1MB 级）但插件少。K8s DaemonSet 采集用 Fluent Bit，中心汇聚层用 Fluentd 是经典组合（详见本系列对比专篇）。

观测云视角：DataKit 对标与迁移

存量 Fluentd 迁移：把 <match> 输出改为 HTTP 指向观测云接收端即可平滑过渡，采集与过滤配置无需推翻；新环境直接用 DataKit，省掉插件维护成本。

常见问题（FAQ）

Fluentd 的 tag 和日志里的字段有什么区别？

tag 是 Fluentd 内部的路由元数据（不进日志内容），字段是日志记录本身的数据。tag 决定"这条日志流往哪"，字段是"这条日志是什么"。

buffer 目录写满会怎样？

新数据会被拒绝（可通过 overflow_action 配置行为：抛错/丢弃/阻断输入）。生产要监控 buffer 目录磁盘水位，并为后端故障留足缓冲空间。

Fluentd 性能瓶颈在哪？

Ruby 运行时决定了它不适合单机极限吞吐场景（数万 EPS 以上）。横向扩展（多实例 + forward 聚合）或对性能敏感链路换 Fluent Bit/Vector/DataKit 是常规解法。

配置文件改完怎么生效？

systemctl reload fluentd 或发 SIGHUP 优雅重载；fluentd --dry-run -c fluent.conf 可先校验配置语法。

系列阅读

• 上一篇：Vector 详解
• 下一篇：Fluent Bit 详解
• 相关阅读：Fluentd vs Fluent Bit 对比 ｜ 日志采集器七款横评

---