Kong v.s API v.s Metrics

昨天將可觀測性的第二隻本柱：trace 完成之後，今天開始準備來實踐最後一根柱子：metrics。筆者在多年前協助組織建立Kong API Management 解決方案時，其實同樣的也將 Promethus與Grafana也建置了起來。但也老實說，在初建立的時候筆者只有覺得一個帥字，因為可以透過儀表板將可以量測到的項目漂亮的展現出來，並且透過告警瓶頸將警告送出到公司的Teams頻道中，突然自己覺得對於Kong平台的掌控度提升了好幾個等級，好像很厲害。

然後？然後就沒有了。

因為例行性的維運上，筆者還是不斷協助開發同仁設定、查錯或是確認認證授權問題，鮮少打開Grafana來觀看各式各樣的儀表板。開最多的還是Kibana來查找Log訊息，並且回饋給維運的同仁發生了甚麼事情。

回頭想想，筆者認為在該環境中原生的架構並不複雜，而且環境中對於高併發壓力的情況並不多見。因此很少會特別需要去注意到，在各個環境中是不是有異常被量測到的行為。就跟trace一樣，如果沒有遇到劇烈天氣之前，都不會認知到地下水道工程的重要性。

不論如何，可觀測性的三本柱還是協助維運的重要項目，就讓這篇系列文繼續介紹下去，如何將metrics實踐在這次的題目中。

架構說明

圖 13-1 metrics 架構

實踐到了第三根本柱，架構示意圖越來越複雜了，這次特別將連接到新增節點的各指向，都用紅色標註出來，讓讀者可以更清楚理解這次新增的不同角色與資料流。

1. 請求 (Request): 使用者端 (Client) 透過 Kong Gateway 的 http://localhost:8000/my-service 發送請求。
2. API Gateway (Kong):
   • 接收請求，並根據 kong.yml 的設定，將請求轉發到後端的 .NET API。
   • 日誌 (Logs): 透過 http-log Plugin，將每筆請求的紀錄發送到 Elasticsearch。
   • 追蹤 (Traces): 透過 opentelemetry Plugin，將追蹤資料發送到 OpenTelemetry Collector。
   • 量測 (Metrics): 透過 promethus Plugin，將量測資料暴露在8001 port，讓 promethus服務透過不斷觀測的方式，將量測資料存入本體。 <=本次新增
3. 應用程式服務 (.NET API):
   • 接收到來自 Kong 的請求並處理業務邏輯。
   • 日誌 (Logs): 使用 Serilog 將結構化的日誌直接寫入 Elasticsearch。
   • 追蹤 (Traces): 使用 OpenTelemetry SDK 將追蹤資料發送到 OpenTelemetry Collector。
   • 量測 (Metrics): 程式碼同樣使用使用 OpenTelemetry SDK 將量測資料發送到 OpenTelemetry Collector。 <=本次新增
4. 遙測資料收集 (OpenTelemetry Collector):
   • 從 Kong 和 .NET API 收集追蹤資料。
   • 將收集到的追蹤資料統一導出到 Jaeger。
   • 將收集到的量測資料，透過8889 port暴露給promethus提供拉取。<=本次新增
5. 資料儲存與可視化:
   • 日誌 (ELK): Elasticsearch 儲存所有日誌，Kibana 提供 UI 介面進行查詢與分析。
   • 追蹤 (Jaeger): Jaeger 從 Collector 接收追蹤資料，並使用 Elasticsearch 作為其後端儲存。使用者可以透過 Jaeger UI 查看分散式追蹤的全貌。
   • 量測(Promethus) : 用來不斷地探測Kong(8001 port)以及API 送到 OTEL(8889 port)的metric資料，並提供給Grafana的UI ，讓管理者可以透過dashboard 查詢與分析。<=本次新增

Docker Compose 設定檔

示範目錄請切換到 ironman2025\case_ELK_Jaeger_Promethus_Grafana\

