New to Claude Skills? Learn how to install them →

google on GitHub

GKE TPU Metrics Monitoring

Free

Monitor and troubleshoot GKE TPU workloads effectively.

by google17.6k stars on google/skills
1 views
Updated Aug 10, 2026
Get this skill

Free · Opens the source repo

What GKE TPU Metrics Monitoring does

The GKE TPU Metrics Monitoring skill is designed for developers and engineers who need to monitor and troubleshoot Google Kubernetes Engine (GKE) Tensor Processing Unit (TPU) workloads. By leveraging GKE system metrics and PromQL, this skill enables users to diagnose performance issues and workload interruptions that may stem from the underlying infrastructure. It focuses specifically on TPU workloads, making it a specialized tool for those working with machine learning and high-performance computing on GKE.

This skill provides a structured approach to monitoring TPU workloads, starting with the verification of TPU runtime metrics configuration. Users can ensure that their workloads are correctly set up to export necessary metrics, such as duty cycle and memory usage. Once configured, the skill allows for real-time monitoring of these metrics, helping users understand the performance of their TPU resources. The ability to query the status of GKE nodes and node pools is also included, allowing for comprehensive oversight of the TPU environment.

In addition to monitoring, the skill includes diagnostic steps to analyze node interruptions and calculate key performance metrics such as Mean Time to Recovery (MTTR) and Mean Time Between Interruptions (MTBI). These metrics are crucial for maintaining the reliability of TPU workloads, especially in production environments where uptime is critical. By providing detailed PromQL queries, the skill empowers users to extract valuable insights from their monitoring data, facilitating informed decision-making and proactive troubleshooting.

Overall, the GKE TPU Metrics Monitoring skill is tailored for engineers and developers working with GKE TPUs who require a robust solution for monitoring and troubleshooting their workloads. It is particularly beneficial in environments where performance and availability are paramount, such as in machine learning applications and high-throughput data processing tasks.

When to use it

Use this skill when you need to monitor GKE TPU workloads and diagnose issues related to performance or interruptions.

When not to use it

This skill is not suitable for monitoring general GKE workloads or for debugging non-metric TPU issues.

What you can build with it

Monitoring TPU Workloads

Use this skill to continuously monitor the performance of your TPU workloads, ensuring they operate efficiently.

Diagnosing Performance Issues

When encountering performance issues, utilize the diagnostic steps provided to identify the root cause of interruptions.

Calculating Recovery Metrics

Employ this skill to calculate MTTR and MTBI metrics, helping you maintain high availability for your TPU workloads.

How to install GKE TPU Metrics Monitoring

View source

1. Install with the skills CLI

npx skills add google/skills/gke-tpu-metrics-monitoring --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by google

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

Frequently asked questions about GKE TPU Metrics Monitoring

Similar skills