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 les 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 configuration 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 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 d'éviction de 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 pour le 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, vous pouvez par exemple procéder comme suit : Sélectionnez votre environnement dans Google Cloud Console, accédez àJournaux et consultez les journaux individuels des nœuds de calcul sous Tous les journaux -> Journaux Airflow -> Nœuds de calcul -> (nœud de calcul individuel).

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”

Correctif :

Remplacez l'option de configuration Airflow dagbag_import_timeout et allouez plus de temps à l'analyse du DAG.

Section Clé Valeur
core dagbag_import_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

É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 ou juste après l'exécution de la tâche.

Les exceptions Lost connection to MySQL server during query se produisent souvent lorsque les conditions suivantes sont satisfaites :

  • 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.