Dépanner les DAG

Cloud Composer 1 | Cloud Composer 2

Cette page fournit des procédures de dépannage et des informations sur les problèmes courants liés aux workflows.

De nombreux problèmes d'exécution de DAG sont causés par des performances d'environnement non optimales. Vous pouvez optimiser votre environnement Cloud Composer 2 en suivant le guide Optimiser les performances et les coûts de l'environnement.

Certains problèmes d'exécution du DAG peuvent être causés par le programmeur Airflow qui ne fonctionne pas correctement ou de manière optimale. Veuillez suivre les instructions de dépannage du programmeur pour résoudre ces problèmes.

Résoudre un problème lié aux workflows

Pour commencer à résoudre les problèmes, procédez comme suit :

  1. Vérifiez les journaux Airflow.
  2. Consultez le tableau de bord Monitoring.
  3. Examinez Cloud Monitoring.
  4. Dans Cloud Console, vérifiez les erreurs sur les pages des composants de votre environnement.
  5. Dans l'interface Web Airflow, vérifiez si les instances de tâche ont échoué dans la vue graphique du DAG.

    Conseil: Pour parcourir un grand DAG à la recherche d'instances de tâches ayant échoué, définissez l'orientation de la vue graphique de LR à RL en ignorant l'option de configuration Airflow suivante:

    Section Clé Valeur
    webserver dag_orientation LR, TB, RL ou BT

Déboguer des échecs de l'opérateur

Pour déboguer un échec de l'opérateur, procédez comme suit :

  1. Recherchez les erreurs spécifiques à la tâche.
  2. Vérifiez les journaux Airflow.
  3. Examinez Cloud Monitoring.
  4. Vérifiez les journaux spécifiques à l'opérateur.
  5. Corrigez les erreurs.
  6. Importez le DAG dans le dossier dags/.
  7. Dans l'interface Web Airflow, effacez les états passés du DAG.
  8. Relancez ou exécutez le DAG.

Problèmes courants

Les sections suivantes décrivent les symptômes et les correctifs potentiels de certains problèmes courants liés aux DAG.

La tâche échoue sans émettre de journaux en raison d'erreurs d'analyse du DAG

Parfois, des erreurs subtiles de DAG peuvent entraîner une situation dans laquelle un programmeur Airflow et un processeur DAG peuvent planifier des tâches pour s'exécuter et analyser un fichier DAG (respectivement), mais le nœud de calcul Airflow ne parvient pas à exécuter des tâches à partir de ce DAG, car il existe des erreurs de programmation dans le fichier DAG Python. Cela peut conduire à une situation dans laquelle une tâche Airflow est marquée comme Failed et où aucun journal n'a été exécuté.

Solution: vérifiez dans les journaux des nœuds de calcul Airflow qu'aucune erreur n'est générée par le nœud de calcul Airflow dans le cas d'erreurs d'analyse du DAG ou du DAG.

La tâche échoue sans émettre de journaux en raison de la pression des ressources

Symptôme: lors de l'exécution d'une tâche, le sous-processus du nœud de calcul Airflow qui est responsable de l'exécution de la tâche Airflow est brusquement interrompu. L'erreur visible dans le journal Airflow du nœud de calcul peut ressembler à celle-ci:

...
File "/opt/python3.8/lib/python3.8/site-packages/celery/app/trace.py", line 412, in trace_task    R = retval = fun(*args, **kwargs)  File "/opt/python3.8/lib/python3.8/site-packages/celery/app/trace.py", line 704, in __protected_call__    return self.run(*args, **kwargs)  File "/opt/python3.8/lib/python3.8/site-packages/airflow/executors/celery_executor.py", line 88, in execute_command    _execute_in_fork(command_to_exec)  File "/opt/python3.8/lib/python3.8/site-packages/airflow/executors/celery_executor.py", line 99, in _execute_in_fork
raise AirflowException('Celery command failed on host: ' + get_hostname())airflow.exceptions.AirflowException: Celery command failed on host: airflow-worker-9qg9x
...

