轻量级日志收集转发 | fluent-bit配置详解（二）

"本文主要对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开始，可用的命令列表如下所示：

2.1、 Include File文件包含

为了避免复杂的长配置文件，我们可以把一个配置文件拆分为不同的配置文件，然后在主配置文件中包含其它配置文件。从fluent-bit 0.12版本开始，我们可以按照如下进行使用。

@INCLUDE somefile.conf

配置读取器将尝试打开somefile.conf ，如果找不到打开当前相对路径下的，例如：

1. 主配置文件路径：/tmp/main.conf；
2. 包含的文件：somefile.conf；
3. fluent-bit将尝试somefile.conf,如果找不到那么将到/tmp/somefile.conf打开此文件。

@INCLUDE只能在顶部靠左侧使用该指令，不能在p内部使用

如下所示支持通配符（*）包含多个配置文件：

@INCLUDE input_*.conf

2.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负载均衡模式，配置如下所示：

配置文件示例：

以下示例定义了一个称为负载均衡的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 secret

5、Scheduler 调度器

fluent-bit引擎支持从输入插件获取数据传输到输出插件，调度器每隔一段时间刷新一次数据，刷新完成后会获得三种状态 OK、Retry、Error。

如果返回状态为OK，则表示它能够成功处理并刷新数据；如果返回状态为Error，则意味着发生了不可恢复的错误，引擎不应尝试再次刷新该数据。如果请求重试，引擎将要求调度程序重试以刷新该数据，调度程序将决定在此之前等待几秒钟。

如何配置重试呢？

调度程序提供了一个称为Retry_Limit的简单配置选项，可以在每个输出节上独立设置。此选项允许禁用重试或施加尝试N次的限制，然后在达到该限制后丢弃数据，配置如下所示：

以下示例配置两个输出，其中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     5

6、总结

本章主要讲解了基于fluent-bit输入输出等插件附属配置项，通过配置项，可以让fluent-bit更好的运行。下文我会继续分享fluent-bit各个版本对接外部服务有哪些，敬请期待。