【官方文档】Fluent Bit 概念

文章目录

1. 关键概念
- 1.1. 事件或记录（Event or Record）
- 1.2. 过滤（Filtering）
- 1.3. 标签（Tag）
- 1.4. 时间戳（Timestamp）
- 1.5. 匹配（Match）
- 1.6. 结构化消息（Structured Messages）
2. 缓冲
3. 数据管道
- 3.1. 输入（Input）
- 3.2. 解析（Parser）
- 3.3. 过滤（Filter）
- 3.4. 缓冲（Buffer）
- 3.5. 路由（Router）
- 3.6. 输出（Output）

官方文档地址： Key Concepts
官方文档地址： Buffering
官方文档地址： Data Pipeline

1. 关键概念

有几个关键概念对于理解 Fluent Bit 的操作方式非常重要。

在进入 Fluent Bit 之前，最好先了解一下该服务的一些关键概念。本文对这些概念和常见的 Fluent Bit 术语进行了简要介绍。下面提供了将要介绍的所有术语的列表，建议从头到尾阅读本文，以便对我们的日志和流处理器有一个更普遍的理解。

事件或记录。
过滤。
标签。
时间戳。
匹配。
结构化消息。

1.1. 事件或记录（Event or Record）

Fluent Bit 检索到的每一个属于日志或指标的输入数据都被视为事件或记录。

以 Syslog 文件为例：

Jan 18 12:52:16 flb systemd[2222]: Starting GNOME Terminal Server
Jan 18 12:52:16 flb dbus-daemon[2243]: [session uid=1000 pid=2243] Successfully activated service 'org.gnome.Terminal'
Jan 18 12:52:16 flb systemd[2222]: Started GNOME Terminal Server.
Jan 18 12:52:16 flb gsd-media-keys[2640]: # watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)

它包含四行，它们代表四个独立的事件。

在内部，一个事件总是有两个组件（以数组形式）：

[TIMESTAMP, MESSAGE]

1.2. 过滤（Filtering）

在某些情况下，需要对事件内容执行修改，更改、填充或删除事件的过程称为过滤。

有许多需要过滤的用例，如：

向事件附加特定信息，如 IP 地址或元数据。
选择一个特定的事件内容。
处理匹配特定模式的事件。

1.3. 标签（Tag）

每一个进入 Fluent Bit 的事件都会被分配一个标签。这个标签是一个内部字符串，路由器稍后会使用它来决定必须通过哪个 Filter 或 Output 阶段。

大多数标签都是在配置中手动分配的。如果没有指定标签，那么 Fluent Bit 将指定生成事件的输入插件实例的名称作为标签。

唯一不分配标签的输入插件是 Forward 输入。这个插件使用名为 Forward 的 Fluentd wire 协议，其中每个事件都有一个相关的标签。Fluent Bit 将始终使用客户端设置的传入标签。

标签记录必须始终具有匹配规则。要了解关于标签和匹配的更多信息，请查看路由部分。

1.4. 时间戳（Timestamp）

时间戳表示事件被创建的时间，每个事件都包含一个相关联的时间戳。时间戳的格式：

SECONDS.NANOSECONDS

Seconds 是自 Unix epoch 以来经过的秒数。

Nanoseconds 是小数秒或十亿分之一秒。

时间戳总是存在的，要么由 Input 插件设置，要么通过数据解析过程发现。

1.5. 匹配（Match）

Fluent Bit 允许将收集和处理的事件传递到一个或多个目的地，这是通过路由阶段完成的。匹配表示一个简单的规则，用于选择与已定义规则匹配的事件。

要了解有关标签和匹配的更多信息，请查看路由部分。

1.6. 结构化消息（Structured Messages）

源事件可以有或没有结构。结构在事件消息中定义了一组键和值。作为一个例子，考虑以下两个消息：

没有结构化的消息

"Project Fluent Bit created on 1398289291"

结构化消息：

{"project": "Fluent Bit", "created": 1398289291}

在较低的级别上，两者都只是字节数组，但结构化消息定义了键和值，具有结构有助于实现对数据快速修改的操作。

Fluent Bit 总是将每个事件消息作为结构化消息处理。出于性能原因，我们使用名为 MessagePack 的二进制序列化数据格式。

可以把 MessagePack 看作是 JSON 的二进制版本。

2. 缓冲

性能和数据安全

当 Fluent Bit 处理数据时，它使用系统内存（heap）作为一个主要的临时位置来存储记录日志，然后在这个私有内存区域中处理记录。

缓冲指的是将记录存储在某个地方的能力，当它们被处理和传递时，仍然能够存储更多的记录。内存缓冲是最快的机制，但在某些情况下，该机制需要特殊的策略来处理背压、数据安全或减少服务在受限环境中的内存消耗。

第三方服务上的网络故障或延迟是很常见的，在接收到新数据时无法足够快地交付数据的情况下，我们可能会面临背压。

我们的缓冲策略旨在解决与背压和一般交付失败相关的问题。