Solution :

La tâche échoue sans émettre de journaux en raison de l'éviction des pods

Les pods Google Kubernetes Engine sont soumis au cycle de vie des pods Kubernetes et à l'éviction des pods. Les pics de tâches et la coplanification des nœuds de calcul sont deux des causes les plus courantes de l'éviction des pods dans Cloud Composer.

L'éviction des pods peut se produire lorsqu'un pod particulier utilise trop de ressources sur un nœud, par rapport aux attentes de consommation de ressources configurées pour le nœud. Par exemple, l'éviction peut se produire lorsque plusieurs tâches gourmandes en mémoire sont exécutées dans un pod, et que leur charge combinée entraîne le dépassement de la limite de consommation de mémoire du pod.

Si un pod de nœud de calcul Airflow est évincé, toutes les instances de tâche qui y sont exécutées sont interrompues, puis marquées comme ayant échoué par Airflow.

Les journaux sont mis en mémoire tampon. Si un pod de nœuds de calcul est évincé avant la purge du tampon, les journaux ne sont pas envoyés. L'échec de la tâche sans journaux indique que les nœuds de calcul Airflow sont redémarrés en raison d'une mémoire saturée (OOM, Out Of Memory). Certains journaux peuvent être présents dans Cloud Logging, même si les journaux Airflow n'ont pas été envoyés.

