Fluentd到Fluent Bit遷移指南

作者：岱軍 2025-07-04 02:00:00

本文介紹了從 Fluentd 遷移到 Fluent Bit 的原因、區別、方法和注意事項。遷移能帶來更高的性能、更好的遙測支持和更靈活的配置。建議逐步遷移，并考慮采用遙測管道架構。

譯自：A Guide To Migrating From Fluentd To Fluent Bit^[1]
作者：Anurag Gupta

編者注：本文是系列文章的一部分。另請閱讀基于 Manning 圖書的節選，“使用 Kubernetes 的 Fluent Bit^[2]”：

Fluentd 創建于 14 年前，至今仍是企業中部署最廣泛的日志收集技術之一。Fluentd 的分布式插件架構和高度寬松的許可使其成為云原生計算基金會 (CNCF)^[3]的理想選擇，現已成為畢業項目。然而，企業現在正被遙測數據淹沒，需要具有更高性能、對不斷發展的模式和格式的更多原生支持以及更高的處理靈活性的解決方案。Fluent Bit 應運而生。

Fluent Bit^[4] 最初在 Fluent 生態系統^[5] 中作為一個子項目發展，后來從 Fluentd 擴展到支持所有遙測類型——日志、指標和追蹤。Fluent Bit 現在是兩者中更受歡迎的一個，擁有超過 150 億的部署，并被 Amazon^[6]、Google^[7]、Oracle^[8] 和 Microsoft^[9] 等公司使用。Fluent Bit 還與 OpenTelemetry^[10] 信號、格式和協議完全一致，這確保了用戶能夠隨著遙測數據的增長和發展而繼續處理這些數據。

作為這些項目的維護者，我們最常被問到的問題包括：

? 我們如何遷移？
? 我們應該注意什么？
? 遷移能給我們帶來什么商業價值？

本文旨在通過示例回答這些問題。我們希望讓從 Fluentd 遷移到 Fluent Bit^[11] 成為一個簡單的決定。

為什么要遷移？

以下是用戶從 Fluentd 切換到 Fluent Bit 的一些原因：

1. 在您已使用的相同資源上獲得更高的性能
2. 完全支持 OpenTelemetry 的日志、指標和追蹤，以及 Prometheus 對指標的支持
3. 更簡單的配置和路由到多個位置的能力
4. 更快地添加自定義處理規則
5. 集成監控以更好地了解性能和數據流

Fluentd 與 Fluent Bit：有什么區別

背景

要了解項目之間的所有差異，重要的是要了解每個項目的背景以及它所構建的時代。對于 Fluentd，主要語言是 Ruby，最初旨在幫助用戶將數據推送到 Hadoop 等大數據平臺。該項目遵循分布式架構，插件在安裝和部署主二進制文件后安裝。

另一方面，Fluent Bit 是用 C 編寫的，專注于在較小的系統（容器、嵌入式 Linux）中的超高性能。該項目借鑒了 Fluentd 的插件，而是選擇完全嵌入式插件，這些插件是核心二進制文件的一部分。

性能

從 Fluentd 切換到 Fluent Bit 的明顯區別和主要價值在于性能。使用 Fluent Bit，您可以使用相同的資源處理的日志量可能比原來高 10 到 40 倍，具體取決于您使用的插件。Fluent Bit 從一開始就被編寫為具有超高性能，專注于盡可能快地傳輸數據以進行數據分析。后來，人們發現性能足夠高效，可以在不影響使代理盡可能快的使命的情況下添加更多的邊緣處理。

路由

Fluent Bit 的其他部分是從 Fluentd 遇到的挑戰演變而來的，例如緩沖和路由。對于 Fluentd，多路由是事后才考慮的，用戶需要“復制”數據流以將數據路由到多個點。這使得配置管理成為一場噩夢，此外還基本上復制了路由數據的資源需求。

在 Fluent Bit 中，緩沖區存儲一次，這允許多個插件“訂閱”數據流。這確保了數據存儲一次并訂閱多次，從而允許進行多路由，而無需在性能和配置疲勞之間進行權衡。

遙測信號焦點

雖然 Fluentd 最初是一個數據傳輸器，但它后來發展成為一個日志記錄代理，用于 Kubernetes^[12] 等項目和 Splunk 等公司。另一方面，Fluent Bit 最初是一個嵌入式指標收集器，日志文件隨后才進入。隨著 Fluent Bit 的采用開始超過 Fluentd 的功能，添加了 OpenTelemetry 日志/指標/追蹤、Prometheus Scrape 和 Remote Write 支持、eBPF 和分析支持等功能。

