Fluent Bit 與 Fluentd 日誌收集組態詳解

– 8 分鐘閱讀

Fluentd 和 Fluent Bit 作為常用的日誌收集工具，在架構和功能上有很多共通點，但實際組態語法和使用場景卻有所不同。Fluent Bit 以輕量高效著稱，適合資源受限的環境如嵌入式系統或邊緣裝置，其組態檔案採用 INI 格式，結構簡潔明瞭。Fluentd 則功能更為豐富，提供彈性的外掛機制和處理能力，適用於複雜的日誌處理和轉發場景，其組態檔案則以 XML 格式為主，設定更為精細。在 Kubernetes 環境中，Fluentd 常以 DaemonSet 方式佈署，確保每個節點都能收集日誌，Fluent Bit 則更常整合於容器內，減少資源消耗。理解兩者的特性和組態差異，才能根據實際需求選擇合適的工具，構建高效的日誌管理系統。

Fluent Bit 的基本組態與運作原理

Fluent Bit 是一種高效能的日誌收集與處理工具，其組態與運作原理與 Fluentd 既有相似之處，也有其獨特的特點。在本章中，我們將探討 Fluent Bit 的組態方式、啟動選項以及日誌層級的控制。

Fluent Bit 的組態方式

Fluent Bit 的組態可以透過組態檔案或命令列引數來完成。組態檔案提供了更清晰的結構和可讀性，而命令列引數則簡化了佈署過程。

組態檔案示例

以下是一個基本的 Fluent Bit 組態檔案示例，用於接收 HTTP 請求並將日誌輸出到控制檯：

[SERVICE]
    Flush 1
    Daemon Off
    Log_Level info

[INPUT]
    Name http
    Host 0.0.0.0
    Port 18080

[OUTPUT]
    Name stdout
    Match *

命令列引陣列態

Fluent Bit 也可以完全透過命令列引數進行組態，例如：

fluent-bit -i tcp://0.0.0.0:28080 -o stdout

這條命令組態 Fluent Bit 從 TCP 埠 28080 接收日誌並輸出到控制檯。

Fluent Bit 的啟動選項

Fluent Bit 提供了多種啟動選項，可以根據不同的需求進行組態。

多輸入源組態

Fluent Bit 不侷限於單一的日誌來源，可以透過命令列引數新增多個輸入源。例如，在 Windows 環境下新增 winlog 事件：

fluent-bit -i tcp://0.0.0.0:28080 -i winlog -o stdout -vv

這條命令除了從 TCP 埠 28080 接收日誌外，還會收集 Windows 日誌事件，並透過 -vv 引數提高日誌層級，顯示更多的執行資訊。

日誌層級控制

Fluentd 和 Fluent Bit 都支援相同的命令列引數和組態選項來控制內部日誌層級。日誌層級可以透過命令列引數或組態檔案進行設定，共有五個層級：trace、debug、info、warn 和 error。

日誌層級對應的命令列引數和組態設定

| 日誌層級 | 命令列引數 | 組態設定 | |

|

-|

-| | Trace | -vv | Log_Level trace | | Debug | -v | Log_Level debug | | Info | | Log_Level info | | Warning | -q | Log_Level warn | | Error | -qq | Log_Level error |

Fluentd 和 Fluent Bit 組態比較

儘管 Fluentd 和 Fluent Bit 在功能上有很多相似之處，但它們的組態檔案語法卻有所不同。以下是一個使用 HTTP 組態的 Fluent Bit 和 Fluentd 的組態比較：

Fluent Bit 組態

[SERVICE]
    Flush 1
    Daemon Off
    Log_Level info

[INPUT]
    Name http
    Host 0.0.0.0
    Port 18080

[OUTPUT]
    Name stdout
    Match *

Fluentd 組態

<system>
    Log_Level info
</system>

<source>
    @type http
    port 18080
</source>

<match *>
    @type stdout
</match>

組態比較分析

透過比較兩者的組態，可以看出它們在語法結構上有所不同。Fluent Bit 使用 INI 風格的組態檔案，而 Fluentd 則使用 XML 風格的組態檔案。不過，兩者在功能實作上是相似的，都定義了輸入源、輸出目標以及日誌處理規則。

Fluentd 與 Fluent Bit 組態差異分析

Fluentd 和 Fluent Bit 是兩款流行的日誌收集和處理工具，廣泛應用於容器化和 Kubernetes 環境中。儘管它們具有相似的功能，但在組態語法和結構上存在一些關鍵差異。

組態語法比較

