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.

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 liés à certains problèmes courants de workflow.

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 émis. 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. Actuellement, 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 taille du DAG.

Symptôme

  1. Dans Cloud Console, accédez au panneau des charges de travail GKE.
  2. Si des pods "airflow-worker" affichent la mention "Expulsé", cliquez sur chaque pod expulsé et recherchez le message The node was low on resource: memory en haut de la fenêtre.

Corriger

  1. Créez un environnement Cloud Composer avec un type de machine plus volumineux que le type de machine actuel.
  2. Assurez-vous que les tâches du DAG sont idempotentes et récupérables.
  3. Configurez les tentatives d'exécution de tâches.

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 des opérations Google Cloud : 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 la configuration Airflow par core-dagbag_import_timeout et allouez plus de temps à l'analyse du DAG.

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. Si vous exécutez composer-1.5.2 ou une version ultérieure, consultez les journaux airflow-webserver dans Cloud Logging pour résoudre 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.