Résoudre les problèmes liés aux modèles Flex

Cette page fournit des conseils de dépannage et des stratégies de débogage qui vous seront utiles si vous utilisez des modèles Flex Dataflow. Ces informations peuvent vous aider à détecter une expiration du délai d'interrogation, à déterminer la raison de ce délai et à corriger le problème.

Résoudre les problèmes liés aux délais d'interrogation

Cette section décrit la procédure permettant d'identifier la cause des délais d'interrogation.

Délais d'interrogation

Votre tâche de modèle Flex peut renvoyer le message d'erreur suivant :

Timeout in polling result file: ${file_path}.
Service account: ${service_account_email}
Image URL: ${image_url}
Troubleshooting guide at https://cloud.google.com/dataflow/docs/guides/common-errors#timeout-polling

Ce problème peut survenir pour les raisons suivantes :

  1. L'image Docker de base a été remplacée.
  2. Le compte de service qui remplit ${service_account_email} ne dispose pas de certaines autorisations nécessaires.
  3. Les adresses IP externes sont désactivées, et les VM ne peuvent pas se connecter à l'ensemble des adresses IP externes utilisées par les API et les services Google.
  4. L'exécution du programme en charge de la création du graphique est trop longue.
  5. Les options de pipeline sont en cours d'écrasement.
  6. (Python uniquement) Le fichier requirements.txt rencontre un problème.
  7. Une erreur temporaire s'est produite.

Pour résoudre ce problème, commencez par rechercher des erreurs temporaires en consultant les journaux de la tâche et en réessayant. Si ces étapes ne permettent pas de résoudre le problème, essayez les étapes de dépannage suivantes.

Vérifier le point d'entrée Docker

Suivez cette étape si vous exécutez un modèle à partir d'une image Docker personnalisée au lieu d'utiliser l'un des modèles fournis.

Recherchez le point d'entrée du conteneur à l'aide de la commande suivante :

docker inspect $TEMPLATE_IMAGE

Le résultat suivant est attendu :

Java

/opt/google/dataflow/java_template_launcher

Python

/opt/google/dataflow/python_template_launcher

Si vous obtenez un autre résultat, le point d'entrée de votre conteneur Docker est remplacé. Restaurez la valeur par défaut de $TEMPLATE_IMAGE.

Vérifier les autorisations du compte de service

Vérifiez que le compte de service mentionné dans le message dispose des autorisations suivantes :

  • Il doit pouvoir lire et écrire le chemin d'accès Cloud Storage qui remplit ${file_path} dans le message.
  • Il doit pouvoir lire l'image Docker qui remplit ${image_url} dans le message.

Configurer l'accès privé à Google

Si les adresses IP externes sont désactivées, vous devez autoriser les VM Compute Engine à se connecter à l'ensemble des adresses IP externes utilisées par les API et services Google. Activez l'accès privé à Google sur le sous-réseau utilisé par l'interface réseau de la VM.

Pour en savoir plus sur la configuration, consultez la section Configurer l'accès privé à Google.

Par défaut, lorsqu'une VM Compute Engine n'a pas d'adresse IP externe attribuée à son interface réseau, elle ne peut envoyer des paquets qu'à d'autres destinations d'adresses IP internes.

Vérifier si le programme de lancement a un problème pour se fermer

Le programme qui construit le pipeline doit se fermer avant que le pipeline puisse démarrer. L'erreur d'interrogation peut indiquer que l'opération est trop longue.

Voici quelques actions que vous pouvez effectuer pour identifier la cause dans le code :

  • Consultez les journaux des tâches et vérifiez si l'exécution d'une opération prend beaucoup de temps. Prenons l'exemple d'une requête pour une ressource externe.
  • Assurez-vous qu'aucun thread ne bloque la fermeture du programme. Certains clients peuvent créer leurs propres threads. Si ces clients ne sont pas arrêtés, le programme attend indéfiniment leur jonction.

Les pipelines lancés directement qui n'utilisent pas de modèle ne sont pas soumis à ces limites. Par conséquent, si le pipeline fonctionne directement, mais pas en tant que modèle, alors l'utilisation d'un modèle peut être la cause du problème. La seule solution est de rechercher et résoudre le problème dans le modèle.

Vérifier si les options de pipeline requises sont supprimées

Lorsque vous utilisez des modèles Flex, vous pouvez configurer certaines options de pipeline lors de l'initialisation du pipeline, mais pas toutes. Pour en savoir plus, consultez la section Échec de la lecture du fichier de job de ce document.