Fluent Bit 作为缓冲策略，在内存中提供了一个主缓冲机制，并使用文件系统提供了一个可选的辅助缓冲机制。使用这种混合解决方案，您可以调整任何用例的安全性，并在处理数据时保持高性能。

这两种机制都不是排他的，当数据准备好被处理或交付时，它将始终在内存中，而队列中的其他数据可能在文件系统中，直到准备好被处理并移到内存中。

要了解更多关于 Fluent Bit 的缓冲配置，请跳转到缓冲和存储部分。

3. 数据管道

3.1. 输入（Input）

从数据源收集数据的方法

Fluent Bit 提供了不同的输入插件来收集来自不同来源的信息，其中一些插件只是从日志文件中收集数据，而另一些插件则可以从操作系统中收集指标信息。有许多插件可以满足不同的需求。

当一个输入插件被加载时，一个内部实例被创建。每个实例都有自己独立的配置。配置键通常称为属性。

每个输入插件都有自己的文档部分，其中指定了如何使用它和哪些属性可用。

更多的细节，请参考输入插件部分。

3.2. 解析（Parser）

将非结构化消息转换为结构化消息

处理原始字符串或非结构化消息是一个持续的痛苦；有一个结构是非常需要的。理想情况下，我们希望在输入插件收集到数据时，为输入数据设置一个结构：

解析器允许您将非结构化数据转换为结构化数据。作为一个演示示例，考虑以下 Apache (HTTP Server) 日志条目：

192.168.2.20 - - [28/Jul/2006:10:27:10 -0300] "GET /cgi-bin/try/ HTTP/1.0" 200 3395

上面的日志行是一个没有格式的原始字符串，理想情况下，我们希望给它一个结构，之后就可以较容易地处理。如果使用了适当的配置，日志条目可以转换为：

{"host":    "192.168.2.20","user":    "-","method":  "GET","path":    "/cgi-bin/try/","code":    "200","size":    "3395","referer": "","agent":   ""}

解析器是完全可配置的，可以由每个输入插件独立处理，更多细节请参考解析器部分。

3.3. 过滤（Filter）

修改、丰富或删除您的记录

在生产环境中，我们希望完全控制所收集的数据，筛选是一个重要特性，它允许我们在将数据交付到某个目的地之前修改数据。

过滤是通过插件实现的，所以每个可用的过滤器都可以用来匹配、排除或用一些特定的元数据丰富您的日志。

我们支持很多过滤器，一个常见的过滤用例是 Kubernetes 的部署。每个 Pod 日志都需要得到适当的关联元数据。

与输入插件非常相似，过滤器在实例上下文中运行，它有自己独立的配置。配置键通常称为属性。

有关可用过滤器及其用法的详细信息，请参阅过滤器部分。

3.4. 缓冲（Buffer）

可靠的数据处理

在前面的 Buffering 概念部分中定义，管道中的缓冲阶段旨在提供统一和持久的机制来存储数据，可以使用主内存模型，也可以使用基于文件系统的模式。

缓冲阶段已经包含了处于不可变状态的数据，这意味着不能应用其他筛选器。

注意，缓冲数据不是原始文本，而是 Fluent Bit 内部的二进制表示。

Fluent Bit 在文件系统中提供缓冲机制，充当备份系统，以避免系统故障时数据丢失。

3.5. 路由（Router）

创建灵活的路由规则

路由是一个核心特性，它允许将数据通过过滤器路由到一个或多个目的地。路由器依赖于标签和匹配规则的概念。

路由中有两个重要的概念：

Tag
Match

当数据由输入插件生成时，它带有一个 Tag（大多数情况下，Tag 是手动配置的），Tag 是一个人类可读的指示器，帮助识别数据源。

为了定义应该将数据路由到何处，必须在输出配置中指定 Match 规则。

思考下面的配置示例，目的是将 CPU 指标交付给 Elasticsearch 数据库，并将内存指标交付给标准输出接口：

[INPUT]Name cpuTag  my_cpu[INPUT]Name memTag  my_mem[OUTPUT]Name   esMatch  my_cpu[OUTPUT]Name   stdoutMatch  my_mem

注意：上面是一个简单的例子，演示了如何配置路由。

路由自动读取输入标签和输出匹配规则。如果某些数据的 Tag 在路由配置上不匹配，则删除该数据。

路由与通配符

路由非常灵活，Match 模式可以支持通配符。下面的例子定义了两个数据源的共同目标：

[INPUT]Name cpuTag  my_cpu[INPUT]Name memTag  my_mem[OUTPUT]Name   stdoutMatch  my_*

匹配规则被设置为my_*，这意味着它将匹配任何以my_开头的标签。

3.6. 输出（Output）

您的数据目的地：数据库，云服务和更多！

输出接口允许我们定义数据的目的地。常见的目标是远程服务、本地文件系统或与其他人的标准接口。输出以插件的形式实现，并且有许多可用的插件。

当一个输出插件被加载时，一个内部实例被创建。每个实例都有自己独立的配置。配置键通常称为属性。

每个输出插件都有自己的文档部分，指定如何使用它以及哪些属性可用。

要了解更多细节，请参阅输出插件部分。