mcpField
G
gke-ai-troubleshooting-tpu-metrics-monitoring

gke-ai-troubleshooting-tpu-metrics-monitoring

github.com/googleクラウド・DevOps21.6k3.8k 回インストール今日更新
リポジトリ

gke-ai-troubleshooting-tpu-metrics-monitoring について

このスキルは、GKEシステム指標を使ってTPUワークロード、ノード、ノードプールを監視するためのものです。Cloud Monitoringの指標とPromQLクエリを用いて、中断や性能問題をインフラ面から調査できます。

主な機能

  1. 01TPU指標の前提条件の確認
  2. 02アクセラレータの稼働率とメモリの監視
  3. 03ノードとノードプールの状態確認
  4. 04中断と復旧指標の分析
  5. 05TPUホストの使用率の監視

活用シーン

  1. 01TPUランタイム指標の設定確認
  2. 02ワークロードの性能問題の診断
  3. 03ノードやノードプールの中断調査
  4. 04復旧時間と中断間隔の算出

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/google/skills --skill gke-ai-troubleshooting-tpu-metrics-monitoring

インストール後、Claude Code で/gke-ai-troubleshooting-tpu-metrics-monitoringを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
attribution.md
failure_signatures.md
scripts/
validate_queries.sh

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

GKE TPU メトリクス監視ガイド

このスキルを使用すると、GKE システムメトリクスを使って、GKE TPU のワークロード、ノード、ノードプールを監視できます。ワークロードの中断やパフォーマンスの問題の原因が、基盤インフラストラクチャにあるかどうかの診断に役立ちます。

ステップ 0:必須コンテキスト

利用可能な GKE ツールと Cloud ツールを使用して、必要なコンテキスト(クラスターの詳細やノードプール名など)を個別に収集するか、指定された {variable} プレースホルダーを使用してください。

  • {project_id}:GCP プロジェクト ID。
  • {cluster_name}:GKE クラスター名。
  • {location}:GKE クラスターのロケーション(リージョンまたはゾーン)。
  • {node_name}:(任意)特定の GKE ノード名。
  • {node_pool_name}:(任意)GKE ノードプール名。

診断手順

ステップ 1:TPU ランタイムメトリクスの設定を確認する[低リスク][自動]

ランタイムメトリクスを分析する前に、ワークロードがそれらをエクスポートするように設定されていることを確認します。これにより、クラスターとコンテナ環境が、自動メトリクススクレイピングとアクセラレータの健全性の可視化に対応するように設定されていることを確認できます。

  • 操作:Pod の仕様とクラスターが、次の前提条件を満たしていることを確認します。
    • TPU コンテナで containerPort: 8431 が公開されている(Prometheus によるメトリクススクレイピングに必須)。
    • JAX を使用する場合は、JAX バージョンが 0.4.14 以降である(それより前のバージョンではランタイムメトリクスがエクスポートされません)。
    • GKE バージョンが 1.27.4-gke.900 以降である(TPU ランタイムメトリクスのサポートに必須)。
    • クラスターで GKE システムメトリクスが有効になっている(Cloud Monitoring への取り込みに必須)。
ステップ 2:TPU ランタイムメトリクスを監視する[低リスク][自動]

正しく設定されている場合、次のメトリクスを Cloud Monitoring で利用できます(監視対象リソースは 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
    • kubernetes.io/node/accelerator/memory_used
    • kubernetes.io/node/accelerator/memory_total
ステップ 3:ノードのステータス条件を確認する[低リスク][自動]

GKE ノードのステータス条件をクエリします(GKE バージョン 1.32.1-gke.1357001 以降)。

  • PromQL クエリ(特定のノードが Ready か確認):
    kubernetes_io:node_status_condition{monitored_resource="k8s_node", cluster_name="{cluster_name}", node_name="{node_name}", condition="Ready", status="True"}
    
  • PromQL クエリ(Ready 以外の条件が True のノードを一覧表示):
    kubernetes_io:node_status_condition{monitored_resource="k8s_node", cluster_name="{cluster_name}", condition!="Ready", status="True"}
    
  • PromQL クエリ(Ready ではないノードを一覧表示):
    kubernetes_io:node_status_condition{monitored_resource="k8s_node", cluster_name="{cluster_name}", condition="Ready", status="False"}
    
  • PromQL クエリ(フリート全体のノードステータス):
    avg by (condition,status)(avg_over_time(kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[5m]))
    
ステップ 4:ノードプールのステータスを確認する[低リスク][自動]

マルチホスト TPU ノードプールのステータスをクエリします。

  • PromQL クエリ(特定のノードプールが Running か確認):
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool", cluster_name="{cluster_name}", node_pool_name="{node_pool_name}", status="Running"}
    
  • PromQL クエリ(ステータス別にグループ化したノードプールを監視):
    count by (status)(count_over_time(kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[5m]))
    
    考えられるステータス:Provisioning、Running、Error、Reconciling、Stopping。
ステップ 5:ノードプールの可用性を確認する[低リスク][自動]

マルチホスト TPU ノードプール内のすべてのノードが利用可能かどうかをクエリします。

  • PromQL クエリ(可用性の経時変化を確認):
    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]))
    
    値:1(True、すべてのノードが利用可能)または 0(False、一部のノードが利用不可)。
ステップ 6:ノードの中断を分析する[低リスク][自動]

GKE ノードの中断回数をクエリします。

  • PromQL クエリ(中断と原因の内訳):
    sum by (interruption_type,interruption_reason)(sum_over_time(kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[5m]))
    
    中断の種類:TerminationEvent、MaintenanceEvent、PreemptionEvent。 中断の理由:HostError、Eviction、AutoRepair。
  • PromQL クエリ(ホストメンテナンスイベントをフィルタリング):
    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 クエリ(ノードプール別に集計した中断回数):
    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]))
    
ステップ 7:復旧および中断のメトリクスを計算する[低リスク][自動]

過去 7 日間の平均復旧時間(MTTR)と平均中断間隔(MTBI)を計算します。

  • PromQL クエリ(MTTR - 平均復旧時間):
    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 クエリ(MTBI - 平均中断間隔):
    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]))
    
ステップ 8:TPU ホストのメトリクスを監視する[低リスク][自動]

GKE バージョン 1.28.1-gke.1066000 以降では、TPU ホストのパフォーマンスを監視します。

  • コンテナのメトリクス:
    • kubernetes.io/container/accelerator/tensorcore_utilization:現在使用されている TensorCore の割合です。
    • kubernetes.io/container/accelerator/memory_bandwidth_utilization:現在使用されているアクセラレータのメモリ帯域幅の割合です。
  • ノードのメトリクス:
    • kubernetes.io/node/accelerator/tensorcore_utilization
    • kubernetes.io/node/accelerator/memory_bandwidth_utilization

コメント