Fluentd 和 Fluent Bit 的組態語法有以下主要區別：

  • 指令定義：Fluentd 使用尖括號（<>）來定義指令，而 Fluent Bit 則使用方括號（[]），並且指令的終止是隱式的，由下一個指令或檔案結尾決定。
  • 通用組態：Fluentd 使用 system 來定義通用組態，而 Fluent Bit 則使用 SERVICE 指令。
  • 外掛定義：Fluentd 使用 @type 來定義要使用的外掛，而 Fluent Bit 使用 Name 屬性。
  • 輸出匹配：Fluentd 使用 Match 指令來定義輸出匹配規則，而 Fluent Bit 則使用 OUTPUT 指令並透過 Match 屬性來定義匹配規則。

Fluent Bit 組態檔案詳解

以下是一個典型的 Fluent Bit 組態檔案範例：

# Hello World 組態檔案，將透過 TCP 協定接收事件，埠為 18080
[SERVICE]
    Flush 1
    Daemon Off
    Log_Level info

# 定義 TCP 源，用於提供日誌事件
[INPUT]
    Name tcp
    Listen 0.0.0.0
    Port 18080

# 接受所有日誌事件，無論標籤如何，並將其寫入控制檯
[OUTPUT]
    Name stdout
    Match *

組態解說

  1. SERVICE 段：定義了 Fluent Bit 的通用組態值。

    • Flush：控制 Fluent Bit 將日誌快取重新整理到輸出通道（如 stdout 和 stderr）的頻率。在此範例中，設定為每 1 秒重新整理一次。
    • Daemon：決定 Fluent Bit 是否應作為守護程式執行。
    • Log_Level：設定日誌級別。

  2. INPUT 段：定義了日誌事件的輸入源。

    • Name：指定輸入外掛名稱，此處為 tcp。
    • Listen 和 Port：定義了監聽的 IP 地址和埠。

  3. OUTPUT 段：定義了日誌事件的輸出目的地。

    • Name：指定輸出外掛名稱，此處為 stdout，表示將日誌輸出到控制檯。
    • Match：定義了匹配規則，* 表示匹配所有日誌事件。

Fluent Bit 中的匹配規則順序

在 Fluent Bit 中，匹配規則的順序非常重要。以下是一個範例組態，展示了匹配規則的順序如何影響日誌事件的處理：

# 將所有日誌事件傳送到本地檔案 test.out
[OUTPUT]
    Name file
    Path ./test.out
    Match *

# 將所有日誌事件寫入控制檯
[OUTPUT]
    Name stdout
    Match *

在這個範例中，由於第一個 OUTPUT 段匹配了所有日誌事件並將其傳送到檔案 test.out，因此沒有日誌事件會到達第二個 OUTPUT 段，即控制檯輸出。

使用 Dummy 外掛進行測試

Fluentd 和 Fluent Bit 都內建了一個名為 dummy 的輸入外掛，可以用於測試。讀者可以嘗試修改相應的 HelloWorld.conf 檔案，加入 dummy 源，然後啟動 Fluentd 和 Fluent Bit，以觀察結果。

Kubernetes 中的 Fluentd 佈署

Fluentd 經常與 Kubernetes 一起使用，用於日誌管理。在 Kubernetes 中，Fluentd 通常透過 DaemonSet 的形式佈署，以收集節點上的日誌事件。以下是一個範例 DaemonSet 組態檔案：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
    version: v1
spec:
  selector:
    matchLabels:
      k8s-app: fluentd-logging
      version: v1
  template:
    metadata:
      labels:
        k8s-app: fluentd-logging
        version: v1
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master

組態解說

  • DaemonSet：確保在每個工作節點上執行一個 Fluentd Pod，以收集本地容器的日誌事件。
  • tolerations：允許 Fluentd Pod 在 master 節點上執行。

透過這種方式，Fluentd 可以有效地收集 Kubernetes 環境中的日誌事件，並將其轉發到指定的目的地。

在 Kubernetes 與容器中佈署 Fluentd

在現代化的日誌管理中，Fluentd 是一個重要的工具，它能夠有效地收集、處理和轉發日誌資料。在 Kubernetes 環境中，Fluentd 可以透過 DaemonSet 的方式進行佈署，確保每個節點上都執行一個 Fluentd 例項。

使用 DaemonSet 佈署 Fluentd

DaemonSet 是 Kubernetes 中的一種資源物件，用於在叢集中的每個節點上執行一個 Pod。對於日誌收集這種需要在每個節點上執行的任務來說，DaemonSet 是一種非常合適的佈署方式。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-forward
        env:
        - name: FLUENT_FORWARD_HOST
          value: "REMOTE_ENDPOINT"
        - name: FLUENT_FORWARD_PORT
          value: "18080"
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

