在 Graylog 中，Pipelines 提供了比 Extractors 更高階、更靈活的日誌處理方式。它允許訊息在寫入 OpenSearch 前，依照自訂邏輯經過「多階段處理流程」，可以判斷、轉換、增補或清理字段。若 Extractors 適合規律性高的訊息解析，那麼 Pipelines 則專注於複雜條件判斷與動態處理。

為什麼要使用 Pipelines

Extractors 雖然簡單，但一旦需求包含「條件判斷」、「跨字段運算」或「不同來源需不同解析」，就會顯得不足。Pipelines 可以：

• 基於規則，針對不同來源做不同邏輯。
• 補充額外欄位，例如地理資訊、狀態標記。
• 修正或清理不一致的資料格式。
• 提升靈活性，避免在來源端做過度複雜處理。

Pipelines 的運作方式

一個 Pipeline 由三個主要元件構成：

• Stages：處理階段，訊息會依序流經。
• Rules：規則，每個規則可包含條件 (when) 與動作 (then)。
• Functions：Graylog 內建的函數，用於解析、轉換或運算。

範例關係：訊息 → Pipeline (Stage1 → Stage2…) → 匹配規則 → 執行動作。

Pipeline rules 範例

簡單規則範例

以下範例檢查輸入訊息是否有 5xx 的 HTTP status code，若有則新增一個 boolean 欄位，標示此訊息是否為錯誤：

rule "mark_http_error"
when
  to_long($message.status) >= 500
then
  set_field("is_error", true);
end

• 當 status >= 500 時，新增字段 is_error = true。
• 在查詢時就能快速過濾錯誤訊息。

JSON 處理範例

假設輸入訊息的 details 欄位內容是 JSON：

{"ip":"192.168.1.10","user":"alice"}

我們可以將其中的 IP 與 user 拆分：

rule "parse_details_json"
when
  has_field("details")
then
  let js = parse_json(to_string($message.details));
  set_fields(js);
end

結果會自動新增兩個新欄位：

• ip = 192.168.1.10
• user = alice

最佳實踐

• 先規劃後處理：將格式單純的解析留給 Extractors，複雜邏輯交由 Pipelines。
• 分階段設計：每個 Stage 與 Rule 專注單一任務，便於維護。
• 測試與回溯：利用 Graylog 內建的 Pipeline Simulator 驗證規則。
• 避免冗長規則：將常用邏輯抽象化，維持乾淨的 Pipelines。

Pipelines 是 Graylog 的「運算中心」，讓訊息能在儲存前進一步被加工與優化。它與 Extractors 互補：前者負責基礎結構化，後者提供進階邏輯與條件運算。