Guidage d'erreur commun

Cette page décrit certaines erreurs courantes que vous pouvez rencontrer lors de l'exécution de votre tâche Dataflow, et suggère des mesures à prendre pour corriger ces erreurs.

Erreurs d'indisponibilité de ressources :

Messages des tâches :

Erreurs d'envoi des tâches :

Journaux de nœud de calcul :

Erreurs d'entrée et de sortie :

Erreurs de démarrage du nœud de calcul :

Journaux :

Recommandations :

Erreurs d'indisponibilité de ressources

Résoudre les erreurs associées à l'épuisement d'un pool de ressources

Parfois, lorsque vous créez une ressource Google Cloud, une erreur peut s'afficher et indiquer l'épuisement d'un pool de ressources. Cette erreur indique une condition d'épuisement temporaire pour une ressource spécifique dans une zone spécifique. Le format des messages est le suivant :

ERROR: ZONE_RESOURCE_POOL_EXHAUSTED

Pour résoudre le problème, vous pouvez attendre un certain délai ou créer la même ressource dans une autre zone. Une bonne pratique que nous vous recommandons consiste à répartir vos ressources sur plusieurs zones et régions afin de permettre la tolérance aux interruptions.

Messages des tâches

The job failed because a work item failed 4 times.

Si une seule opération entraîne l'échec du code de nœud de calcul à quatre reprises, par le code qui génère une exception ou provoque une panne, Dataflow fait échouer la tâche et le message a work item failed 4 times est affiché. Vous ne pouvez pas configurer ce seuil d'échec. Pour plus de détails, reportez-vous à la section Traitement des erreurs et des exceptions de pipeline.

Recherchez les quatre échecs un par un dans les journaux Cloud Monitoring de la tâche. Recherchez des entrées de journal de niveau Erreur ou de niveau Fatal dans les journaux des nœuds de calcul qui affichent des exceptions ou des erreurs. Vous devez voir au moins quatre de ces exceptions ou erreurs.

Erreurs d'encodage, exceptions IOException ou comportement inattendu dans le code utilisateur.

Les SDK Apache Beam et les nœuds de calcul Dataflow dépendent de composants tiers courants. Ces composants importent des dépendances supplémentaires. Les conflits de version peuvent entraîner un comportement inattendu au niveau du service. Si vous utilisez l'un de ces packages dans votre code, sachez que certaines bibliothèques peuvent ne pas offrir une compatibilité ascendante. Vous devrez peut-être épingler les versions incluses dans le champ d'application pendant l'exécution. La page Dépendances des SDK et des nœuds de calcul contient la liste des dépendances et des versions requises associées.

Des tâches qui fonctionnaient auparavant échouent maintenant avec le message d'erreur Staged package...is inaccessible

  • Vérifiez que le bucket Cloud Storage utilisé pour la préproduction ne présente pas de paramètres TTL (Time To Live) entraînant la suppression des packages en préproduction.
  • Vérifiez que le compte de service du contrôleur du projet Dataflow est autorisé à accéder au bucket Cloud Storage utilisé en préproduction. Les lacunes des autorisations peuvent être dues à l'une des raisons suivantes :

    • Le bucket Cloud Storage utilisé en préproduction est présent dans un autre projet.
    • Le bucket Cloud Storage utilisé en préproduction a été migré d'un accès ultraprécis à un accès uniforme au niveau du bucket. En raison de l'incohérence entre les stratégies IAM et ACL, la migration du bucket de préproduction vers un accès uniforme au niveau du bucket interdit les LCA pour les ressources Cloud Storage, ce qui comprend les autorisations dont dispose le service de contrôleur de votre projet Dataflow sur le bucket de préproduction.

Pour en savoir plus, consultez la page Accéder aux buckets Cloud Storage entre projets Google Cloud.

Expiration du délai d'interrogation du modèle Flex

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

Cela peut être dû aux 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. L'exécution du programme en charge de la création du graphique est trop longue.
  4. (Python uniquement) Le fichier requirements.txt présente un problème.
  5. Une erreur temporaire s'est produite.

En plus de vérifier les journaux des tâches et de relancer les tentatives en cas d'échec temporaire, voici quelques étapes de dépannage supplémentaires.

Vérifier le point d'entrée Docker

Cette étape est destinée aux utilisateurs qui exécutent 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

La page suivante doit normalement s'afficher :

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.

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 attendra indéfiniment que ces threads soient associés.

Notez que les pipelines lancés directement (sans utiliser de modèle) ne présentent pas ces limites. Si le pipeline fonctionnait directement, mais a échoué en tant que modèle, il pourrait s'agir de l'origine des problèmes.

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

Si votre Dockerfile inclut un fichier requirements.txt avec apache-beam[gcp], vous devez le supprimer du fichier et l'installer séparément. Exemple :

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

L'ajout de Beam à ce fichier d'exigences rallonge les temps de lancement et entraîne souvent un délai d'attente.