Supprimer Apache Beam du fichier d'exigences (Python uniquement)

Si votre Dockerfile inclut un fichier requirements.txt avec apache-beam[gcp], supprimez-le du fichier et installez-le séparément. La commande suivante montre comment effectuer cette étape :

RUN pip install apache-beam[gcp]
RUN pip install -U -r ./requirements.txt

L'ajout d'Apache Beam au fichier d'exigences peut entraîner de longs délais de lancement, ce qui entraîne souvent un délai d'inactivité.

Délais d'interrogation lors de l'utilisation de Python

Si vous exécutez une tâche Dataflow en utilisant un modèle Flex avec Python, votre tâche peut être mise en file d'attente pendant une certaine période, ne pas réussir à s'exécuter, puis afficher l'erreur suivante :

Timeout in polling

Le fichier requirements.txt utilisé pour installer les dépendances requises génère l'erreur. Lorsque vous lancez une tâche Dataflow, toutes les dépendances sont d'abord mises en préproduction afin de rendre ces fichiers accessibles aux VM de nœud de calcul. Ce processus implique le téléchargement et la compilation de toutes les dépendances directes et indirectes figurant dans le fichier requirements.txt. La compilation de certaines dépendances peut prendre plusieurs minutes. La compilation de PyArrow peut prendre du temps. PyArrow est une dépendance indirecte utilisée par Apache Beam et la plupart des bibliothèques clientes Cloud.

Pour optimiser les performances de votre tâche, utilisez un Dockerfile ou un conteneur personnalisé pour pré-empaqueter les dépendances. Pour en savoir plus, consultez la section Dépendances de packages de la page "Configurer des modèles Flex".

Échecs de lancement de tâches

La section suivante contient des erreurs courantes qui entraînent des échecs de lancement de tâches et des étapes pour les résoudre ou pour le dépannage.

Problèmes de démarrage précoce

Lorsque le processus de lancement de modèle échoue de façon précoce, les journaux de modèle Flex standards peuvent ne pas être disponibles. Pour enquêter sur les problèmes de démarrage, activez la journalisation des ports série pour la VM du lanceur de modèles.

Pour activer la journalisation des modèles Java, définissez l'option enableLauncherVmSerialPortLogging sur true. Pour activer la journalisation pour les modèles Python et Go, définissez l'option enable_launcher_vm_serial_port_logging sur true. Dans la console Google Cloud, le paramètre est répertorié dans la section Paramètres facultatifs comme Activer la journalisation du port série des VM de lanceur d'applications.

Vous pouvez afficher les journaux des données de sortie du port série des VM de lanceur de modèles dans Cloud Logging. Pour trouver les journaux d'une VM de lanceur spécifique, utilisez la requête resource.type="gce_instance" "launcher-number", où number commence par la date actuelle au format YYYMMDD.

Votre règle d'administration peut vous interdire d'activer la journalisation des données en sortie du port série.

Échec de la lecture du fichier de tâche

Lorsque vous essayez d'exécuter une tâche à partir d'un modèle Flex, votre tâche peut échouer avec l'une des erreurs suivantes :

Failed to read the job file : gs://dataflow-staging-REGION-PROJECT_ID/staging/template_launches/TIMESTAMP/job_object with error message: ...: Unable to open template file

ou

Failed to read the result file : gs://BUCKET_NAME with error message: (ERROR_NUMBER): Unable to open template file: gs://BUCKET_NAME

Cette erreur se produit lorsque les options d'initialisation de pipeline nécessaires sont écrasées. Lorsque vous utilisez des modèles Flex, vous pouvez configurer certaines options de pipeline lors de l'initialisation du pipeline, mais pas toutes. Si les arguments de ligne de commande requis par le modèle Flex sont écrasés, la tâche peut ignorer, remplacer ou supprimer les options de pipeline transmises par le lanceur de modèles. La tâche peut échouer au lancement ou une tâche qui n'utilise pas le modèle Flex peut être lancée.

Pour éviter ce problème, ne modifiez pas les options de pipeline suivantes dans le code utilisateur ou dans le fichier metadata.json lors de l'initialisation du pipeline :

Java

  • runner
  • project
  • jobName
  • templateLocation
  • region

Python

  • runner
  • project
  • job_name
  • template_location
  • region

Go

  • runner
  • project
  • job_name
  • template_location
  • region

Autorisation refusée pour la ressource

Lorsque vous essayez d'exécuter une tâche à partir d'un modèle Flex, votre tâche peut échouer avec l'erreur suivante:

