Dépannage

Cette page vous explique comment résoudre les problèmes liés à Batch.

Si vous essayez de dépanner une tâche pour laquelle vous n'avez pas de message d'erreur, vérifiez si l'historique de la tâche contient des messages d'erreur en affichant les événements d'état avant de consulter ce document.

Pour en savoir plus sur le dépannage d'une tâche, consultez également les documents suivants:

• Problèmes connus
• Analyser un job à l'aide de journaux
• Consulter les journaux d'audit

Erreurs lors de la création d'offres d'emploi

Si vous ne parvenez pas à créer un job, cela peut être dû à l'une des erreurs présentées dans cette section.

Quota insuffisant

Problème

L'un des problèmes suivants se produit lorsque vous essayez de créer une tâche:

• Lorsque la tâche présente l'état QUEUED, le problème suivant apparaît dans le champ statusEvents:

  Quota checking process decides to delay scheduling for the job JOB_UID due to inadequate quotas [Quota: QUOTA_NAME, limit: QUOTA_LIMIT, usage: QUOTA_CURRENT_USAGE, wanted: WANTED_QUOTA.].
  

  Ce problème indique que la tâche a été retardée, car l'utilisation actuelle (QUOTA_USAGE) et la limite (QUOTA_LIMIT) du quota QUOTA_NAME ont empêché l'utilisation demandée par la tâche (WANT_QUOTA).

• Lorsque la tâche est à l'état QUEUED, SCHEDULED ou FAILED, l'un des problèmes suivants apparaît dans le champ statusEvents:

  RESOURCE_NAME creation failed:
  Quota QUOTA_NAME exceeded. Limit: QUOTA_LIMIT in region REGION
  

  RESOURCE_NAME creation failed:
  Quota QUOTA_NAME exceeded. Limit: QUOTA_LIMIT in zone ZONE
  

  Ce problème indique que la création d'une ressource a échoué, car la requête a dépassé votre quota QUOTA_NAME, qui est limité à QUOTA_LIMIT dans l'emplacement spécifié.

Solution

Pour identifier le problème, procédez comme suit :

• Si la tâche a été retardée, essayez d'attendre qu'un quota supplémentaire soit libéré.

• Si la tâche échoue en raison d'un quota insuffisant ou si ces délais persistent, essayez d'éviter un quota insuffisant en procédant de l'une des façons suivantes:

  • Créez des jobs qui utilisent une quantité inférieure de ce quota ou un quota différent. Par exemple, spécifiez un autre emplacement ou type de ressource autorisé pour le job, ou répartissez l'utilisation du quota entre d'autres projets.

  • Demandez à Google Cloud une limite de quota plus élevée pour votre projet.

Pour en savoir plus, consultez les pages Quotas et limites par lot et Utiliser des quotas.

Autorisations insuffisantes pour agir en tant que compte de service

Problème

Le problème suivant se produit lorsque vous essayez de créer une tâche:

• Si le job n'utilise pas de modèle d'instance, le problème apparaît comme suit:

  caller does not have access to act as the specified service account: SERVICE_ACCOUNT_NAME
  

• Si le job utilise un modèle d'instance, le problème apparaît comme suit:

  Error: code - CODE_SERVICE_ACCOUNT_MISMATCH, description - The service account specified in the instance template INSTANCE_TEMPLATE_SERVICE_ACCOUNT doesn't match the service account specified in the job JOB_SERVICE_ACCOUNT for JOB_UID, project PROJECT_NUMBER
  

Ce problème se produit généralement lorsque l'utilisateur qui crée la tâche ne dispose pas des autorisations suffisantes pour agir en tant que compte de service utilisé par la tâche, qui est contrôlé par l'autorisation iam.serviceAccounts.actAs.

Solution

Pour identifier le problème, procédez comme suit :

1. Si la tâche utilise un modèle d'instance, vérifiez que le compte de service spécifié dans le modèle d'instance correspond au compte de service spécifié dans la définition de la tâche.
2. Assurez-vous que l'utilisateur qui crée la tâche dispose du rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur le compte de service spécifié pour la tâche. Pour en savoir plus, consultez Gérer l'accès.
3. Recréez le job.

