Catalog
google/gke-tpu-metrics-monitoring

google

gke-tpu-metrics-monitoring

Monitors and troubleshoots GKE TPU workloads, nodes, and node pools using GKE system metrics and PromQL. Use when monitoring TensorCore duty cycle, TPU memory, node readiness, multi-host TPU node pool availability, host maintenance or preemption interruptions, and calculating MTTR or MTBI metrics for GKE TPUs. Don't use for general non-TPU GKE workload monitoring or non-metric TPU debugging.

v1.0LATEST
NewUpdated Jul 30, 2026

GKE TPU Metrics Monitoring Guide

This skill enables the agent to monitor GKE TPU workloads, nodes, and node pools using GKE system metrics. It helps diagnose if workload interruptions or performance issues are caused by underlying infrastructure.

Step 0: Mandatory Context

Independently gather required context (such as cluster details or node pool names) using available GKE and Cloud tools, or use the provided {variable} placeholders:

  • {project_id}: The GCP Project ID.
  • {cluster_name}: The GKE Cluster Name.
  • {location}: The GKE Cluster Location (region or zone).
  • {node_name}: (Optional) The name of the specific GKE node.
  • {node_pool_name}: (Optional) The name of the GKE node pool.

Diagnostic Steps

Step 1: Verify TPU Runtime Metrics Configuration [Low Risk] [Auto]

Before analyzing runtime metrics, verify that the workload is configured to export them.

  • Action: Verify that the Pod specification for the TPU workload includes:
    • containerPort: 8431
    • JAX version 0.4.14 or later (if using JAX).
    • GKE version is 1.27.4-gke.900 or later.
    • GKE System Metrics are enabled on the cluster.

Step 2: Monitor TPU Runtime Metrics [Low Risk] [Auto]

If configured correctly, the following metrics are available in Cloud Monitoring (monitored resources k8s_node and k8s_container):

  • Container Metrics:
    • kubernetes.io/container/accelerator/duty_cycle: Percentage of time over the past sampling period (60 seconds) during which the TensorCores were actively processing on a TPU chip.
    • kubernetes.io/container/accelerator/memory_used: Amount of accelerator memory allocated in bytes.
    • kubernetes.io/container/accelerator/memory_total: Total accelerator memory in bytes.
  • Node Metrics:
    • kubernetes.io/node/accelerator/duty_cycle
    • kubernetes.io/node/accelerator/memory_used
    • kubernetes.io/node/accelerator/memory_total

Step 3: Check Node Status Condition [Low Risk] [Auto]

Query the status condition of GKE nodes (GKE version 1.32.1-gke.1357001 or later).

  • PromQL Query (Check if a specific node is Ready):
    kubernetes_io:node_status_condition{monitored_resource="k8s_node", cluster_name="{cluster_name}", node_name="{node_name}", condition="Ready", status="True"}
    
  • PromQL Query (List nodes with non-Ready conditions that are True):
    kubernetes_io:node_status_condition{monitored_resource="k8s_node", cluster_name="{cluster_name}", condition!="Ready", status="True"}
    
  • PromQL Query (List nodes that are NOT Ready):
    kubernetes_io:node_status_condition{monitored_resource="k8s_node", cluster_name="{cluster_name}", condition="Ready", status="False"}
    
  • PromQL Query (Fleet-wide node status):
    avg by (condition,status)(avg_over_time(kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[5m]))
    

Step 4: Check Node Pool Status [Low Risk] [Auto]

Query the status of multi-host TPU node pools.

  • PromQL Query (Verify if a specific node pool is Running):
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool", cluster_name="{cluster_name}", node_pool_name="{node_pool_name}", status="Running"}
    
  • PromQL Query (Monitor node pools grouped by status):
    count by (status)(count_over_time(kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[5m]))
    
    Possible statuses: Provisioning, Running, Error, Reconciling, Stopping.

Step 5: Check Node Pool Availability [Low Risk] [Auto]

Query if all nodes in a multi-host TPU node pool are available.

  • PromQL Query (Check availability over time):
    avg by (node_pool_name)(avg_over_time(kubernetes_io:node_pool_multi_host_available{monitored_resource="k8s_node_pool", cluster_name="{cluster_name}"}[5m]))
    
    Value: 1 (True, all nodes available) or 0 (False, some nodes unavailable).

Step 6: Analyze Node Interruptions [Low Risk] [Auto]

Query the count of interruptions for GKE nodes.

  • PromQL Query (Breakdown of interruptions and causes):
    sum by (interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[5m]))
    
    Interruption Types: TerminationEvent, MaintenanceEvent, PreemptionEvent. Interruption Reasons: HostError, Eviction, AutoRepair.
  • PromQL Query (Filter for Host Maintenance events):
    sum by (interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[5m]))
    
  • PromQL Query (Interruption count aggregated by node pool):
    sum by (node_pool_name,interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name="{node_pool_name}"}[5m]))
    

Step 7: Calculate Recovery and Interruption Metrics [Low Risk] [Auto]

