Component 介紹

昨天，我們大致了解了 OpenTelemetry 的設計理念，以及它是如何讓這些理念落地的。今天，讓我們從負責 OpenTelemetry 資料流的核心：Collector 開始介紹。

版本選擇

OpenTelemetry Collector 有兩種版本，分別是 Core 以及 Contrib。Core 裡面只包含最基本的元件，例如otlp exporter等；而 Contrib 能支援第三方的元件較多，若需要和特定的第三方進行整合，就可能需要使用 Contrib 版本。

Collector Components

Collector 中的三個元件 Receiver、Processor、Exporter 各自分工明確，其模組化的設計，讓我們可以隨意組合，客製化自己的 telemetry data pipeline。

Collector 的設定檔以 YAML 格式呈現。receiver、processor、exporter等區塊是用來宣告元件設定的，我們必須透過service區塊來啟用這些元件。若需宣告多種相同類型的元件，則可以在 key 值後面加上自定義的名字就可以。範例如下：

receivers:
  # 兩種相同的otlp元件，使用/[name] 來做區別
  otlp/trace:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
  otlp/metrics:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
  jaeger:
    endpoint: jaeger:14250
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp/trace]
      processors: [batch]
      exporters: [prometheus]
    metrics:
      receivers: [otlp/metrics]
      processors: [batch]
      exporters: [jaeger]

由於許多元件除了由 OpenTelemetry 核心團隊所開發外，也有許多來自開源社群的元件可以使用，因此我會直接找到該元件的 README，照著說明進行設定即可。在以下介紹元件的小章節中也會提供各元件的 GitHub 路徑給各位參考。

Receivers

Receiver 可以透過 pull 或者 push 的方式來收集來自不同來源的 telemetry，包含 Metrics, Logs, Traces, Baggage（*註1） 都可以收集。我們可以參照 Core 和 Contrib 專案底下的 Receiver 路徑來找到適合自身需求的 Receiver。

若我今天想要接收應用程式端使用 SDK 打過來的 telemetry，就可以使用 otlp receiver，按照官方文件設定如下：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

其他常見的 Receiver 還包括：

• Prometheus Receiver: 用來 scrape Prometheus metrics
• Filelog Receiver: 讀取檔案系統中的 log 檔案
• Jaeger Receiver: 接收 Jaeger 格式的 traces

Processor

通過 receiver 送進來的 telemetry 資料會接著被送到 processor 進行加工處理。Processor 是可選的元件，可以對資料進行批次處理、過濾、轉換等操作，例如我們可以針對收進來的資料額外加上attribute，或者根據現有的attribute進行修改等。我們可以參照兩個專案底下的 processor 路徑來找到適合的 Processor。

Batch Processor 可以讓資料累積到一定的數量之後再進行處理。這樣的批次處理可以讓資料被更好地壓縮，也能避免頻繁的資料傳輸。根據官方建議，每個 Collector 都應該要有 batch processor，因為它可以顯著提升效能、降低後端服務的負載。

同時，它也被建議要放在 memory_limit 和 sampling processor 後面。因為只有被篩選過的資料才需要做批次傳輸。

在這裡，我們也可以發現，在 Collector 中是可以設定 processor 在 pipeline 當中的處理順序的。

processors:
  batch:
    timeout: 1s # 若資料沒有累積到 send_batch_size，但已經超過1秒，資料也會被強製發送
    send_batch_size: 1024

Exporter

Exporter 負責將處理過的資料送到最終的儲存後端或者下游系統。可以參照exporter 路徑來找到適合的 exporter。

即便不直接將資料送進既有的監控工具或服務，也可以透過OTLP Exporter，以 OTLP 格式送到其他 Collector 或支援 OTLP 的後端：

exporters:
  otlp:
    endpoint: [your-grpc-ednpoint-url] # 可以是任何支援 gRPC 的 endpoint
    tls:
      insecure: true
  otlphttp:
    endpoint: [your-http-ednpoint-url] # 可以是任何支援 HTTP 的 endpoint
    encoding: json # 預設是protobuf, 但也可以選擇使用json

結語

今天我們深入了解了 Collector 的三大元件：Receiver、Processor、Exporter，並且學會了如何透過 YAML 設定檔來組合這些元件。透過模組化的設計，我們可以靈活地建構符合需求的資料處理管線。明天我們將會探討 Collector 的不同部署策略，包括 Agent 模式和 Gateway 模式的選擇考量。

參考資料

OpenTelemetry - batchprocessor

OpenTelemetry Docs - Collector Configuration

OpenTelemetry - otlpexporter

OpenTelemetry - otlpreceiver