Réseaux répétés

Problème

Le problème suivant se produit lorsque vous essayez de créer une tâche:

Networks must be distinct for NICs in the same InstanceTemplate

Ce problème est dû au fait que vous avez spécifié le réseau pour une tâche plusieurs fois.

Solution

Pour résoudre le problème, recréez le job et spécifiez le réseau en utilisant l'une des options suivantes:

• Modèle d'instance de VM:si vous souhaitez utiliser un modèle d'instance de VM lors de la création de ce job, vous devez spécifier le réseau dans le modèle d'instance de VM.
• Champs network et subnetwork:ces champs peuvent être utilisés dans le corps de la requête lorsque vous créez une tâche à l'aide de l'API Batch ou dans le fichier de configuration JSON lorsque vous créez une tâche à l'aide de la gcloud CLI.
• Options --network et --subnetwork:ces options peuvent être utilisées avec la commande gcloud batch jobs submit lorsque vous créez une tâche à l'aide de la gcloud CLI.

Pour en savoir plus, consultez la section Spécifier le réseau pour une tâche.

Réseau non valide pour VPC Service Controls

Problème

Le problème suivant se produit lorsque vous essayez de créer une tâche:

no_external_ip_address field is invalid. VPC Service Controls is enabled for the project, so external ip address must be disabled for the job. Please set no_external_ip_address field to be true

Solution

Ce problème survient lorsque vous essayez de créer et d'exécuter une tâche avec des VM disposant d'adresses IP externes dans un périmètre de service VPC Service Controls.

Pour résoudre le problème, créez une tâche qui bloque l'accès externe pour toutes les VM.

Pour en savoir plus sur la configuration de la mise en réseau d'une tâche dans un périmètre de service VPC Service Controls, consultez la page Utiliser VPC Service Controls avec Batch.

Problèmes liés aux jobs et erreurs d'échec

Si une tâche ne s'exécute pas correctement ou a échoué pour des raisons peu claires, cela peut être dû à l'une des erreurs de cette section ou à l'un des codes de sortie décrits dans la section Codes de sortie des échecs de tâches ci-dessous.

Aucun journal dans Cloud Logging

Problème

Vous devez déboguer une tâche, mais aucun journal ne s'affiche pour celle-ci dans Cloud Logging.

Ce problème survient souvent pour les raisons suivantes:

• L'API Cloud Logging n'est pas activée pour votre projet. Même si vous configurez correctement tout le reste pour les journaux d'une tâche, celle-ci ne générera pas de journaux si le service n'est pas activé pour votre projet.
• Le compte de service de la tâche ne dispose pas des autorisations nécessaires pour écrire des journaux. Une tâche ne peut pas générer de journaux sans autorisations suffisantes.
• Le job n'a pas été configuré pour générer des journaux. Pour que vous puissiez générer des journaux dans Cloud Logging, Cloud Logging doit être activé sur un job. Les exécutables de la tâche doivent également être configurés pour écrire toutes les informations que vous souhaitez afficher dans les journaux sur les flux de sortie standard (stdout) et d'erreur standard (stderr). Pour en savoir plus, consultez la page Analyser une tâche à l'aide de journaux.
• Les tâches n'ont pas été exécutées. Les journaux ne peuvent pas être produits tant que les ressources n'ont pas été attribuées et que les tâches ne commencent pas à s'exécuter.
• Cloud Logging a été configuré de manière à exclure automatiquement les journaux du job. Les journaux des tâches Batch ne peuvent pas apparaître si vous avez configuré des filtres d'exclusion pour Cloud Logging qui entraînent l'exclusion des journaux des tâches Batch.

Solution

Pour résoudre ce problème, procédez comme suit :

