"本文主要對fluent-bit 1.3版本配置做詳細介紹，關注後回覆【pdf】獲得文檔"
1、回顧
隨着集羣規模不斷擴大，日誌收集問題將一直縈繞在我們耳邊，前段時間我用五篇文章安利了使用fluentd及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_*.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負載均衡模式，配置如下所示：
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 secret
5、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 5
6、總結
本章主要講解了基於fluent-bit輸入輸出等插件附屬配置項，通過配置項，可以讓fluent-bit更好的運行。下文我會繼續分享fluent-bit各個版本對接外部服務有哪些，敬請期待。關注、公衆號後臺回覆【pdf】可獲得詳細文檔。
推薦閱讀：
Kubernetes中如何使用ClusterDNS進行服務發現？
從Ice到Kubernetes容器技術，微服務架構經歷了什麼？
原創不易，隨手關注或者”在看“，誠摯感謝！