同樣的，先從這次有異動的 Docker Compose開始，關注到示範專案下的 docker-compose.yaml，這次新增的區塊如下：

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: unless-stopped
    networks:
      - kong-net
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: unless-stopped
    networks:
      - kong-net
    ports:
      - "3000:3000"
    volumes:
      - ./grafana/provisioning/:/etc/grafana/provisioning/
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SMTP_ENABLED=true
      - GF_SMTP_HOST=smtp.gmail.com:587
      - GF_SMTP_USER=你的Gmail帳號
      - GF_SMTP_PASSWORD=你的Gmail應用程式密碼
      - GF_SMTP_FROM_ADDRESS=你的Gmail帳號
      - GF_SMTP_FROM_NAME=Grafana
      - GF_SMTP_SKIP_VERIFY=true

networks:
 ... 省略...

volumes:
  esdata:
    driver: local
  prometheus_data:
    driver: local
  grafana_data:
    driver: local

上面這段簡單節錄一些重點說明，重點著重在架構圖上的相關開放port為主。

• prometheus 服務
  • container_name: 容器名稱為 prometheus。
  • ports: 對外開放 9090 連接埠（Prometheus 預設 UI）。
• grafana 服務
  • container_name: 容器名稱為 grafana。
  • ports: 對外開放 3000 連接埠（Grafana 預設 UI）。
  • environment:發出告警示範用的gmail相關資訊。
• volumes
  • 這些vulumes則是提供各個服務可持久儲存的位置。

Prometheus 的設定檔

接下來請關注到示範資料夾中prometheus的相關設定，路徑：case_ELK_Jaeger_Promethus_Grafana\prometheus\prometheus.yml，並將內容節錄說明如下：

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'kong'
    metrics_path: /metrics
    static_configs:
      - targets: ['kong-dbless:8001']

  - job_name: 'otel-collector-APIProvider'
    metrics_path: /metrics
    static_configs:
      - targets: ['opentelemetry-collector:8889']

可以注意到prometheus分別去持續執行三個工作，分別是：

• prometheus
  • targets : localhost:9090。
  • 這是promtheus 預設量測自己的狀態。
• 'kong'
  • targets : kong-dbless:8001。
  • 量測kong開放出來的 8001 port。
• otel-collector-APIProvider
  • targets : opentelemetry-collector:8889。
  • 用來持續量測OTEL Collector所開放出來的metrics。

OTEL Collector 的設定檔

由於 OTEL Collector準備要協助API Provider抓取metrics資料，提供給Prometheus取得，因此也要調整相關的設定，請關注到 case_ELK_Jaeger_Promethus_Grafana\otel-collector-config.yaml，筆者將詫異處標註出來：

...上方省略...
exporters:
  ...
  prometheus:
    endpoint: "0.0.0.0:8889"

service:
  pipelines:
  ...
    metrics:
      ...
      exporters: [debug, prometheus]
...下方省略...

可以看到這次設定檔新增的內容，為了要可以承接 API Provider，因此新增了8889 port提供prometheus使用，並在metrics區塊新增了prometheus輸出類型。

Grafana 的設定檔

接下來請關注到示範資料夾中grafana的相關設定，路徑：case_ELK_Jaeger_Promethus_Grafana\grafana\provisioning\datasources\datasource.yml，並將內容節錄說明如下：

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

這段設定是 Grafana 的資料來源（datasource）自動化設定檔，簡單說明如下：

• name: Prometheus
  資料來源的名稱為 Prometheus，方便在 Grafana 介面辨識。
• type: prometheus
  型態是 Prometheus，這樣 Grafana 才能正確解析和查詢 metrics。
• access: proxy
  代表 Grafana 會以 proxy 模式存取 Prometheus，所有查詢都會經過 Grafana 伺服器再轉發到 Prometheus。
• url: http://prometheus:9090
  指定 Prometheus 服務的位址與 port，這裡是指向 docker-compose 內部的 prometheus 服務。
• isDefault: true
  設定這個資料來源為預設，之後建立 dashboard 時會自動選用這個資料來源。

小結

今天一口氣地將所有新增的相關結點設定檔，都說明了一遍，明天將來說明，關於在Kong 中的plugin的調整，以及API應該要調整的程式內容，還請期待~