Docker Compose 設定檔 - 2

架構細節設定說明

圖 11-1

扣除Day10說的kong-init的一次性任務，接下來要詳細說明有關於這次新增的這些服務所扮演的角色。

OpenTelemetry Collctor

首先會先看到，不論是Kong還是.NET API Service，都先將遙測資料都蒐集到OpenTelemetry Collector。過去筆者有個疑問，為何不直接就收攏到Jaeger就好？因為筆者最早最早的實驗，就是直接將Trace資料直接往Jaeger倒，反正可以直接查詢。

但在今年研討會DevOpsDays Taipei 2025中，筆者聽到講者們所說的那些不同類型的架構，其實跟可擴展性有一定的關係。如果如筆者前面說的將trace資料直接收攏到Jaeger中供追蹤，這代表送出遙測資料的發起端，一定要遵循Jaeger的格式將追蹤資料不斷地送入。

當一切順利的時候，當然沒有問題。但一個服務的運行，有非常多實務面上的考量。例如當Jaeger服務不被愛了(例如有人抱怨不夠美？或是被某間商用公司買走有意識形態問題？也可能是存入的一些格式原生議題？)，必須要被更換。這時候已經有大量的開發人員將自己開發的系統，已經將遙測資料都寫為Jaeger格式了，這時候就代表有大量工作需要被重新執行，這對於企業絕對不是利多。

因此，在架構上首先先將遙測資料送到OpenTelemetry Collector 是一個對於開發隊的利多作法，因為樣設計是為了彈性、相容性與可擴展性，各元件各司其職，讓整個追蹤資料流更穩定、好維護(當然，對於SRE會是一個比較辛苦需維護查錯的架構)。

設定說明

首先一定是繼續關注到本次的docker compose yaml，讀者可以參考到示範專案下路徑：ironman2025\case_ELK_Jaeger\docker-compose.yaml，節錄opentelemetry-collector部分如下：

opentelemetry-collector:
    image: otel/opentelemetry-collector:latest
    container_name: opentelemetry-collector
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "14317:4317" # OTLP gRPC receiver
      - "14318:4318" # OTLP HTTP receiver
    networks:
      - kong-net
    depends_on:
      - jaeger-collector # Depends on Jaeger Collector to send data to it

讀者應該可以注意到設定其實很簡單，其中有兩個要特別注意的部分：

• volumes：將本機的 otel-collector-config.yaml 掛載到容器內，讓 Collector 依照你的自訂設定運作。
• ports
  • 14317:4317：對外開放 OTLP gRPC 協議的接收埠。
  • 14318:4318：對外開放 OTLP HTTP 協議的接收埠。

這兩個埠讓其他服務（如 Kong、.NET API）可以把追蹤資料送進來。

另外就是關注到上面掛載進來的otel-collector-config.yaml，在與docker compose yaml同一個資料夾下，節錄如下：

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

exporters:
  otlp:
    endpoint: jaeger-collector:4317
    tls:
      insecure: true
  debug:
    verbosity: detailed

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp, debug]
    metrics:
      receivers: [otlp]
      exporters: [debug]
    logs:
      receivers: [otlp]
      exporters: [debug]

這個檔案是 OpenTelemetry Collector 的設定檔（otel-collector-config.yaml），用來定義 Collector 如何接收、處理、以及導出（export）追蹤資料、指標（metrics）、與日誌（logs）。

receivers

這是定義 Collector 要接收哪些協議的資料。設定了 otlp，同時支援 gRPC（4317）和 HTTP（4318）兩種協議。Kong 的 opentelemetry plugin 會把 trace 傳到 http://opentelemetry-collector:4318/v1/traces。

exporters

這段則是定義 Collector 要把資料送到哪裡。

• otlp： 將資料用 OTLP 協議送到 jaeger-collector:4317（這是 docker compose 裡 jaeger-collector 的服務名稱與 port）。
• debug： 把資料詳細內容輸出到 Collector 的 log，方便除錯。

service/pipelines

定義資料流動的管線（pipelines）。

• traces： trace 資料由 otlp receiver 收進來，經過 otlp 與 debug 兩個 exporter。
• metrics、logs： 同樣由 otlp receiver 收進來，經 debug exporter 輸出（但這次沒用到，還是採用傳統的往elastic search送）。

Jeager Collector

jaeger-collector:
    image: jaegertracing/jaeger-collector:latest
    container_name: jaeger-collector
    environment:
      - SPAN_STORAGE_TYPE=elasticsearch
      - ES_SERVER_URLS=http://elasticsearch:9200
      - COLLECTOR_ZIPKIN_HTTP_PORT=9411 # Optional: if you want to receive Zipkin traces
    ports:
      - "4317:4317" # gRPC
      - "4318:4318" # HTTP
      - "9411:9411" # Zipkin HTTP
    networks:
      - kong-net
    depends_on:
      elasticsearch:
        condition: service_healthy

這段設定檔主要設定在把OpenTelemetry Collector的tracing透過4317走gRPC協議收進來，並送到elasticseach:9200存入。之所以會需要需要 Jaeger Collector，因為它負責將追蹤資料轉換成 Jaeger UI 能查詢的格式並正確寫入 Elasticsearch。直接用 OTEL Collector 寫入雖然技術上可行，但 Jaeger UI 會無法正確查詢與顯示這些 trace 資料。

小結

今天花了不少篇幅說明架構中所需要用到的不同instance，明天筆者會把Kong API 完成OpenTelemetry(OTEL)的設定後，就來開始追蹤~

我們明天見~