文章目录
官方文档地址: 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 cpu
Tag my_cpu
[INPUT]
Name mem
Tag my_mem
[OUTPUT]
Name es
Match my_cpu
[OUTPUT]
Name stdout
Match my_mem
注意:上面是一个简单的例子,演示了如何配置路由。
路由自动读取输入标签和输出匹配规则。如果某些数据的 Tag 在路由配置上不匹配,则删除该数据。
路由与通配符
路由非常灵活,Match 模式可以支持通配符。下面的例子定义了两个数据源的共同目标:
[INPUT]
Name cpu
Tag my_cpu
[INPUT]
Name mem
Tag my_mem
[OUTPUT]
Name stdout
Match my_*
匹配规则被设置为my_*
,这意味着它将匹配任何以my_
开头的标签。
3.6. 输出(Output)
您的数据目的地:数据库,云服务和更多!
输出接口允许我们定义数据的目的地。常见的目标是远程服务、本地文件系统或与其他人的标准接口。输出以插件的形式实现,并且有许多可用的插件。
当一个输出插件被加载时,一个内部实例被创建。每个实例都有自己独立的配置。配置键通常称为属性。
每个输出插件都有自己的文档部分,指定如何使用它以及哪些属性可用。
要了解更多细节,请参阅输出插件部分。