"本文主要對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容器技術，微服務架構經歷了什麼？
原創不易，隨手關注或者”在看“，誠摯感謝！