Dépannage

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

Si vous essayez de résoudre des problèmes liés à une tâche pour laquelle vous ne recevez pas de message d'erreur, vérifiez si les événements d'état de la tâche contiennent des messages d'erreur avant de consulter ce document:

  1. Affichez les détails de la mission.
  2. Examinez le champ "Événements d'état" :

    • Si vous utilisez la console Google Cloud, cliquez sur l'onglet Événements, puis consultez la section Liste des événements.
    • Si vous utilisez gcloud CLI ou l'API Batch, vérifiez le champ statusEvents.

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

Erreurs liées à la création de jobs

Si vous ne parvenez pas à créer de 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 est à 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 à l'emplacement spécifié.

Solution

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

  • Si le job a été retardé, essayez d'attendre que davantage de quota soit libéré.

  • Si la tâche a échoué en raison d'un quota insuffisant ou si ces retards persistent, essayez d'éviter que le quota soit insuffisant en procédant comme suit:

    • Créez des jobs qui utilisent une partie de ce quota inférieure ou un quota différent. Par exemple, vous pouvez spécifier un autre emplacement ou un autre type de ressource autorisé pour la tâche, ou répartir l'utilisation du quota sur 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 un job:

  • Si le job n'utilise pas de modèle d'instance, le problème se présente comme suit:

    caller does not have access to act as the specified service account: SERVICE_ACCOUNT_NAME
    
  • Si la tâche utilise un modèle d'instance, le problème se présente 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 est généralement dû au fait que 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 s'est vu attribuer le 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 la tâche.

Réseaux répétés

Problème

Le problème suivant se produit lorsque vous essayez de créer un job:

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 plusieurs fois pour un job.

Solution

Pour résoudre le problème, recréez la tâche et spécifiez le réseau à l'aide de 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.
  • Indicateurs --network et --subnetwork:ces indicateurs peuvent être utilisés avec la commande gcloud batch jobs submit lorsque vous créez une tâche à l'aide de 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 un job:

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 est dû au fait que vous essayez de créer et d'exécuter un job 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 plus d'informations sur la configuration de la mise en réseau pour une tâche dans un périmètre de service VPC Service Controls, consultez la page Utiliser VPC Service Controls avec Batch.

Erreurs liées à l'échec du job

Si vous rencontrez des problèmes avec une tâche qui 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 de la section Codes de sortie pour les échecs de tâches.

Aucun journal dans Cloud Logging

Problème

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

Ce problème se produit 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, celui-ci ne générera pas de journaux si le service n'est pas activé pour votre projet.
  • Le compte de service du job ne dispose pas des autorisations nécessaires pour écrire des journaux. Une tâche ne peut pas produire de journaux si elle ne dispose pas des autorisations nécessaires.
  • La tâche n'a pas été configurée pour générer des journaux. Pour générer des journaux dans Cloud Logging, Cloud Logging doit être activé pour une tâche. Les exécutables de la tâche doivent également être configurés pour écrire les informations que vous souhaitez voir apparaître dans les journaux des flux de sortie standard (stdout) et d'erreur standard (stderr). Pour plus d'informations, consultez la page Analyser une tâche à l'aide des journaux.
  • Tâches non exécutées. Les journaux ne peuvent être générés que lorsque des ressources sont attribuées aux tâches et qu'elles commencent à s'exécuter.

Solution

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

  1. Assurez-vous que l'API Cloud Logging est activée pour votre projet.
  2. Assurez-vous que le compte de service de 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.
  3. 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 elle n'a pas généré de journaux. Elles peuvent vous fournir les informations que vous espériez obtenir à partir des journaux. Par exemple, procédez comme suit :
    1. Pour vérifier que la journalisation est activée, examinez le champ logsPolicy de la tâche.
    2. Pour vérifier que la tâche a bien été exécutée, examinez le champ status de celle-ci.

Aucun rapport 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 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 signale à l'agent de service Batch.