1. Assurez-vous que les journaux n'ont pas été automatiquement exclus de Cloud Logging en désactivant les filtres d'exclusion pour Cloud Logging actuels.
2. Assurez-vous que l'API Cloud Logging est activée pour votre projet.
3. Assurez-vous que le compte de service associé à la tâche dispose du rôle IAM Rédacteur de journaux (roles/logging.logWriter). Pour en savoir plus, consultez la page Activer Batch pour un projet.
4. Affichez les détails de la tâche à l'aide de gcloud CLI ou de l'API Batch. Les détails de la tâche peuvent vous aider à comprendre pourquoi la tâche n'a pas produit de journaux et fournir des informations que vous espériez obtenir à partir des journaux. Par exemple :
   1. Pour vérifier que la journalisation est activée, consultez le champ logsPolicy de la tâche.
   2. Pour vérifier que la tâche s'est bien exécutée, consultez le champ status de la tâche.

Une fois les modifications effectuées, recréez la tâche et attendez la fin de son exécution avant de vérifier les journaux.

Aucun reporting d'agent de service

Problème

Le problème suivant apparaît dans le champ statusEvents pour une tâche qui ne s'exécute pas correctement ou qui a échoué avant la création des VM:

No VM has agent reporting correctly within time window NUMBER_OF_SECONDS seconds, VM state for instance VM_NAME is TIMESTAMP,agent,start

Le problème indique qu'aucune VM d'une tâche ne renvoie de rapport à l'agent de service Batch.

Ce problème survient souvent pour les raisons suivantes:

• Les VM de la tâche ne disposent pas des autorisations nécessaires. Les VM d'une tâche nécessitent des autorisations spécifiques pour communiquer leur état à l'agent de service Batch. Vous pouvez fournir ces autorisations pour les VM d'une tâche en attribuant le rôle Responsable de signalement d'agent par lot (roles/batch.agentReporter) au compte de service de la tâche.
• Les VM de la tâche présentent des problèmes de réseau. Les VM d'un job ont besoin d'un accès réseau pour communiquer avec l'agent de service Batch.
• Les VM de la tâche utilisent une image d'OS de VM par lot obsolète ou une image d'OS de VM avec un logiciel d'agent de service Batch obsolète. Les VM de la tâche nécessitent un logiciel dans son image d'OS de VM qui fournit les dépendances actuelles pour la création de rapports à l'agent de service Batch.

Solution

Pour identifier le problème, procédez comme suit :

1. Vérifiez que les VM de la tâche disposent des autorisations nécessaires pour signaler leur état à l'agent de service Batch.

   1. Pour identifier le compte de service de la tâche, affichez les détails de la tâche à l'aide de gcloud CLI ou de l'API Batch. Si aucun compte de service n'est répertorié, la tâche utilise par défaut le compte de service Compute Engine par défaut.

   2. Vérifiez que le compte de service de la tâche dispose des autorisations nécessaires pour le rôle Responsable du signalement d'agent par lot (roles/batch.agentReporter). Pour en savoir plus, consultez les sections Gérer l'accès et Restreindre l'utilisation des comptes de service.

      Par exemple, pour accorder au compte de service Compute Engine par défaut les autorisations requises, utilisez la commande suivante:

      gcloud projects add-iam-policy-binding PROJECT_ID \
        --role roles/batch.agentReporter \
        --member serviceAccount:[e-mail]
      

      • Remplacez PROJECT_NUMBER par votre numéro de projet.
      • Remplacez PROJECT_ID par l'ID de votre projet.

2. Vérifiez que les VM du job disposent d'un accès réseau approprié. Pour en savoir plus, consultez les pages Présentation de la mise en réseau par lots et Résoudre les problèmes de mise en réseau courants.

