Fluent Bit 的定位#

Fluent Bit 是一個輕量級、高效能的通用資料收集器，雖然最常被用來收集日誌，但它能處理的資料類型遠不止於此——Metrics、Traces 也在它的守備範圍內。

Fluent Bit 由 C 語言撰寫，記憶體佔用極低（通常在 10 到 50 MB），啟動速度快，非常適合資源受限的環境，如容器、邊緣裝置、嵌入式系統。

Fluent Bit 是 CNCF（Cloud Native Computing Foundation）的畢業專案，這意味著它經過了嚴格的成熟度審查，在雲原生生態系中擁有廣泛的採用與社群支持。

Pipeline 架構：四個階段#

Fluent Bit 的核心是一個可插拔的 Pipeline 架構，資料依序流經四個階段：

Input（輸入）#

定義資料從哪裡來。常見的 Input 插件包括：

• tail：讀取日誌檔（最常用）
• systemd：讀取 systemd Journal
• forward：接收來自其他 Fluent Bit/Fluentd 的資料
• kubernetes_events：收集 Kubernetes 事件

Parser（解析）#

將非結構化的日誌文字轉為結構化的 Key-Value 記錄。支援多種格式：

• JSON、Regex、Logfmt、LTSV 等
• 可以自定義 Parser 來處理應用程式特有的日誌格式

Filter（過濾與加工）#

對資料做中間處理：

• kubernetes：自動附加 Pod Name、Namespace、Container 等 Kubernetes Metadata
• grep：根據條件保留或丟棄記錄
• modify：新增、刪除、重新命名欄位
• lua：用 Lua 腳本做自定義處理

Output（輸出）#

定義資料要送到哪裡。這是 Fluent Bit 最強大的能力之一——同一份資料可以同時送往多個目的地：

• Loki、Elasticsearch、OpenSearch
• S3、GCS 等物件儲存
• Kafka、Splunk、Datadog
• stdout（除錯用）

Fluent Bit 的多輸出能力在「漸進式遷移」場景中特別有用。例如你正在從 Elasticsearch 遷移到 Loki，可以同時輸出到兩個系統，驗證 Loki 的查詢結果是否正確後再切換。

Fluent Bit vs Fluentd#

Fluent Bit 和 Fluentd 同屬 Fluent 專案家族，但定位不同：

在現代的 Kubernetes 環境中，Fluent Bit 已經取代 Fluentd 成為主流選擇。除非你需要某個 Fluentd 特有的社群插件，否則 Fluent Bit 在大多數場景下都是更好的選擇。

為什麼 Kubernetes 生態系偏好 Fluent Bit#

Fluent Bit 在 Kubernetes 環境中幾乎是「預設選擇」，原因包括：

• 資源佔用小：作為 DaemonSet 部署在每個 Node 上，低記憶體消耗意味著更多資源留給業務 Pod
• 啟動快：Node 擴展時，Fluent Bit 能在數秒內就緒
• 原生 Kubernetes 支持：內建的 kubernetes Filter 能自動從 Kubernetes API 獲取 Pod Metadata，不需要額外設定
• CNCF 背書：與 Kubernetes 同屬 CNCF 生態系，整合度高

Fluent Bit 的 kubernetes Filter 會呼叫 Kubernetes API 來獲取 Pod Metadata。在大規模叢集中（數千個 Node），這可能對 API Server 造成壓力。確保設定適當的快取策略和請求頻率限制。

Event 與 Config 的概念#

Event#

在 Fluent Bit 中，每一筆流經 Pipeline 的資料都是一個 Event。一個 Event 由三部分組成：

• Timestamp：事件發生的時間
• Metadata：附加的中繼資料（如 Kubernetes Label）
• Body：事件內容本身（日誌文字或結構化資料）

Config File#

Fluent Bit 的設定檔定義了 Pipeline 的每個階段。傳統上使用自定義的 INI-like 格式，較新版本也支援 YAML 格式。

設定的核心思路是：宣告 Input、Parser、Filter、Output 各自的行為，Fluent Bit 會自動將它們串成一條 Pipeline。

Service#

Service 區段定義 Fluent Bit 本身的全域行為，例如：

• Flush 間隔：多久將緩衝區的資料送出一次
• Log Level：Fluent Bit 自身的日誌等級
• HTTP Server：是否開啟內建的 Metrics 端點（用於監控 Fluent Bit 自身的健康狀態）

適用場景#

Fluent Bit 最適合的情境：

• Kubernetes 環境的日誌收集，需要自動附加 Pod Metadata
• 需要統一收集多種來源的資料（日誌檔、systemd、TCP/UDP 等）
• 需要同時送資料到多個後端（Loki + S3、Elasticsearch + Kafka 等）
• 團隊希望用一個工具處理日誌 + Metrics + Traces
• 資源受限的環境，需要極低的記憶體佔用

Fluent Bit 與 Promtail 的取捨#

Fluent Bit 的設定靈活度是把雙面刃。插件眾多、選項豐富，但也意味著初次設定的學習曲線比 Promtail 陡峭不少。如果你的需求真的只是「把日誌送到 Loki」，不要為了「以後可能用到」而過度工程化。

小結#

Fluent Bit 是資料收集領域的瑞士刀——輕量、高效能、可插拔、多輸出。它在 Kubernetes 生態系中的廣泛採用不是偶然，而是因為它在「資源佔用」與「功能豐富度」之間找到了一個極佳的平衡點。當你的需求超出「單一後端的日誌收集」時，Fluent Bit 是最值得優先評估的選擇。