Tâche de modèle Flex Python entre en file d'attente et expire

Si vous exécutez une tâche Dataflow à l'aide d'un modèle Flex et de Python, votre tâche peut être mise en file d'attente pendant un certain temps, puis échouer. Un message d'erreur Timeout in polling s'affiche.

L'erreur est due au fichier requirements.txt utilisé pour installer les dépendances requises. 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. Le processus implique le téléchargement et la recompilation de toutes les dépendances directes et indirectes figurant dans le fichier requirements.txt. La compilation de certaines dépendances peut prendre plusieurs minutes, notamment PyArrow, qui est une dépendance indirecte utilisée par Apache Beam et la plupart des bibliothèques clientes Google Cloud.

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

  1. Téléchargez les dépendances précompilées du fichier Dockerfile dans le répertoire de préproduction de Dataflow.

  2. Définissez la variable d'environnement PIP_NO_DEPS sur True.

    Ce paramètre empêche pip de télécharger et de compiler à nouveau toutes les dépendances, ce qui permet d'éviter l'erreur d'expiration de délai.

Voici un exemple de code qui montre comment les dépendances sont pré-téléchargées.

# Copyright 2020 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#    http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

FROM gcr.io/dataflow-templates-base/python3-template-launcher-base

ENV FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE="/template/requirements.txt"
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="/template/streaming_beam.py"

COPY . /template