3. Si vous avez spécifié l'image d'OS de la VM pour la tâche, vérifiez qu'elle est actuellement compatible.

   1. Si vous avez activé Cloud Logging pour la tâche, vous pouvez identifier ce problème en recherchant l'un des journaux d'agent suivants (batch_agent_logs). Pour en savoir plus, consultez la section Analyser une tâche à l'aide des journaux.

      • Journal pour l'erreur logicielle obsolète de l'agent de service Batch:

        rpc error: code = FailedPrecondition, desc = Invalid resource state for BATCH_AGENT_VERSION: outdated Batch agent version used.
        

        BATCH_AGENT_VERSION est la version du logiciel permettant de communiquer avec l'agent de service Batch utilisé par la tâche (par exemple, cloud-batch-agent_20221103.00_p00).

      • Journal de l'erreur d'image d'OS de VM par lot obsolète:

        rpc error: code = FailedPrecondition, desc = Invalid resource state for BATCH_VM_OS_IMAGE_NAME: outdated Batch image version.
        

        BATCH_VM_OS_IMAGE_NAME est la version spécifique d'une image de système d'exploitation de VM issue de Batch que le job utilise, par exemple batch-debian-11-20220909-00-p00.

   2. Vous pouvez résoudre ce problème en utilisant une image d'OS de VM plus récente. Si la tâche utilise une image personnalisée, recréez-la en vous basant sur l'une des dernières versions d'une image publique compatible.

      Pour en savoir plus, consultez Images d'OS de VM compatibles et Afficher les images d'OS de VM.

4. Recréez le job.

Métriques sur les ressources manquantes dans Cloud Monitoring

Problème

Vous souhaitez afficher les métriques relatives aux ressources d'une tâche, mais certaines ou toutes les métriques attendues sont manquantes.

Ce problème survient souvent pour les raisons suivantes:

• L'API n'a pas été activée pour votre projet. Même si vous configurez correctement tous les autres éléments de votre projet, les métriques sur les ressources peuvent ne pas apparaître tant que l'API Cloud Monitoring n'est pas activée. Pour l'agent Ops, vous devez également activer l'API Cloud Logging.
• Vous ne disposez pas des autorisations nécessaires pour afficher les métriques. Vous ne pouvez pas afficher les métriques sans autorisations suffisantes.
• Les VM du job ne se sont pas exécutées. Pour qu'une tâche puisse générer des métriques, au moins l'une des VM associées doit être en cours d'exécution.
• La configuration ou les autorisations du job n'étaient pas compatibles avec les métriques de l'agent Ops. Certaines métriques liées aux ressources ne peuvent être fournies que par l'agent Ops. Pour utiliser les métriques de l'agent Ops, une tâche doit répondre aux exigences de l'agent Ops, l'installer et utiliser un compte de service capable d'écrire des métriques dans Monitoring.
• Vous devez utiliser une autre méthode ou un autre filtre pour afficher les métriques. Certaines méthodes d'affichage des métriques n'affichent pas les métriques pour les VM après leur suppression. De plus, les métriques ne s'affichent pas si elles sont omises par les filtres ou la période affichée. De plus, la résolution des graphiques de métriques est ajustable, ce qui peut rendre de petites quantités de données trop fines pour être affichées.
• Les métriques ont été supprimées. Vous ne pouvez plus afficher les métriques après leur suppression, qui se produit automatiquement après la durée de conservation de Monitoring.

Solution

Si seules des métriques de l'agent Ops sont manquantes, essayez d'abord de résoudre le problème comme suit:

1. Vérifiez la configuration de la tâche en procédant comme suit :
   1. Pour afficher toutes les informations de configuration de la tâche, affichez les détails de la tâche à l'aide de gcloud CLI ou de l'API Batch. Utilisez le résultat pour les étapes restantes.
   2. Assurez-vous que le compte de service de la tâche dispose des autorisations nécessaires pour écrire des métriques de l'agent Ops.
   3. Assurez-vous que la tâche répond à toutes les exigences de l'Agent Ops.
   4. Assurez-vous que le job installe correctement l'agent Ops. Bien qu'il soit possible d'installer l'agent Ops manuellement dans un exécutable, la méthode recommandée consiste à installer automatiquement l'agent Ops en définissant le champ installOpsAgent sur true.
2. Si le problème persiste, consultez la section Résoudre les problèmes liés à l'agent Ops dans la documentation Google Cloud Observability.

Sinon, procédez comme suit pour résoudre le problème:

1. Assurez-vous que l'API Monitoring est activée pour votre projet :

   Activer l'API

2. Assurez-vous que les VM du job ont commencé à s'exécuter et que la durée d'exécution est toujours comprise dans les durées de conservation Monitoring. Vous pouvez consulter la durée d'exécution de la tâche en affichant les détails de la tâche.
3. Pour vérifier qu'il n'y a pas de problème avec les méthodes que vous utilisez pour afficher les métriques, procédez comme suit :
   1. À moins que vous ne souhaitiez afficher les métriques que pour les ressources en cours d'exécution, assurez-vous de les afficher à l'aide de l'explorateur de métriques ou d'un tableau de bord personnalisé créé à partir de graphiques de l'explorateur de métriques. D'autres méthodes, telles que les tableaux de bord Compute Engine, n'affichent pas de métriques sur les ressources supprimées.
   2. Assurez-vous que la période d'affichage inclut la durée d'exécution du job. Pour les graphiques, assurez-vous également que la résolution du graphique est adaptée à vos données.
   3. Assurez-vous qu'aucun filtre ne masque les données.
4. Si le problème persiste, consultez les pages Résoudre les problèmes liés à Cloud Monitoring dans la documentation Google Cloud Observability.

Contrainte non respectée pour les adresses IP externes des VM

Problème

Le problème suivant apparaît dans le champ statusEvents en cas d'échec d'une tâche:

Instance VM_NAME creation failed: Constraint constraints/compute.vmExternalIpAccess violated for project PROJECT_NUMBER.
Add instance VM_NAME to the constraint to use external IP with it.

Ce problème est dû au fait que votre projet, dossier ou organisation a défini la contrainte de règle d'administration compute.vmExternalIpAccess de sorte que seules les VM figurant sur la liste d'autorisation peuvent utiliser des adresses IP externes.

Solution

Pour résoudre le problème, recréez le job et effectuez l'une des opérations suivantes:

• Utilisez un projet exempt de la contrainte.
• Créez un job qui bloque l'accès externe pour toutes les VM.

Contrainte non respectée pour les images de confiance

Problème

Le problème suivant apparaît dans le champ statusEvents en cas d'échec d'une tâche:

Instance VM_NAME creation failed: Constraint constraints/compute.trustedImageProjects violated for project PROJECT_ID. Use of images from project batch-custom-image is prohibited.

Solution

Ce problème est dû au fait que votre projet a défini la contrainte de règle des images de confiance (compute.trustedImageProjects). Par conséquent, les images de Batch, qui se trouvent dans le projet d'images batch-custom-image, ne sont pas autorisées.

Pour résoudre le problème, effectuez au moins l'une des opérations suivantes:

• Recréez la tâche pour spécifier une image d'OS de VM déjà autorisée par la contrainte de règle des images de confiance.
• Demandez à votre administrateur de vous autoriser à modifier la contrainte de règle relative aux images de confiance afin d'autoriser les images d'OS de VM du projet d'images batch-custom-image. Pour obtenir des instructions, consultez la section Contrôler l'accès aux images d'OS de VM pour Batch.

Échec du job lors de l'utilisation d'un modèle d'instance

Problème

Le problème suivant apparaît dans le champ statusEvents pour une tâche ayant échoué qui utilise un modèle d'instance:

INVALID_FIELD_VALUE,BACKEND_ERROR

Ce problème est dû à des problèmes peu clairs avec le modèle d'instance du job.

Solution

Pour déboguer le problème, procédez comme suit:

1. Créez un MIG à l'aide du modèle d'instance et examinez avec plus de détails si des erreurs se produisent.

2. Facultatif: Pour essayer de trouver plus d'informations, consultez l'opération de longue durée qui crée le MIG dans la console Google Cloud.

   Accéder à la page "Opérations Compute Engine"

Codes de sortie d'échec de la tâche

Lorsqu'une tâche spécifique échoue, celle-ci renvoie un code de sortie différent de zéro. Selon la configuration du champ ignoreExitStatus, une tâche en échec peut ou non entraîner l'échec d'une tâche.