Pour afficher les journaux :

  1. Dans Google Cloud Console, accédez à la page Environnements.

    Accéder à la page Environnements

  2. Dans la liste des environnements, cliquez sur le nom de votre environnement. La page Environment details (Détails sur l'environnement) s'ouvre.

  3. Accédez à l'onglet Logs (Journaux).

  4. Affichez les journaux de chaque nœud de calcul sous All logs -> Airflow logs -> Workers -> (individual worker).

L'exécution du DAG est limitée en mémoire. L'exécution de chaque tâche commence par deux processus Airflow : l'exécution et la surveillance de la tâche. Chaque nœud peut accepter jusqu'à six tâches simultanées (environ 12 processus chargés avec des modules Airflow). Vous pouvez utiliser plus de mémoire, en fonction de la nature du DAG.

Symptôme :

  1. Dans Google Cloud Console, accédez à la page Charges de travail.

    Accéder à la page Charges de travail

  2. Si des pods airflow-worker affichent Evicted, cliquez sur chaque pod évincé et recherchez le message The node was low on resource: memory en haut de la fenêtre.

Correctif :

  • Dans Cloud Composer 1, créez un environnement Cloud Composer avec un type de machine plus volumineux que le type de machine actuel.
  • Dans Cloud Composer 2, augmentez les limites de mémoire pour les nœuds de calcul Airflow.
  • Vérifiez les journaux des airflow-worker pods pour déterminer les causes possibles de l'éviction. Pour en savoir plus sur la récupération de journaux à partir de pods individuels, consultez la page Résoudre les problèmes liés aux charges de travail déployées.
  • Assurez-vous que les tâches du DAG sont idempotentes et récupérables.

Délai avant expiration de l'importation du chargement DAG

Symptôme :

  • Dans l'interface Web Airflow, en haut de la page répertoriant les DAG, une alerte rouge affiche Broken DAG: [/path/to/dagfile] Timeout.
  • Dans Cloud Monitoring, les journaux airflow-scheduler contiennent des entrées semblables à celles-ci :

    • ERROR - Process timed out
    • ERROR - Failed to import: /path/to/dagfile
    • AirflowTaskTimeout: Timeout

Correctif :

Ignorez l'option de configuration Airflow dag_file_processor_timeout et prévoyez plus de temps pour l'analyse du DAG:

Section Clé Valeur
core dag_file_processor_timeout Nouvelle valeur du délai

Augmentation du trafic réseau vers et depuis la base de données Airflow

La quantité de trafic réseau entre le cluster GKE de votre environnement et la base de données Airflow dépend du nombre de DAG, du nombre de tâches dans les DAG et de la manière dont les DAG accèdent aux données de la base de données Airflow. Les facteurs suivants peuvent influencer l'utilisation du réseau :

  • Requêtes envoyées à la base de données Airflow. Si vos DAG effectuent de nombreuses requêtes, ils génèrent une grande quantité de trafic. Exemples : vérifier l'état des tâches avant de poursuivre avec d'autres tâches, interroger la table XCom, créer un vidage du contenu de la base de données Airflow.

  • Grand nombre de tâches. Plus le nombre de tâches à planifier est élevé, plus du trafic réseau est généré. Ces considérations s'appliquent au nombre total de tâches dans vos DAG et à la fréquence de planification. Lorsque le programmeur Airflow planifie l'exécution du DAG, il envoie des requêtes à la base de données Airflow et génère du trafic.

  • L'interface Web Airflow génère du trafic réseau, car elle envoie des requêtes à la base de données Airflow. L'utilisation intensive de pages avec des graphiques, des tâches et des schémas peut générer de gros volumes de trafic réseau.

Le DAG entraîne le plantage du serveur Web Airflow ou lui fait renvoyer une erreur 502 gateway timeout

Des défaillances du serveur Web peuvent survenir pour plusieurs raisons. Consultez les journaux airflow-webserver dans Cloud Logging pour déterminer la cause de l'erreur 502 gateway timeout.

Calculs lourds

Cette section s'applique uniquement à Cloud Composer 1.

Évitez d'exécuter des calculs lourds au moment de l'analyse du DAG.

Contrairement aux nœuds de calcul et aux programmeurs, dont les types de machine peuvent être personnalisés pour augmenter la capacité du processeur et de la mémoire, le serveur Web utilise un type de machine fixe, ce qui peut entraîner des échecs d'analyse du DAG si le calcul au moment de l'analyse est trop lourd.

Veuillez prendre en compte que le serveur Web dispose de deux processeurs virtuels et de 2 Go de mémoire. La valeur par défaut pour core-dagbag_import_timeout est de 30 secondes. La valeur du délai avant expiration définit la limite supérieure de la durée pendant laquelle Airflow charge un module Python dans le dossier dags/.

Autorisations incorrectes

Cette section s'applique uniquement à Cloud Composer 1.

Le serveur Web ne s'exécute pas sous le même compte de service que les nœuds de calcul et le planificateur. En tant que tels, les nœuds de calcul et le planificateur peuvent être en mesure d'accéder à des ressources gérées par l'utilisateur auxquelles le serveur Web n'a pas accès.

Nous vous recommandons d'éviter l'accès à des ressources non publiques lors de l'analyse du DAG. Parfois, c'est inévitable et vous devrez accorder des autorisations au compte de service du serveur Web. Le nom du compte de service est dérivé du domaine de serveur Web. Par exemple, si le domaine est example-tp.appspot.com, le compte de service est example-tp@appspot.gserviceaccount.com.

Erreurs du DAG

Cette section s'applique uniquement à Cloud Composer 1.

Le serveur Web s'exécute sur App Engine et est distinct du cluster GKE de votre environnement. Le serveur Web analyse les fichiers de définition du DAG, et une erreur 502 gateway timeout peut se produire en cas d'erreurs dans le DAG. Airflow fonctionne normalement sans serveur Web fonctionnel si le DAG problématique n'interrompt aucun processus en cours d'exécution dans GKE. Dans ce cas, vous pouvez utiliser gcloud composer environments run pour récupérer les détails de votre environnement et comme solution de contournement si le serveur Web devient indisponible.

Dans d'autres cas, vous pouvez exécuter l'analyse du DAG dans GKE et rechercher les DAG générant des exceptions fatales Python ou ce délai d'expiration (30 secondes par défaut). Pour résoudre ce problème, connectez-vous à une interface système distante dans un conteneur de nœud de calcul Airflow et testez les erreurs de syntaxe. Pour en savoir plus, reportez-vous à la section Tester les DAG.

Erreur 504 lors de l'accès au serveur Web Airflow

Consultez la section Erreur 504 lors de l'accès à l'interface utilisateur Airflow.

L'exception Lost connection to MySQL server during query est générée pendant ou juste après l'exécution de la tâche.

Lost connection to MySQL / PostgreSQL server during query exceptions se produisent souvent lorsque les conditions suivantes sont remplies:

  • Votre DAG utilise PythonOperator ou un opérateur personnalisé.
  • Votre DAG envoie des requêtes à la base de données Airflow.

Si plusieurs requêtes sont effectuées à partir d'une fonction appelable, les traces peuvent pointer vers la ligne self.refresh_from_db(lock_for_update=True) dans le code Airflow de manière incorrecte car il s'agit de la première requête de base de données après l'exécution de la tâche. La cause réelle de l'exception se produit avant, lorsqu'une session SQLAlchemy n'est pas correctement fermée.

Les sessions SQLAlchemy s'appliquent à un thread et sont créées dans une session de fonction appelable qui peut ensuite être prolongée dans le code Airflow. S'il existe des délais importants entre les requêtes au sein d'une même session, la connexion a peut-être déjà été fermée par le serveur MySQL ou PostgreSQL. Le délai avant expiration de la connexion dans les environnements Cloud Composer est d'environ 10 minutes.

Correctif :

  • Utilisez le décorateur airflow.utils.db.provide_session. Ce décorateur fournit une session valide à la base de données Airflow dans le paramètre session et ferme correctement la session à la fin de la fonction.
  • N'utilisez pas une seule fonction de longue durée. Déplacez plutôt toutes les requêtes de base de données vers des fonctions distinctes, afin qu'il existe plusieurs fonctions avec le décorateur airflow.utils.db.provide_session. Dans ce cas, les sessions sont automatiquement fermées après la récupération des résultats de la requête.

Calcul de l'exécution des DAG, tâches et exécutions en parallèle du même DAG

Si vous souhaitez contrôler la durée d'exécution d'un DAG pour un DAG particulier, vous pouvez utiliser le paramètre dagrun_timeout du DAG. Par exemple, si vous vous attendez à ce qu'une seule exécution du DAG (quelle que soit l'exécution, avec succès ou échec), ne doit pas dépasser une heure, puis définir ce paramètre sur 3 600 secondes.

