Surveiller l'état des TPU Cloud

La surveillance de l'état de Cloud TPU fournit des informations en temps réel sur l'état des VM et des tranches de TPU. À l'aide de la console Cloud Monitoring ou de Google Cloud CLI, vous pouvez identifier les défaillances matérielles lorsqu'elles se produisent et réallouer des ressources, ce qui vous permet d'éviter les échecs de tâches et de minimiser la dégradation des performances.

La surveillance de l'état des TPU attribue l'état HEALTHY ou UNHEALTHY à chaque instance de TPU en cours d'utilisation. L'état HEALTHY est attribué aux TPU qui fonctionnent comme prévu, et l'état UNHEALTHY est attribué à ceux qui ne fonctionnent plus ou dont les performances sont fortement réduites.

En plus de l'état, la surveillance de l'état des TPU fournit des métriques de journalisation pour des tâches spécifiques. Vous pouvez utiliser ces métriques pour diagnostiquer plus précisément les problèmes d'état et de performances des TPU qui ne sont pas causés par des problèmes matériels.

Détection des TPU non opérationnels

Lorsque la surveillance de l'état des TPU attribue l'état UNHEALTHY à un TPU, elle fournit des informations d'identification du TPU défaillant via le point de terminaison de service compute.googleapis.com/instance/tpu/infra_health.

Causes de l'état des TPU

Une machine est classée comme UNHEALTHY lorsqu'il existe des problèmes avec le matériel physique. Lorsqu'une machine est classée comme UNHEALTHY, la surveillance de l'état des TPU fournit l'une des causes suivantes :

  • BAD_TPU_CHIP : défaillance physique au sein du matériel TPU lui-même. La VM peut s'exécuter comme prévu, mais un TPU connecté à la VM est défectueux.
  • NETWORKING_ISSUE: problèmes matériels dans la communication réseau sous-jacente entre les différents workers ou composants du système TPU distribué, tels que les appels de procédure à distance (RPC) de transfert abandonnés.
  • BAD_SC_CHIP : défaillance physique dans un SparseCore d'une puce TPU.

Étiquettes de métriques

La surveillance de l'état des TPU fournit les étiquettes de métriques suivantes pour identifier le TPU non opérationnel spécifique :

Nom de l'étiquette Type Description
health_status STRING État général de l'instance de TPU.
unhealthy_category STRING Cause de l'état. Cette étiquette n'est renseignée que lorsque la valeur de la métrique est UNHEALTHY.
machine_type STRING Type de machine Compute Engine de l'instance.
reservation_id STRING ID de la réservation de la machine physique.

La surveillance de l'état des TPU fournit également les étiquettes de ressources suivantes :

Nom de l'étiquette Type Description
project STRING Numéro du projet.
service STRING Service d'API (compute.googleapis.com).
resource_type STRING Instance de VM.
location STRING Zone de l'instance.
resource_id STRING ID de l'instance Compute Engine.

La surveillance de l'état des TPU fournit les étiquettes de métriques supplémentaires suivantes pour les réservations en mode "All Capacity" via TPU Cluster Director :

Nom de l'étiquette Type Description
machine_id STRING ID de la machine physique hébergeant la VM.
block_id STRING ID du bloc au sein du cluster hébergeant la VM.
cluster_id STRING ID du cluster hébergeant la VM.
subblock_id STRING ID du sous-bloc hébergeant la VM.

Journalisation

Une machine sans problème physique peut être défectueuse ou non fonctionnelle en raison de problèmes sans rapport avec le matériel. Dans ce cas, la surveillance de l'état des TPU continue de classer la machine comme HEALTHY, mais enregistre également les causes potentielles du problème avec Cloud Logging dans le projet associé. Les journaux fournissent des informations sur le problème, y compris une brève description, la cause racine suspectée, les coupables potentiels et les prochaines étapes à suivre.