# We could get rid of installing libffi-dev and git, or we could leave them.
RUN apt-get update \
    && apt-get install -y libffi-dev git \
    && rm -rf /var/lib/apt/lists/* \
    # Upgrade pip and install the requirements.
    && pip install --no-cache-dir --upgrade pip \
    && pip install --no-cache-dir -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE \
    # Download the requirements to speed up launching the Dataflow job.
    && pip download --no-cache-dir --dest /tmp/dataflow-requirements-cache -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE

# Since we already downloaded all the dependencies, there's no need to rebuild everything.
ENV PIP_NO_DEPS=True

Erreurs d'envoi des tâches

413 Request Entity Too Large/The size of serialized JSON representation of the pipeline exceeds the allowable limit

Si vous rencontrez une erreur liée à la charge utile JSON lors de l'envoi de votre tâche, cela signifie que la représentation JSON de votre pipeline dépasse la taille de requête maximale, fixée à 20 Mo. Ces erreurs peuvent être signalées par l'un des messages suivants dans la fenêtre de la console ou du terminal :

  • 413 Request Entity Too Large
  • "The size of serialized JSON representation of the pipeline exceeds the allowable limit" (La taille de la représentation JSON sérialisée du pipeline dépasse la limite autorisée)
  • "Failed to create a workflow job: Invalid JSON payload received" (Échec de la création d'une tâche de workflow : la charge utile JSON reçue n'est pas valide)
  • "Failed to create a workflow job: Request payload exceeds the allowable limit" (Échec de la création d'une tâche de workflow : la charge utile de la requête dépasse la limite autorisée)

La taille de votre tâche est spécifiquement liée à la représentation JSON du pipeline. Plus celui-ci est grand, plus la taille de la requête sera importante. Dataflow limite actuellement la taille des requêtes à 20 Mo.

Pour estimer la taille de la requête JSON correspondant à votre pipeline, exécutez celui-ci avec l'option suivante :

Java

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

Cette commande écrit une représentation JSON de votre tâche dans un fichier. La taille du fichier sérialisé fournit une bonne approximation de la taille de la requête. La taille réelle sera légèrement supérieure du fait de l'inclusion d'informations supplémentaires dans la requête.

Certaines caractéristiques de votre pipeline peuvent amener la représentation JSON à dépasser la limite. Les facteurs de dépassement les plus courants sont les suivants :

  • Une transformation Create incluant une grande quantité de données en mémoire.
  • Une instance DoFn volumineuse sérialisée pour transmission aux nœuds de calcul distants
  • Une fonction DoFn définie comme une instance d'une classe interne anonyme, et qui intègre (peut-être par inadvertance) une grande quantité de données à sérialiser

Pour éviter ces situations, envisagez de restructurer votre pipeline.

The job graph is too large. Please try again with a smaller job graph, or split your job into two or more smaller jobs.

La taille du graphique de votre tâche ne doit pas dépasser 10 Mo. Certaines conditions existantes dans votre pipeline peuvent entraîner un dépassement de la limite de la part du graphique. Les facteurs de dépassement les plus courants sont les suivants :

  • Une transformation Create incluant une grande quantité de données en mémoire.
  • Une instance DoFn volumineuse sérialisée pour transmission aux nœuds de calcul distants
  • Une fonction DoFn définie comme une instance d'une classe interne anonyme, et qui intègre (peut-être par inadvertance) une grande quantité de données à sérialiser

Pour éviter ces situations, envisagez de restructurer votre pipeline.

Total number of BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit ou Total size of the BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit.

Java

Cette erreur est susceptible de se produire lorsque vous lisez des données à partir d'un très grand nombre de fichiers via TextIO, AvroIO ou une autre source basée sur des fichiers. La limite exacte dépend des détails de votre source (par exemple, l'intégration de schémas dans AvroIO.Read limite le nombre de fichiers autorisés), mais elle est de l'ordre de plusieurs dizaines de milliers de fichiers par pipeline.

Vous pouvez également rencontrer cette erreur si vous avez créé une source de données personnalisée pour votre pipeline et que la méthode splitIntoBundles de votre source a renvoyé une liste d'objets BoundedSource qui occupe plus de 20 Mo une fois sérialisée.

La limite autorisée pour la taille totale des objets BoundedSource générés par l'opération splitIntoBundles() de votre source personnalisée est de 20 Mo. Vous pouvez contourner cette limitation en modifiant votre sous-classe BoundedSource personnalisée de telle sorte que la taille totale des objets BoundedSource générés soit inférieure à cette limite de 20 Mo. Par exemple, votre source pourrait générer un nombre réduit de divisions initiales et s'appuyer sur le rééquilibrage dynamique du travail pour fractionner davantage les entrées à la demande.

"Les options de pipeline du SDK ou la liste des fichiers de préproduction dépassent la taille maximale. La longueur de chaque élément doit être inférieure à 256 000 octets, soit 512 000 octets au total."

Le pipeline n'a pas pu démarrer en raison du dépassement des limites de métadonnées de Google Compute Engine. Ces limites ne peuvent pas être modifiées. Dataflow utilise les métadonnées Compute Engine pour les options de pipeline. Cette limite est documentée dans les limites des métadonnées personnalisées Compute Engine.

Si les fichiers JAR à placer sont trop nombreux, la représentation JSON peut dépasser la limite.

Comment trouver l'option de pipeline complète et sa longueur ? Pour estimer la taille de la requête JSON correspondant à votre pipeline, exécutez celui-ci avec l'option suivante :

Java

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

La taille du fichier de sortie ci-dessus doit être inférieure à 256 000 octets. 512 000 octets dans le message d'erreur font référence à la taille totale du fichier de sortie ci-dessus et aux options de métadonnées personnalisées pour l'instance de VM Compute Engine. Une estimation approximative de l'option de métadonnées personnalisées pour l'instance de VM peut être déterminée à partir de l'exécution de tâches Dataflow dans le projet. Choisissez une tâche Dataflow en cours d'exécution, sélectionnez une instance de VM, puis accédez à la page des détails de l'instance de VM Compute Engine pour cette VM afin de vérifier la section des métadonnées personnalisées. La longueur totale des métadonnées personnalisées et du fichier ci-dessus doit être inférieure à 512 000 octets. Il n'est pas possible de donner une estimation précise pour la tâche ayant échoué, car les VM associées à cette tâche n'ont pas été activées.

Si votre liste de fichiers JAR atteint la limite des 256 000 octets, examinez-la et réduisez les fichiers JAR inutiles. Si elle est toujours trop importante, essayez d'exécuter la tâche Dataflow à l'aide d'un fichier Uber JAR.

La section Cloud Functions de la documentation contient un exemple de création et d'utilisation de fichier Uber JAR.

Startup of the worker pool in zone $ZONE failed to bring up any of the desired $N workers. The project quota may have been exceeded or access control policies may be preventing the operation; review the Cloud Logging 'VM Instance' log for diagnostics.

Cette erreur a deux causes possibles :

  • Vous avez peut-être dépassé l'un des quotas Compute Engine dont dépend la création de nœuds de calcul Dataflow.
  • Votre organisation a mis en place des contraintes qui interdisent certains aspects du processus de création d'instances de VM, telles que le compte utilisé ou la zone ciblée.

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

Consultez le journal des instances de VM.

  1. Accédez à la visionneuse Cloud Logging.
  2. Dans la liste déroulante Ressource auditée, sélectionnez Instance de VM.
  3. Dans la liste déroulante Tous les journaux, sélectionnez compute.googleapis.com/activity_log.
  4. Recherchez dans le journal les entrées éventuelles liées à l'échec de la création d'une instance de VM.

Vérifiez votre utilisation des quotas Compute Engine.

  1. Sur la ligne de commande de votre machine locale ou dans Cloud Shell, exécutez la commande suivante pour afficher l'utilisation des ressources Compute Engine par rapport aux quotas Dataflow pour la zone que vous ciblez :

    gcloud compute regions describe [REGION]

  2. Examinez les résultats des ressources suivantes pour voir si certaines dépassent le quota :

    • CPUS
    • DISKS_TOTAL_GB
    • IN_USE_ADDRESSES
    • INSTANCE_GROUPS
    • INSTANCE_GROUP_MANAGERS
    • INSTANCES
  3. Si nécessaire, demandez une modification du quota.

Examinez les contraintes liées aux règles d'administration.

  1. Accéder à la page Règles d'administration
  2. Passez en revue les contraintes pour tout élément pouvant limiter la création d'instances de VM pour le compte que vous utilisez (il s'agit du compte de service Dataflow par défaut) ou dans la zone que vous ciblez.

Journaux de nœud de calcul

"Traitement bloqué à l'étape <step_id> pendant au moins <time_interval> sans sortie ni fin à l'état terminé sur <stack_trace>"

Si Dataflow passe plus de temps à exécuter une opération DoFn que le temps spécifié dans <time_interval> sans retour, ce message est affiché.

Cette erreur a deux causes possibles :

  • Votre code DoFn est tout simplement lent, ou en attente d'une opération externe lente.
  • Votre code DoFn peut être bloqué ou anormalement lent pour terminer le traitement.

Pour déterminer votre cas, développez l'entrée de journal Cloud Monitoring pour afficher une trace de la pile. Recherchez les messages indiquant que le code DoFn est bloqué ou rencontre des problèmes. Si aucun n'est présent, le problème peut être la vitesse d'exécution du code DoFn. Envisagez d'utiliser Cloud Profiler ou un autre outil pour analyser les performances du code.

Vous pouvez approfondir les recherches sur la cause de blocage de votre code si votre pipeline s'appuie sur la VM Java (avec Java ou Scala). Effectuez un vidage de thread complet de la VM Java entière (pas seulement du thread bloqué) en procédant comme suit :

  1. Notez le nom du nœud de calcul à partir de l'entrée de journal.
  2. Dans la section Compute Engine de Cloud Console, recherchez l'instance Compute Engine avec le nom du nœud de calcul que vous avez noté.
  3. Accédez via SSH à l'instance portant ce nom.
  4. Exécutez la commande suivante :

    curl http://localhost:8081/threadz
    

Exceptions liées à une clé de brassage trop volumineuse

Si vous rencontrez des exceptions indiquant que la clé de brassage est trop volumineuse, cela signifie que la clé sérialisée attribuée à une valeur (Co-)GroupByKey particulière, après l'application du codeur correspondant, est trop grande. Dataflow possède une limite pour les clés de brassage sérialisées. Pensez à réduire la taille des clés ou à utiliser des codeurs plus économes en espace.

KeyCommitTooLargeException

Dans les scénarios de traitement par flux, cela peut être dû au regroupement d'une très grande quantité de données sans utiliser de transformation Combine, ou à la production d'une grande quantité de données à partir d'un seul élément en entrée. Les stratégies suivantes peuvent réduire le risque de rencontrer cette exception :

  • Assurez-vous que le traitement d'un seul élément ne peut pas entraîner des sorties ou des modifications d'état dépassant les limites.
  • Si plusieurs éléments ont été regroupés suivant une clé, envisagez d'augmenter l'espace de clé pour réduire les éléments regroupés par clé.
  • Si les éléments associés à une clé sont émis à une fréquence élevée sur une courte période, cela peut générer de nombreux Go d'événements pour cette clé dans les fenêtres. Réécrivez le pipeline afin de détecter les clés de ce type et émettez une sortie indiquant uniquement que la clé figurait fréquemment dans cette fenêtre.
  • Veillez à utiliser des transformations d'espace sous-linéaires Combine pour les opérations commutatives et associatives. N'utilisez pas de combinaison si elle ne réduit pas l'espace. Par exemple, utiliser une combinaison pour ajouter des chaînes est pire que de ne pas utiliser de combinaison.

Exceptions de délai avant expiration de RPC, exceptions DEADLINE_EXCEEDED ou erreurs Server Unresponsive

Si vous rencontrez des exceptions de dépassement du délai RPC, des exceptions DEADLINE_EXCEEDED ou des erreurs Server Unresponsive pendant l'exécution de votre tâche, il s'agit généralement de l'un des deux problèmes suivants :

  • Il manque une règle de pare-feu dans le réseau VPC utilisé pour votre tâche. Cette règle de pare-feu doit autoriser tout le trafic TCP entre les VM du réseau VPC que vous avez spécifié dans les options de pipeline. Pour plus de détails, consultez la page Spécifier votre réseau et votre sous-réseau.

  • Votre tâche est limitée en capacités de brassage. Appliquez l'une ou plusieurs des mesures correctives suivantes :

    Java

    • Si la tâche n'utilise pas le brassage basé sur les services, passez à la fonctionnalité Dataflow Shuffle basée sur les services en définissant --experiments=shuffle_mode=service. Pour plus d'informations, consultez la page Dataflow Shuffle.
    • Ajoutez des nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --numWorkers.
    • Augmentez la taille des disques associés aux nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --diskSizeGb.
    • Utilisez un disque persistant SSD. Essayez d'exécuter votre pipeline en spécifiant une valeur pour le paramètre --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd".

    Python

    • Si la tâche n'utilise pas le brassage basé sur les services, passez à la fonctionnalité Dataflow Shuffle basée sur les services en définissant --experiments=shuffle_mode=service. Pour plus d'informations, consultez la page Dataflow Shuffle.
    • Ajoutez des nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --num_workers.
    • Augmentez la taille des disques associés aux nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --disk_size_gb.
    • Utilisez un disque persistant SSD. Essayez d'exécuter votre pipeline en spécifiant une valeur pour le paramètre --worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd".

Un appel provenant du faisceau du nœud de calcul Java vers une classe Python DoFn a échoué avec l'erreur <error message>

Si un objet DoFn implémenté dans Python échoue et génère une exception, le message d'erreur correspondant s'affiche.

Développez l'entrée du journal des erreurs Cloud Monitoring, et examinez le message d'erreur et la trace. Vous découvrirez ainsi quelle ligne de code a échoué afin de la corriger si nécessaire. Si vous pensez qu'il s'agit d'un bug dans Apache Beam ou Dataflow, veuillez le signaler.

Aucun espace restant sur le dispositif

Lorsqu'une tâche manque d'espace disque, des erreurs No space left on device peuvent s'afficher dans les journaux des nœuds de calcul.

Si une tâche télécharge des dépendances volumineuses lors de l'exécution, utilise de grands conteneurs personnalisés ou écrit beaucoup de données temporaires sur le disque local, le stockage persistant du nœud de calcul risque de manquer d'espace.

Lorsque vous utilisez Dataflow Shuffle, Dataflow définit une taille minimale de disque par défaut. Par conséquent, les tâches provenant du brassage basé sur les nœuds de calcul peuvent également afficher cette erreur.

Il est également possible que le disque de démarrage du nœud de calcul se remplisse s'il enregistre plus de 50 entrées par seconde.

Pour afficher les ressources de disque associées à un seul nœud de calcul, recherchez les détails d'instance de VM pour les VM de nœud de calcul associées à votre tâche. Une partie de l'espace disque est consommée par le système d'exploitation, les fichiers binaires, les journaux et les conteneurs.

Pour augmenter l'espace sur le disque persistant ou le disque de démarrage, ajustez l'option de pipeline de taille de disque.

Vous pouvez suivre l'utilisation de l'espace disque sur les instances de VM de nœud de calcul à l'aide de Cloud Monitoring. Consultez la section Recevoir les métriques de VM de nœuds de calcul via l'agent Monitoring pour obtenir des instructions sur la configuration.

Vous pouvez également rechercher les problèmes d'espace de disque de démarrage en affichant les données en sortie du port série sur les instances de VM de nœud de calcul, et en recherchant des messages tels que "Échec de l'ouverture du journal système : aucun espace restant sur le dispositif". Si vous disposez d'un grand nombre d'instances de VM de nœud de calcul, vous pouvez plutôt créer un script pour exécuter gcloud compute instances get-serial-port-output sur toutes ces instances simultanément et examiner le résultat produit.

Pour en savoir plus, consultez la section Tarifs des disques persistants.

EOFError : données marshal trop courtes

Cette erreur se produit parfois lorsque les nœuds de calcul du pipeline Python manquent d'espace disque. Consultez la section Espace insuffisant sur l'appareil.

Avertissements Bad request dans les journaux du shuffler

Lors de l'exécution d'une tâche Dataflow, les journaux Cloud Monitoring peuvent afficher une série d'avertissements semblables à ce qui suit :

Unable to update setup work item <step_id> error: generic::invalid_argument: Http(400) Bad Request
Update range task returned 'invalid argument'. Assuming lost lease for work with id <lease_id>
with expiration time: <timestamp>, now: <timestamp>. Full status: generic::invalid_argument: Http(400) Bad Request

Des avertissements "Requête incorrecte" apparaissent car les informations sur l'état du nœud de calcul sont obsolètes ou désynchronisées en raison de retards de traitement. Le plus souvent, votre tâche Dataflow aboutit, malgré ces avertissements "Requête incorrecte". Si tel est le cas, ignorez les avertissements.

Une clé chaude <hot-key-name> a été détectée dans...

Ces erreurs identifient une clé chaude dans vos données. Une clé chaude est une clé contenant suffisamment d'éléments pour avoir un impact négatif sur les performances du pipeline. Ces clés limitent la capacité de Dataflow à traiter les éléments en parallèle, ce qui a pour effet d'augmenter le temps d'exécution.

Pour consigner la présence d'une clé chaude , utilisez l'option de pipeline de clé chaude.

Vérifiez si vos données sont réparties de manière égale. Si une clé comporte un nombre disproportionné de valeurs, appliquez les mesures suivantes :

Échec du pipeline de conteneurs personnalisé Python avec SystemError : opcode inconnu

Si vous rencontrez une erreur Python SystemError: unknown opcode inattendue juste après l'envoi de la tâche et que la trace de la pile inclut apache_beam/internal/pickler.py, vérifiez que la version de Python que vous utilisez correspond localement à la version du conteneur, en termes de version majeure et de version mineure. Une différence au niveau de la version de correctif, telle que 3.6.7 et 3.6.8, ne crée pas de problèmes de compatibilité, mais une différence de version mineure, telle que 3.6.8 et 3.8.2, peut entraîner des échecs du pipeline.

Erreurs d'entrée et de sortie

Les graphiques de métriques d'E/S utilisent des codes d'erreur canoniques. Si ces codes d'erreur persistent dans vos sources et récepteurs, consultez la liste suivante pour connaître les causes possibles et les actions que vous pouvez entreprendre.

  • RESOURCE_EXHAUSTED. Le projet peut avoir dépassé son quota de ressources pour le service utilisé par la source ou le récepteur.

    Si l'erreur se produit occasionnellement ou si le graphique Requêtes par seconde indique un volume élevé de requêtes effectuées, cela peut indiquer que vous avez atteint un quota de limitation du débit des API et que vous devez augmenter le quota.

  • DEADLINE_EXCEEDED. La source ou le récepteur peuvent avoir dépassé le délai d'attente de lecture ou d'écriture d'un grand lot de données. Vérifiez le graphique de latence et les journaux des nœuds de calcul. Si l'erreur persiste, contactez l'assistance.

  • INVALID_ARGUMENT. Les paramètres spécifiés pour la source ou le récepteur peuvent être incorrects (par exemple, un sujet Pub/Sub). Vérifiez la configuration de la source ou du récepteur, puis consultez les journaux des nœuds de calcul.

  • FAILED_PRECONDITION. Vérifiez la configuration de la source ou du récepteur, puis consultez les journaux des nœuds de calcul. Ce code d'erreur peut également indiquer un bug.

  • OUT_OF_RANGE. Vérifiez que la ressource utilisée par la source ou le récepteur existe (par exemple un sujet ou un abonnement Pub/Sub).

  • UNAUTHENTICATED. Vérifiez que le compte de service Dataflow dispose des autorisations Identity and Access Management pour le service spécifique et que les API associées sont activées pour le projet.

  • PERMISSION_DENIED. Vérifiez que le compte de service Dataflow dispose des autorisations Identity and Access Management pour le service spécifique et que les API associées sont activées pour le projet.

  • NOT_FOUND. Vérifiez que les entités utilisées par la source ou le récepteur existent (par exemple, un sujet ou un abonnement Pub/Sub).

  • ABORTED. Il est possible que le service ne gère pas correctement la source, ou que les récepteurs tentent de lire ou d'écrire des données. Si l'erreur persiste, contactez l'assistance.

  • ALREADY_EXISTS. E/S peut essayer de créer une entité qui existe déjà (comme un sujet ou un abonnement Pub/Sub). Si l'erreur persiste, contactez l'assistance.

  • CANCELLED. Cela peut se produire lorsqu'un nœud de calcul Dataflow est arrêté ou lorsqu'une logique de source ou de récepteur décide d'annuler intentionnellement les tentatives de lecture ou d'écriture de données.

  • DATALOSS. Indique qu'une perte de données irréversible ou une altération s'est produite. Vous pouvez créer un nouvel ensemble de données pour vos sources et réexécuter la tâche Dataflow.

    Vous pouvez également vérifier si des instructions de sauvegarde et de restauration sont disponibles pour le service Google Cloud sous-jacent.

  • UNKNOWN. Il est possible que le service soit en panne. Recherchez les mises à jour éventuelles sur le tableau de bord d'état du cloud pour en savoir plus.

  • INTERNAL. Il est possible que le service soit en panne. Recherchez les mises à jour éventuelles sur le tableau de bord d'état du cloud pour en savoir plus.

  • UNAVAILABLE. Il est possible que le service soit en panne. Recherchez les mises à jour éventuelles sur le tableau de bord d'état du cloud pour en savoir plus.

  • UNIMPLEMENTED. La source ou le récepteur a tenté d'utiliser le service de manière incorrecte. Il est possible que votre pipeline soit mal configuré. Si l'erreur persiste, contactez l'assistance.

Erreurs de démarrage du nœud de calcul

Les erreurs dans les types de journaux dataflow.googleapis.com/worker-startup, dataflow.googleapis.com/harness-startup et dataflow.googleapis.com/kubelet indiquent des problèmes de configuration d'une tâche. Elles peuvent également indiquer des conditions empêchant le bon fonctionnement du chemin d'accès de journalisation normal.

Erreurs NoClassDefFound

Ces erreurs peuvent également se présenter sous la forme Unable to initialize main class [...]. Les erreurs NoClassDefFound indiquent que les fichiers JAR importés dans le service Dataflow ne contiennent pas les classes nécessaires à l'exécution de Dataflow. Cela se produit le plus souvent lorsque--filesToStagePipelineOption est ignoré, et certains fichiers JAR ou de classe requis sont omis.

Échec de la demande d'extraction d'image avec une erreur

Cette erreur indique qu'un nœud de calcul n'a pas pu démarrer, car il n'a pas pu extraire une image de conteneur Docker. Cela peut se produire si l'URL de l'image du conteneur personnalisé du SDK est incorrecte, ou si le nœud de calcul ne dispose pas des identifiants ou d'un accès réseau à l'image distante.

Si vous utilisez une image de conteneur personnalisée avec votre tâche, vérifiez que l'URL de votre image est correcte, qu'elle contient un tag ou un condensé valide, et que l'image est accessible par les nœuds de calcul Dataflow.

Vérifiez que les images publiques peuvent être extraites localement en exécutant la commande docker pull $image à partir d'une machine non authentifiée.

Il existe également des considérations supplémentaires relatives aux images privées ou aux nœuds de calcul privés.

  • Dataflow n'accepte les images de conteneurs privées que si elles sont hébergées sur Container Registry. Si vous utilisez Container Registry pour héberger votre image de conteneur, le compte de service Google Cloud par défaut peut déjà accéder aux images du même projet. Si vous utilisez des images d'un autre projet que celui utilisé pour exécuter votre tâche Google Cloud, veillez à configurer le contrôle d'accès pour le compte de service Google Cloud par défaut.
  • Si vous utilisez un cloud privé virtuel (VPC) partagé, assurez-vous que les nœuds de calcul peuvent accéder à l'hôte du dépôt de conteneurs personnalisés.
  • Utilisez ssh pour vous connecter à une VM de nœud de calcul de tâche en cours d'exécution et exécutez docker pull $image pour vérifier directement que le nœud de calcul est correctement configuré.

Si les nœuds de calcul échouent plusieurs fois de suite en raison de cette erreur et qu'aucun travail n'a commencé sur une tâche, celle-ci peut échouer avec une erreur de type Job appears to be stuck. .... Si vous avez supprimé l'accès à l'image pendant l'exécution de la tâche, que ce soit en supprimant l'image elle-même ou en révoquant les identifiants du compte de service de nœud de calcul Dataflow ou l'accès Internet permettant d'accéder aux images, Dataflow ne consigne que les erreurs et ne prend pas de mesures pour faire échouer la tâche. Dataflow évite également de faire échouer les pipelines de streaming de longue durée afin d'éviter de perdre l'état des pipelines.

D'autres erreurs peuvent provenir de problèmes de quota de dépôt ou d'interruptions. Si vous rencontrez des problèmes de dépassement du quota Docker Hub pour l'extraction d'images publiques ou de pannes générales liées à un dépôt tiers, envisagez d'utiliser Container Registry en tant que service de dépôt d'images.

Erreur lors de la synchronisation du pod ... Échec de "StartContainer"

Cette erreur indique qu'un conteneur Docker de nœud de calcul n'a pas pu démarrer. Cela se produit généralement lorsqu'un des conteneurs plante en permanence au démarrage.

Si le conteneur plante, recherchez un message d'erreur décrivant l'échec dans les journaux worker-startup, harness-startup ou docker. Les erreurs d'installation pip (pip install failed with error...) sont une erreur de démarrage courante pour les tâches Python liée à des problèmes de dépendance. Cela peut inclure la spécification de dépendances incompatibles ou des problèmes de réseau qui rendent les dépôts spécifiés inaccessibles. Le SDK Python Apache Beam installé dans le conteneur doit être identique au SDK utilisé pour lancer la tâche.

Cette erreur peut également se produire si l'image de conteneur ne peut pas être extraite lors d'une tâche de longue durée. Pour en savoir plus, consultez la section "Échec de la demande d'extraction d'image avec une erreur".

"Une erreur fatale a été détectée par l'environnement d'exécution Java"

Cela indique que le pipeline utilise JNI (Java Native Interface) pour exécuter du code non Java, et qu'il y a une erreur dans ce code ou dans les liaisons JNI.

Journaux

Aucun journal ne s'affiche

Si vous ne voyez aucun journal pour vos tâches, supprimez les filtres d'exclusion contenant resource.type="dataflow_step" de tous les récepteurs du Routeur de journaux de Cloud Logging.

Accéder au Routeur de journaux

Pour en savoir plus sur la suppression de vos exclusions de journaux, consultez le guide Supprimer des exclusions.

Recommandations

Utilisation élevée du quota de transfert Streaming Engine

Les tâches qui utilisent Streaming Engine sont soumises à une limite régionale pour la quantité de données qu'elles peuvent transférer vers/depuis Streaming Engine. Il est important de rester en dessous de cette limite, car cela peut affecter les performances des tâches. En outre, réduire le nombre d'octets transférés peut également réduire les coûts facturés.

Pour afficher la limite de votre projet, consultez les instructions de la section Quotas et limites. Pour afficher l'utilisation actuelle liée à vos tâches, cliquez sur ce lien vers l'explorateur de métriques. Si nécessaire, sélectionnez le projet dans lequel votre tâche s'exécute. Remplacez ensuite REGION par la région qui vous intéresse, puis cliquez sur "Exécuter la requête".

Suggestions permettant de réduire l'utilisation :

  • Réduisez la quantité de données traitées par les transformations GroupByKey et Combine. Pour ce faire, vous pouvez réduire le nombre d'éléments transmis ou omettre les champs inutiles.
  • Encodez les données plus efficacement pour qu'elles occupent moins d'espace. Dans certains cas, cela peut augmenter l'utilisation du processeur sur le nœud de calcul.

    • Pour les types de données personnalisés, le codeur par défaut peut être inefficace (SerializableCoder en Java, PickleCoder en Python). Essayez de sélectionner un codeur par défaut plus efficace pour le type personnalisé ou une PCollection avec un schéma.

      Pour des explications plus détaillées concernant les codeurs et leur spécification, consultez le chapitre du guide de programmation de Beam consacré à l'encodage des données. Pour en savoir plus sur les PCollections avec des schémas, consultez le chapitre consacré aux schémas.

    • Pour les éléments volumineux, l'application de la compression peut aider.

  • Réduisez les opérations de lecture d'état volumineuses. Par exemple, un pipeline doté d'un état BagState suffisamment gros doit le transférer depuis Streaming Engine chaque fois qu'il est récupéré.

    • Essayez de réduire la taille de l'état.
    • Essayez de réduire la fréquence des récupérations d'état.
    • L'état est lié à une clé et une fenêtre spécifiques. Le fenêtrage non global peut être utilisé pour limiter la taille des états.

    Pour en savoir plus sur l'état, consultez le chapitre du guide de programmation de Beam consacré aux états et aux timers.

Autoscaling : la valeur maxNumWorkers peut être augmentée

Dataflow a détecté qu'une tâche utilise le nombre maximal de nœuds de calcul autorisés (maxNumWorkers ou max_num_workers) et qu'elle pourrait utiliser davantage de nœuds de calcul si ce maximum est augmenté. Par exemple, cette recommandation est fournie pour une tâche dont le paramètre maxNumWorkers est défini sur 50 et qui utilise 50 nœuds de calcul avec une utilisation moyenne du processeur supérieure à 80 %.

En règle générale, l'augmentation de maxNumWorkers accroît le débit du pipeline : un pipeline par lots peut se terminer en moins de temps, et un pipeline en streaming peut gérer des pics de données plus importants et traiter davantage d'éléments par seconde. Cette opération peut toutefois entraîner une augmentation des coûts (consultez la section Tarifs des ressources de nœuds de calcul). Consultez le guide d'autoscaling pour en savoir plus sur le fonctionnement et la configuration de l'algorithme d'autoscaling.

Suggestions :

  • Essayez d'augmenter l'option de pipeline maxNumWorkers ou de la supprimer. Sans cette option, Dataflow utilisera les valeurs par défaut répertoriées dans le guide de l'autoscaling.
  • Vous pouvez laisser les choses en l'état si les performances du pipeline sont satisfaisantes.
    • Pour les pipelines par lots, vérifiez que le temps d'exécution total répond à vos exigences.
    • Pour les pipelines de streaming, consultez le graphique de fraîcheur des données dans l'onglet "Métriques de la tâche" de la page de la tâche. Assurez-vous que ce graphique n'augmente pas en permanence et que les valeurs sont situées dans les limites acceptables.

Distribution ramifiée élevée détectée

Dataflow a détecté qu'une tâche comporte une ou plusieurs transformations avec une distribution ramifiée élevée. Cela se produit lorsqu'une opération ParDo ayant un ratio d'éléments sortie-entrée élevé est fusionnée avec une opération ParDo ultérieure. Dans ce cas, la deuxième opération ParDo est exécutée de manière séquentielle avec la première. Cela force tous les éléments de sortie d'une entrée donnée sur le même nœud de calcul, ce qui réduit le parallélisme et ralentit les performances.

Suggestions :

  • Insérez une fonction GroupByKey et dissociez le groupe après votre première opération ParDo. Le service Dataflow ne fusionne jamais les opérations ParDo sur une agrégation.
  • Transmettez la classe PCollection intermédiaire en tant qu'entrée secondaire à une autre opération ParDo. Le service Dataflow matérialise toujours les entrées secondaires.
  • Insérez une étape de rebrassage. Le rebrassage empêche la fusion, contrôle les données et reconfigure la stratégie de fenêtrage pour qu'aucune donnée ne soit supprimée. Le rebrassage des données est pris en charge par Dataflow, même s'il est marqué comme obsolète dans la documentation d'Apache Beam (notez que le rebrassage des données peut augmenter le coût d'exécution de votre pipeline).