Vous pouvez également contrôler la durée de conservation d'une tâche Airflow unique. Pour ce faire, vous pouvez utiliser execution_timeout.

Si vous souhaitez contrôler le nombre de DAG actifs que vous souhaitez exécuter pour un DAG en particulier, vous pouvez utiliser l'[core]max-active-runs-per-dagoption de configuration Airflow.

Si vous voulez qu'une seule instance d'un DAG s'exécute à un moment donné, définissez le paramètre max-active-runs-per-dag sur 1.

Problèmes affectant la synchronisation des DAG et des plug-ins avec les programmeurs, les nœuds de calcul et les serveurs Web

Cloud Composer synchronise le contenu des dossiers /dags et /plugins avec les programmeurs et nœuds de calcul. Certains objets des dossiers /dags et /plugins peuvent empêcher le bon fonctionnement de cette synchronisation ou la ralentir.

  • Le dossier /dags est synchronisé avec les programmeurs et les nœuds de calcul. Ce dossier n'est pas synchronisé avec les serveurs Web dans Cloud Composer 2 ou si vous activez DAG Serialization dans Cloud Composer 1.

  • Le dossier /plugins est synchronisé avec les programmeurs, les nœuds de calcul et les serveurs Web.

Vous pouvez rencontrer les problèmes suivants:

  • Vous avez importé des fichiers compressés au format gzip qui utilisent le transcodage de compression pour les dossiers /dags et /plugins. Cela se produit généralement si vous utilisez la commande gsutil cp -Z pour importer des données dans le bucket.

    Solution: supprimez l'objet qui a utilisé le transcodage de compression et réimportez-le dans le bucket.

  • L'un des objets est nommé '.'. Un tel objet n'est pas synchronisé avec les programmeurs et les nœuds de calcul, et peut arrêter du tout la synchronisation.

    Solution: renommez un objet problématique.

  • L'un des objets des dossiers /dags ou /plugins contient un symbole / à la fin du nom de l'objet. De tels objets peuvent induire en erreur le processus de synchronisation, car le symbole / signifie qu'un objet est un dossier, et non un fichier.

    Solution: supprimez le symbole / du nom de l'objet problématique.

  • Ne stockez pas les fichiers inutiles dans les dossiers /dags et /plugins.

    Parfois, les DAG et les plug-ins que vous implémentez sont accompagnés de fichiers supplémentaires, tels que des fichiers stockant les tests de ces composants. Ces fichiers sont synchronisés avec les nœuds de calcul et les programmeurs, et ils influent sur le temps nécessaire à leur copie sur les programmeurs, les nœuds de calcul et les serveurs Web.

    Solution: ne stockez pas de fichiers supplémentaires inutiles dans les dossiers /dags et /plugins.

