Pod 層級的排程指標

Gthulhu 提供由 eBPF 驅動的 Pod 層級排程指標，讓您在不修改應用程式程式碼的情況下，觀察叢集中每個 Pod 的底層核心排程行為。

概述

指標收集管線運作方式如下：

graph LR
    A[核心 tracepoints
sched_switch / sched_process_exit] -->|per-PID 資料| B[eBPF hash map
task_metrics]
    B -->|每 N 秒輪詢| C[Go Collector
+ PodMapper]
    C -->|聚合為 per-Pod| D[Prometheus /metrics]
    D --> E[Grafana 儀表板]
    C -->|透過 API 查詢| F[Web GUI]
    C -->|EWMA + 分群| G[Adaptive Classification]

1. eBPF tracepoints（tp_btf/sched_switch、tp_btf/sched_process_exit）在核心層捕捉每個 PID 的排程事件。
2. Go Collector 定期讀取 BPF hash map，並透過 /proc/<pid>/cgroup 將 PID 對映到 Pod。
3. 每個 PID 的指標聚合為 Pod 層級指標，並透過 Prometheus 和 REST API 公開。

可用指標

Prometheus 指標名稱使用 gthulhu_pod_ 前綴，例如：

• gthulhu_pod_voluntary_ctx_switches_total
• gthulhu_pod_involuntary_ctx_switches_total
• gthulhu_pod_cpu_time_nanoseconds_total
• gthulhu_pod_wait_time_nanoseconds_total
• gthulhu_pod_run_count_total
• gthulhu_pod_cpu_migrations_total
• gthulhu_pod_process_count

所有指標帶有以下標籤：pod_name、pod_uid、namespace、node_name。

設定指標收集

您可以透過 Web GUI 或 PodSchedulingMetrics CRD 建立指標收集設定。

方式一：Web GUI

1. 登入 Gthulhu Web GUI（存取方式請參閱設定排程策略）。
2. 在側邊欄中點選 Pod Metrics。
3. 點擊 New Config 開啟設定面板。

填寫以下欄位：

儲存後，設定立即生效——每個節點上的 eBPF 收集器將開始追蹤匹配 Pod 的行程。

方式二：PodSchedulingMetrics CRD

如果您偏好宣告式設定，可以套用 PodSchedulingMetrics 自訂資源：

apiVersion: gthulhu.io/v1alpha1
kind: PodSchedulingMetrics
metadata:
  name: monitor-upf
  namespace: default
spec:
  labelSelectors:
    - key: app
      value: upf
  k8sNamespaces:
    - free5gc
  commandRegex: ".*"
  collectionIntervalSeconds: 10
  enabled: true
  metrics:
    voluntaryCtxSwitches: true
    involuntaryCtxSwitches: true
    cpuTimeNs: true
    waitTimeNs: false
    runCount: false
    cpuMigrations: false

使用以下指令套用：

kubectl apply -f pod-scheduling-metrics.yaml

每個節點上的 CRD Watcher 會偵測到該資源，並動態更新 eBPF 監控範圍。

檢視執行時期指標

Web GUI

在 Pod Metrics 頁面，Latest Collected Metrics 表格會顯示即時資料：

隨時點擊 Refresh 可取得最新資料。

REST API

您也可以透過程式化方式查詢執行時期指標：

# 列出所有指標設定
curl -H "Authorization: Bearer $TOKEN" \
  http://localhost:8080/api/v1/pod-scheduling-metrics

# 取得最新收集的執行時期指標
curl -H "Authorization: Bearer $TOKEN" \
  http://localhost:8080/api/v1/pod-scheduling-metrics/runtime

執行時期端點回傳的 JSON 回應如下：

{
  "success": true,
  "data": {
    "items": [
      {
        "namespace": "free5gc",
        "podName": "upf-pod-abc123",
        "nodeID": "worker-1",
        "voluntaryCtxSwitches": 15234,
        "involuntaryCtxSwitches": 892,
        "cpuTimeNs": 4820000000,
        "waitTimeNs": 120000000,
        "runCount": 16126,
        "cpuMigrations": 47
      }
    ],
    "warnings": []
  }
}

Prometheus 與 Grafana

指標透過 monitor 的 Prometheus 端點匯出（預設埠號 9090）。您可以：

1. 將 Gthulhu monitor 新增為 Prometheus 抓取目標。
2. 使用 Grafana 建立儀表板，視覺化各 Pod 的排程行為。

範例 PromQL 查詢：

# 每個 Pod 的自願上下文切換速率
rate(gthulhu_pod_voluntary_ctx_switches_total[5m])

# 過去一小時每個 Pod 的 CPU 時間
increase(gthulhu_pod_cpu_time_nanoseconds_total[1h])

# 非自願上下文切換最多的前 10 個 Pod
topk(10, rate(gthulhu_pod_involuntary_ctx_switches_total[5m]))

Adaptive Classification

Adaptive Classification 會根據 Pod 的短期與長期排程行為，自動辨識工作負載型態與可能的排程瓶頸。它使用收集到的 Pod 層級指標建立 EWMA（指數加權移動平均）輪廓，並透過自適應分群模型將 Pod 標記為不同類型，協助您判斷是否需要調整 CPU、優先權或 NUMA 配置。

在 Pod Metrics 頁面的 Adaptive Classification 表格中，您可以依以下條件篩選結果：

表格欄位說明如下：

分類器階段

工作負載類型

Drift 與建議動作

Drift 分數表示短期 EWMA 與長期 EWMA 的平均偏差，並以長期變異量標準化。當分數大於 1.5 時會進入 drifting 狀態；若連續 3 個週期維持高偏移，會確認為 transitioning，代表工作負載型態可能已改變。

先決條件