本文說明如何監控使用預留容量建立的 A4X Max、A4X、A4、A3 Ultra 或 A3 Mega Compute Engine 執行個體。具體來說，本文說明如何使用 Cloud Monitoring 資訊主頁，找出獨立運算執行個體或 Slurm 叢集中的效能瓶頸並進行疑難排解。使用這些資訊主頁有助於減少工作負載的停機時間和效能問題。
建立或使用預先建構的 Monitoring 資訊主頁監控獨立運算執行個體或 Slurm 叢集時，您可以監控下列項目：
運算執行個體健康狀態
GPU 效能
網路傳輸效率
區塊和子區塊之間的網路效率
機器學習 (ML) 工作負載效率
進度落後項目偵測
事前準備
監控工作負載前，請先完成下列步驟 (如尚未完成)：
瞭解工作負載監控服務 Google Cloud ：
本文中的指標使用 Monitoring 資訊主頁。瞭解 Monitoring 資訊主頁、Monitoring 保留期限和 Monitoring 定價。
使用 Google Cloud 控制台存取 Google Cloud 服務和 API 時，無須設定驗證。
限制
只有在符合下列所有條件的運算執行個體上執行的工作負載，才支援這份文件中的指標：
- 運算執行個體必須建立為獨立的 Compute Engine 執行個體，或是 Slurm 叢集的一部分。
- 運算執行個體必須是使用預留容量建立。
- 運算執行個體必須使用 A4X Max、A4X、A4、A3 Ultra 或 A3 Mega 機器系列。
- 不過，落後偵測功能也支援使用 A3 Mega 機器系列的虛擬機器 (VM) 執行個體。
如要監控機器學習工作負載指標，請為工作負載設定監控機制。
落後偵測指標有下列額外限制：
必要的角色
如要取得監控 AI Hypercomputer 工作負載指標所需的權限，請要求管理員授予您下列 IAM 角色：
-
如要在 Cloud Monitoring 中查看指標：
專案的「Monitoring 編輯者」 (
roles/monitoring.editor) -
如要在 Logging 中查看落後偵測記錄：
專案的記錄檢視器 (
roles/logging.viewer)
如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和組織的存取權」。
這些預先定義的角色具備監控 AI Hypercomputer 工作負載指標所需的權限。如要查看確切的必要權限，請展開「Required permissions」(必要權限) 部分：
所需權限
如要監控 AI Hypercomputer 工作負載的指標，必須具備下列權限：
-
如要查看資訊主頁：
monitoring.dashboards.get專案 -
建立資訊主頁：
monitoring.dashboards.create在專案上 -
如要查看記錄項目：
logging.logEntries.list專案
可用的指標
視應用情況而定，您可以使用下列指標監控運算執行個體和 Slurm 叢集：
如要監控附加至運算執行個體的 GPU 健康狀態、效能和網路效能，請參閱「基礎架構指標」。
如要監控機器學習工作負載中 GPU 的效率，請參閱「機器學習工作負載指標」。
如要監控機器學習工作負載中疑似進度落後且效能緩慢的運算執行個體，請參閱「進度落後偵測指標」。
如要瞭解如何查看這些指標，請參閱本文的「指標視覺化」一節。
基礎架構指標
如要監控附加至運算執行個體的 GPU 健康狀態、效能和網路效能，可以使用下列指標：
如要查看 Compute Engine 中可用的指標總覽，請參閱Google Cloud 指標。
GPU 健康指標
如要監控 GPU 健康狀態，請使用下列指標：
| 名稱 | 指標類型 | 支援的機器系列 | 說明 |
|---|---|---|---|
| 機台狀態 | machine/machine_status |
A4X Max、A4X、A4、A3 Ultra 或 A3 Mega | 運算執行個體使用的機器是否正常運作，或機器健康狀態不佳，需要修復。 |
| NVSwitch 狀態 | instance/gpu/nvswitch_status |
A4X Max、A4X、A4、A3 Ultra 或 A3 Mega | 附加至運算執行個體的 NVIDIA GPU 是否發生 NVLink 交換器問題。 |
| VM 基礎架構健康狀態 | instance/gpu/infra_health |
A4X、A4、A3 Ultra 或 A3 Mega | 叢集、區塊、子區塊和主機的健康狀態，以及運算執行個體執行的主機。如果這項指標顯示運算執行個體的基礎架構不正常，指標也會說明問題。 |
| VM 故障預測分數 | instance/gpu/failure_prediction_score |
A4X、A4、A3 Ultra 或 A3 Mega |
運算執行個體執行的主機在接下來五小時內發生效能下降的機率。這個值可介於 0.0 至 1.0 之間。如果值在一段時間內持續接近 1.0，運算執行個體就越有可能效能降低。在這種情況下，建議您將工作移至其他運算執行個體，如果運算執行個體發生問題，請將其主機回報為有故障。 |
GPU 效能指標
如要監控 GPU 的效能，請使用下列指標：
| 名稱 | 指標類型 | 支援的機器系列 | 說明 |
|---|---|---|---|
| 累積情境使用率 | instance/gpu/accumulated_context_utilization_seconds |
A4X Max、A4X、A4、A3 Ultra 或 A3 Mega | GPU 忙於處理工作負載的總時間 (以秒為單位)。 |
| GPU 耗電量 | instance/gpu/power_consumption |
A4X Max、A4X、A4、A3 Ultra 或 A3 Mega | 主機上個別 GPU 的耗電量 (瓦特)，以十進位值表示。如果運算執行個體附加多個 GPU，這項指標會分別提供主機上每個 GPU 的耗電量。 |
| SM 使用率 | instance/gpu/sm_utilization |
A4X Max、A4X、A4、A3 Ultra 或 A3 Mega | 如果值不為零，表示 GPU 上的串流多處理器 (SM) 正在使用中。 |
| GPU 溫度 | instance/gpu/temperature |
A4X Max、A4X、A4、A3 Ultra 或 A3 Mega | 主機上個別 GPU 的溫度 (攝氏)，以十進位值表示。如果運算執行個體附加多個 GPU，這項指標會分別提供主機上每個 GPU 的溫度。 |
| GPU 熱餘裕 | instance/gpu/tlimit |
A4X Max、A4X、A4、A3 Ultra 或 A3 Mega | 以攝氏 (℃) 和十進位值表示的熱空間，指出個別 GPU 因溫度過高而需要減速前，還能承受的溫度。如果運算執行個體附加多個 GPU，這項指標會分別提供主機上每個 GPU 的散熱空間。 |
GPU 網路效能指標
如要監控 GPU 的網路效能，請使用下列指標：
| 名稱 | 指標類型 | 支援的機器系列 | 說明 |
|---|---|---|---|
| 連結電信業者變更 | instance/gpu/link_carrier_changes |
A4X、A4、A3 Ultra 或 A3 Mega | 網路連結載波在一分鐘內變更的頻率。 |
| 網路 RTT | instance/gpu/network_rtt |
A4X、A4、A3 Ultra 或 A3 Mega | 網路資料在來源和目的地之間往返所需的封包往返時間，以微秒為單位。 |
| 區塊間的網路流量 | instance/gpu/network/inter_block_tx |
A4X、A4、A3 Ultra 或 A3 Mega | 區塊間的網路流量位元組數。 |
| 子區塊間的網路流量 | instance/gpu/network/inter_subblock_tx |
A4X、A4、A3 Ultra 或 A3 Mega | 子區塊之間的網路流量位元組數。 |
| 子區塊內網路流量 | instance/gpu/network/intra_subblock_tx |
A4X、A4、A3 Ultra 或 A3 Mega | 單一子區塊內的網路流量位元組數。 |
| NVLink 運作速度 | instance/gpu/nvlink_active_speed |
A4X Max、A4X、A4、A3 Ultra 或 A3 Mega | 目前的存取連結埠速度 (以 GBps 為單位)。 |
| 處理量 Rx 位元組 | instance/gpu/throughput_rx_bytes |
A4X、A4、A3 Ultra 或 A3 Mega | 從網路流量接收的位元組數。 |
| 處理量 TX 位元組 | instance/gpu/throughput_tx_bytes |
A4X、A4、A3 Ultra 或 A3 Mega | 傳輸至網路流量的位元組數。 |
GPU 嚴重錯誤指標
如要監控 GPU 遇到的錯誤，以及可能導致運算執行個體停止運作或對效能造成負面影響的錯誤，請使用下列指標：
| 名稱 | 指標類型 | 支援的機器系列 | 說明 |
|---|---|---|---|
| NVLink 執行階段錯誤 | instance/gpu/nvlink_runtime_error |
A4X Max 或 A4X | 是否發生 NVLink 執行階段錯誤。 |
| 無法修正的 DRAM ECC 錯誤 | instance/gpu/dram_uncorrectable_ecc_error_count |
A4X Max 或 A4X | GPU 動態隨機存取記憶體 (DRAM) 中無法修正的錯誤修正碼 (ECC) 數量。 |
| 無法修正的 DRAM 列重新對應次數 | instance/gpu/dram_uncorrectable_row_remapping_count |
A4X Max 或 A4X | GPU DRAM 中無法修正的錯誤導致的資料列重新對應次數。 |
| 無法修正的 DRAM 列重新對應失敗 | instance/gpu/dram_row_remapping_failed |
A4X Max 或 A4X | GPU DRAM 中的資料列重新對應是否因下列其中一個問題而失敗：
|
| 無法修正的 PCIe 錯誤 | instance/gpu/pcie_fatal_error_count |
A4X Max 或 A4X | 無法修正的周邊元件互連高速 (PCIe) 錯誤數量。 |
| 無法修正的快取 ECC 錯誤 | instance/gpu/cache_uncorrectable_ecc_error_count |
A4X Max 或 A4X | 快取記憶體中無法修正的 ECC 數量。 |
機器學習工作負載指標
如要監控機器學習工作負載的生產力 (具體來說是有效輸送量)，請使用下列指標：
| 名稱 | 指標類型 | 支援的機器系列 | 說明 |
|---|---|---|---|
| 有效工作時間 | workload/goodput_time |
A4X、A4、A3 Ultra 或 A3 Mega | 工作負載執行有效處理量活動所花費的時間 (以秒為單位)。這些活動是實用的核心工作，例如模型訓練期間的前向或後向傳遞。 |
| 非有效處理時間 | workload/badput_time |
A4X、A4、A3 Ultra 或 A3 Mega | 工作負載用於 badput 活動的時間 (以秒為單位)。 這些活動是額外工作，例如載入或預先處理訓練資料。 |
進度落後項目偵測指標
延遲偵測指標可協助您發現並找出疑似延遲的項目。 進度落後項目是單點故障，不會導致系統當機，但最終會拖慢整個工作負載。
如要監控 VM 的進度落後偵測功能，請使用下列指標：
| 名稱 | 指標類型 | 支援的機器系列 | 說明 |
|---|---|---|---|
| 疑似進度落後的項目 | instance/gpu/straggler_status |
A4X、A4、A3 Ultra 或 A3 Mega | VM 是否疑似為影響工作負載效能的落後者。建議您只在其他指標顯示工作負載發生問題時，才對疑似落後的執行個體採取行動。 |
您也可以在 A4X、A4、A3 Ultra 或 A3 Mega 執行個體的記錄項目中，查看落後偵測指標。舉例來說，您可以使用下列查詢：
| 說明 | 查詢 |
|---|---|
| 特定 VM 的記錄，其中可能含有落後者。使用這項查詢，檢查專案中特定工作負載是否有任何疑似落後項目。 |
logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
將
OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
|
| 專案的落後偵測記錄。如果未偵測到疑似落後者，請使用這項查詢來確認落後者偵測服務是否正在執行。(由於限制，您無法依特定 VM 篩選記錄檔，找出疑似落後的 VM。) |
|
對於大規模機器學習工作負載，進度落後偵測指標特別實用，原因如下：
大規模機器學習工作負載非常容易受到落後者影響。大規模 ML 工作負載會使用同步且大量分散式運算。(換句話說，這些系統有許多高度相互依存的元件，而且這些元件會同時執行)。這個架構會導致大規模機器學習工作負載非常容易受到單點故障影響，例如落後者。
在大型機器學習工作負載中，很難發現並找出落後者。 請注意，單點故障分為兩種：
停止失敗：導致整個系統停止運作的失敗，例如主機錯誤和維護事件。這類問題相對容易偵測及解決。
緩慢失敗：導致效能嚴重降低，但不會造成當機的失敗。這類錯誤很難找出並偵錯。
由於這類工作負載的失敗速度緩慢，因此本質上難以發現和找出，尤其是在大規模同步工作負載中。
查看指標
如要查看運算執行個體和 Slurm 叢集的指標，請按照下列步驟使用 Monitoring 資訊主頁：
如要查看基礎架構指標和進度落後偵測指標，請按照下列步驟操作：
如要查看機器學習工作負載指標，請參閱設定工作負載監控功能的說明文件。
如要查看延遲偵測記錄，請參閱這篇文章。
如果使用資訊主頁時遇到問題，請參閱「排解效能緩慢問題」。
使用預先建構的資訊主頁
您可以透過為 AI Hypercomputer 預先建構的 Monitoring 資訊主頁，查看運算執行個體和 Slurm 叢集的指標。您也可以複製預建的資訊主頁，然後根據需求修改。
如要使用 AI 超級電腦的預先建構資訊主頁，請按照下列步驟操作：
-
前往 Google Cloud 控制台的「Dashboards」(資訊主頁) 頁面：
如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。
在「名稱」欄中，按一下下列其中一個資訊主頁的名稱，視您要查看的指標而定：
如要監控運算執行個體健康狀態、GPU 效能和偵測落後者，請使用「Cluster Director Health Monitoring」(叢集導向器健康狀態監控) 資訊主頁。
如要進一步瞭解如何使用這些指標找出及分析問題，請參閱 GCE 互動式應對手冊 - Cluster Director 監控健康狀態應對手冊資訊主頁。
如要監控網路傳輸效率，請使用「Cluster Director Transmission Efficiency」(Cluster Director 傳輸效率) 資訊主頁。
如要監控區塊和子區塊之間的網路效率，請使用 Cluster Director Block Network 資訊主頁。
如要進一步瞭解如何使用這些指標找出及分析問題，請參閱 GCE Interactive Playbook - Cluster Director Block Network 劇本資訊主頁。
系統會開啟所選資訊主頁的詳細資料頁面。您可以使用工具列中的時間範圍選取器，變更資料的時間範圍。
選用：如要複製資訊主頁並自訂內容，以符合您的需求，請按一下 「複製資訊主頁」。
建立自訂資訊主頁
如要建立自訂 Monitoring 資訊主頁，請按照下列步驟操作：
選擇要監控的指標。如尚未查看，請參閱本文中的「可用指標」。
查看進度落後項目偵測記錄
如要使用Logs Explorer查看落後偵測記錄，請完成下列步驟：
-
前往 Google Cloud 控制台的 「Logs Explorer」頁面：
如果您是使用搜尋列尋找這個頁面，請選取子標題為「Logging」的結果。
這個頁面預設會查詢專案中的所有記錄。按一下「停止查詢」。
使用工具列中的時間範圍選取器，選取要分析的時間範圍。
在「Query」(查詢) 窗格中，輸入用於偵測落後記錄的查詢。
按一下 [Run Query] (執行查詢)。
以下是偵測到落後者的記錄項目範例。
{
...
"jsonPayload": {
...
"@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
"suspectedStragglersDetection": {
"numNodes": 4,
"nodes": [
{
"latencyMs": 9,
"instanceId": "INSTANCE_ID_1"
},
{
"latencyMs": 9,
"instanceId": "INSTANCE_ID_2"
},
{
"instanceId": "INSTANCE_ID_3",
"latencyMs": 4
},
{
"instanceId": "INSTANCE_ID_4",
"latencyMs": 0
}
],
"message": "Suspected stragglers detected."
}
},
"resource": {
"type": "project",
"labels": {
"project_id": "PROJECT_NUMBER"
}
},
...
"severity": "INFO",
"logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
...
}
記錄項目包含下列欄位：
numNodes：專案中偵測到的疑似落後運算執行個體數量。在這個範例中，系統偵測到四個疑似進度落後的運算執行個體。instanceId：系統偵測到疑似落後者的運算執行個體 ID。