GKE TPU 指标监控与故障排查指南基于 GKE System Metrics 与 PromQL 的 TPU 工作负载观测【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills导读本文基于开源仓库 gke-ai-troubleshooting-tpu-metrics-monitoring 技能文档系统讲解如何借助 GKE System MetricsGKE 系统指标与 PromQL 查询对 GKE 上的 TPU 工作负载、节点与节点池进行持续监控与故障排查。文章覆盖从「验证 TPU 运行时指标配置」到「计算 MTTR/MTBI 可靠性指标」的完整 8 步诊断流程读者学完后将能够确认集群是否具备 TPU 指标导出能力、识别 TensorCore 利用率与 TPU 内存水位、判定节点与多主机节点池的健康状态、按类型与原因分析节点中断事件并基于指标签名快速定位基础设施层面的根因。前置条件与适用边界本技能适用于 GKE 上 TPUTensor Processing Unit工作负载的指标驱动监控与排障典型场景包括监控 TensorCore 占空比duty cycle与 TPU 内存使用情况检查节点就绪Ready状态与多主机 TPU 节点池可用性分析主机维护maintenance或抢占preemption造成的中断计算 MTTRMean Time to Recovery与 MTBIMean Time Between Interruptions等可靠性指标。不适用场景通用非 TPU 的 GKE 工作负载监控应使用 gke-basics 等基础技能、以及非指标驱动的 TPU 调试如日志类排障可参考仓库中 gke-ai-troubleshooting-tpu-vbar-oom 等配套技能。必需上下文变量在开始任何查询前需要先独立收集可通过现有 GKE 与 Cloud 工具获取以下上下文或直接使用占位符替换变量含义是否必填{project_id}GCP 项目 ID必填{cluster_name}GKE 集群名称必填{location}GKE 集群所在地域或可用区必填{node_name}具体 GKE 节点名称可选{node_pool_name}GKE 节点池名称可选Step 1验证 TPU 运行时指标配置在分析运行时指标之前必须确认工作负载已正确配置以导出这些指标从而保证集群与容器环境具备自动抓取能力并可观测到加速器健康状况。需要核对的先决条件如下容器端口TPU 容器必须暴露containerPort: 8431Prometheus 指标抓取所必需JAX 版本若使用 JAX版本需为0.4.14或更高更早版本不会导出运行时指标GKE 版本集群版本需为1.27.4-gke.900或更高TPU 运行时指标支持的前提GKE System Metrics集群需已启用 GKE 系统指标供 Cloud Monitoring 摄取。这些版本门槛直接决定了后续查询能否取到数据属于「先配置、后观测」的硬性前置条件。Step 2监控 TPU 运行时指标配置正确后以下指标即可在 Cloud Monitoring 中查询到监控资源monitored resources为k8s_node与k8s_container。容器级指标指标说明kubernetes.io/container/accelerator/duty_cycle过去采样周期60 秒内 TPU 芯片上 TensorCore 处于活跃处理状态的时间百分比kubernetes.io/container/accelerator/memory_used已分配的加速器内存字节数kubernetes.io/container/accelerator/memory_total加速器总内存字节数节点级指标指标说明kubernetes.io/node/accelerator/duty_cycle节点维度 TensorCore 占空比kubernetes.io/node/accelerator/memory_used节点维度已用加速器内存kubernetes.io/node/accelerator/memory_total节点维度加速器总内存低利用率签名解读结合仓库中 failure_signatures.md 的故障签名定义当duty_cycle或tensorcore_utilization在训练活跃期间长期低于0.220%说明 TPU 严重利用不足大概率是数据瓶颈或 batch size 过小所致应从数据管线与训练配置层面排查而非基础设施。Step 3检查节点状态条件对于 GKE 版本1.32.1-gke.1357001或更高可通过kubernetes_io:node_status_condition系列查询节点状态条件。查询特定节点是否 Readykubernetes_io:node_status_condition{monitored_resourcek8s_node, cluster_name{cluster_name}, node_name{node_name}, conditionReady, statusTrue}列出处于非 Ready 条件且状态为 True 的节点kubernetes_io:node_status_condition{monitored_resourcek8s_node, cluster_name{cluster_name}, condition!Ready, statusTrue}列出 NOT Ready 的节点kubernetes_io:node_status_condition{monitored_resourcek8s_node, cluster_name{cluster_name}, conditionReady, statusFalse}集群全域Fleet-wide节点状态概览avg by (condition,status)(avg_over_time(kubernetes_io:node_status_condition{monitored_resourcek8s_node}[5m]))节点未就绪签名根据 failure_signatures.md指标kubernetes.io/node/status_condition签名conditionReady、statusFalse或statusUnknown含义承载 TPU 的 GKE 节点不健康该节点上的工作负载将被打断。Step 4检查节点池状态针对多主机multi-hostTPU 节点池查询kubernetes_io:node_pool_status系列指标。验证指定节点池是否 Runningkubernetes_io:node_pool_status{monitored_resourcek8s_node_pool, cluster_name{cluster_name}, node_pool_name{node_pool_name}, statusRunning}按状态分组的节点池监控count by (status)(count_over_time(kubernetes_io:node_pool_status{monitored_resourcek8s_node_pool}[5m]))可能的节点池状态Provisioning、Running、Error、Reconciling、Stopping。节点池错误签名根据 failure_signatures.md指标kubernetes.io/node_pool/status签名statusError含义多主机 TPU 节点池遇到错误例如置备失败。Step 5检查节点池可用性查询多主机 TPU 节点池中所有节点是否可用使用kubernetes_io:node_pool_multi_host_available指标avg by (node_pool_name)(avg_over_time(kubernetes_io:node_pool_multi_host_available{monitored_resourcek8s_node_pool, cluster_name{cluster_name}}[5m]))取值含义1True所有节点可用或0False部分节点不可用。多主机 TPU 通常依赖拓扑互联任意一个节点不可用都可能拖垮整个切片训练因此该指标是判断训练是否中断的关键信号。Step 6分析节点中断通过kubernetes_io:node_interruption_count与kubernetes_io:node_pool_interruption_count查询 GKE 节点的中断计数。中断类型与原因明细sum by (interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_interruption_count{monitored_resourcek8s_node}[5m]))中断类型Interruption TypesTerminationEvent终止事件、MaintenanceEvent维护事件、PreemptionEvent抢占事件中断原因Interruption ReasonsHostError主机错误、Eviction驱逐、AutoRepair自动修复仅过滤主机维护Host Maintenance事件sum by (interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_interruption_count{monitored_resourcek8s_node, interruption_reasonHW/SW Maintenance}[5m]))按节点池聚合的中断计数sum by (node_pool_name,interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_pool_interruption_count{monitored_resourcek8s_node_pool, interruption_reasonHW/SW Maintenance, node_pool_name{node_pool_name}}[5m]))抢占与主机错误签名结合 failure_signatures.md 对中断结果进行判读节点抢占签名interruption_typePreemptionEvent—— 节点被抢占常见于 Spot VM工作负载需要重新调度主机错误签名interruption_typeTerminationEvent且interruption_reasonHostError—— 底层物理主机发生硬件错误GKE 应触发 AutoRepair。若查询结果中interruption_reasonHW/SW Maintenance的计数大于 0说明底层 Compute Engine VM 因计划内主机维护被中断。更详细的维护事件排查流程可参考仓库配套技能 gke-ai-troubleshooting-handle-disruption-gpu-tpu。Step 7计算恢复与中断可靠性指标基于最近 7 天的数据计算 MTTR平均恢复时间与 MTBI平均中断间隔。MTTR平均恢复时间sum(sum_over_time(kubernetes_io:node_pool_accelerator_times_to_recover_sum{monitored_resourcek8s_node_pool, cluster_name{cluster_name}}[7d])) / sum(sum_over_time(kubernetes_io:node_pool_accelerator_times_to_recover_count{monitored_resourcek8s_node_pool,cluster_name{cluster_name}}[7d]))该公式用「恢复时间总和 ÷ 恢复事件次数」计算节点池加速器的平均恢复时长。MTBI平均中断间隔sum(count_over_time(kubernetes_io:node_memory_total_bytes{monitored_resourcek8s_node, node_name~gke-tpu.*|gk3-tpu.*, cluster_name{cluster_name}}[7d])) / sum(sum_over_time(kubernetes_io:node_interruption_count{monitored_resourcek8s_node, node_name~gke-tpu.*|gk3-tpu.*, cluster_name{cluster_name}}[7d]))该公式用「观测时间窗口内的采样次数 ÷ 中断次数」估算平均中断间隔其中node_name~gke-tpu.*|gk3-tpu.*正则用于限定 TPU 节点命名前缀gke-tpu与gk3-tpu避免把非 TPU 节点计入分母。Step 8监控 TPU 主机指标对于 GKE 版本1.28.1-gke.1066000或更高可进一步监控 TPU 主机host的性能表现。容器级指标指标说明kubernetes.io/container/accelerator/tensorcore_utilization当前 TensorCore 利用率百分比kubernetes.io/container/accelerator/memory_bandwidth_utilization当前加速器内存带宽利用率百分比节点级指标指标说明kubernetes.io/node/accelerator/tensorcore_utilization节点维度 TensorCore 利用率kubernetes.io/node/accelerator/memory_bandwidth_utilization节点维度内存带宽利用率该组指标与 Step 2 的duty_cycle一起构成判断「TPU 是否真正跑满」的双重视角duty_cycle反映时间维度上的活跃占比tensorcore_utilization反映瞬时算力占用二者结合可区分「计算单元闲置」与「算力未打满」两种瓶颈形态。配套脚本与验证方式本技能在仓库中附带 validate_queries.sh 校验脚本。运行方式为export PROJECT_ID{project_id} bash skills/cloud/gke-ai-troubleshooting-tpu-metrics-monitoring/scripts/validate_queries.sh脚本逻辑说明要求显式设置PROJECT_ID环境变量未设置时直接报错退出避免误用gcloud默认项目由于本技能定位为「纯指标PromQL驱动的观测」不包含 Cloud Logging LQL 查询脚本会打印No Cloud Logging LQL queries defined in this skill to validate.并跳过日志查询校验脚本以set -e严格模式运行任何非预期失败都会中断执行便于在 CI 中早期发现问题。对比参考仓库中 gke-ai-troubleshooting-jobset-interruption 的校验脚本则通过curl调用 Cloud Monitoring Prometheus API 对 PromQL 做编译期 dry-run说明此类技能普遍遵循「查询模板 脚本校验」的可维护模式。典型排查路径总结综合上述 8 个步骤一套完整的基础设施根因排查路径如下确认数据通路核对containerPort: 8431、JAX ≥0.4.14、GKE ≥1.27.4-gke.900、GKE System Metrics 已启用Step 1判断是「性能问题」还是「可用性问题」先用duty_cycle/tensorcore_utilization判断 TPU 是否被有效利用Step 2、Step 8低于 20% 优先查数据管线逐层定位中断来源节点层查node_status_conditionStep 3→ 节点池层查node_pool_status与node_pool_multi_host_availableStep 4、Step 5→ 事件层查node_interruption_count按类型/原因细分Step 6量化影响并持续观测用 MTTR / MTBI 评估恢复速度与中断频率Step 7为容量规划与调度策略如 Reserved/On-Demand、Compact Placement提供数据依据。整个流程完全基于 GKE System Metrics 与 PromQL无需在集群中部署额外采集器即可形成从「单点故障确认」到「长期可靠性量化」的完整闭环。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
GKE TPU 指标监控与故障排查指南：基于 GKE System Metrics 与 PromQL 的 TPU 工作负载观测
GKE TPU 指标监控与故障排查指南基于 GKE System Metrics 与 PromQL 的 TPU 工作负载观测【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills导读本文基于开源仓库 gke-ai-troubleshooting-tpu-metrics-monitoring 技能文档系统讲解如何借助 GKE System MetricsGKE 系统指标与 PromQL 查询对 GKE 上的 TPU 工作负载、节点与节点池进行持续监控与故障排查。文章覆盖从「验证 TPU 运行时指标配置」到「计算 MTTR/MTBI 可靠性指标」的完整 8 步诊断流程读者学完后将能够确认集群是否具备 TPU 指标导出能力、识别 TensorCore 利用率与 TPU 内存水位、判定节点与多主机节点池的健康状态、按类型与原因分析节点中断事件并基于指标签名快速定位基础设施层面的根因。前置条件与适用边界本技能适用于 GKE 上 TPUTensor Processing Unit工作负载的指标驱动监控与排障典型场景包括监控 TensorCore 占空比duty cycle与 TPU 内存使用情况检查节点就绪Ready状态与多主机 TPU 节点池可用性分析主机维护maintenance或抢占preemption造成的中断计算 MTTRMean Time to Recovery与 MTBIMean Time Between Interruptions等可靠性指标。不适用场景通用非 TPU 的 GKE 工作负载监控应使用 gke-basics 等基础技能、以及非指标驱动的 TPU 调试如日志类排障可参考仓库中 gke-ai-troubleshooting-tpu-vbar-oom 等配套技能。必需上下文变量在开始任何查询前需要先独立收集可通过现有 GKE 与 Cloud 工具获取以下上下文或直接使用占位符替换变量含义是否必填{project_id}GCP 项目 ID必填{cluster_name}GKE 集群名称必填{location}GKE 集群所在地域或可用区必填{node_name}具体 GKE 节点名称可选{node_pool_name}GKE 节点池名称可选Step 1验证 TPU 运行时指标配置在分析运行时指标之前必须确认工作负载已正确配置以导出这些指标从而保证集群与容器环境具备自动抓取能力并可观测到加速器健康状况。需要核对的先决条件如下容器端口TPU 容器必须暴露containerPort: 8431Prometheus 指标抓取所必需JAX 版本若使用 JAX版本需为0.4.14或更高更早版本不会导出运行时指标GKE 版本集群版本需为1.27.4-gke.900或更高TPU 运行时指标支持的前提GKE System Metrics集群需已启用 GKE 系统指标供 Cloud Monitoring 摄取。这些版本门槛直接决定了后续查询能否取到数据属于「先配置、后观测」的硬性前置条件。Step 2监控 TPU 运行时指标配置正确后以下指标即可在 Cloud Monitoring 中查询到监控资源monitored resources为k8s_node与k8s_container。容器级指标指标说明kubernetes.io/container/accelerator/duty_cycle过去采样周期60 秒内 TPU 芯片上 TensorCore 处于活跃处理状态的时间百分比kubernetes.io/container/accelerator/memory_used已分配的加速器内存字节数kubernetes.io/container/accelerator/memory_total加速器总内存字节数节点级指标指标说明kubernetes.io/node/accelerator/duty_cycle节点维度 TensorCore 占空比kubernetes.io/node/accelerator/memory_used节点维度已用加速器内存kubernetes.io/node/accelerator/memory_total节点维度加速器总内存低利用率签名解读结合仓库中 failure_signatures.md 的故障签名定义当duty_cycle或tensorcore_utilization在训练活跃期间长期低于0.220%说明 TPU 严重利用不足大概率是数据瓶颈或 batch size 过小所致应从数据管线与训练配置层面排查而非基础设施。Step 3检查节点状态条件对于 GKE 版本1.32.1-gke.1357001或更高可通过kubernetes_io:node_status_condition系列查询节点状态条件。查询特定节点是否 Readykubernetes_io:node_status_condition{monitored_resourcek8s_node, cluster_name{cluster_name}, node_name{node_name}, conditionReady, statusTrue}列出处于非 Ready 条件且状态为 True 的节点kubernetes_io:node_status_condition{monitored_resourcek8s_node, cluster_name{cluster_name}, condition!Ready, statusTrue}列出 NOT Ready 的节点kubernetes_io:node_status_condition{monitored_resourcek8s_node, cluster_name{cluster_name}, conditionReady, statusFalse}集群全域Fleet-wide节点状态概览avg by (condition,status)(avg_over_time(kubernetes_io:node_status_condition{monitored_resourcek8s_node}[5m]))节点未就绪签名根据 failure_signatures.md指标kubernetes.io/node/status_condition签名conditionReady、statusFalse或statusUnknown含义承载 TPU 的 GKE 节点不健康该节点上的工作负载将被打断。Step 4检查节点池状态针对多主机multi-hostTPU 节点池查询kubernetes_io:node_pool_status系列指标。验证指定节点池是否 Runningkubernetes_io:node_pool_status{monitored_resourcek8s_node_pool, cluster_name{cluster_name}, node_pool_name{node_pool_name}, statusRunning}按状态分组的节点池监控count by (status)(count_over_time(kubernetes_io:node_pool_status{monitored_resourcek8s_node_pool}[5m]))可能的节点池状态Provisioning、Running、Error、Reconciling、Stopping。节点池错误签名根据 failure_signatures.md指标kubernetes.io/node_pool/status签名statusError含义多主机 TPU 节点池遇到错误例如置备失败。Step 5检查节点池可用性查询多主机 TPU 节点池中所有节点是否可用使用kubernetes_io:node_pool_multi_host_available指标avg by (node_pool_name)(avg_over_time(kubernetes_io:node_pool_multi_host_available{monitored_resourcek8s_node_pool, cluster_name{cluster_name}}[5m]))取值含义1True所有节点可用或0False部分节点不可用。多主机 TPU 通常依赖拓扑互联任意一个节点不可用都可能拖垮整个切片训练因此该指标是判断训练是否中断的关键信号。Step 6分析节点中断通过kubernetes_io:node_interruption_count与kubernetes_io:node_pool_interruption_count查询 GKE 节点的中断计数。中断类型与原因明细sum by (interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_interruption_count{monitored_resourcek8s_node}[5m]))中断类型Interruption TypesTerminationEvent终止事件、MaintenanceEvent维护事件、PreemptionEvent抢占事件中断原因Interruption ReasonsHostError主机错误、Eviction驱逐、AutoRepair自动修复仅过滤主机维护Host Maintenance事件sum by (interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_interruption_count{monitored_resourcek8s_node, interruption_reasonHW/SW Maintenance}[5m]))按节点池聚合的中断计数sum by (node_pool_name,interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_pool_interruption_count{monitored_resourcek8s_node_pool, interruption_reasonHW/SW Maintenance, node_pool_name{node_pool_name}}[5m]))抢占与主机错误签名结合 failure_signatures.md 对中断结果进行判读节点抢占签名interruption_typePreemptionEvent—— 节点被抢占常见于 Spot VM工作负载需要重新调度主机错误签名interruption_typeTerminationEvent且interruption_reasonHostError—— 底层物理主机发生硬件错误GKE 应触发 AutoRepair。若查询结果中interruption_reasonHW/SW Maintenance的计数大于 0说明底层 Compute Engine VM 因计划内主机维护被中断。更详细的维护事件排查流程可参考仓库配套技能 gke-ai-troubleshooting-handle-disruption-gpu-tpu。Step 7计算恢复与中断可靠性指标基于最近 7 天的数据计算 MTTR平均恢复时间与 MTBI平均中断间隔。MTTR平均恢复时间sum(sum_over_time(kubernetes_io:node_pool_accelerator_times_to_recover_sum{monitored_resourcek8s_node_pool, cluster_name{cluster_name}}[7d])) / sum(sum_over_time(kubernetes_io:node_pool_accelerator_times_to_recover_count{monitored_resourcek8s_node_pool,cluster_name{cluster_name}}[7d]))该公式用「恢复时间总和 ÷ 恢复事件次数」计算节点池加速器的平均恢复时长。MTBI平均中断间隔sum(count_over_time(kubernetes_io:node_memory_total_bytes{monitored_resourcek8s_node, node_name~gke-tpu.*|gk3-tpu.*, cluster_name{cluster_name}}[7d])) / sum(sum_over_time(kubernetes_io:node_interruption_count{monitored_resourcek8s_node, node_name~gke-tpu.*|gk3-tpu.*, cluster_name{cluster_name}}[7d]))该公式用「观测时间窗口内的采样次数 ÷ 中断次数」估算平均中断间隔其中node_name~gke-tpu.*|gk3-tpu.*正则用于限定 TPU 节点命名前缀gke-tpu与gk3-tpu避免把非 TPU 节点计入分母。Step 8监控 TPU 主机指标对于 GKE 版本1.28.1-gke.1066000或更高可进一步监控 TPU 主机host的性能表现。容器级指标指标说明kubernetes.io/container/accelerator/tensorcore_utilization当前 TensorCore 利用率百分比kubernetes.io/container/accelerator/memory_bandwidth_utilization当前加速器内存带宽利用率百分比节点级指标指标说明kubernetes.io/node/accelerator/tensorcore_utilization节点维度 TensorCore 利用率kubernetes.io/node/accelerator/memory_bandwidth_utilization节点维度内存带宽利用率该组指标与 Step 2 的duty_cycle一起构成判断「TPU 是否真正跑满」的双重视角duty_cycle反映时间维度上的活跃占比tensorcore_utilization反映瞬时算力占用二者结合可区分「计算单元闲置」与「算力未打满」两种瓶颈形态。配套脚本与验证方式本技能在仓库中附带 validate_queries.sh 校验脚本。运行方式为export PROJECT_ID{project_id} bash skills/cloud/gke-ai-troubleshooting-tpu-metrics-monitoring/scripts/validate_queries.sh脚本逻辑说明要求显式设置PROJECT_ID环境变量未设置时直接报错退出避免误用gcloud默认项目由于本技能定位为「纯指标PromQL驱动的观测」不包含 Cloud Logging LQL 查询脚本会打印No Cloud Logging LQL queries defined in this skill to validate.并跳过日志查询校验脚本以set -e严格模式运行任何非预期失败都会中断执行便于在 CI 中早期发现问题。对比参考仓库中 gke-ai-troubleshooting-jobset-interruption 的校验脚本则通过curl调用 Cloud Monitoring Prometheus API 对 PromQL 做编译期 dry-run说明此类技能普遍遵循「查询模板 脚本校验」的可维护模式。典型排查路径总结综合上述 8 个步骤一套完整的基础设施根因排查路径如下确认数据通路核对containerPort: 8431、JAX ≥0.4.14、GKE ≥1.27.4-gke.900、GKE System Metrics 已启用Step 1判断是「性能问题」还是「可用性问题」先用duty_cycle/tensorcore_utilization判断 TPU 是否被有效利用Step 2、Step 8低于 20% 优先查数据管线逐层定位中断来源节点层查node_status_conditionStep 3→ 节点池层查node_pool_status与node_pool_multi_host_availableStep 4、Step 5→ 事件层查node_interruption_count按类型/原因细分Step 6量化影响并持续观测用 MTTR / MTBI 评估恢复速度与中断频率Step 7为容量规划与调度策略如 Reserved/On-Demand、Compact Placement提供数据依据。整个流程完全基于 GKE System Metrics 与 PromQL无需在集群中部署额外采集器即可形成从「单点故障确认」到「长期可靠性量化」的完整闭环。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
