Vector 的定位#

Vector 是由 Datadog 開源的高效能可觀測性資料管道，用 Rust 語言撰寫。它的目標是成為一個統一的工具，取代你可能需要的多個資料收集與轉換元件。

Vector 在 2019 年首次發布，相較於 Fluent Bit（2014 年）和 Fluentd（2011 年）是個後來者。但後發也有優勢——它站在前人的肩膀上，從一開始就針對現代基礎設施的需求進行設計。

Vector 雖然由 Datadog 開源，但它不綁定 Datadog 的任何服務。你可以完全自由地將資料送往任何後端——Loki、Elasticsearch、S3、Kafka，甚至是 Datadog 的競爭對手。

Pipeline 架構：Sources、Transforms、Sinks#

Vector 的 Pipeline 架構與 Fluent Bit 概念類似，但命名與設計更為現代：

Sources（來源）#

定義資料從哪裡進入 Vector。常見的 Sources 包括：

• file：讀取日誌檔案
• kubernetes_logs：收集 Kubernetes 容器日誌
• journald：讀取 systemd Journal
• host_metrics：收集主機系統指標（CPU、記憶體、磁碟）
• internal_metrics：Vector 自身的運作指標

Transforms（轉換）#

對資料做中間處理。這是 Vector 最閃耀的環節：

• remap：使用 VRL（Vector Remap Language）做資料轉換
• filter：條件過濾
• aggregate：資料聚合
• dedupe：去重複
• route：根據條件將資料分流到不同的下游

Sinks（目的地）#

定義資料要送到哪裡：

• Loki、Elasticsearch、OpenSearch
• S3、GCS 等物件儲存
• Kafka、Pulsar 等訊息佇列
• Datadog、New Relic 等 SaaS 平台
• 另一個 Vector 實例（用於多層架構）

Vector 的差異化優勢#

Rust 的極致效能#

Vector 用 Rust 撰寫，這帶來了幾個實質的好處：

• 記憶體安全：沒有 GC（Garbage Collection）暫停，延遲表現穩定且可預測
• 高吞吐量：在基準測試中，Vector 的吞吐量通常優於 Fluent Bit，在高負載場景下差距更明顯
• 低資源佔用：雖然二進位檔體積比 Fluent Bit 大，但運行時的 CPU 和記憶體效率極高

VRL：強大的資料轉換語言#

VRL（Vector Remap Language） 是 Vector 專為資料轉換設計的領域特定語言（DSL）。相比 Fluent Bit 的 Lua 腳本或 Filter 插件，VRL 有幾個關鍵優勢：

• 型別安全：VRL 在編譯時就能檢查型別錯誤，不會在運行時才爆出意外
• 錯誤處理：強制你處理可能失敗的操作（如 JSON 解析），避免 Pipeline 因為一筆異常資料而中斷
• 表達力強：字串操作、正則表達式、條件判斷、巢狀物件存取——用簡潔的語法完成複雜的轉換
• 效能優異：VRL 被編譯成原生程式碼，比解釋型腳本（Lua）快很多

VRL 的強制錯誤處理一開始可能讓人覺得「麻煩」，但在 Production 環境中這是巨大的優勢。日誌資料充滿了各種意想不到的格式——一個沒有被處理的解析錯誤可能讓整條 Pipeline 卡住。VRL 從語言層面就防止了這類問題。

內建可觀測性#

Vector 自身就是一個可觀測的系統：

• 內建 Metrics：暴露 Prometheus 格式的指標，讓你監控 Vector 的吞吐量、錯誤率、延遲
• 內建 Health Check：每個 Sink 都有健康檢查機制
• Topology 視覺化：vector top 命令可以即時查看 Pipeline 中每個元件的狀態

「監控你的監控系統」聽起來很諷刺，但這是非常實際的需求。如果日誌收集管道靜默地失敗了——資料丟失、Pipeline 阻塞——你可能要等到出事時才發現日誌不見了。Vector 的內建可觀測性讓你能主動發現這些問題。

Vector vs Fluent Bit：如何選擇#

選 Vector 的理由：

• 你的環境有高吞吐量需求，每秒處理數十萬甚至數百萬筆事件
• 需要做複雜的資料轉換，VRL 的表達力比 Lua 腳本更適合
• 團隊重視型別安全和可靠性，不想在 Production 中遇到腳本運行時錯誤
• 願意投入較新的技術，接受生態系尚在成長的現況

選 Fluent Bit 的理由：

• 需要某個 Fluent Bit/Fluentd 特有的插件
• 偏好 CNCF 畢業專案的穩定性與社群保障
• 環境對二進位檔大小敏感（如嵌入式裝置）
• 團隊已有 Fluent 生態系的經驗，不想增加學習成本

Vector 作為 Aggregator#

Vector 不只能作為部署在每台機器上的 Agent，也能作為架構中的 Aggregator（聚合層）。

在多層架構中：

• Agent 層：每台機器上的 Vector（或 Fluent Bit）負責基本的日誌收集與初步過濾
• Aggregator 層：一組 Vector 實例接收來自所有 Agent 的資料，進行更複雜的處理——聚合、抽樣、路由、重新格式化——然後送往最終的儲存後端

這種架構的好處：

• Agent 保持輕量：複雜的轉換邏輯集中在 Aggregator，Agent 端的資源消耗最小化
• 集中管理：轉換規則只需在 Aggregator 更新，不需要逐台 Agent 重新部署
• 緩衝與重試：Aggregator 可以做更大的本地緩衝，應對後端暫時不可用的情況

如果你的團隊已經在 Agent 層用了 Fluent Bit，不一定要全面換成 Vector。一個常見的混搭架構是：Fluent Bit 當 Agent + Vector 當 Aggregator——利用 Fluent Bit 的輕量級優勢做收集，利用 Vector 的 VRL 和高效能做集中處理。

小結#

Vector 代表了資料收集工具的新一代演進——Rust 的效能、VRL 的安全轉換、內建的可觀測性，這些都是從前人的經驗中提煉出來的設計決策。它不是 Fluent Bit 的「替代品」，而是提供了不同的取捨：更高的效能天花板和更安全的資料轉換，換取了較年輕的生態系和較大的二進位檔。對於高吞吐量、複雜轉換需求的環境，Vector 是非常值得認真評估的選擇。