"本文主要对fluent-bit 1.3版本配置做详细介绍，关注后回复【pdf】获得文档"
1、回顾
随着集群规模不断扩大，日志收集问题将一直萦绕在我们耳边，前段时间我用五篇文章安利了使用fluentd及fluent-bit好处，具体可以参考如下链接：
- Kubernetes日志收集解决方案
- Kubernetes集群环境下fluentd日志收集方案介绍
- 日志收集工具fluentd安装配置及使用介绍
- 一文了解日志收集工具fluent-bit
- 轻量级日志收集转发 | fluent-bit指令详解（一）
下面我就直接介绍fluent-bit整体收集架构和插件，如果对整体有不理解的部分，可以参考如上链接。
2、配置介绍
配置文件必须足够灵活以适应任何配置需求，他们必须保持一定的可读性。
fluent-bit扩展了具有特定内置功能的配置文件。从fluent-bit 0.12开始，可用的命令列表如下所示：
Commands | Prototype | Description |
@INCLUDE | @INCLUDE FILE | 包含配置文件 |
@SET | @SET KEY=VAL | 设置环境变量 |
2.1、 Include File文件包含
为了避免复杂的长配置文件，我们可以把一个配置文件拆分为不同的配置文件，然后在主配置文件中包含其它配置文件。从fluent-bit 0.12版本开始，我们可以按照如下进行使用。
@INCLUDE somefile.conf配置读取器将尝试打开somefile.conf ，如果找不到打开当前相对路径下的，例如：
- 主配置文件路径：/tmp/main.conf；
- 包含的文件：somefile.conf；
- fluent-bit将尝试somefile.conf,如果找不到那么将到/tmp/somefile.conf打开此文件。
@INCLUDE只能在顶部靠左侧使用该指令，不能在p内部使用
如下所示支持通配符（*）包含多个配置文件：
@INCLUDE input_*.conf2.2、环境变量配置功能
fluent-bit支持通过key关联的任何值中使用环境变量。变量区分大小写，可以按照如下格式使用：
${MY_VARIABLE}fluent-bit启动时，配置读取器会尝试读取${MY_VARIABLE}的任何请求，并将其解析成值。
1. shell终端设置
例如创建以下配置文件fluent-bit.conf
[SERVICE]
Flush 1
Daemon Off
Log_Level info
[INPUT]
Name cpu
Tag cpu.local
[OUTPUT]
Name ${MY_OUTPUT}
Match *打开终端并使用环境变量
$ export MY_OUTPUT=stdout上面改的命令行把 MY_OUTPUT设置为stdout，使用上面创建的配置文件fluent-bit.conf并运行。
如你所见，配置正确，服务正常运行。
$ bin/fluent-bit -c fluent-bit.conf
Fluent-Bit v0.11.0
Copyright (C) Treasure Data
[2017/04/03 12:25:25] [ info] [engine] started
[0] cpu.local: [1491243925, {"cpu_p"=>1.750000, "user_p"=>1.750000, "system_p"=>0.000000, "cpu0.p_cpu"=>3.000000, "cpu0.p_user"=>2.000000, "cpu0.p_system"=>1.000000, "cpu1.p_cpu"=>0.000000, "cpu1.p_user"=>0.000000, "cpu1.p_system"=>0.000000, "cpu2.p_cpu"=>4.000000, "cpu2.p_user"=>4.000000, "cpu2.p_system"=>0.000000, "cpu3.p_cpu"=>1.000000, "cpu3.p_user"=>1.000000, "cpu3.p_system"=>0.000000}]2. 文件内部设置
如果在文件内部全局声明，@SET指令只能在每行的开始使用，意味着不能在p内部使用。具体如下所示：
@SET my_input=cpu
@SET my_output=stdout
[SERVICE]
Flush 1
[INPUT]
Name ${my_input}
[OUTPUT]
Name ${my_output}3、服务器压力配置
如果获取的日志比发送的日志的速度更快，很大程度上会增加服务器压力，常见的情况是，把一个大日志文件发送到服务器后台，这需要一定时间来响应，这会产生服务器压力，从而导致服务器消耗更多的内存。为了避免服务器压力fluent bit引擎实现了一种输入插件读取数据量的限制。这个限制是通过Mem_Buf_Limit来控制。
此选项应用于所有输入插件，默认情况下是禁用的
如果在使用过程中，超过内存限制，fluent-bit引擎会进入自我保护状态，不会接收更多的数据，当内存释放后，再进行数据接收。并非所有的插件都实现了暂停和恢复操作，如上所述，这些回调都是插件的通知机制。实现良好的是input tail插件，当暂停回调触发时，将停止收集数据，当重新回调时，它会开始数据收集。
那么我们如何估算内存使用大小呢？
在某些场景和环境下，对于fluent-bit能够使用多少内存，这个限制是有一定必要性的，为了进行估算，我们需要对Mem_Buf_Limit变量进行设置。
如果需要处理10M数据，我们需要考虑最坏的情况，输出插件可能需要20M（fluent-bit能够内部处理二进制数据格式，故要尽量少的在fluent-bit进行数据处理），在数据没有到达influxDB或者ES时，会缓存在自己的缓冲区内部，因此至少需要30*1.2=36M。
4、Upstream Servers
fluent-bit可以连接到外部服务器传输日志。例如：HTTP、forward、ES等，能够连接到一个节点是正常的，为了实现负载均衡以应付更多的实例，输出插件就必须支持Upstream功能。
当前主要实现了round-robin负载均衡模式，配置如下所示：
Section | Key | Description |
UPSTREAM | name | 上游名称 |
NODE | name | 节点名称 |
host | 目标IP地址或主机名 | |
port | 目标tcp端口 |
配置文件示例：
以下示例定义了一个称为负载均衡的Upstream，提供给输出插件使用，它注册了三个Node：
- 节点1：连接到127.0.0.1:43000
- 节点2：连接到127.0.0.1:44000
- node-3：使用TLS无需验证即可连接到127.0.0.1:45000。它还定义了称为shared_key的Forward输出所需的特定配置选项。
[UPSTREAM]
name forward-balancing
[NODE]
name node-1
host 127.0.0.1
port 43000
[NODE]
name node-2
host 127.0.0.1
port 44000
[NODE]
name node-3
host 127.0.0.1
port 45000
tls on
tls.verify off
shared_key secret5、Scheduler 调度器
fluent-bit引擎支持从输入插件获取数据传输到输出插件，调度器每隔一段时间刷新一次数据，刷新完成后会获得三种状态 OK、Retry、Error。
如果返回状态为OK，则表示它能够成功处理并刷新数据；如果返回状态为Error，则意味着发生了不可恢复的错误，引擎不应尝试再次刷新该数据。如果请求重试，引擎将要求调度程序重试以刷新该数据，调度程序将决定在此之前等待几秒钟。
如何配置重试呢？
调度程序提供了一个称为Retry_Limit的简单配置选项，可以在每个输出节上独立设置。此选项允许禁用重试或施加尝试N次的限制，然后在达到该限制后丢弃数据，配置如下所示：
value | Description | |
Retry_Limit | n | 整数值，用于设置允许的最大重试次数。N必须> = 1（默认值：2） |
Retry_Limit | False | 当Retry_Limit设置为False时，意味着调度程序可以进行的重试次数没有限制。 |
以下示例配置两个输出，其中HTTP插件具有无限次重试，而Elasticsearch插件具有5次限制：
[OUTPUT]
Name http
Host 192.168.5.6
Port 8080
Retry_Limit False
[OUTPUT]
Name es
Host 192.168.5.20
Port 9200
Logstash_Format On
Retry_Limit 56、总结
本章主要讲解了基于fluent-bit输入输出等插件附属配置项，通过配置项，可以让fluent-bit更好的运行。下文我会继续分享fluent-bit各个版本对接外部服务有哪些，敬请期待。