內容解密：

  • apiVersion 和 kind 定義了 Kubernetes 資源的型別，這裡使用的是 DaemonSet。
  • spec 部分定義了 DaemonSet 的規格，包括選擇器、範本等。
  • tolerations 部分允許 Fluentd Pod 在具有特定汙點（taint）的節點上執行，例如 master 節點。
  • containers 部分定義了 Pod 中的容器，這裡使用的是 Fluentd 的官方映象。
  • env 部分設定了環境變數，用於組態 Fluentd 的轉發目標。
  • resources 部分定義了容器的資源限制和請求。
  • volumeMounts 和 volumes 部分定義了容器內部的掛載點和主機上的路徑，用於存取日誌檔案。

Dockerized Fluentd

除了使用 DaemonSet 佈署 Fluentd 外，也可以透過 Docker 容器引擎來佈署。Fluentd 和 Fluent Bit 都提供了預先構建的 Docker 映象，可以直接使用。

使用 Fluentd UI

Fluentd 提供了一個 Web UI，用於簡化組態和管理。要安裝 Fluentd UI，需要執行以下命令：

gem install -V fluentd-ui
fluentd-ui setup
fluentd-ui start

存取 http://localhost:9292 即可進入 Fluentd UI 的登入介面。

內容解密：

  • gem install -V fluentd-ui 命令安裝了 Fluentd UI。
  • fluentd-ui setup 命令進行初始化設定。
  • fluentd-ui start 命令啟動了 Fluentd UI 服務。

安全考慮

預設情況下，Fluentd UI 使用 HTTP 協定，這在生產環境中是不安全的。可以使用以下方法來提高安全性：

  1. 使用反向代理（例如 Nginx 或 Apache Server）來新增 SSL/TLS 支援。
  2. 組態 Puma（Ruby 應用伺服器）以使用 SSL/TLS 證書。

內容解密：

  • 使用反向代理可以增加一層安全性，並且不需要修改 Fluentd UI 的程式碼。
  • 組態 Puma 需要修改 Ruby 程式碼和啟動引數，這可能會增加維護的複雜度。

綜上所述，Fluentd 可以透過多種方式佈署在 Kubernetes 環境中，並且提供了 Web UI 用於簡化管理。然而，在生產環境中使用時，需要考慮安全性問題，並採取適當的措施來保護 Fluentd UI。

Fluentd 的概念、架構與佈署

Fluentd UI 的使用與組態

預設情況下，Fluentd UI 的登入使用者名稱為 admin，密碼為 changeme。登入後，UI 介面如圖 2.14 所示。由於 UI 具有反應式和回應式特性，因此根據用於檢視 UI 的裝置不同，佈局可能會有所調整。

組態 Fluentd 節點

要使 Fluentd 節點正常運作，需要提供一些組態值。點選 Setup Fluentd 可進入組態行為的 UI，如圖 2.15 所示。

Fluentd UI 的限制

對於生產環境，建議使用 Git 等工具控制 Fluentd 組態檔，而非透過 UI 進行組態變更。這樣可以確保變更的可控性和環境的一致性，降低「組態漂移」的風險。因此，建議僅在實驗目的下使用 Fluentd UI，而非在生產環境中使用。

Fluentd UI 的功能與操作

在組態欄位中設定預設值後，將 Config File 選項切換至指向現有的 HelloWorld.conf 檔案，用於執行 Fluentd。同時，也可以提供程式識別碼（PID）和日誌檔案的其他位置。點選 UI 中的 Create 按鈕後，如果位置和檔案可讀寫，則伺服器程式將啟動。UI 將切換到不同的首頁，如圖 2.16 所示。

導航選單與日誌檢視

左側的導航選單提供了豐富的功能，包括組態檔案的操作、日誌存取和錯誤日誌等。顯示的日誌與控制檯輸出相同。導航選單允許檢視已安裝的外掛程式、推薦的外掛程式和更新的外掛程式的詳細資訊。

組態檔的編輯與外掛程式管理

UI 提供了對組態檔的直接編輯功能，以及透過表單呈現的外掛程式組態介面，如圖 2.17 所示。點選 Source、Filter 或 Output 等元素可導航至對應的外掛程式組態 UI，如圖 2.18 所示。

本章重點

  • 日誌事件由標籤、時間戳和記錄組成。
  • 在多台伺服器上使用 NTP 同步時間對於確保日誌順序至關重要。
  • Fluentd 和 Fluent Bit 可佈署在大多數環境中，基礎設施要求極小。
  • 有多種方式佈署 Fluentd，包括使用 Ruby 和 RubyGems。
  • Fluentd UI 提供了視覺化組態和觀察 Fluentd 的功能，但建議僅在實驗環境中使用。

後續章節預覽

接下來的章節將探討 Fluentd 的功能和組態，包括捕捉日誌事件、儲存日誌事件到不同目的地、日誌事件路由和屬性注入等主題。這將為讀者提供足夠的知識，以建立大多數使用案例的組態。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。