OTel Collector

對! 今天要聊的就是中間那個黃澄澄的Collector

Collector主要提供與vendor無關的服務, 用來receive, process和export telemetry data.
以往我們需要在業務系統中處理與負責匯出到右半邊的綠色的可觀測性三本柱的後端服務上.
現在可以把一些配置設定給集中在collector身上就好,
業務系統只要負責信號的收集與簡單的處理和匯出到OTel collector就好.

此外我們在Trace Sampling也聊到Tail-based sampling, 這個也能在collector才決定是否要被採樣存儲起來了.

Design Objectives

• Usable : 簡單的配置, 各種流行的協議與後端都支持, 開箱即用(runs and collects out of the box, 學到了新片語)
• Performant : 希望就是提供高度可靠且高性能的服務
• Observable : 總不會要求別人的系統滿足可觀測性, 當然這服務本身也要能提供可觀測性的功能
• Extensible : 可以客製化extention來擴充processor
• Unified : 這裡講的是single codebase, 社群希望開發者們能把自己的東西給提供上來回饋於社群

其中有幾個component是必要的組件

上圖要從左往右看, 由上往下看.

首先是Receiver, 再來Processor, 最後是Exporter
其中Processor與Exporter的功用, 跟之前提的是一樣的.
能參考Trace Processor和Trace Exporter

Pipeline

上圖是Collector處理資料的pipeline, 它定義了telemetry data遵循的路線.
從receiver接收到data開始, 進一步processor處理它或者修改其內容, 最後透過exporter導出去三本柱後端.
Processor也能有多組, 處理順序跟宣告順序一樣的, 這在trace processor也有提到一樣的特性. 如果中間的processor是sampler採樣器, 走之前提到的RatioBased策略, 就會在這裡把data給drop, 就不會傳遞給下一個processor了.

處理完畢的telemetry data, 會到一個名為**FanOutConnector**的處理器, 它會負責把該資料fanout扇出給有訂閱該類型的多個exporter.

以下是Pipeline在YAML設定檔的一些配置樣子
YAML剛好之前也有分享設定檔格式YAML
每個Pipeline都有一個在這份檔案裡唯一的名稱, 裡面的三個組件各自可以配置多組

# The service lists extensions not directly related to data pipelines, but used
# by the service.
services:
    <pipeline name>: # key is string, unique name of pipeline
      receivers: [receiver-name-1, receiver-name-2, ...]
      processors: [processor-name-1, processor-name-2, ...]
      exporters: [exporter-name-1, exporter-name-2, ...]

service:
  pipelines: # section that can contain multiple subsections, one per pipeline
    traces:  # type of the pipeline
      receivers: [otlp, jaeger, zipkin]
      processors: [memory_limiter, batch]
      exporters: [otlp, jaeger, zipkin]

這配置我們針對trace類型的資料, 定義了3種receiver,2種processor, 3種exporter.
若一個屬性有多個成員時, 會用YAML的ARRAY**[item1, item2, item...]**形式

[睡醒繼續寫, 今天太累了, 上第二天班就累了ZZzzz]

參考連結

OTel Collector Doc

OpenTelemetry Collector Configuration Format