Calculate Mean Time to Recovery (MTTR) and Mean Time Between Interruptions (MTBI) over the last 7 days.

  • PromQL Query (MTTR - Mean Time to Recovery):
    sum(sum_over_time(kubernetes_io:node_pool_accelerator_times_to_recover_sum{monitored_resource="k8s_node_pool", cluster_name="{cluster_name}"}[7d])) / sum(sum_over_time(kubernetes_io:node_pool_accelerator_times_to_recover_count{monitored_resource="k8s_node_pool",cluster_name="{cluster_name}"}[7d]))
    
  • PromQL Query (MTBI - Mean Time Between Interruptions):
    sum(count_over_time(kubernetes_io:node_memory_total_bytes{monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="{cluster_name}"}[7d])) / sum(sum_over_time(kubernetes_io:node_interruption_count{monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="{cluster_name}"}[7d]))
    

Step 8: Monitor TPU Host Metrics [Low Risk] [Auto]

For GKE version 1.28.1-gke.1066000 or later, monitor TPU host performance.

  • Container Metrics:
    • kubernetes.io/container/accelerator/tensorcore_utilization: Current percentage of the TensorCore that is utilized.
    • kubernetes.io/container/accelerator/memory_bandwidth_utilization: Current percentage of the accelerator memory bandwidth that is being used.
  • Node Metrics:
    • kubernetes.io/node/accelerator/tensorcore_utilization
    • kubernetes.io/node/accelerator/memory_bandwidth_utilization
Files3
3 files · 12.8 KB

Select a file to preview

Overall Score

78/100

Grade

B

Good

Grades are signals, not a certification. Always review a skill yourself before use.

Safety

88

Quality

75

Clarity

82

Completeness

68

Summary

This skill guides agents to monitor and troubleshoot GKE TPU workloads using Cloud Monitoring metrics and PromQL queries. It provides structured diagnostic steps to check node status, node pool health, interruptions, recovery times, and TPU-specific performance metrics (duty cycle, memory utilization, TensorCore usage). The skill is read-only, focusing on metric analysis rather than infrastructure modifications.

Detected Capabilities

Cloud Monitoring metric queriesPromQL query executionGKE metadata inspectionSystem metric analysis

Trigger Keywords

Phrases that agents use to match this skill to user intent.

monitor tpu workloadgke tpu interruptiontensor core utilizationnode pool availabilitytpu duty cyclemttr mtbi calculationgke preemption analysistpu recovery metrics

Risk Signals

INFO

Variable substitution with user-provided placeholders ({project_id}, {cluster_name}, {location}, {node_name}, {node_pool_name})

SKILL.md: Step 0, throughout PromQL queries
INFO

PromQL queries reference GKE metrics endpoints (kubernetes_io namespace) but do not execute destructive operations

SKILL.md: Steps 3-8
INFO

Script environment variable validation (PROJECT_ID)

scripts/validate_queries.sh

Referenced Domains

External domains referenced in skill content, detected by static analysis.

www.apache.org

Use Cases

  • Monitor TPU duty cycle and memory utilization across GKE workloads
  • Diagnose node readiness issues in multi-host TPU node pools
  • Analyze preemption and maintenance interruption patterns affecting TPU workloads
  • Calculate Mean Time to Recovery (MTTR) and Mean Time Between Interruptions (MTBI) for TPU infrastructure
  • Track TensorCore utilization and memory bandwidth consumption for performance optimization
  • Identify host errors and low utilization signatures causing workload disruption
  • Compare node pool availability status over time for capacity planning

Quality Notes

  • Strength: Clear diagnostic workflow with 8 sequential steps, each labeled with risk level (Low Risk) and execution mode (Auto)
  • Strength: Comprehensive metric definitions including both container-level and node-level metrics for TPU monitoring
  • Strength: Step 0 establishes context gathering pattern, making queries parameterized and environment-agnostic
  • Strength: Includes failure signature reference file documenting what metric values mean in practice
  • Strength: Proper scope boundaries—explicitly restricts to TPU-specific monitoring and excludes non-TPU GKE workload monitoring
  • Strength: GKE version requirements documented (1.27.4, 1.28.1, 1.32.1) for feature availability
  • Strength: PromQL query examples are production-ready with proper aggregation and time window specifications
  • Weakness: No error handling guidance if metrics are unavailable or queries return empty results
  • Weakness: No guidance on how to interpret specific metric values beyond failure signatures (e.g., what is 'good' duty cycle?)
  • Weakness: Limited coverage of edge cases (e.g., single-host TPU vs multi-host differences, behavior during autoscaling)
  • Weakness: validate_queries.sh does not actually validate the PromQL syntax or test Cloud Monitoring connectivity
  • Weakness: No troubleshooting flowchart or decision tree for common scenarios
Model: claude-haiku-4-5-20251001Analyzed: Jul 30, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Use google/gke-tpu-metrics-monitoring in your dev environment

Command Palette

Search for a command to run...