今天，Fluent Bit 與 OpenTelemetry 模式、格式和協議保持一致，旨在成為一種輕量級實現，具有高度的性能。

自定義處理

Fluentd 和 Fluent Bit 具有許多相同的處理器名稱，但在自定義處理方面，選項卻大不相同：

? 對于 Fluentd，選項是 enable_ruby，它允許在配置中使用自定義 Ruby 腳本來執行操作。這對于小型任務可以有效地工作；但是，隨著邏輯變得越來越復雜，它會帶來很大的懲罰，從而增加了更多的性能瓶頸。
? 對于 Fluent Bit，自定義處理是用 Lua 語言完成的，這提供了極大的靈活性。但是，與 Fluentd 不同，Fluent Bit 的 Lua 處理器性能非常出色，可以大規模使用（100+ TB/天）。

自定義插件

這兩個項目都允許自定義插件來幫助您連接到源或目標。對于 Fluentd，這些自定義插件是“Ruby Gems”，您可以下載并將其安裝到現有或新的安裝或部署中。對于 Fluent Bit，自定義插件是用 Go 編寫和編譯的。還有一些新的舉措，允許您用您想要的任何語言編寫自定義插件，并將它們編譯成 WebAssembly。

我們從 Fluentd 的分布式插件架構中吸取的一個教訓是，插件的數量可能會呈指數級增長。然而，通常所需的高質量和維護使得許多插件被放棄且不受支持。對于 Fluent Bit，插件都集成到源代碼本身中，這確保了與每個版本的兼容性。自定義插件仍然獨立于主存儲庫。但是，我們正在尋找方法，允許它們也共享主 GitHub 存儲庫中本機 C 插件的相同優勢。

監控

了解數據如何在您的環境中傳輸通常是部署 Fluentd 或 Fluent Bit 的用戶提出的首要請求。對于 Fluentd，啟用這些設置可能需要通過“monitor_agent”或使用第三方 Prometheus 導出器插件進行復雜的配置。這些監控插件也增加了 Fluentd 的維護開銷，這會影響性能。

Fluent Bit 將監控作為其核心功能的一部分，并且可以通過本機插件（fluentbit_metrics）檢索，或者可以在 HTTP 端口上進行抓取。Fluent Bit 的指標也比 Fluentd 的包含更多信息，這使您可以了解字節、記錄、存儲和連接信息。

如何開始從 Fluentd 遷移到 Fluent Bit

我們要回答的下一個問題是：如何開始？

第一個重要步驟是了解 Fluentd 的部署方式、環境中發生的處理以及數據流向何處。

您無需擔心什么：

1. 架構支持： 兩個應用程序都支持 x86 和 ARM。

2. 平臺支持： Fluent Bit 支持與 Fluentd 今天相同的平臺，甚至更多。舊系統可能有所不同；但是，重要的是要注意，這些系統在任何 OSS 項目中都沒有維護。

3. 正則表達式： 如果您使用 Onigmo 解析器庫構建了一個大型正則表達式庫，您可以放心地知道 Fluent Bit 支持它。

部署

作為代理部署（Linux 或 Windows 包）

當 Fluentd 作為代理部署在 Linux 或 Windows 上時，其主要功能是收集本地日志文件或 Windows 事件日志，并將它們路由到特定目標。值得慶幸的是，Fluent Bit 的本地收集能力與 Fluentd 的能力相同，包括在失敗時恢復、存儲上次收集的日志行和本地緩沖的能力。

在 Kubernetes 中作為 DaemonSet 部署

如果 Fluentd 在您的 Kubernetes 集群中作為 DaemonSet 運行，您應該首先檢查正在運行的鏡像。由于 Fluentd 具有分布式插件，因此 DaemonSet 鏡像可能包含特定的插件，這確保您可以直接從讀取 Kubernetes 日志到最終目標。此示例^[13] 包含 OpenSearch 和 Kafka 作為插件，因此您應該驗證您使用的鏡像是否具有與 Fluent Bit 相同的插件。Fluent Bit 還支持對所有日志進行 Kubernetes 富集，提供有關命名空間、pod、標簽等的數據。

作為聚合器/收集器部署

如果您的 Fluentd 部署用于從 syslog、網絡設備或 HTTP 請求收集日志，您可以首先驗證 Fluent Bit 是否具有相同的功能。例如，Fluent Bit 具有 syslog、TCP、HTTP 和 UDP 插件，可以覆蓋大多數這些用例。此外，Fluent Bit 還可以接收 OpenTelemetry HTTP1/gRPC、Prometheus Remote Write、HTTP gzip 和 Splunk HTTP Event Collector (HEC) 作為額外的入站信號。