延續「DCGM + Prometheus：Kubernetes 裡怎麼看懂 GPU」，這篇聚焦「從 Pod 到請求：Logs、Metrics、Tracing 如何串起 AI Serving」：先定義變因與停止線，再由實驗結果檢驗原本的直覺。

今天要回答的問題

讓單次 inference 可以追到 Pod、模型與延遲來源，建立 troubleshooting 路徑。

工程邊界

Kubernetes 指標與 GPU 指標要能對到 Pod／Namespace

DCGM Exporter 可以把 GPU telemetry 暴露給 Prometheus；重點是保留 workload labels，讓你知道某張 GPU 的 utilization、memory、temperature 或 error 對應到哪個 Pod。

再把 serving metrics 與 trace 接進來，才能從「某張卡很忙」追到「哪個 namespace、哪個模型、哪一類 request 造成 tail latency」。這才是可操作的 observability。

一個可以直接重現的起點

今天的實作原則

驗證時先固定環境與輸入，每次只改一個變因，並同時記錄操作方法與判定標準。

讓 correlation ID 跟著請求移動

這份 YAML 將「為一次請求傳遞 correlation ID 並串接 log、metric、trace」的變因與觀察欄位留在版本控制中，再由實際 workload 引用。

apiVersion: v1
kind: ConfigMap
metadata:
  name: day22-experiment
  namespace: ai-lab
data:
  change: "為一次請求傳遞 correlation ID 並串接 log、metric、trace"
  fixed: "image, model, input"
  metrics: "trace completeness, Pod identity, latency breakdown"
  repeats: "3"

驗證與落地方式

驗證可從「為一次請求傳遞 correlation ID 並串接 log、metric、trace」開始。選擇一組具有代表性的請求，讓 correlation ID 從入口一路傳到 Pod、模型與下游服務，並先校正各元件時間。接著製造一個可控制的延遲或錯誤，確認 metric、log 與 trace 能否指向同一段時間與同一個工作負載。

這篇優先比較：trace completeness、Pod identity、latency breakdown。重點不只是「有資料」，而是資料能否回答使用者受到什麼影響、哪個元件先異常，以及問題是否集中在特定 node、Pod 或 GPU。缺少 label、時間戳不一致或 cardinality 過高，都可能讓資料存在卻無法用於排障。

常見誤判

• Dashboard 有圖就認為可觀測性完成，實際事故發生時卻無法從請求追到執行位置。
• 只收集 GPU utilization，沒有同步保留 request rate、queue、latency 與 error，難以判斷因果關係。
• 所有欄位無限制寫入 label，造成 Prometheus cardinality 與儲存成本快速增加。

上線前檢查

先定義保留期限、取樣策略、敏感欄位遮蔽與必要 labels，再建立從告警到 dashboard、log 與 trace 的固定查詢路徑。版本更新後也要驗證 metric 名稱與 labels 沒有悄悄改變，避免監控仍顯示綠色，實際上資料早已中斷。

遙測管線本身也需要健康檢查。若 exporter、scrape 或儲存層中斷，告警應明確指出資料缺失，不能把空白圖表解讀成系統沒有異常。

如何閱讀結果

排障時先從使用者層的錯誤率與延遲確定影響範圍，再用 trace 縮小服務與時間區段，最後以 log 和 GPU／node metrics 驗證假設。這個順序可以減少從大量主機指標盲目搜尋的時間。

若同一請求無法在各層對齊，應把缺口視為驗證失敗，而不是依靠人工猜測補完。可觀測性的價值在於縮短不確定時間，而不是累積最多資料。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：能從請求定位 Pod、node 與 GPU 時段才算可觀測。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：能從請求定位 Pod、node 與 GPU 時段才算可觀測。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：故障注入：Pod、Node、GPU 任一層出事會怎樣。

參考資料

• Kubernetes: Schedule GPUs
• Kubernetes: Resource Management
• Kubernetes: Assigning Pods to Nodes
• NVIDIA DCGM Documentation