Fluentd Fluentd

Fluentd 配置基础:Source、Filter、Match 与标签

每份 Fluentd 配置都由哪些指令构成、标签如何把它们连接起来,以及如何在运行之前验证配置。

12 min 初级

一条 Fluentd 管线 —— 收集、转换、发送 —— 完全通过一个配置文件来表达,由一小组指令构成。本指南介绍每个指令的作用、标签如何把它们连接在一起,以及如何在把真实流量交给配置之前检查它。

配置文件在哪里

Fluentd 自己的打包发行版称为 fluent-package(较早的 td-agent 名称的继任者;如果你阅读的文档或教程提到 td-agent,它是同一个项目的旧品牌名)。以这种方式安装时,配置文件通常位于 /etc/fluent/fluentd.conf。另一个由不同组织维护的发行版 Calyptia Fluentd 使用它自己的路径。请查阅你所用安装方式的文档以确认确切位置,而不要想当然。

三个核心指令

  • <source> 定义日志数据的来源。每个 source 都声明一个插件 @type(tail 用于跟踪文件,http 用于通过 HTTP 接收条目,以及其他),并且至关重要的是还要声明一个 tag,即来自此 source 的每个条目在管线其余部分中携带的标签。
  • <filter> 在条目到达输出之前,就地处理匹配给定标签模式的条目。常见用途:添加字段(丰富)、删除字段(脱敏),或完全丢弃匹配某个模式的条目。
  • <match> 是匹配的条目真正被发送的地方。与 <filter> 一样,它也限定于某个标签模式,但它不是就地转换数据,而是管线的输出阶段:一个目的地,以及知道如何写入该目的地的插件 @type。
<source>
  @type tail
  path /var/log/apache2/access.log
  pos_file /var/log/fluent/apache-access.log.pos
  tag apache.access
  <parse>
    @type apache2
  </parse>
</source>

<filter apache.access>
  @type record_transformer
  remove_keys host
</filter>

<match apache.access>
  @type elasticsearch
  host localhost
  port 9200
  index_name fluentd-apache
</match>

自上而下阅读:source 跟踪 Apache 的访问日志,使用 Fluentd 内置的 Apache 日志格式解析器解析每一行,并给每个产生的条目打上 apache.access 标签。filter 限定于同一个标签,在每个条目继续前进之前去掉其中的 host 字段。match 同样限定于该标签,将(已脱敏的)条目发送到 Elasticsearch。

标签匹配,而不只是标签相等

<filter> 或 <match> 块的标签模式不必是精确的字符串。apache.* 匹配任何以 apache. 开头的标签;** 匹配一切。这就是路由灵活的原因:一个 <match **> 块可以充当兜底目的地,而更具体的模式则以不同方式处理特定的 source,对某个 source 的数据做脱敏而对另一个不做,或者将不同的 source 发送到完全不同的目的地。

读取数据:嵌套的 <parse> 块

将原始日志行变成结构化的键值数据,是解析器的工作,它被配置为 source 内部的嵌套 <parse> 块(这种嵌套形式是当前 Fluentd 的语法;较早的配置示例有时会把解析选项作为平铺的参数直接写在 source 上,那是过时的风格,已不是当前版本所期望的写法)。Fluentd 开箱即带有常见格式的解析器:json、apache2、nginx、syslog、csv,以及用于不匹配任何内置格式的 regexp 解析器:

<parse>
  @type json
</parse>

为某个 source 选对解析器,才能把无结构的文本行变成你可以在下游逐个过滤、丰富和查询的字段,而不是一个不透明的文本块。

用 include 组织配置

一旦配置涵盖多个 source,把所有内容放在一个文件里就变得难以驾驭。@include 指令可以把配置拆分到多个文件中:

# fluentd.conf
@include apache.conf
@include containers.conf
@include outputs.conf

每个被包含的文件都包含它自己的 <source>、<filter> 或 <match> 块,Fluentd 会把它们当作内联书写一样组装起来。这纯粹是为了组织结构;它不改变标签、匹配或处理的工作方式,只是让配置在增长时仍保持可读。

运行之前先验证

在真正启动 Fluentd 之前,检查配置是否格式正确:

fluentd --dry-run -c /etc/fluent/fluentd.conf

这会解析并验证配置,而不处理任何实际的日志数据。一次干净的 dry run 并不保证管线按你的意图工作,那仍需要用真实数据测试,但它确实能在语法错误和插件配置错误表现为令人困惑的运行时故障之前就将其捕获。

运行并观察它工作

用于手动测试的方式(区别于生产环境中通常将 Fluentd 作为受管后台服务运行):

fluentd -c /etc/fluent/fluentd.conf

当 source 跟踪一个文件、match 写入 @type stdout 时,你可以在新行被写入源文件的同时,实时观察条目流过管线,这是在把新的 source 或 filter 指向真实目的地之前,确认它确实按预期工作的快速方法。

热门指南