Ce problème se produit souvent pour les raisons suivantes:

  • Les VM du job ne disposent pas des autorisations suffisantes. Les VM d'une tâche nécessitent des autorisations spécifiques pour signaler leur état à l'agent de service Batch. Vous pouvez accorder ces autorisations aux VM d'une tâche en attribuant le rôle Responsable du signalement d'agent de traitement par lot (roles/batch.agentReporter) au compte de service de la tâche.
  • Les VM du job présentent des problèmes de réseau. Les VM d'une tâche ont besoin d'un accès réseau pour communiquer avec l'agent de service Batch.
  • Les VM du job utilisent une image d'OS de VM Batch 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 requièrent 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 du job 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 listé, le job utilise par défaut le compte de service Compute Engine par défaut.
    2. Vérifiez que le compte de service du job dispose des autorisations nécessaires pour le rôle "Auteur du signalement de l'agent par lot" (roles/batch.agentReporter). Pour en savoir plus, consultez Gérer l'accès et Limiter l'utilisation des comptes de service.

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

      gcloud projects add-iam-policy-binding \
        --role roles/batch.agentReporter \
        --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com
      

      Remplacez PROJECT_NUMBER par le numéro 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 de l'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 Analyser une tâche à l'aide des journaux.

      • Journal des erreurs logicielles de l'agent de service Batch obsolètes:

        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 des erreurs liées à l'image de système d'exploitation de VM Batch 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 d'OS de VM issue de Batch utilisée par le job (par exemple, batch-debian-11-20220909-00-p00).

    2. Vous pouvez résoudre ce problème en utilisant une image de l'OS de VM plus récente. Si la tâche utilise une image personnalisée, recréez-la à partir de 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 la tâche.

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

Problème

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

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 ajoutées à la liste d'autorisation puissent utiliser des adresses IP externes.

Solution

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

Contrainte non respectée pour les images de confiance

Problème

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

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 Images de confiance (compute.trustedImageProjects) de sorte que 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 de l'OS de VM déjà autorisée par la contrainte de règle relative aux images de confiance.
  • Demandez à votre administrateur d'autoriser la modification de la contrainte de règle relative aux images de confiance pour 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 d'une tâche ayant échoué qui utilise un modèle d'instance:

INVALID_FIELD_VALUE,BACKEND_ERROR

Ce problème survient en raison de problèmes peu clairs avec le modèle d'instance du job.

Solution

Pour poursuivre le débogage du problème, procédez comme suit:

  1. Créez un groupe d'instances géré à l'aide du modèle d'instance et observez si des erreurs se produisent avec plus de détails.
  2. Facultatif: Pour essayer d'obtenir 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 en cas d'échec de la tâche

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

En plus des codes de sortie que vous définissez dans un exécutable, un Batch possède 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 pour le 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 effectuant des relances automatisées de tâches ou en la réexécutant manuellement.
  • Pour vous assurer qu'il n'y a pas de préemption, utilisez plutôt des VM avec le modèle de provisionnement standard.

Délai d'expiration des rapports sur les 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 d'inactivité dans le backend a entraîné l'arrêt de la réception des mises à jour par une VM pour le job.

Solution

Pour résoudre ce problème, relancez la tâche soit en effectuant de nouvelles tentatives automatisées, soit en la réexécutant manuellement.

VM redémarrée 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 à une tâche redémarre de manière inattendue pendant l'exécution.

Solution

Pour résoudre ce problème, relancez la tâche soit en effectuant de nouvelles tentatives automatisées, soit en la réexécutant manuellement.

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 le délai imparti pour ne pas répondre et ne peut pas être annulée.

Solution

Pour résoudre ce problème, relancez la tâche soit en effectuant de nouvelles tentatives automatisées, soit en la réexécutant manuellement.

La tâche s'exécute au-delà de 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 se produit lorsque la durée d'exécution d'une tâche dépasse la limite de temps spécifiée dans le champ maxRunDuration.

Solution

Pour résoudre le problème, essayez de vérifier le temps nécessaire à l'exécution de chaque tâche. Effectuez l'une des opérations suivantes :

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

  • Sinon, si l'exécution des tâches dépasse systématiquement la limite autorisée par le champ maxRunDuration, recréez la tâche, puis augmentez la valeur du champ maxRunDuration ou supprimez-le.

Étapes suivantes