En plus de tous les codes de sortie que vous définissez dans un exécutable, un Batch comporte plusieurs codes de sortie réservés, y compris les codes de sortie suivants.

Préemption de VM (50001)

Problème

Le problème suivant apparaît dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to Spot Preemption with exit code 50001.

Ce problème se produit lorsqu'une VM Spot dédiée au job est préemptée pendant l'exécution.

Solution

Pour résoudre le problème, effectuez l'une des opérations suivantes:

• Relancez la tâche soit en utilisant des tentatives automatisées, soit en réexécutant manuellement la tâche.
• Pour garantir l'absence de préemption, utilisez plutôt des VM avec le modèle de provisionnement standard.

Délai avant expiration des rapports de la VM (50002)

Problème

Le problème suivant apparaît dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to Batch no longer receives VM updates with exit code 50002.

Ce problème se produit lorsqu'un délai avant expiration dans le backend a empêché une VM de la tâche de recevoir des mises à jour.

Solution

Pour résoudre ce problème, relancez la tâche à l'aide de nouvelles tentatives automatisées ou réexécutez manuellement la tâche.

La VM a redémarré pendant l'exécution (50003)

Problème

Le problème suivant apparaît dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to VM is rebooted during task execution with exit code 50003.

Ce problème se produit lorsqu'une VM associée à un job redémarre de manière inattendue pendant l'exécution.

Solution

Pour résoudre ce problème, relancez la tâche à l'aide de nouvelles tentatives automatisées ou réexécutez manuellement la tâche.

La VM et la tâche ne répondent pas (50004)

Problème

Le problème suivant apparaît dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to tasks cannot be canceled with exit code 50004.

Ce problème se produit lorsqu'une tâche atteint la limite de temps sans réponse et ne peut pas être annulée.

Solution

Pour résoudre ce problème, relancez la tâche à l'aide de nouvelles tentatives automatisées ou réexécutez manuellement la tâche.

La tâche s'exécute sur la durée d'exécution maximale (50005)

Problème

Le problème suivant apparaît dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to task runs over the maximum runtime with exit code 50005.

Ce problème survient dans les cas suivants:

• La durée d'exécution d'une tâche dépasse la limite de temps spécifiée dans le champ maxRunDuration
• La durée d'exécution d'un exécutable dépasse la limite de temps spécifiée dans le champ timeout

Pour identifier précisément le délai dépassé, affichez les journaux de la tâche et recherchez un journal mentionnant le code de sortie 50005. Le champ textPayload de ce journal indique où et quand la limite de temps a été dépassée.

Important :En raison d'un problème connu, les journaux générés par Batch pour le dépassement du délai avant expiration n'indiquent pas si le délai avant expiration de la tâche ou de l'exécutable a été dépassé. Pour savoir comment identifier le délai avant expiration dépassé, consultez le problème connu.

Solution

Pour résoudre le problème, essayez de vérifier la durée d'exécution totale requise par la tâche ou l'exécutable qui a dépassé le délai. Effectuez l'une des opérations suivantes :

• Si vous ne vous attendez à cette erreur qu'occasionnellement, par exemple pour une tâche ou un exécutable avec une durée d'exécution incohérente, vous pouvez essayer de recréer la tâche et de la configurer pour automatiser les tentatives d'exécution des tâches afin d'essayer d'augmenter le taux de réussite.

• Sinon, si la tâche ou l'exécution a besoin intentionnellement de plus de temps que le délai d'expiration actuel pour s'exécuter de manière cohérente, définissez un délai avant expiration plus long.

VM recréée pendant l'exécution (50006)

Problème

Le problème suivant apparaît dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to VM is recreated during task execution with exit code 50006.

Ce problème se produit lorsqu'une VM est recréée de manière inattendue pour un job pendant l'exécution.

Solution

Pour résoudre ce problème, relancez la tâche à l'aide de nouvelles tentatives automatisées ou réexécutez manuellement la tâche.

Étapes suivantes

• Obtenez de l'aide pour Batch.