Permission "MISSING_PERMISSION" denied on resource "projects/PROJECT_ID/locations/REGION/repositories/REPOSITORY_NAME" (or it may not exist).

Cette erreur se produit lorsque le compte de service utilisé n'est pas autorisé à accéder aux ressources nécessaires pour exécuter un modèle Flex.

Pour éviter ce problème, vérifiez que le compte de service dispose des autorisations requises. Ajustez les autorisations du compte de service si nécessaire.

Option fournie, mais non définie

Lorsque vous essayez d'exécuter un modèle Flex Go avec l'option de pipeline worker_machine_type, le pipeline échoue avec l'erreur suivante :

flag provided but not defined: -machine_type

Cette erreur est due à un problème connu dans les versions 2.47.0 et antérieures du SDK Apache Beam pour Go. Pour résoudre ce problème, mettez à niveau Apache Beam Go vers la version 2.48.0 ou une version ultérieure.

Délai du lanceur de modèles Flex

Lorsque vous envoyez un job de modèle Flex, la requête du job est placée dans une file d'attente Spanner. Le lanceur de modèles récupère la tâche dans la file d'attente Spanner, puis exécute le modèle. Lorsqu'un backlog de messages est présent dans Spanner, un délai important peut s'écouler entre le moment où vous envoyez le job et celui où le job est lancé.

Pour contourner ce problème, lancez votre modèle Flex à partir d'une autre région.

Les paramètres du modèle ne sont pas valides

Lorsque vous essayez d'utiliser gcloud CLI pour exécuter une tâche qui utilise un modèle fourni par Google, l'erreur suivante se produit :

ERROR: (gcloud.beta.dataflow.flex-template.run) INVALID_ARGUMENT: The template
parameters are invalid. Details: defaultSdkHarnessLogLevel: Unrecognized
parameter defaultWorkerLogLevel: Unrecognized parameter

Cette erreur se produit, car certains modèles fournis par Google ne sont pas compatibles avec les options defaultSdkHarnessLog et defaultWorkerLog.

Pour contourner ce problème, copiez le fichier de spécification du modèle dans un bucket Cloud Storage. Ajoutez les paramètres supplémentaires suivants au fichier.

"metadata": {
    ...
    "parameters": [
      ...,
      {
        "name": "defaultSdkHarnessLogLevel",
        "isOptional": true,
        "paramType": "TEXT"
      },
      {
        "name": "defaultWorkerLogLevel",
        "isOptional": true,
        "paramType": "TEXT"
      }
    ]
  }

Après avoir apporté cette modification au fichier de modèle, exécutez le modèle à l'aide de la commande suivante.

--template-file-gcs-location=gs://BUCKET_NAME/FILENAME

Remplacez les valeurs suivantes :

  • BUCKET_NAME : nom de votre bucket Cloud Storage
  • FILENAME : nom du fichier de spécification de modèle

Les journaux du lanceur de modèle Flex affichent une gravité incorrecte

Lorsqu'un lancement de modèle Flex personnalisé échoue, le message suivant s'affiche dans les fichiers journaux avec la gravité ERROR :

ERROR: Error occurred in the launcher container: Template launch failed. See console logs.

La cause première de l'échec du lancement apparaît généralement dans les journaux avant ce message avec le niveau de gravité INFO. Bien que ce niveau de journalisation puisse être incorrect, il est normal que le lanceur de modèle Flex ne puisse pas extraire les détails de gravité des messages de journal générés par l'application Apache Beam.

Si vous souhaitez afficher le niveau de gravité correct pour chaque message dans le journal du lanceur, configurez votre modèle pour générer des journaux au format JSON plutôt qu'au format texte brut. Cette configuration permet au lanceur de modèles d'extraire le niveau de gravité correct des messages de journal. Utilisez la structure de messages suivante :

{
  "message": "The original log message",
  "severity": "DEBUG/INFO/WARN/ERROR"
}

En Java, vous pouvez utiliser l'enregistreur Logback avec une implémentation appender JSON personnalisée. Pour en savoir plus, consultez l'exemple de configuration Logback et l'exemple de code d'appender JSON dans GitHub.

Ce problème ne concerne que les journaux générés par le lanceur de modèle Flex lors du lancement du pipeline. Une fois le lancement réussi et le pipeline en cours d'exécution, la gravité des journaux produits par les nœuds de calcul Dataflow est appropriée.

Les modèles fournis par Google affichent le niveau de gravité correct lors du lancement du job, car ils utilisent cette approche de journalisation JSON.