OpenTelemetry Collector 是一個與廠商無關、用於收集與處理 Telemetry Data 的 Agent。它能接收不同格式的 Traces、Metrics、Logs，再以可組合的 Pipeline 匯出到不同後端。雖然應用程式可以直接把資料寫往 Tempo 或 Jaeger，但這會讓服務與後端強耦合：後端故障、需要更換、或想加一段資料處理時，都得回頭改程式碼。Collector 作為服務與後端間的中介層，達到了「依賴反轉」的效果，並提供豐富的 Processor 來進行轉換、過濾、Sampling 等動態調整，全部透過設定檔即可完成。

Core 與 Contrib 兩個版本#

OpenTelemetry Collector 在 GitHub 上分為兩個 Repository：

  • Core：提供最基本的元件。
  • Contrib：包含各種額外元件，例如 Routing Connector、Kafka Receiver 等都只在 Contrib 提供。

選用前先確認所需元件屬於哪個版本，必要時直接採用 Contrib。

部署模式#

官方文件整理了三種主要部署模式，可依架構複雜度與彈性需求權衡：

  • No Agent：應用程式直接寫往後端。
    • 優點：架構單純、上手快。
    • 缺點：服務與後端強耦合，調整資料處理就得改程式碼。
  • Agent：應用程式 → Collector → Backend。
    • 優點：能在 Collector 額外處理資料，解耦應用與後端，免改程式碼。
    • 缺點：多了一個元件需要維運與擴展。
  • Gateway：應用程式 → Gateway Collector → 多個下游 Collector → Backend。
    • 優點：類似從單體拆成微服務的概念，不同 Collector 可專注於不同類型資料或不同後端，整體更有彈性。
    • 缺點：架構最為複雜，需考慮 Gateway 自身的高可用與監控。

多加 Collector 帶來彈性，也帶來新的單點故障與維運成本，導入時務必補上對應的監控與備援機制。

設定檔結構#

Collector 的設定檔採用 YAML，主要分為兩類 Section：宣告元件的 receivers、processors、exporters、connectors、extensions，以及定義實際行為的 service。整體輪廓如下：

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  otlp:
    endpoint: otelcol:4317

connectors:
  forward:

extensions:
  health_check:
  pprof:
  zpages:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
  telemetry:
    metrics:
      level: detailed
      address: 0.0.0.0:8888
  extensions:
    - health_check
    - pprof
    - zpages

同一類型元件可以宣告多個實例，於 Key 後加 /[name] 區分，例如 otlp/trace、otlp/metrics；只有 Key、沒有 value 則表示全部採預設值。

Receiver#

最常用的 Receiver 是 OTLP Receiver，可同時接收 Traces、Metrics、Logs：

receivers:
  otlp:
    protocols:
      grpc: # 預設 0.0.0.0:4317
      http: # 預設 0.0.0.0:4318

針對不同 Protocol 還有 CORS、TLS 等進階設定可調整。

Exporter#

Collector 支援多種 Exporter，例如同時把資料以 OTLP 格式送往 Tempo 與 Jaeger：

exporters:
  otlp:
    endpoint: tempo:4317
    tls:
      insecure: true
  otlp/jaeger:
    endpoint: jaeger-collector:4317
    tls:
      insecure: true

兩者實際上都是 otlp 類型，透過命名後綴區分。

Processor#

Processor 是資料加工層，常見功能包含過濾、轉換、Sampling 等。官方強烈建議啟用的是 Batch Processor，將資料暫存後分批處理可顯著降低傳輸負擔：

processors:
  batch:

Service#

service Section 把前面宣告的元件實際串接起來，主要包含 pipelines、extensions、telemetry 三個部分。Pipeline 範例如下：

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Pipeline 也分為 traces、metrics、logs 三種類型，各自處理對應資料；同一類型可以建立多個 Pipeline，用 /[name] 區分（例如 traces/jaeger、traces/tempo）。Processor 順序會影響資料處理流程，需特別注意。

Extensions 用於啟用 Collector 自身的額外功能，例如 health_check：

service:
  extensions:
    - health_check

Telemetry 則用於揭露 Collector 自身的觀測資料，便於外部監控：

service:
  telemetry:
    metrics:
      level: detailed
      address: 0.0.0.0:8888

Connector#

Connector 同時扮演某個 Pipeline 的 Exporter 與另一個 Pipeline 的 Receiver，是 Pipeline 之間的橋樑。Forward Connector 可用來把多條 Pipeline 匯流成一條，常見於先各自處理、再共享後段批次與輸出邏輯的情境：

connectors:
  forward:
service:
  pipelines:
    logs/blue:
      exporters: [forward] # 各自上游處理後丟進 forward
    logs/green:
      exporters: [forward]
    logs: # 匯流後再批次輸出
      receivers: [forward]
      processors: [batch]
      exporters: [bar]

更多 Connector 類型（如 Routing、Span Metrics）與完整範例請參考官方文件。

小結#

OpenTelemetry Collector 透過 Receiver、Processor、Exporter（Collector 概念）與 Connector 的組合，把 Telemetry Data 的處理流程拆成可重組的 Pipeline。它讓服務只需關心「把資料送往 Collector」，而後端、抽樣與資料轉換策略則收斂在 Collector 設定檔中。對於已經有多個後端、或預期未來會調整資料處理邏輯的團隊，Collector 是降低耦合與擁抱演化的核心元件。

原文出處#

  • 原書/iThome：https://ithelp.ithome.com.tw/articles/10336143
Backward 資料保留期 Vector Forward