Résoudre les problèmes liés aux DAG (workflows)

Cette page décrit les étapes de dépannage, ainsi que des informations sur les problèmes courants liés aux workflows.

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 la suite d'opérations de Google Cloud.
  3. Dans Cloud Console, recherchez les erreurs sur les pages des composants Google Cloud exécutant votre environnement.
  4. Dans l'interface Web Airflow, recherchez les instances de tâche ayant échoué dans la Vue graphique du DAG.

    Conseil: Pour naviguer dans un DAG volumineux afin de rechercher des instances de tâches ayant échoué, modifiez l'orientation de la vue graphique en la faisant passer de droite à gauche. Pour ce faire, remplacez la valeur dag_orientation par défaut du serveur Web:

    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. Consultez la suite d'opérations de Google Cloud.
  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 antérieurs 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

Les journaux sont mis en mémoire tampon. Si un nœud de calcul meurt avant que la mémoire tampon ne soit purgée, les journaux ne sont pas transmis. 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).

L'exécution du DAG est limitée par la mémoire RAM. 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 Cloud Console, accédez au panneau Kubernetes Engine > Charges de travail.

    Ouvrir le panneau "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.

Corrigé

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

Symptôme :

  • Interface utilisateur Web Airflow : en haut de la page contenant la liste des DAG, une zone d'alerte rouge indique Broken DAG: [/path/to/dagfile] Timeout.
  • Suite Google Cloud Operations : les journaux airflow-scheduler contiennent des entrées semblables aux suivantes :
    • “ERREUR - Le processus a expiré”
    • “ERREUR - Échec de l'importation : /path/to/dagfile”
    • “AirflowTaskTimeout : Timeout”

Solution:

Remplacez l'élémentdagbag_import_timeout Option de configuration Airflow et prévoyez plus de temps pour l'analyse des DAG:

Section Clé Valeur
core dagbag_import_timeout Nouvelle valeur du délai avant expiration

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

La quantité de trafic 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 dans la base de données Airflow. Les facteurs suivants peuvent avoir une incidence sur l'utilisation du réseau:

  • Requêtes envoyées à la base de données Airflow Si vos DAG effectuent beaucoup de requêtes, ils génèrent un volume important de trafic. Exemples: vérifier l'état des tâches avant de poursuivre l'exécution d'autres tâches, interroger la table XCom et vider le contenu de la base de données Airflow.

  • Nombre de tâches important. Plus il y a de tâches à planifier, plus le trafic réseau est généré. Cette considération s'applique au nombre total de tâches dans vos DAG et à la fréquence de planification. Lorsque le planificateur Airflow planifie les exécutions de 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 diagrammes peut générer de grands 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 différentes raisons. Consultez les journaux airflow-webserver dans Cloud Logging pour déterminer la cause de l'erreur 502 gateway timeout.

Calculs lourds

Évitez d'exécuter des calculs lourds au moment de l'analyse du DAG. Contrairement aux nœuds de calcul et de planificateur, 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 les calculs au moment de l'analyse sont trop lourds.

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

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 foo-tp.appspot.com, le compte de service est foo-tp@appspot.gserviceaccount.com.

Erreurs du DAG

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 des détails de votre environnement ou comme solution de contournement en cas d'indisponibilité du serveur Web.

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.

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

Les exceptions Lost connection to MySQL server during query 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 renvoyer vers la ligne self.refresh_from_db(lock_for_update=True) du code Airflow de manière incorrecte. 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 a lieu avant cela, lorsqu'une session SQLAlchemy n'est pas correctement fermée.

Les sessions SQLAlchemy sont limitées à un thread et créées dans une session de fonction appelable peut être suivie plus tard dans le code Airflow. S'il existe des retards importants entre les requêtes au sein d'une même session, la connexion peut être déjà fermée par le serveur MySQL ou PostgreSQL. Le délai avant expiration de la connexion dans les environnements Cloud Composer est défini sur environ 10 minutes.

Solution:

  • 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 la base de données vers des fonctions distinctes afin d'avoir 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.