L'erreur Done [Errno 21] Is a directory: '/home/airflow/gcs/dags/...' est générée par les programmeurs et les nœuds de calcul

Ce problème survient, car les objets peuvent avoir des espaces de noms qui se chevauchent dans Cloud Storage, tandis que les programmeurs et les nœuds de calcul utilisent simultanément des systèmes de fichiers traditionnels. Par exemple, il est possible d'ajouter à la fois un dossier et un objet portant le même nom à un bucket d'environnement. Lorsque le bucket est synchronisé avec les programmeurs et les nœuds de calcul de l'environnement, cette erreur est générée, ce qui peut entraîner des échecs de tâche.

Pour résoudre ce problème, assurez-vous qu'il n'y a pas d'espaces de noms qui se chevauchent dans le bucket de l'environnement. Par exemple, si /dags/misc (un fichier) et /dags/misc/example_file.txt (un autre fichier) se trouvent dans un bucket, une erreur est générée par le programmeur.

Interruptions temporaires lors de la connexion à la base de données de métadonnées Airflow

Cloud Composer s'exécute sur une infrastructure cloud distribuée. Par conséquent, il peut arriver que des problèmes temporaires puissent interrompre l'exécution de vos tâches Airflow.

Dans ces cas-là, les messages d'erreur suivants peuvent s'afficher dans les nœuds de calcul Airflow et dans les journaux:

"Can't connect to MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (111)"

ou

"Can't connect to MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"

Ces problèmes occasionnels peuvent également être causés par des opérations de maintenance effectuées pour vos environnements Cloud Composer.

En général, ces erreurs sont intermittentes et si vos tâches Airflow sont idempotentes et que vous avez des tentatives de configuration, vous devez les protéger. Vous pouvez également définir des intervalles de maintenance.

Le manque de ressources dans votre cluster d'environnement peut également être à l'origine de ces erreurs. Dans ce cas, vous pouvez effectuer un scaling à la hausse ou à l'optimisation de votre environnement, comme indiqué dans les instructions Scaling des environnements ou Optimisation de votre environnement.

Symptômes associés à la pression de charge de la base de données Airflow

L'entrée de journal d'avertissement suivante peut parfois s'afficher dans les journaux des nœuds de calcul Airflow:

(_mysql_exceptions.OperationalError) (2006, "Lost connection to MySQL server at 'reading initial communication packet', system error: 0")"

Cette erreur ou cet avertissement peut provenir de la présence d'un symptôme entre la base de données des métadonnées Airflow et le nombre de requêtes qu'elle doit traiter.

Solutions possibles:

Étapes suivantes