為什麼需要一個中間層？#
想像一個由十個微服務組成的系統，每個服務都直接把 Trace 資料送到 Jaeger。某天團隊決定從 Jaeger 換到 Tempo，你需要修改十個服務的設定，重新部署十次。如果同時還想把一份 Trace 送到 Datadog 做 APM 分析呢？再改十次。
OTel Collector 的核心價值就是消除這個耦合。 應用程式只需要把資料送到 Collector，至於最終送往哪裡——Tempo、Jaeger、Datadog，或同時送往三個——由 Collector 的設定決定，跟應用程式無關。
這就是標題所說的依賴反轉：應用程式不再依賴具體的後端，而是依賴一個抽象的中間層。未來不管怎麼換後端，應用程式的程式碼和設定完全不需要改動。
Pipeline 架構：Receivers → Processors → Exporters#
OTel Collector 的內部架構是清晰的三段式 Pipeline：
Receivers（接收器）#
負責接收資料。Collector 可以同時監聽多種協定和格式：
- OTLP：OpenTelemetry 的原生協定，支援 gRPC 和 HTTP
- Jaeger：接收 Jaeger 格式的資料（Thrift 或 gRPC）
- Zipkin：接收 Zipkin 格式的資料
- Prometheus：主動抓取 Prometheus Metrics 端點
一個 Collector 可以同時啟用多個 Receiver，這意味著它能統一接收來自不同語言、不同框架、不同格式的可觀測性資料。
Processors（處理器）#
資料在中間經過處理。常見的 Processor 包括：
- Batch Processor：將多筆資料打包成批次，減少網路呼叫次數
- Filter Processor：根據條件丟棄不需要的資料，例如排除健康檢查端點的 Trace
- Attributes Processor：新增、修改或刪除 Span 的屬性
- Tail Sampling Processor：在請求完成後，根據結果（錯誤、延遲）決定是否保留整條 Trace
- Resource Processor：添加環境資訊（如 Kubernetes Namespace、節點名稱）
Processor 是 OTel Collector 最強大的能力之一。在應用程式端做 Sampling 或資料轉換既複雜又不一致，但在 Collector 這個集中的中間層做，只需要維護一份設定。特別是 Tail Sampling——這個需要等待整條 Trace 完成才能做決策的操作，在應用程式端幾乎不可能實現，但 Collector 天生就適合做這件事。
Exporters（匯出器）#
處理完的資料送往最終目的地。同一份資料可以同時送往多個後端：
- 一份送 Tempo 做長期儲存
- 一份送 Jaeger 做即時查詢
- 一份送商業 APM 平台做進階分析
這種「一次收集、多處使用」的能力，是 OTel Collector 最實用的價值之一。
兩種部署模式#
OTel Collector 有兩種典型的部署方式，適用於不同場景：
Agent 模式（DaemonSet）#
每個節點部署一個 Collector，以 Kubernetes DaemonSet 或 Sidecar 形式運行。
- 就近接收本地應用程式的資料，降低網路延遲
- 可以做初步的處理（如 Batch、添加節點資訊）
- 即使中央 Collector 暫時不可用，Agent 可以做本地緩衝
Gateway 模式（集中式）#
獨立部署的 Collector 叢集，所有資料匯聚到這裡做集中處理後再送出。
- 適合做全域的聚合和路由：根據服務名稱送往不同的後端
- 適合做 Tail Sampling：需要看到完整 Trace 的所有 Span 才能做決策
- 可以做存取控制：限制哪些資料可以送往外部的商業平台
生產環境中最常見的是 Agent + Gateway 的兩層架構。Agent 部署在每個節點負責接收和初步處理，然後統一轉發到 Gateway 做全域處理和匯出。這樣既有就近收集的低延遲優勢，又有集中處理的靈活性。
不只是 Trace#
雖然這一章放在 Traces 的 Part 裡，但 OTel Collector 其實是三種信號通吃的通用資料管道：
- Traces：接收 OTLP、Jaeger、Zipkin 格式的 Trace 資料
- Metrics：接收 OTLP Metrics，甚至可以主動抓取 Prometheus 端點
- Logs：接收 OTLP Logs，也可以透過 Filelog Receiver 直接讀取日誌檔案
這意味著你可以用一套基礎設施處理所有的可觀測性資料。應用程式把三種信號都送到 OTel Collector，由 Collector 統一處理後分別送到 Mimir（Metrics）、Loki（Logs）、Tempo（Traces）。
OTel Collector 的角色和 Part 3 介紹的 Fluent Bit、Vector 有部分重疊——它們都是可觀測性資料的中間管道。差別在於 OTel Collector 是 OpenTelemetry 原生的，對 OTLP 的支援最完整；而 Fluent Bit 和 Vector 在日誌處理上有更豐富的生態系。有些團隊會同時使用——OTel Collector 處理 Traces 和 Metrics，Fluent Bit/Vector 處理 Logs。
依賴反轉的設計意義#
回到章節標題：依賴反轉不只是一個技術實作，它改變了團隊的工作方式。
- 開發者只關心埋點：應用程式只需要引入 OTel SDK，把資料送到 Collector 的 OTLP 端點。後端是什麼、資料怎麼處理，開發者完全不需要知道
- 平台團隊掌控管道：後端的選擇、取樣策略、資料路由——這些都在 Collector 的設定中，由平台團隊統一管理
- 切換後端零成本：從 Jaeger 換到 Tempo？改 Collector 的 Exporter 設定就好，不需要改任何應用程式
- 漸進式導入：可以先在少數幾個服務前面放 Collector，驗證效果後再逐步擴展
什麼時候需要 OTel Collector？#
幾乎所有生產環境都應該使用 OTel Collector。但以下場景特別受益：
- 多團隊、多語言環境：不同團隊用不同語言開發，Collector 統一了資料的入口和格式
- 需要後端靈活性：組織還在評估各種可觀測性後端，或者未來可能切換
- 需要集中的資料處理：Sampling、過濾、敏感資料遮罩等操作，在集中式 Collector 做比在每個服務端做更容易維護
- 想建立統一的可觀測性平台：OTel Collector 是「可觀測性管道」的核心，它讓你把 Traces、Metrics、Logs 三種信號串在同一條管道上
OTel Collector 本身也是需要維運的基礎設施。在高流量環境中，它需要足夠的 CPU 和記憶體來處理資料；Gateway 模式需要做好高可用設定。不要把它當成一個「部署完就不用管」的元件——監控你的監控系統是可觀測性工程中永恆的課題。