從需求到挑戰：監控Kubernetes中的GPU記憶體使用量
在我多年的DevOps工作經驗中，有些看似簡單的需求往往會演變成意想不到的技術挑戰。最近我接到一個看似直觀的任務：在Kubernetes環境中監控每個Pod的GPU記憶體使用情況，特別是Jupyter的Pod。雖然這聽起來很基礎，但實際操作卻充滿了曲折。
在面對這類別監控需求時，我通常會先評估現有解決方案，因為「重新發明輪子」往往是效率低下的。Nvidia提供了官方的DCGM-Exporter，以及一個非官方但廣受歡迎的nvidia-gpu-exporter。從檔案看，DCGM-Exporter似乎提到了與Pod關聯的功能，這正是我們需要的。
Nvidia官方監控工具的侷限性
DCGM-Exporter作為Nvidia的官方工具，理論上應該是首選。它的檔案中確實提到了$DCGM_EXPORTER_KUBERNETES環境變數，用於啟用Kubernetes Pod與監控指標的對映功能。從檔案提供的指標範例中，我們可以看到：
DCGM_FI_DEV_GPU_UTIL{gpu="",UUID="",device="",modelName="",Hostname="",DCGM_FI_DRIVER_VERSION="",container="",namespace="",pod=""}
這裡的pod標籤本應指向產生工作負載的Pod，但實際上，預設情況下它指向的是監控器Pod本身。這就是問題所在——檔案中沒有明確說明如何設定它來顯示實際工作負載Pod的名稱。
經過對論壇的深入研究，我發現許多使用者都遇到了類別似問題。常見的解決方案包括：
- 新增特定環境變數：
extraEnv:
- name: "DCGM_EXPORTER_KUBERNETES"
value: "true"
- name: "DCGM_EXPORTER_KUBERNETES_GPU_ID_TYPE"
value: "device-name" # 或 "uid"
- 確保安裝nvidia-device-plugin
- 確保kubelet、device-plugin和dcgm-exporter使用相同的目錄
- 在ServiceMonitor中增加
honorLabels: true以解決標籤衝突
雖然這些建議在某些環境中有效，但在我們的設定中卻不起作用。在嘗試了各種設定後，我決定轉向另一種方法——根據現有工具開發自己的監控解決方案。
尋找替代方案：Nvidia SMI Exporter
在決定自建監控工具前，我先評估了Nvidia SMI Exporter (Docker Prometheus Nvidia SMI Exporter)。這個工具根據nvidia-smi命令提取GPU指標，包括顯示卡統計資料和各程式的GPU使用情況。
nvidia-smi是NVIDIA提供的命令列工具，用於管理和監控NVIDIA GPU裝置。它的基本輸出如下：
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.xx.xx Driver Version: 550.xx.xx CUDA Version: 12.x |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 Tesla xxxxxxxxxxxxxx Off | 00000000:01:00.0 Off | 0 |
| N/A 29C P0 36W / 250W | 499MiB / xxxxxxxx | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 87068 /opt/java/openjdk/bin/java 496MiB |
+-----------------------------------------------------------------------------------------+
這個輸出提供了GPU的基本資訊和目前執行在GPU上的程式。關鍵是，它顯示了每個程式使用的GPU記憶體量，這正是我們需要的資訊。然而，它只提供程式ID和程式名稱，而不是Kubernetes Pod名稱。這就是我們需要解決的關鍵問題。
自建監控解決方案的思路
在評估了現有工具後，我決定根據Nvidia SMI Exporter開發自己的解決方案。核心思路是：
- 使用nvidia-smi取得GPU使用情況和程式資訊
- 建立程式ID (PID) 與Kubernetes Pod的對應關係
- 將這些資訊轉換為Prometheus指標格式
這聽起來簡單，但實際實作中有幾個技術挑戰：
挑戰一：取得程式與Pod的對應關係
在Kubernetes環境中，每個容器中的程式在主機上都有對應的PID，但這個PID與Pod名稱之間沒有直接關聯。我們需要透過一系列步驟建立這種對應關係：
- 使用Kubernetes API取得所有Pod資訊
- 對於每個Pod，取得其容器ID
- 使用容器ID在主機上查詢對應的程式
挑戰二：處理多容器Pod
Kubernetes Pod可能包含多個容器，每個容器可能有多個程式。我們需要正確識別哪些程式屬於哪個Pod的哪個容器。
挑戰三：許可權問題
要讀取主機上的程式資訊和容器詳情，我們的監控Pod需要特殊許可權。這涉及到安全考量，需要謹慎處理。
實作自建GPU監控器
根據上述思路，我設計了自己的監控解決方案。核心步驟包括：
- 佈署一個具有適當許可權的守護程式集合，在每個有GPU的節點上執行
- 定期執行nvidia-smi收集GPU使用情況
- 透過cAdvisor或直接存取容器執行時API取得容器與程式的對應關係
- 透過Kubernetes API取得Pod資訊
- 將收集到的資料轉換為Prometheus指標
這種方法的優勢在於：
- 完全掌控監控邏輯，可以根據需求進行客製化
- 直接從源頭取得資料，避免中間層的複雜性
- 可以增加更多自定義指標，不僅限於GPU記憶體使用量
實作過程中，我發現使用Go語言是較好的選擇，因為它有完善的Kubernetes客戶端函式庫rometheus指標函式庫時具有良好的效能。
從Nvidia SMI Exporter到自定義監控的轉變
在研究Nvidia SMI Exporter的原始碼時，我發現它已經實作了從nvidia-smi取得資料並轉換為Prometheus指標的功能。我只需要擴充套件它，增加Pod資訊關聯的功能。
關鍵的改進點包括：
- 增加Kubernetes客戶端，用於查詢Pod資訊
- 實作PID到Pod名稱的對映邏輯
- 在指標中增加Pod和名稱空間標籤
- 最佳化指標收集頻率，控制對系統的影響
這些改進使得監控工具能夠提供更有價值的資訊，讓我們可以直觀地看到每個Pod的GPU使用情況，而不僅是程式級別的資料。
監控解決方案的佈署與整合
完成監控工具的開發後，佈署和整合也是關鍵步驟。我選擇使用Helm 圖表管理佈署，這樣可以方便地設定和更新。
佈署架構包括：
- 一個守護程式集合，在每個有GPU的節點上執行監控Pod
- 適當的RBAC設定，確保監控Pod有許可權讀取所需資訊
- 一個ServiceMonitor，用於Prometheus自動發現和抓取指標
- 設定Grafana儀錶板，直觀顯示監控資料
在Prometheus和Grafana的整合中，我設計了幾個關鍵的
- 按Pod顯示的GPU記憶體使用量趨勢
- 按名稱空間的GPU資源分配情況
- GPU利用率與記憶體使用的對比
- 異常使用模式的警示設定
這些視覺化工具極大地提升了團隊對GPU資源使用情況的理解，也為資源最佳化提供了依據。
監控方案的實際效益與經驗教訓
實施這套自建監控解決方案後，我們獲得了以下效益：
- 精確掌握每個Jupyter Pod的GPU記憶體使用情況
- 識別出資源浪費的Pod，最佳化資源分配
- 建立了GPU使用的歷史趨勢，有助於容量規劃
- 提高了異常情況的發現速度，減少了服務中斷
從這個專案中，我總結了幾點重要經驗：
不要過度依賴官方工具：官方工具如DCGM-Exporter雖然功能全面，但設定複雜與檔案不完善，有時自建解決方案反而更簡單直接。
理解底層原理：深入理解nvidia-smi、容器執行時和Kubernetes的工作原理，是成功實作監控解決方案的關鍵。
考慮擴充套件性：設計時考慮未來可能的需求變化，如支援多種GPU型號或監控更多指標。
權衡開發成本與維護成本：自建解決方案的開發成本可能較高，但長期維護成本可能低於設定複雜的第三方工具。
未來改進方向
雖然目前的監控解決方案已經滿足了基本需求，但還有幾個可能的改進方向：
- 支援更多GPU指標，如計算利用率、溫度等
- 增加人工智慧異常檢測，根據歷史資料識別異常使用模式
- 整合資源限制建議，幫助最佳化Pod的資源請求和限制
- 支援多叢集環境的統一監控檢視
這些改進將進一步提升監控系統的價值，為GPU資源管理提供更全面的支援。
在Kubernetes環境中實作GPU資源的精細化監控是一個挑戰，但也是最佳化資源使用和確保應用效能的關鍵。當現有工具無法滿足需求時，不要害怕開發自己的解決方案。
透過深入理解底層技術並結合實際需求，我們成功構建了一個能夠精確監控Pod級別GPU使用情況的系統。這不僅解決了目前的業務需求，也為團隊積累了寶貴的技術經驗。
在技術選型時，始終記住：最佳解決方案不一定是最複雜或最官方的，而是最適合你特定需求的那一個。有時候，簡單直接的自建工具反而能帶來更大的價值。
NVIDIA-SMI-Exporter 的監控困境與解決之道
在容器化環境中監控 GPU 資源使用情況時，我們常遇到一個關鍵問題：雖然能取得 GPU 使用量資料，但難以直接關聯到特定的 Kubernetes Pod。這使得在微服務架構中追蹤 GPU 資源消耗變得相當困難。在一次為金融科技客戶最佳化 AI 基礎架構時，我發現標準的 NVIDIA-SMI-Exporter 無法提供足夠的關聯資訊，這促使我深入研究並擴充套件了這個工具。
現有 Prometheus 指標的侷限性
先來看標準 NVIDIA-SMI-Exporter 輸出的 Prometheus 指標範例：
nvidiasmi_clock_policy_auto_boost{id="00000000:01:00.0",uuid="GPU-xxxxxxxxxxx",name="Tesla xxxxxxxxxxx"} 0
nvidiasmi_clock_policy_auto_boost_default{id="00000000:01:00.0",uuid="GPU-xxxxxxxxxxx",name="Tesla xxxxxxxxxxx"} 0
nvidiasmi_process_used_memory_bytes{id="00000000:01:00.0",uuid="GPU-xxxxxxxxxxx",name="Tesla xxxxxxxxxxx",process_pid="87068", process_name="/opt/java/openjdk/bin/java",process_type="C"} 5.20093696e+08
觀察這些指標後，我注意到一個關鍵問題：雖然有 process_pid 和 process_name 等標籤，但缺乏直接對應到 Kubernetes Pod 的標籤。這使得我們無法直接瞭解哪些 Pod 正在消耗 GPU 資源，大限制了在容器環境中的監控能力。
改良版 NVIDIA-SMI-Exporter 的核心功能與運作原理
針對上述問題，我開發了增強版的 NVIDIA-SMI-Exporter，它能夠將 GPU 使用量資訊與 Kubernetes Pod 關聯起來。這個改良版本保留了原始功能，同時增加了追蹤 Pod 名稱的能力。
運作機制概述
改良版 Exporter 的工作流程如下：
資料收集：在每個配備 GPU 的 Worker 節點上佈署為服務，透過
nvidia-smi工具產生包含 GPU 特性和相關程式的 XML 檔案資料轉換：解析 XML 檔案並轉換為 Prometheus 格式的指標
Pod 資訊關聯：針對每個使用 GPU 的程式，透過新增的
LookupPod函式追蹤其對應的 Pod 資訊- 根據程式 ID 檢查 cgroup
- 從 cgroup 中提取容器 ID
- 根據容器執行時（Docker 或 containerd）查詢容器名稱
這種方式讓我們能夠將 GPU 使用量直接關聯到特定的 Kubernetes Pod，大幅提升監控的價值。
程式碼深入剖析：如何實作 Pod 資訊整合
讓我們深入探索改進版 NVIDIA-SMI-Exporter 的程式碼。我選擇使用 Go 語言開發，主要是因為原始專案也是用 Go 編寫，這樣能更容易整合新功能。
核心功能：透過 nvidia-smi 收集 GPU 資訊
首先，我們需要設計一個能夠靈活設定的方式來呼叫 nvidia-smi 工具。相較於原始版本使用硬編碼的路徑，我改用環境變數來提高靈活性：
func metrics(w http.ResponseWriter, r *http.Request) {
log.Print("Serving /metrics")
var cmd *exec.Cmd
NVIDIA_SMI_PATH, exists_path := os.LookupEnv("NVIDIA_SMI_PATH")
if exists_path == false {
NVIDIA_SMI_PATH = "/usr/bin/nvidia-smi"
}
log.Print("Path to nvidia-smi: ", NVIDIA_SMI_PATH)
cmd = exec.Command(NVIDIA_SMI_PATH, "-q", "-x")
// 執行系統命令
stdout, err := cmd.Output()
if err != nil {
println(err.Error())
if testMode != "1" {
println("Something went wrong with the execution of nvidia-smi")
}
return
}
這段程式碼的關鍵改進在於允許透過環境變數 NVIDIA_SMI_PATH 來設定 nvidia-smi 工具的路徑，若未設定則使用預設路徑。這樣一來，我們可以在不重新編譯程式碼的情況下，適應不同環境中的工具位置。
資料解析：將 XML 轉換為結構化資料
Exporter 會將 nvidia-smi 輸出的 XML 資料解析為 Go 結構體：
var xmlData NvidiaSmiLog
xml.Unmarshal(stdout, &xmlData)
為了處理 XML 資料，我定義了一個詳細的結構體來對映所有需要的欄位：
type NvidiaSmiLog struct {
DriverVersion string `xml:"driver_version"`
CudaVersion string `xml:"cuda_version"`
AttachedGPUs string `xml:"attached_gpus"`
GPU []struct {
Id string `xml:"id,attr"`
ProductName string `xml:"product_name"`
ProductBrand string `xml:"product_brand"`
DisplayMode string `xml:"display_mode"`
DisplayActive string `xml:"display_active"`
PersistenceMode string `xml:"persistence_mode"`
AccountingMode string `xml:"accounting_mode"`
AccountingModeBufferSize string `xml:"accounting_mode_buffer_size"`
DriverModel struct {
CurrentDM string `xml:"current_dm"`
PendingDM string `xml:"pending_dm"`
} `xml:"driver_model"`
Serial string `xml:"serial"`
UUID string `xml:"uuid"`
// 更多程式碼...
PCI struct {
Bus string `xml:"pci_bus"`
Device string `xml:"pci_device"`
// 更多程式碼...
} `xml:"pci"`
FanSpeed string `xml:"fan_speed"`
PerformanceState string `xml:"performance_state"`
FbMemoryUsage struct {
Total string `xml:"total"`
Used string `xml:"used"`
Free string `xml:"free"`
} `xml:"fb_memory_usage"`
// 更多程式碼...
Processes struct {
ProcessInfo []struct {
Pid string `xml:"pid"`
Type string `xml:"type"`
ProcessName string `xml:"process_name"`
UsedMemory string `xml:"used_memory"`
} `xml:"process_info"`
} `xml:"processes"`
} `xml:"gpu"`
}
這個結構體設計相當詳盡，涵蓋了 GPU 的各種屬性，包括驅動版本、CUDA 版本、PCI 資訊、記憶體使用量，以及最重要的 - 使用 GPU 的程式資訊。這些程式資訊將是我們連結到 Kubernetes Pod 的關鍵。
核心創新：從程式 ID 查詢 Pod 資訊
在開發過程中，我發現最大的挑戰在於如何從程式 ID 追蹤到對應的 Kubernetes Pod。這就是我開發的 LookupPod 函式的核心功能。這個函式透過檢查程式的 cgroup 資訊，找出容器 ID，然後根據不同的容器執行時（Docker 或 containerd）查詢容器名稱。
從我的經驗來看，這個函式的實作需要考慮多種容器環境，因為企業環境中常混合使用不同的容器執行時。我曾經在一個大型金融機構的環境中遇到同時使用 Docker 和 containerd 的情況，這促使我設計了一個能適應多種環境的解決方案。
在實際開發中，我會在下一個部分詳細介紹這個 LookupPod 函式的實作，它是整個改進方案的核心創新點。
Pod 查詢功能的實作細節
LookupPod 函式是整個改進方案的核心，它負責將程式 ID 對映到 Kubernetes Pod 名稱。讓我們深入剖析這個函式的實作細節。
從程式 ID 到容器 ID
首先，我們需要從程式 ID 找到對應的容器 ID。這是透過檢查程式的 cgroup 資訊來完成的：
func LookupPod(pid string) (string, error) {
// 讀取程式的 cgroup 資訊
cgroupFile := fmt.Sprintf("/proc/%s/cgroup", pid)
content, err := ioutil.ReadFile(cgroupFile)
if err != nil {
return "", fmt.Errorf("無法讀取 cgroup 檔案: %v", err)
}
// 使用正規表示式尋找容器 ID
containerIDPattern := regexp.MustCompile(`[0-9a-f]{64}`)
matches := containerIDPattern.FindAllString(string(content), -1)
if len(matches) == 0 {
return "", fmt.Errorf("找不到容器 ID")
}
containerID := matches[0]
// 後續將使用此容器 ID 查詢 Pod 名稱
這段程式碼首先讀取程式的 cgroup 檔案，然後使用正規表示式尋找 64 字元的十六進位制字串，這通常是容器 ID 的格式。
根據容器執行時查詢 Pod 名稱
一旦我們獲得了容器 ID，下一步是根據不同的容器執行時查詢容器名稱。我針對 Docker 和 containerd 兩種常見的執行時實作了查詢邏輯：
// 嘗試使用 Docker 查詢
dockerCmd := exec.Command("docker", "inspect", "--format", "{{.Name}}", containerID)
dockerOut, dockerErr := dockerCmd.Output()
if dockerErr == nil {
// Docker 查詢成功
podName := strings.TrimPrefix(strings.TrimSpace(string(dockerOut)), "/")
return podName, nil
}
// 嘗試使用 containerd (runc) 查詢
runcCmd := exec.Command("runc", "state", containerID)
runcOut, runcErr := runcCmd.Output()
if runcErr == nil {
// 解析 runc 輸出以取得容器名稱
var runcState map[string]interface{}
if err := json.Unmarshal(runcOut, &runcState); err != nil {
return "", fmt.Errorf("無法解析 runc 輸出: %v", err)
}
if name, ok := runcState["id"].(string); ok {
return name, nil
}
}
return "", fmt.Errorf("無法確定容器名稱")
}
這段程式碼首先嘗試使用 Docker 命令查詢容器名稱。如果失敗（可能是因為使用的是 containerd 而非 Docker），則嘗試使用 runc 命令查詢。這種雙重查詢策略使得我們的解決方案能夠在不同的容器執行時環境中正常工作。
整合到指標生成流程
最後，我們需要將 LookupPod 函式整合到指標生成流程中。對於每個使用 GPU 的程式，我們呼叫這個函式來取得對應的 Pod 名稱，並將其作為標籤增加到 Prometheus 指標中：
// 遍歷每個 GPU 上的每個程式
for _, gpu := range xmlData.GPU {
for _, process := range gpu.Processes.ProcessInfo {
podName, err := LookupPod(process.Pid)
podLabel := "unknown"
if err == nil {
podLabel = podName
}
// 將 Pod 名稱作為標籤增加到指標中
fmt.Fprintf(w, "nvidiasmi_process_used_memory_bytes{id=\"%s\",uuid=\"%s\",name=\"%s\",process_pid=\"%s\",process_name=\"%s\",process_type=\"%s\",pod=\"%s\"} %f\n",
gpu.Id, gpu.UUID, gpu.ProductName, process.Pid, process.ProcessName, process.Type, podLabel, parseNvidiaValue(process.UsedMemory))
}
}
GPU 資源監控的關鍵挑戰
在現代雲端架構中，GPU 資源監控一直是系統管理者面臨的難題。特別是在 Kubernetes 環境下，將 GPU 使用情況與特定 Pod 關聯起來更是技術挑戰。在我多年負責大規模 AI 訓練平台的經驗中，這個問題一直困擾著許多團隊。
本文將探討如何透過 Prometheus 收集 NVIDIA GPU 資料，並將這些資料與 Kubernetes Pod 名稱關聯起來，實作精確的資源監控。這套方案已在多個產品環境中證明有效，能夠幫助團隊更好地管理 GPU 資源分配。
Prometheus 指標生成機制
在分析程式碼之前，先了解我們要達成的目標：將 GPU 使用情況與 Kubernetes Pod 名稱關聯起來，以便更精確地監控資源使用。
首先看到關鍵的指標生成程式碼：
for _, GPU := range xmlData.GPU {
io.WriteString(w, formatVersion("nvidiasmi_driver_version", "id=\""+GPU.Id+"\",uuid=\""+GPU.UUID+"\",name=\""+GPU.ProductName+"\"", xmlData.DriverVersion))
io.WriteString(w, formatVersion("nvidiasmi_cuda_version", "id=\""+GPU.Id+"\",uuid=\""+GPU.UUID+"\",name=\""+GPU.ProductName+"\"", xmlData.CudaVersion))
// 處理電源狀態 - 舊版 NVIDIA-SMI
if GPU.PowerReadings.PowerState != "" {
io.WriteString(w, formatValue("nvidiasmi_power_state_int", "id=\""+GPU.Id+"\",uuid=\""+GPU.UUID+"\",name=\""+GPU.ProductName+"\"", filterNumber(GPU.PowerReadings.PowerState)))
}
// 處理電源狀態 - 新版 NVIDIA-SMI
if GPU.GpuPowerReadings.PowerState != "" {
io.WriteString(w, formatValue("nvidiasmi_power_state_int", "id=\""+GPU.Id+"\",uuid=\""+GPU.UUID+"\",name=\""+GPU.ProductName+"\"", filterNumber(GPU.GpuPowerReadings.PowerState)))
}
io.WriteString(w, formatValue("nvidiasmi_clock_policy_auto_boost", "id=\""+GPU.Id+"\",uuid=\""+GPU.UUID+"\",name=\""+GPU.ProductName+"\"", filterUnit(GPU.ClockPolicy.AutoBoost)))
io.WriteString(w, formatValue("nvidiasmi_clock_policy_auto_boost_default", "id=\""+GPU.Id+"\",uuid=\""+GPU.UUID+"\",name=\""+GPU.ProductName+"\"", filterUnit(GPU.ClockPolicy.AutoBoostDefault)))
// 處理每個程式的 GPU 使用情況
for _, Process := range GPU.Processes.ProcessInfo {
podName := LookupPod(Process.Pid)
io.WriteString(w, formatValue("nvidiasmi_process_used_memory_bytes", "id=\""+GPU.Id+"\",uuid=\""+GPU.UUID+"\",name=\""+GPU.ProductName+"\",process_pid=\""+Process.Pid+"\", pod_name=\""+podName+"\",process_name=\""+Process.ProcessName+"\",process_type=\""+Process.Type+"\"", filterUnit(Process.UsedMemory)))
}
}
內容解密
這段程式碼的核心功能是遍歷每個 GPU 裝置並生成多種 Prometheus 指標：
- 驅動版本與 CUDA 版本：記錄 NVIDIA 驅動與 CUDA 版本資訊
- 電源狀態：同時支援新舊版本 NVIDIA-SMI 的電源狀態讀取
- 時鐘策略：記錄 GPU 的自動提升狀態與預設設定
- 程式記憶體使用：這是我們最關注的部分，它記錄了每個使用 GPU 的程式所消耗的記憶體
最後一部分的 nvidiasmi_process_used_memory_bytes 指標是關鍵，它不僅包含了程式 ID、程式名稱和類別，還透過 LookupPod(Process.Pid) 函式取得了該程式所屬的 Pod 名稱。
Pod 名稱查詢機制
讓我們深入瞭解 LookupPod 函式，這是整個監控系統的核心部分：
func LookupPod(pid string) (string) {
log.Print("Pid:", pid)
f, err := os.Open(fmt.Sprintf("/proc/%s/cgroup", pid))
if err != nil {
log.Print(err)
return ""
}
defer f.Close()
scanner := bufio.NewScanner(f)
for scanner.Scan() {
line := scanner.Text()
log.Print("line:" , line)
cId := kubePattern.FindStringSubmatch(line)
log.Print("cId-test ", cId)
if cId == nil {
cId := kubePatternConD.FindStringSubmatch(line)
if cId == nil {
fmt.Fprintln(os.Stderr, "Something wrong with pattern")
return ""
}
log.Print("cId[2] ", cId[2])
fmt.Fprintln(os.Stderr, "cgroup by kuber (containerd)")
argCmd = fmt.Sprintf(`runc --root /run/containerd/runc/k8s.io/ state %s | grep '"io.kubernetes.cri.sandbox-name":' | sed 's/.*"io.kubernetes.cri.sandbox-name": "\|".*//g' `, cId[2])
} else {
log.Print("cId[2] ", cId[2])
fmt.Fprintln(os.Stderr, "cgroup by kuber (docker)")
argCmd = fmt.Sprintf(`docker inspect --format '{{index .Config.Labels "io.kubernetes.pod.name"}}' %s | tr -d '\n' `, cId[2])
}
log.Print("argCmd: ", argCmd)
out, err := exec.Command("bash","-c", argCmd ).Output()
if err != nil {
log.Print(err)
}
log.Print("Pod name: ", string(out))
podN := string(out)
return podN
}
return ""
}
內容解密
這個函式實作了從程式 ID 到 Kubernetes Pod 名稱的對映，整個流程相當巧妙：
- 讀取 cgroup 資訊：透過開啟
/proc/{pid}/cgroup檔案，取得程式的 cgroup 資訊 - 正規表示式比對：使用預定義的正規表示式從 cgroup 路徑中提取容器 ID
- 容器執行時適配：根據比對結果判斷容器執行時是 Docker 還是 containerd
- 執行系統命令：根據不同的容器執行時，執行不同的命令來取得 Pod 名稱
- 回傳 Pod 名稱：最後回傳找到的 Pod 名稱
這個函式處理了兩種不同的容器執行時系統：
- Docker：使用
docker inspect命令從容器標籤中取得 Pod 名稱 - Containerd：使用
runc state命令從容器狀態中提取 Pod 名稱
正規表示式模式分析
為了從 cgroup 路徑中提取容器 ID，系統預先定義了兩種正規表示式模式：
kubePattern = regexp.MustCompile(`\d+:.+:.*/(pod[^/]+)/([0-9a-f]{64})`)
kubePatternConD = regexp.MustCompile(`.*/(kubepods-burstable-.*)/cri-containerd-(.*).scope`)
這些模式針對不同執行時的 cgroup 路徑格式：
Docker cgroup 路徑範例：
11:blkio:/kubepods/pod387d67a0-2e0a-4418-bacb-435kk85a1b37/bbb083cc31864b731b273ab74628e7hdfg85d7cd1224391dee7c62b69201dbc6
Containerd cgroup 路徑範例：
0::/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod6ee8558e_a273_417d_9a57_57f3c7773bd4.slice/cri-containerd-2cbbbe2a9f38fa2255006fd6faed661a55f92bf6f924aae08261634jbv5ff0f67.scope
透過這些正規表示式，系統能夠從 cgroup 路徑中提取出容器 ID，進而查詢對應的 Pod 名稱。
實用改進建議
在實際佈署此監控系統時，玄貓建議考慮以下幾點改進：
- 效能最佳化：對於大型叢集，可以考慮實作一個簡單的快取機制，避免每次都需要執行系統命令
- 錯誤處理：增強錯誤處理機制，例如當容器已經終止但程式仍在執行時的處理
- 監控範圍擴充套件：除了記憶體使用外，還可以監控 GPU 使用率、溫度等指標與 Pod 的關係
- 多版本相容：隨著 Kubernetes 和容器執行時的更新，正規表示式可能需要調整，建議實作一個更靈活的比對機制
監控系統架構圖
為了更直觀地理解這個監控系統，以下是一個簡化的系統架構圖：
graph TD
A[NVIDIA-SMI] -->|XML 資料| B[Prometheus Exporter]
B -->|解析 GPU 資料| C[程式到 Pod 對映]
C -->|查詢 cgroup| D[/proc/{pid}/cgroup]
C -->|執行命令| E[Docker/Containerd]
E -->|回傳 Pod 名稱| C
B -->|生成指標| F[Prometheus 指標]
F -->|暴露 HTTP 端點| G[Prometheus Server]
G -->|儲存與查詢| H[Grafana]
實際應用場景
這套監控系統在多種場景下都非常有價值：
- 資源使用稽核：精確追蹤哪些 Pod 消耗了多少 GPU 資源
- 計費系統：在多租戶環境中實作根據使用量的精確計費
- 異常檢測：識別異常的 GPU 使用模式，例如記憶體洩漏
- 資源配額管理：幫助管理員最佳化 GPU 資源分配策略
在我之前經手的一個大型 AI 研究平台中，實施了類別似的監控系統後，我們發現某些 Pod 在完成訓練後沒有釋放 GPU 記憶體，透過這套系統精確定位到問題所在，大幅提升了資源利用率。
整合到現有監控系統
如果你已經有了完整的 Kubernetes 監控系統，整合這套 GPU 監控相對簡單：
- 佈署這個 Prometheus Exporter 到所有 GPU 節點
- 在 Prometheus 設定中增加這個 Exporter 作為抓取目標
- 在 Grafana 中建立專門的 GPU 使用量儀錶板，按 Pod 名稱分組顯示
玄貓在多個環境中測試過這套方案，效果都很理想。特別是在分享 GPU 的環境中，能夠清晰看到每個 Pod 的實際資源消耗，避免了「黑盒」問題。
透過這套系統，我們不僅能夠監控 GPU 資源使用情況，更能夠將這些資訊與 Kubernetes 的工作負載關聯起來，實作更精細的資源管理。這對於執行 GPU 密集型工作負載的團隊來說，是一個極具價值的工具。
在實際實施過程中，最大的挑戰往往不是技術本身，而是如何正確解讀這些資料並據此做出決策。建議結合實際業務需求，定製專屬的監控儀錶板和告警規則，最大化這套系統的價值。
Kubernetes 環境中的 GPU 監控挑戰
在管理執行機器學習工作負載的 Kubernetes 叢集時，我經常面臨一個關鍵挑戰：如何有效追蹤每個 Pod 的 GPU 資源使用情況。雖然市面上已有許多 GPU 監控工具，但大多數只能提供裝置層級的指標，而無法直接對應到 Kubernetes 的 Pod 層級，這使得資源使用分析和問題排查變得困難。
在一個大型 ML 平台專案中，我發現要解決這個問題，需要自訂一個能夠將 GPU 使用量與 Kubernetes Pod 名稱關聯的監控解決方案。本文將分享我如何透過擴充套件現有的 NVIDIA SMI 匯出器，實作按 Pod 名稱追蹤 GPU 記憶體使用量的完整過程。
為何需要自訂 GPU 監控方案？
標準的 GPU 監控工具通常提供以下指標：
- 總體 GPU 使用率
- 總體 GPU 記憶體使用量
- GPU 溫度
- GPU 功耗
然而，這些工具往往缺少一個關鍵資訊：**哪個 Kubernetes Pod 正在使用這些資源？**當多個機器學習工作負載分享同一個 GPU 節點時，這個問題尤為重要。
監控方案設計思路
經過深入研究，我發現實作這個目標的關鍵在於建立 GPU 程式與 Kubernetes Pod 之間的關聯。這個關聯可以透過以下步驟建立：
- 使用
nvidia-smi取得使用 GPU 的程式 ID (PID) - 根據 PID 找到對應的容器 ID
- 透過容器 ID 查詢對應的 Kubernetes Pod 名稱
- 將 Pod 名稱作為標籤增加到 Prometheus 指標中
這個方法需要對容器執行時（Docker 或 containerd）有深入理解，因為不同的容器執行時使用不同的方式來儲存容器與 Pod 的關聯資訊。
自訂 NVIDIA SMI 匯出器實作
我選擇根據現有的 NVIDIA SMI 匯出器進行擴充套件，以實作這個功能。以下是關鍵實作部分：
核心函式：將 PID 對應到 Pod 名稱
首先，我們需要一個函式來將 GPU 程式的 PID 轉換為 Kubernetes Pod 名稱：
func getPodNameFromPid(pid string) (string, error) {
var podName string
var containerID string
if testMode == "1" {
log.Print("PID: ", pid)
}
// 從 /proc/{pid}/cgroup 讀取容器 ID
data, err := os.ReadFile("/proc/" + pid + "/cgroup")
if err != nil {
return "", err
}
// 解析 cgroup 內容
cgroups := strings.Split(string(data), "\n")
for _, cgroup := range cgroups {
if strings.Contains(cgroup, "docker") || strings.Contains(cgroup, "containerd") {
cId := strings.Split(cgroup, "/")
if len(cId) > 2 {
containerID = cId[2]
containerID = strings.TrimSpace(containerID)
break
}
}
}
if containerID == "" {
return "", errors.New("Container ID not found")
}
// 根據不同容器執行時查詢 Pod 名稱
if strings.Contains(cgroups[0], "docker") {
cmd := exec.Command("docker", "inspect", "--format", "{{index .Config.Labels \"io.kubernetes.pod.name\"}}", containerID)
output, err := cmd.Output()
if err != nil {
return "", err
}
podName = strings.TrimSpace(string(output))
} else if strings.Contains(cgroups[0], "containerd") {
cmd := exec.Command("sh", "-c", "runc --root /run/containerd/runc/k8s.io/ state "+containerID+" | grep '\"io.kubernetes.cri.sandbox-name\":' | sed 's/.*\"io.kubernetes.cri.sandbox-name\":\"\\|\".*//g'")
output, err := cmd.Output()
if err != nil {
return "", err
}
podName = strings.TrimSpace(string(output))
}
return podName, nil
}
這個函式首先從 /proc/{pid}/cgroup 讀取容器 ID，然後根據容器執行時（Docker 或 containerd）使用不同的命令取得 Pod 名稱。
整合到指標收集邏輯
接下來，我將這個函式整合到匯出器的指標收集邏輯中：
func metrics(w http.ResponseWriter, r *http.Request) {
// 設定 HTTP 標頭
w.Header().Set("Content-Type", "text/plain; version=0.0.4; charset=utf-8")
// 執行 nvidia-smi 命令取得 GPU 資訊
cmd := exec.Command("nvidia-smi", "--query-gpu=index,uuid,utilization.gpu,memory.total,memory.used,memory.free,driver_version,name,gpu_serial,display_active,display_mode,temperature.gpu,fan.speed,pstate,throttled.reasons.active,clocks.current.graphics,clocks.current.memory", "--query-compute-apps=pid,process_name,used_memory", "--format=csv,noheader,nounits")
stdout, err := cmd.Output()
if err != nil {
log.Print(err)
return
}
// 解析輸出並收集指標
lines := strings.Split(string(stdout), "\n")
// 省略其他指標收集邏輯...
// 處理 GPU 程式使用資訊
for _, GPU := range GPUs {
for _, Process := range GPU.Processes {
// 取得 Pod 名稱
podName, err := getPodNameFromPid(Process.Pid)
if err != nil {
podName = "unknown"
if testMode == "1" {
log.Print(err)
}
}
// 輸出包含 Pod 名稱的指標
io.WriteString(w, formatValue("nvidiasmi_process_used_memory_bytes", "id=\""+GPU.Id+"\",uuid=\""+GPU.UUID+"\",name=\""+GPU.ProductName+"\",process_pid=\""+Process.Pid+"\", pod_name=\""+podName+"\",process_name=\""+Process.ProcessName+"\",process_type=\""+Process.Type+"\"", filterUnit(Process.UsedMemory)))
}
}
}
透過這種方式，我在 nvidiasmi_process_used_memory_bytes 指標中增加了 pod_name 標籤，使我們能夠直接檢視每個 Pod 的 GPU 記憶體使用情況。
容器 ID 與 Pod 名稱的對應關係
在實際環境中，容器 ID 的格式因容器執行時而異：
- Docker 容器 ID 範例：
bbb083cc31864b731b273ab74628e7hdfg85d7cd1224391dee7c62b69201dbc6 - Containerd 容器 ID 範例：
2cbbbe2a9f38fa2255006fd6faed661a55f92bf6f924aae08261634jbv5ff0f67
根據不同的容器執行時，我們使用不同的命令查詢 Pod 名稱：
# Docker 環境
docker inspect --format '{{index .Config.Labels "io.kubernetes.pod.name"}}' <container_id>
# Containerd 環境
runc --root /run/containerd/runc/k8s.io/ state <container_id> | grep '"io.kubernetes.cri.sandbox-name":' | sed 's/.*"io.kubernetes.cri.sandbox-name":"\|".*//g'
這樣，我們就能將 GPU 使用程式與 Kubernetes Pod 關聯起來，並在指標中加入 pod_name 標籤。
函式互動流程
整個監控流程可以概括為以下步驟：
- 匯出器接收到
/metrics請求 - 執行
nvidia-smi命令取得 GPU 和程式資訊 - 對每個使用 GPU 的程式，呼叫
getPodNameFromPid函式取得 Pod 名稱 - 將 Pod 名稱作為標籤增加到指標中
- 回傳完整的指標資料
主函式設計
匯出器的主函式設計如下：
func main() {
testMode = os.Getenv("TEST_MODE")
if testMode == "1" {
log.Print("測試模式已啟用")
}
LISTEN_ADDRESS, exists_port := os.LookupEnv("NVIDIASMI_EXP_PORT")
if exists_port == false {
LISTEN_ADDRESS = ":9202"
}
log.Print("監聽連線埠: ", LISTEN_ADDRESS)
log.Print("Nvidia SMI 匯出器正在監聽 " + LISTEN_ADDRESS)
http.HandleFunc("/", index)
http.HandleFunc("/metrics", metrics)
http.ListenAndServe(LISTEN_ADDRESS, nil)
}
這個設計允許我們透過環境變數 NVIDIASMI_EXP_PORT 自定義監聽連線埠，預設為 9202。
編譯與佈署
編譯匯出器
使用以下命令編譯 Go 程式碼：
go build -o ./nvidiasmi-exporter ./main.go
系統服務佈署
我選擇將匯出器佈署為系統服務，以下是服務設定檔案：
[Unit]
Description=Nvidia-smi-exporter
ConditionPathExists=/opt/nvidiasmi-exporter
After=network.target
[Service]
Type=simple
User=root
WorkingDirectory=/opt/nvidiasmi-exporter
ExecStart=/opt/nvidiasmi-exporter/nvidiasmi-exporter
Restart=on-failure
RestartSec=10
StartLimitInterval=60
[Install]
WantedBy=multi-user.target
對於不同的容器執行時，可以增加相應的依賴關係：
# Docker 環境
After=docker.service
Requires=docker.service
# Containerd 環境
After=containerd.service
Requires=containerd.service
Grafana 中視覺化指標
在實際使用中，我將這些指標整合到了現有的 Grafana 儀錶板中。重點是展示每個 Pod 的 GPU 記憶體使用量，並按節點分組顯示。
由於我們的匯出器提供了 pod_name 標籤，我們可以使用以下 PromQL 查詢來顯示每個 Pod 的 GPU 記憶體使用情況：
sum(nvidiasmi_process_used_memory_bytes{uuid=~"GPU-$gpu"}) by (pod_name)
這裡需要注意的是，我們的匯出器與另一個名為 nvidia_gpu_exporter 的匯出器共同使用，兩者在 GPU UUID 格式上有所不同：
# nvidia_gpu_exporter 格式
uuid="2f76546a-404c-0563-5f49-815xxxxxxx"
# 我們的 nvidiasmi-exporter 格式
uuid="GPU-2f76546a-404c-0563-5f49-815xxxxxxx"
因此在查詢時需要使用模式比對 uuid=~"GPU-$gpu" 來適配兩種格式。
實際效果與收穫
完成這個自訂監控解決方案後，我們終於能夠直觀地看到每個 Pod 的 GPU 記憶體使用情況。這大提高了我們排查問題和最佳化資源分配的效率。例如，我們可以：
- 快速識別哪些 Pod 消耗了過多的 GPU 資源
- 監控特定機器學習工作負載的 GPU 使用模式
- 根據實際使用情況最佳化資源分配策略
在實施這個解決方案的過程中，我深入理解了容器執行時與 Kubernetes 的互動機制，以及如何在系統層面追蹤資源使用情況。這些經驗對於構建更全面的容器化應用監控系統非常寶貴。
透過這種自訂監控方案，我們不僅解決了目前的 GPU 監控需求，還為未來增加更多容器資源指標奠定了基礎。針對 Kubernetes 環境的監控解決方案必須能夠跨越容器邊界，將系統級指標與 Kubernetes 抽象概念（如 Pod、Deployment 等）關聯起來，這正是我們實作的核心價值。
GPU 資源在機器學習工作負載中至關重要與成本高昂，有效監控每個 Pod 的使用情況不僅能幫助我們最大化資源利用率，還能及時發現潛
Kubernetes GPU 資源監控的挑戰與解決之道
在管理大型 Kubernetes 叢集時，GPU 資源的監控一直是我面臨的重要挑戰。過去幾年，隨著機器學習和人工智慧工作負載的增加，我發現傳統監控方法已無法滿足精確追蹤每個 Pod 對 GPU 資源消耗的需求。特別是當多個團隊分享同一叢集的 GPU 資源時，缺乏精確的監控工具常導致資源爭用和效能瓶頸。
為何標準監控工具不足
標準的 Kubernetes 監控工具通常只提供基本的 GPU 使用率資訊，但無法細分到具體哪個 Pod 消耗了多少資源。這些工具通常只能顯示節點層級的 GPU 使用情況，對於需要精確計費或資源最佳化的團隊來說遠不夠。
當我在某金融科技公司建立機器學習平台時，發現這個問題尤為嚴重：資料科學家們的訓練任務常因無法追蹤各 Pod 的 GPU 資源消耗而導致效能問題難以診斷。我們需要一個能夠提供 Pod 層級 GPU 監控的解決方案。
開發自定義 GPU 監控架構
經過多次嘗試和改進，我設計了一套根據 Prometheus 和 Grafana 的自定義監控解決方案，能夠精確追蹤每個 Pod 的 GPU 資源使用情況。
監控架構的核心元件
我的監控架構包含以下關鍵元件：
- 自定義 Prometheus Exporter：透過修改現有的 GPU Exporter，使其能夠收集 Pod 層級的 GPU 使用資料
- Prometheus 伺服器：負責收集、儲存和查詢監控指標
- Grafana 儀錶板：視覺化呈現 GPU 資源使用情況，支援多維度分析
這個架構的關鍵在於能夠建立 Pod 與其使用的 GPU 資源之間的關聯，讓我們能夠回答「哪個 Pod 正在消耗多少 GPU 資源」的問題。
引數互動關係
在實作過程中，我發現引數之間的互動關係尤為重要。下面是我設計的引數互動模型：
- Pod 識別資訊：包括 Pod 名稱、名稱空間、標籤等
- GPU 資源指標：包括 GPU 記憶體使用率、計算單元使用率、溫度等
- 時間維度資料：使資源使用趨勢分析成為可能
這些引數的互動使得我們能夠建立多維度的資源使用分析檢視，幫助團隊更好地理解 GPU 資源的使用模式。
實作自定義 Prometheus Exporter
在設計監控系統後，下一步是實作自定義的 Prometheus Exporter。這是整個解決方案的核心，負責收集並暴露與 Pod 相關的 GPU 指標。
Exporter 的設計原則
我在設計 Exporter 時遵循了以下原則：
- 低開銷：Exporter 本身不應成為系統瓶頸
- 準確性：確保收集的資料準確反映 GPU 使用情況
- 可擴充套件性：支援不同類別的 GPU 和多 GPU 環境
- 容錯性：即使部分指標收集失敗，仍能提供有價值的監控資料
核心程式碼實作
下面是我實作的 Exporter 核心程式碼：
import time
import os
from prometheus_client import start_http_server, Gauge
import subprocess
import json
# 定義 Prometheus 指標
gpu_memory_usage = Gauge('pod_gpu_memory_usage_bytes',
'GPU memory usage by pod',
['pod_name', 'namespace', 'gpu_id'])
gpu_utilization = Gauge('pod_gpu_utilization_percent',
'GPU utilization percentage by pod',
['pod_name', 'namespace', 'gpu_id'])
def get_pod_gpu_mapping():
"""取得 Pod 和 GPU 的對映關係"""
mapping = {}
# 執行 kubectl 指令取得使用 GPU 的 Pod 列表
cmd = "kubectl get pods --all-namespaces -o json"
result = subprocess.run(cmd.split(), capture_output=True, text=True)
pods_data = json.loads(result.stdout)
for pod in pods_data['items']:
pod_name = pod['metadata']['name']
namespace = pod['metadata']['namespace']
# 檢查 Pod 是否請求 GPU 資源
for container in pod['spec']['containers']:
if 'resources' in container and 'limits' in container['resources']:
limits = container['resources']['limits']
if 'nvidia.com/gpu' in limits:
# 取得分配給此 Pod 的 GPU ID
gpu_ids = get_gpu_ids_for_pod(pod_name, namespace)
if gpu_ids:
mapping[(pod_name, namespace)] = gpu_ids
return mapping
def get_gpu_ids_for_pod(pod_name, namespace):
"""取得分配給特定 Pod 的 GPU ID"""
# 這裡使用 nvidia-smi 和容器 ID 來識別 GPU 分配
# 實際實作可能更複雜，需要考慮容器執行時和 GPU 外掛
cmd = f"kubectl exec -n {namespace} {pod_name} -- nvidia-smi --query-gpu=index --format=csv,noheader"
try:
result = subprocess.run(cmd.split(), capture_output=True, text=True, timeout=5)
if result.returncode == 0:
return [int(gpu_id.strip()) for gpu_id in result.stdout.split('\n') if gpu_id.strip()]
except Exception as e:
print(f"Error getting GPU IDs for pod {pod_name}: {e}")
return []
def collect_metrics():
"""收集 GPU 使用指標並暴露給 Prometheus"""
pod_gpu_mapping = get_pod_gpu_mapping()
for (pod_name, namespace), gpu_ids in pod_gpu_mapping.items():
for gpu_id in gpu_ids:
# 收集 GPU 記憶體使用情況
cmd = f"kubectl exec -n {namespace} {pod_name} -- nvidia-smi --id={gpu_id} --query-gpu=memory.used --format=csv,noheader,nounits"
try:
result = subprocess.run(cmd.split(), capture_output=True, text=True, timeout=5)
if result.returncode == 0:
memory_used = float(result.stdout.strip()) * 1024 * 1024 # 轉換為位元組
gpu_memory_usage.labels(pod_name=pod_name, namespace=namespace, gpu_id=str(gpu_id)).set(memory_used)
except Exception as e:
print(f"Error collecting memory usage for pod {pod_name}, GPU {gpu_id}: {e}")
# 收集 GPU 使用率
cmd = f"kubectl exec -n {namespace} {pod_name} -- nvidia-smi --id={gpu_id} --query-gpu=utilization.gpu --format=csv,noheader,nounits"
try:
result = subprocess.run(cmd.split(), capture_output=True, text=True, timeout=5)
if result.returncode == 0:
utilization = float(result.stdout.strip())
gpu_utilization.labels(pod_name=pod_name, namespace=namespace, gpu_id=str(gpu_id)).set(utilization)
except Exception as e:
print(f"Error collecting GPU utilization for pod {pod_name}, GPU {gpu_id}: {e}")
if __name__ == '__main__':
# 啟動 HTTP 伺服器暴露指標
start_http_server(9400)
# 定期收集指標
while True:
collect_metrics()
time.sleep(15) # 每 15 秒收集一次
內容解密
上述程式碼實作了一個自定義的 Prometheus Exporter，其核心功能包括：
定義監控指標：建立了兩個關鍵指標
pod_gpu_memory_usage_bytes和pod_gpu_utilization_percent，這些指標都包含 pod_name、namespace 和 gpu_id 標籤，使我們能夠準確追蹤每個 Pod 的 GPU 使用情況。Pod-GPU 對映：
get_pod_gpu_mapping()函式透過 kubectl 指令取得叢集中所有請求 GPU 資源的 Pod，並建立 Pod 與 GPU 之間的對映關係。取得 GPU ID：
get_gpu_ids_for_pod()函式用於確定特定 Pod 使用的 GPU 裝置 ID，這是實作 Pod 層級 GPU 監控的關鍵步驟。指標收集：
collect_metrics()函式是核心，它執行 nvidia-smi 指令收集 GPU 記憶體使用和使用率資訊，並將這些資訊與相應的 Pod 關聯起來。服務啟動：主程式啟動一個 HTTP 伺服器監聽 9400 連線埠，並定期收集 GPU 指標。
這種實作方式的巧妙之處在於它不需要修改 Kubernetes 或容器執行時，而是利用現有工具和 API 建立了 Pod 與 GPU 資源之間的關聯。
設定 Grafana 儀錶板
收集指標只是第一步，為了讓這些資料發揮價值，我設計了專門的 Grafana 儀錶板來視覺化呈現這些資料。
儀錶板設計理念
在設計儀錶板時，我遵循了以下原則：
- 清晰性：資訊呈現清晰，一目瞭然
- 多維度：支援從不同維度分析 GPU 使用情況
- 實用性：專注於對維運和開發人員有實際幫助的指標
- 可操作性：提供足夠資訊以支援資源最佳化決策
建立堆積積疊折線圖
儀錶板的核心是堆積積疊折線圖（Stacked Line 圖表），這種圖表形式非常適合展示多個 Pod 隨時間變化的 GPU 資源使用情況。以下是建立此類別圖表的 PromQL 查詢：
sum by (pod_name) (pod_gpu_memory_usage_bytes)
這個查詢按 Pod 名稱對 GPU 記憶體使用進行分組和加總，讓我們能夠清楚看到每個 Pod 的 GPU 記憶體使用趨勢。
儀錶板變數設定
為了增加儀錶板的靈活性，我設定了以下變數：
- 名稱空間：可選擇特定的 Kubernetes 名稱空間
- Pod 名稱：可過濾特定的 Pod
- GPU ID：可選擇特定的 GPU 裝置
- 時間範圍：可調整監控的時間視窗
這些變數讓使用者能夠快速切換視角，關注特定的監控目標。
實際應用成效
經過三個月的實際應用，這套監控解決方案在我管理的多個 Kubernetes 叢集中展現了顯著價值。
資源最佳化案例
在一個資料科學團隊使用的叢集中，我們透過這套監控系統發現了幾個關鍵問題：
- 某些批次處理任務在完成主要計算後仍然佔用 GPU 資源
- 部分開發 Pod 請求了 GPU 資源但實際使用率極低
- 特定時間段存在 GPU 資源爭用高峰
根據這些發現，我們實施了一系列最佳化措施：
- 修改批次處理程式碼，確保計算完成後及時釋放 GPU 資源
- 為開發環境引入資源配額，限制非必要的 GPU 使用
- 調整任務排程，避開高峰期資源競爭
這些最佳化措施帶來了約 40% 的 GPU 資源使用效率提升，大幅減少了資源爭用問題。
業務價值
除了技術層面的改進，這套監控系統還為業務帶來了實質性價值：
- 成本控制：精確瞭解各團隊和專案的 GPU 資源消耗，支援更合理的成本分攤
- 效能保障：及時發現並解決資源瓶頸，確保關鍵任務的執行效能
- 容量規劃：根據歷史使用模式，更準確地預測 GPU 資源需求，最佳化硬體投資
未來監控系統演進方向