Les journaux contiennent l'une des causes suivantes :

  • FINGERPRINT_MISMATCH: les programmes qui doivent exécuter le même module TPU contiennent des empreintes binaires différentes. Cela est probablement dû à des incohérences causées par des problèmes de compilateur.
  • DATA_INPUT_STALL: les TPU sont bloqués lors des opérations d'accès direct à la mémoire (DMA) ou des transferts de données. Les TPU ne peuvent pas continuer tant que les opérations DMA ne sont pas terminées.
  • UNRECOVERABLE_ERROR: un ou plusieurs workers ont rencontré une erreur irrécupérable et se trouvent dans un état indéfini.
  • DIFFERENT_MODULE: les workers exécutent différents modules TPU alors qu'ils doivent exécuter le même module.
  • UNKNOWN_CAUSE : cause d'erreur indéterminée.

Vous pouvez afficher les journaux à l'aide de l'Explorateur de journaux ou de l'API Logs. Pour en savoir plus sur Google Cloud la journalisation, consultez Google Cloud Journalisation.

Surveillance avec la console

Le tableau de bord Monitoring de la Google Cloud console fournit des visualisations en temps réel de l'état des machines, des tendances historiques et des nombres totaux. Le tableau Failure Event (Événement de défaillance) associe les échecs de tâches à leurs causes racines.

Pour afficher un tableau de bord prédéfini dans Cloud Monitoring :

  1. Dans la Google Cloud console, accédez à la page Cloud Monitoring.
    Accéder à la console Monitoring
  2. Dans le volet de navigation, cliquez sur Tableaux de bord.
  3. Dans le champ Filter search (Filtrer la recherche), saisissez "TPU Instance Health Dashboard".

Le tableau de bord affiche les métriques suivantes par défaut :

  • Overall TPU instance health (État général des instances de TPU) : pourcentage d'instances de TPU classées comme HEALTHY.
  • Number of instances (Nombre d'instances) : nombre total d'instances de TPU en cours d'utilisation.
  • Number of healthy TPU instances (Nombre d'instances de TPU opérationnelles) : nombre total d'instances de TPU classées comme HEALTHY.
  • Number of unhealthy TPU instances (Nombre d'instances de TPU non opérationnelles) : nombre total d'instances de TPU classées comme UNHEALTHY.
  • VM infra health distribution (Distribution de l'état de l'infrastructure des VM) : nombre d'instances HEALTHY au fil du temps.

Pour ajouter une requête personnalisée, cliquez sur Add Query (Ajouter une requête) et rédigez une requête PromQL. Par exemple, la requête suivante récupère toutes les instances de TPU non opérationnelles :

count({__name__="compute.googleapis.com/instance/tpu/infra_health", monitored_resource="gce_instance", health_status="UNHEALTHY"})

Pour en savoir plus sur la surveillance avec la Google Cloud console, consultez la documentation Cloud Monitoring.

Surveillance avec la CLI

Google Cloud CLI fournit des données en temps réel sur l'état des TPU. L'exemple de requête suivant récupère tous les TPU UNHEALTHY :

export TOKEN=$(gcloud auth application-default print-access-token)

export PROMQL_QUERY='count({__name__="compute.googleapis.com/instance/tpu/infra_health", monitored_resource="gce_instance", health_status="UNHEALTHY"})'

export LOCATION="global"

curl -G \
  --header "Authorization: Bearer ${TOKEN}" \
  --header "Content-Type: application/json" \
  --header "X-Goog-User-Project: ${PROJECT_ID}" \
  --data-urlencode "query=${PROMQL_QUERY}" \
  "https://monitoring.googleapis.com/v1/projects/${PROJECT_ID}/location/${LOCATION}/prometheus/api/v1/query"

Vous devriez obtenir une réponse semblable à la suivante :

{"status":"success","data":{"resultType":"vector","result":[65]}}

Pour en savoir plus sur gcloud CLI, consultez la présentation de gcloud CLI.