2. Fluentd事件的生命周期

事件（Event）是Fluentd内部处理流程使用的数据结构，日志记录一旦进入Fluentd便被封装成一个event。Event由三部分组成：tag、time、record。

• tag: 标识事件的来源，或者说类型，用于内部消息路由，即后续交由哪个插件处理；
• time: 是事件的发生时间；
• record: 为日志的实际内容，这是一个JSON对象。

Input插件负责将源数据封装为event，比如input_tail插件从文本中生成event。对于下边这行文本：

192.168.0.1 - - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777

将会产生下边的event对象：

tag: apache.access    #根据插件的tag参数来设置
time: 1362020400      # 28/Feb/2013:12:00:00 +0900
record: {"user":"-","method":"GET","code":200,"size":777,"host":"192.168.0.1","path":"/"}    #根据input_tail插件中的parse项来决定如何解析单行日志记录，并生成相应的JSON对象

通过一个具体的配置来讲解事件的处理过程。

本例使用一个很基础的配置片段来描述各插件是如何关联到一起的，它包括了如何定义输入源（或者说监听器），以及如何设置通用的匹配规则将event路由到输出端。

我们使用input_http和output_stdout这两个插件来描述event的循环过程。

<source>
  @type http
  @id input_http
  port 8888
</source>

上边的配置使用input_http插件定义了一个HTTP服务器，监听端口为8888。然后我们再定义一个匹配（Match）规则，event路由引擎会根据这个规则将http请求派发到输出端。这里的输出端是stdout，仅仅将http请求打印到屏幕上。

<match test.cycle>
  @type stdout
  @id output_stdout
</match>

Match的作用是设置一个匹配规则test.cycle，对于每个进入Fluentd的event，如果其tag值和test.cycle相等（或者说匹配，因为match可以使用通配符。这里的tag是由input_http插件生成的。），那么这个event就会进入此match定义的output插件，本例中的output插件就是output_stdout。

至此，我们定义了三个基本项：Input、Match和Output，虽然仅仅使用两个配置段。这就是一个可以使用的采集配置了，可以通过以下命令进行测试：

curl -i -X POST -d 'json={"action":"login","user":2}' http://localhost:8888/test.cycle

会看到如下输出：

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: Keep-Alive
Content-Length: 0

在/var/log/td-agent/td-agent.log中会有如下输出：

2020-11-03 14:34:09.624879668 +0800 test.cycle: {"action":"login","user":2}

下边开始了解一下事件是如何被处理和改变的。

当你准备好一个采集配置后，Fluentd就生成了用以处理输入数据的各种规则。日志事件会历经一系列的处理流程，从而决定了事件的循环周期。

1.过滤器（Filters）

过滤器用于对事件进行筛选，决定是否接收或者丢弃事件。我们可以在上边的示例中增加一个过滤器。

<source>
  @type http
  @id input_http
  bind 0.0.0.0
  port 8888
</source>

<filter test.cycle>
  @type grep
  <exclude>
    key action
    pattern ^logout$
  </exclude>
</filter>

<match test.cycle>
  @type stdout
  @id output_stdout
</match>

添加过滤器之后，事件在路由到match之前必须经过过滤器的处理。过滤器根据事件的类型和过滤规则来决定是否接受此事件。

示例中使用的是grep过滤器，这个过滤器对test.cycle这类事件进行过滤，会排除http请求中action值为logout的事件。
所以，如果尝试发送下边的请求，在td-agent.log中是看不到任何输出的。

curl -i -X POST -d 'json={"action":"logout","user":2}' http://localhost:8888/test.cycle

从示例中可以看到，事件是根据配置顺序自上而下来被处理的。我们可以根据需要配置任意多个过滤器，这样一来，配置文件会变得很长很复杂。Fluentd提供了标签来解决此问题。

2.标签（Labels）

标签的作用是用来定义一组配置项，这组配置项可以被其他配置项引用，从而实现事件路由跳转。类似编程语言中的goto的功能。

还是上边的示例，我们定义一个标签来看一下效果。

<source>
  @type http
  @id input_http
  bind 0.0.0.0
  port 8888
  @label @STAGING
</source>

<filter test.cycle>
  @type grep
  <exclude>
    key action
    pattern ^logout$
  </exclude>
</filter>

<label @STAGING>
  <filter test.cycle>
    @type grep
    <exclude>
      key action
      pattern ^login$
    </exclude>
  </filter>

  <match test.cycle>
    @type stdout
    @id output_stdout
  </match>
</label>

这个STARTING标签将之前的filter和match封装到了一起，然后在source中进行了引用。如此一来，事件由input插件生成后将会跳过那个独立的filter，直接进入STARTING定义的处理流程中。

# 如下这个没有输出，因为跳过了独立的filter
curl -i -X POST -d 'json={"action":"logout","user":2}' http://localhost:8888/test.cycle

# 如下这个有输出，直接进入STARTING定义的处理流程中开始filter
curl -i -X POST -d 'json={"action":"login","user":2}' http://localhost:8888/test.cycle 

这种效果可以实现一些特定的处理逻辑，让事件快速到达指定目的地。

3.缓存（Buffers）
我们看到了事件从input产生，经由filter筛选，最后到达output的过程。在上边的示例中，我们使用的是stdout插件直接输出到控制台，并没有经过缓存。
实际应用中，一般会先把数据进行缓存，达到一定条件后再flush到目标存储中。这样可以提升系统可靠性，对于稳定系统吞吐量也很重要。

官方关于缓存的文档地址：https://docs.fluentd.org/configuration/buffer-section

总的来说，事件会在各插件之间接续流转，直到到达output，结束整个生命周期。
如下图：