"本文主要对fluent-bit 1.3版本指令做详细介绍，关注后回复【pdf】获得文档"
1、回顾
随着集群规模不断扩大，日志收集问题将一直萦绕在我们耳边，前段时间我用四篇文章安利了使用fluentd及fluent-bit好处，具体可以参考如下链接：
下面我就直接介绍fluent-bit整体收集架构和插件，如果对整体有不理解的部分，可以参考如上链接。
2、插件介绍
整体功能流程如下图所示：
插件 | 描述 |
Input | 数据入口点，通过输入插件实现，此接口允许收集和接收数据，比如日志文件、TCP上报数据等。 |
Parser | Parser能够把从input接口获取的非结构化数据进行格式化操作，Parser是可选的，具体取决于Input输入插件。 |
Filter | Filter是过滤器插件，它允许修改input插件提取的数据。 |
Buffer | 默认情况下，Buffer把Input插件的数据缓存在内存当中，直到路由并传递到output接口为止。 |
Routing | 用于标记Input接口获取的数据，根据规则匹配把数据路由到什么位置。 |
OutPut | OutPut用于定义数据目的地和目的地输出插件，注意：借助于Routing插件可以把数据输出到多个目的地。 |
3、fluent-bit插件详细介绍
3.0、Input
fluent-bit提供了各种各样的日志插件来收集不同来源的日志文件，比如可以从日志文件收集、操作系统收集一些度量数据。当Input插件被加载以后，fluent-bit会在内部创建一个实例，每个实例都有自己独立的配置，这些配置我们通常称作它的属性。
Input定义了输入源信息，如下所示Input相关配置信息，注意每个Input插件都可以定义自己的配置键。
key | value |
Name | Input输入标签名称 |
Tag | Input插件产生记录标签名称 |
Name是必填项，它使Fluent-bit知道应该加载那个输入插件，除输入和转发插件外，其它插件Name都是必填项。使用示例如下所示：
[INPUT]
Name cpu
Tag my_cpu
3.1、Parser
实际情况下，原始字符串的使用是一件很痛苦的事情，通常情况下，我们期望在收集到输入数据后立刻转换为结构化的数据,默认可以处理Apche、Nginx、Docker等日志。
通过以下实例（Apache HTTP服务器）可以看出非结构化的数据转换为结构化数据的过程：
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": ""
}
解析器是完全可以配置的，并且可以由每个输入插件独立且可选的方式进行处理。
具体配置使用示例，如下所示：
[PARSER]
Name docker
Format json
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L
Time_Keep On
[PARSER]
Name syslog-rfc5424
Format regex
Regex ^\<(?<pri>[0-9]{1,5})\>1 (?<time>[^ ]+) (?<host>[^ ]+) (?<ident>[^ ]+) (?<pid>[-0-9]+) (?<msgid>[^ ]+) (?<extradata>(\[(.*)\]|-)) (?<message>.+)$
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L
Time_Keep On
Types pid:integer
3.2、Filter
生产环境中，我们要完全控制我们需要收集的数据，Filter是一个很重要的特性，它能够保证数据在没有到达目的地之前对其进行修改。Filter是通过插件进行实现的，因此每个可用的标记都可以用来匹配,过滤或丰富特定元数据的日志。
Filter和Input非常类似，它在实例上下文中运行，有着自己独立的配置，如下所示是Filter相关配置信息：
key | desc |
Name | 过滤器名称 |
Match | 与传入记录标签匹配的模式，它区分大小写，并可以用 * 作为通配符。 |
Match_Regex | 与传入记录标签匹配的正则表达式，如果要使用完整的正则表达式语法，请使用此选项。 |
Name是必填项，它使fluent-bit知道应该加载那个插件，Match和Match_Regex是匹配模式插件，如果两者同时定义，以Match_Regex优先。使用示例如下所示：
[FILTER]
Name stdout
Match *
3.3、Buffer
Buffer在fluent-bit中是一个可供选择的缓冲机制，该机制能够充当数据备份系统，以避免系统故障导致的数据丢失。
fluent-bit最终目标是收集、解析、过滤、最终把日志发到中心位置，在此过程中存在多个阶段，而关键的功能之一就是缓冲的能力，即把处理后的数据存放在临时位置，随时可以发送到最终位置。默认情况下，fluent-bit在处理数据时，使用内存进行存储记录和临时位置，但是在理想情况下，是在文件系统中提供持久化存储机制，以保证数据的聚合和安全功能。
从fluent-bit 1.0开始，fluent-bit提供了新的存储层，该存储层可以是内存也可以是文件系统，可以在输入插件中进行配置启用。
注意：缓存的数据不在是默认的日志数据格式，而是fluent-bit内部二进制表示形式。
Buffer有两个区域需要配置，如下：
Service
INPUT
可以在Service Section配置一个全局存储变量，在Input Section定义使用什么机制。
Service相关的配置信息如下所示：
Key | Description | Default |
storage.path | 在文件系统中配置一个可选位置用于存储数据流和数据块，如果未设置此参数，那么只能使用内存作为缓存。 | |
storage.sync | 开启数据同步到文件存储系统，可以配置normal和full两种配置。 | 正常 |
storage.checksum | 从文件系统中读取或写入数据时启用完整性检查，存储层使用CRC32算法。 | 关闭 |
storage.backlog.mem_limit | 如果设置了storage.path，fluent-bit会查找尚未分发出去的数据块，这些数据块称之为积压数据，此配置用来控制处理这些积压数据时占用系统内存大小。 | 5M |
Service部分示例如下：
[SERVICE]
flush 1
log_Level info
storage.path /var/log/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
如上所示配置了一个缓冲机制，缓冲区路径/var/log/flb-storage/，它将使用正常的同步模式，没有校验和，并且在处理积压数据时最大可以使用5M内存。
Input部分配置信息如下所示：
Input插件可以配置如下可选存储配置项，下表描述了可选的配置：
Key | Description | Default |
storage.type | 指定要使用的缓冲机制，内存或者文件系统 | 内存 |
如下所示配置了一个缓冲服务的功能，两个Input插件，第一个文件系统，第二个内存。
[SERVICE]
flush 1
log_Level info
storage.path /var/log/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
[INPUT]
name cpu
storage.type filesystem
[INPUT]
name mem
storage.type memory
3.4 、Routing
它是一项核心功能，可以通过过滤器把数据路由到一个或者多个目的地。
路由中有两个重要概念：
Tag：当数据由输入插件生成时，它会附带一个标签（大多数情况下是人为手动配置该标签），该标签是用户可读的指示器，有助于识别数据源。
Match：它在输出插件中指定，主要用于定义当前数据路由目的地。
参考以下示例，该示例旨在把CPU信息路由到ES数据仓库，内存信息传递到标准输出接口。
[INPUT]
Name cpu
Tag my_cpu
[INPUT]
Name mem
Tag my_mem
[OUTPUT]
Name es
Match my_cpu
[OUTPUT]
Name stdout
Match my_mem
路由会自动读取输入规则和输出匹配标签，如果一些数据输入标签和输出标签不匹配，那么该数据将被忽略。
路由具有足够的灵活性，以支持通配符的匹配模式。下面这个例子说明了两个数据源共同定义了一个目的地。
[INPUT]
Name cpu
Tag my_cpu
[INPUT]
Name mem
Tag my_mem
[OUTPUT]
Name stdout
Match my_*
匹配规则设置成my_*,那么意味着，它将匹配所有以my_开头的数据。
3.5、OUTPUT
它用于定义数据的输出目的地。目的地可以是远程服务、本地文件系统、或其它可用的标准接口。OutPut有很多可用的输出插件实现。加载输出插件后，将创建一个独立的实例，每个实例都有自己独立的配置。OUTPUT支持以下属性配置：
Key | Desc |
Name | 输出插件的名称 |
Match | 与传入记录标签匹配的模式，它区分大小写，并可以用 * 作为通配符。 |
Match_Regex | 与传入记录标签匹配的正则表达式，如果要使用完整的正则表达式语法，请使用此选项。 |
如下所示是OUTPUT的使用示例：
[OUTPUT]
Name stdout
Match my*cpu
如下所示是收集CPU指标示例：
[SERVICE]
Flush 5
Daemon off
Log_Level debug
[INPUT]
Name cpu
Tag my_cpu
[OUTPUT]
Name stdout
Match my*cpu
4、Service
运行于整个数据链的输入和输出；比如可以配置为fluent-bit是否为守护进程、过滤日志记录、刷新间隔等。
Service定义了服务的全局属性，通过下表可以说明当前版本可用的属性：
键值 | 描述 | 默认值 |
Flush | 设置flush时间（以秒为单位）每次超时，fluent-bit都会把数据刷新到输出插件中。 | 5 |
Daemon | 一个布尔值，用于设置fluent-bit是否为守护进程（后台运行），允许使用yes, no, on 和 off | 否 |
Log_File | 可选日志文件的绝对路径 | |
Log_Level | 设置日志记录的详细程度，允许使用error, warning, info, debug 和 trace. 注意只有WITH_TRACE启用的情况下trace模式才可用。 | |
Parsers_File | Parsers配置路径，可使用多个Parsers_File路径 | |
Plugins_File | 插件配置路径，可以配置外部插件 | |
Streams_File | 流处理器配置文件路径 | |
HTTP_Server | 启用内置Http服务器 | 否 |
HTTP_Listen | 启用Http监听端口 | 0.0.0.0 |
HTTP_Port | tcp端口 | 2020 |
Coro_Stack_Size | 设置协程堆栈大小（以字节为单位）。该值应该大于允许系统页面大小，不要设置太小，否则协程可能会超出堆栈缓冲区 | 24576 |
使用示例如下：
[SERVICE]
Flush 5
Daemon off
Log_Level debug
5、总结
本文主要详细介绍了fluent-bit从输入到输出过程中使用的插件。下文我会继续分享各个插件Configuration配置、Include信息含义及使用，敬请期待。关注、公众号后台回复【pdf】可获得详细文档。
推荐阅读：
Kubernetes中如何使用ClusterDNS进行服务发现？
从Ice到Kubernetes容器技术，微服务架构经历了什么？
原创不易，随手关注或者”在看“，诚挚感谢！