Dépanner les DAG

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

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

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

Certains problèmes d'exécution de DAG peuvent être dus au fait que le planificateur Airflow ne fonctionne pas correctement ou de manière optimale. Suivez les instructions de dépannage du planificateur 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.

    Vous pouvez augmenter le niveau de journalisation d'Airflow en remplaçant l'option de configuration Airflow suivante.

    Section Clé Valeur
    logging logging_level La valeur par défaut est INFO. Définissez la valeur sur DEBUG pour obtenir plus de détails dans les messages du journal.

  2. Consultez le tableau de bord de surveillance.

  3. Consultez Cloud Monitoring.

  4. Dans la console Google Cloud , recherchez les erreurs sur les pages des composants de votre environnement.

  5. Dans l'interface Web Airflow, recherchez les instances de tâche ayant échoué dans la vue graphique du DAG.

    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 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 antérieurs du DAG.
  8. Relancez ou exécutez le DAG.

Résoudre les problèmes d'exécution des tâches

Airflow est un système distribué avec de nombreuses entités telles que le programmateur, l'exécuteur et les nœuds de calcul qui communiquent entre eux via une file d'attente de tâches et la base de données Airflow, et qui envoient des signaux (comme SIGTERM). Le schéma suivant offre une vue d'ensemble des interconnexions entre les composants Airflow.

Interaction entre les composants Airflow
Figure 1. Interaction entre les composants Airflow (cliquez pour agrandir)

Dans un système distribué comme Airflow, il peut y avoir des problèmes de connectivité réseau ou l'infrastructure sous-jacente peut rencontrer des problèmes intermittents. Cela peut entraîner l'échec et la reprogrammation de l'exécution des tâches, ou l'échec de l'exécution des tâches (par exemple, les tâches zombies ou les tâches bloquées en cours d'exécution). Airflow dispose de mécanismes pour faire face à de telles situations et reprendre automatiquement le fonctionnement normal. Les sections suivantes expliquent les problèmes courants qui se produisent lors de l'exécution des tâches par Airflow : tâches zombies, arrêt de l'instance et signaux SIGTERM.

Résoudre les problèmes liés aux tâches zombies

Airflow détecte deux types d'incohérences entre une tâche et un processus qui l'exécute :

  • Les tâches zombies sont des tâches qui sont censées s'exécuter, mais qui ne le font pas. Cela peut se produire si le processus de la tâche a été arrêté ou ne répond pas, si le nœud de calcul Airflow n'a pas signalé l'état d'une tâche à temps parce qu'il est surchargé, ou si la VM sur laquelle la tâche est exécutée a été arrêtée. Airflow recherche régulièrement ces tâches et les fait échouer ou les relance, selon les paramètres de la tâche.

    Découvrir les tâches zombies

    resource.type="cloud_composer_environment"
resource.labels.environment_name="ENVIRONMENT_NAME"
log_id("airflow-scheduler")
textPayload:"Detected zombie job"

  • Les tâches mortes-vivantes sont des tâches qui ne sont pas censées être en cours d'exécution. Airflow recherche régulièrement ces tâches et les arrête.

Les sections suivantes décrivent les raisons et les solutions les plus courantes pour les tâches zombies.

Le nœud de calcul Airflow est à court de mémoire

Chaque nœud de calcul Airflow peut exécuter jusqu'à [celery]worker_concurrency instances de tâches simultanément. Si la consommation de mémoire cumulée de ces instances de tâches dépasse la limite de mémoire d'un nœud de calcul Airflow, un processus aléatoire est arrêté pour libérer des ressources.

Découvrir les événements de mémoire saturée des nœuds de calcul Airflow

resource.type="k8s_node"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
log_id("events")
jsonPayload.message:"Killed process"
jsonPayload.message:("airflow task" OR "celeryd")

Parfois, le manque de mémoire sur un nœud de calcul Airflow peut entraîner l'envoi de paquets mal formés lors d'une session SQL Alchemy à la base de données, à un serveur DNS ou à tout autre service appelé par un DAG. Dans ce cas, l'autre extrémité de la connexion peut refuser ou abandonner les connexions du nœud de calcul Airflow. Exemple :

"UNKNOWN:Error received from peer
{created_time:"2024-11-31T10:09:52.217738071+00:00", grpc_status:14,
grpc_message:"failed to connect to all addresses; last error: UNKNOWN:
ipv4:<ip address>:443: handshaker shutdown"}"

Solutions :

Le nœud de calcul Airflow a été évincé

Les évictions de pods font partie intégrante de l'exécution des charges de travail sur Kubernetes. GKE évince les pods s'ils manquent d'espace de stockage ou pour libérer des ressources pour les charges de travail ayant une priorité plus élevée.

Découvrir les évictions de nœuds de calcul Airflow

resource.type="k8s_pod"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.pod_name:"airflow-worker"
log_id("events")
jsonPayload.reason="Evicted"

Solutions :

  • Si une éviction est due au manque d'espace de stockage, vous pouvez réduire l'utilisation de l'espace de stockage ou supprimer les fichiers temporaires dès qu'ils ne sont plus nécessaires. Vous pouvez également augmenter l'espace de stockage disponible ou exécuter des charges de travail dans un pod dédié avec KubernetesPodOperator.

Le nœud de calcul Airflow a été arrêté

Les nœuds de calcul Airflow peuvent être supprimés en externe. Si les tâches en cours d'exécution ne se terminent pas pendant la période d'arrêt progressif, elles sont interrompues et peuvent être détectées comme zombies.

Découvrir les arrêts de pods de nœuds de calcul Airflow

resource.type="k8s_cluster"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
protoPayload.methodName:"pods.delete"
protoPayload.response.metadata.name:"airflow-worker"

Scénarios et solutions possibles :

  • Les nœuds de calcul Airflow sont redémarrés lors des modifications de l'environnement, telles que les mises à niveau ou l'installation de packages :

    Découvrir les modifications apportées à l'environnement Composer

    resource.type="cloud_composer_environment"
resource.labels.environment_name="ENVIRONMENT_NAME"
log_id("cloudaudit.googleapis.com%2Factivity")

    Vous pouvez effectuer ces opérations lorsqu'aucune tâche critique n'est en cours d'exécution ou activer les nouvelles tentatives pour les tâches.

  • Divers composants peuvent être temporairement indisponibles lors des opérations de maintenance.

    Découvrir les opérations de maintenance GKE

    resource.type="gke_nodepool"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
protoPayload.metadata.operationType="UPGRADE_NODES"

    Vous pouvez spécifier des intervalles de maintenance pour minimiser

    chevauche l'exécution des tâches critiques.

  • Dans les versions de Cloud Composer 2 antérieures à la version 2.4.5, un nœud de calcul Airflow en cours d'arrêt peut ignorer le signal SIGTERM et continuer à exécuter des tâches :

    Découvrir la réduction de la capacité par l'autoscaling Composer

    resource.type="cloud_composer_environment"
resource.labels.environment_name="ENVIRONMENT_NAME"
log_id("airflow-worker-set")
textPayload:"Workers deleted"

    Vous pouvez passer à une version ultérieure de Cloud Composer dans laquelle ce problème est résolu.

Le nœud de calcul Airflow était soumis à une charge importante

La quantité de ressources de processeur et de mémoire disponibles pour un nœud de calcul Airflow est limitée par la configuration de l'environnement. Si l'utilisation des ressources se rapproche des limites, cela peut entraîner une contention des ressources et des retards inutiles lors de l'exécution des tâches. Dans les cas extrêmes, lorsque les ressources manquent pendant de longues périodes, cela peut entraîner des tâches zombies.

Solutions :

La base de données Airflow était fortement sollicitée

Une base de données est utilisée par différents composants Airflow pour communiquer entre eux et, en particulier, pour stocker les signaux de présence des instances de tâches. Le manque de ressources sur la base de données entraîne des temps de requête plus longs et peut affecter l'exécution des tâches.

Les erreurs suivantes sont parfois présentes dans les journaux d'un nœud de calcul Airflow :

(psycopg2.OperationalError) connection to server at <IP address>,
port 3306 failed: server closed the connection unexpectedly

This probably means the server terminated abnormally before or while
processing the request.

Solutions :

La base de données Airflow était temporairement indisponible

Un nœud de calcul Airflow peut mettre du temps à détecter et à gérer correctement les erreurs intermittentes, telles que les problèmes de connectivité temporaires. Il peut dépasser le seuil de détection des zombies par défaut.

Découvrir les délais avant expiration des pulsations Airflow

resource.type="cloud_composer_environment"
resource.labels.environment_name="ENVIRONMENT_NAME"
log_id("airflow-worker")
textPayload:"Heartbeat time limit exceeded"

Solutions :

  • Augmentez le délai avant expiration des tâches zombies et remplacez la valeur de l'option de configuration Airflow [scheduler]scheduler_zombie_task_threshold :

    Section Clé Valeur Remarques
    scheduler scheduler_zombie_task_threshold Nouveau délai avant expiration (en secondes) La valeur par défaut est 300.

Résoudre les problèmes de résiliation d'instance

Airflow utilise le mécanisme d'instance en cours d'arrêt pour arrêter les tâches Airflow. Ce mécanisme est utilisé dans les situations suivantes :

  • Lorsqu'un planificateur met fin à une tâche qui n'a pas été terminée à temps.
  • Lorsqu'une tâche expire ou est exécutée trop longtemps.

Lorsque Airflow met fin à des instances de tâches, les entrées de journal suivantes s'affichent dans les journaux d'un nœud de calcul Airflow ayant exécuté la tâche :

  INFO - Subtask ... WARNING - State of this instance has been externally set
  to success. Terminating instance.
  INFO - Subtask ... INFO - Sending Signals.SIGTERM to GPID <X>
  INFO - Subtask ... ERROR - Received SIGTERM. Terminating subprocesses.

Solutions possibles :

  • Vérifiez si le code de la tâche contient des erreurs qui pourraient entraîner une exécution trop longue.

  • Augmentez le processeur et la mémoire des nœuds de calcul Airflow pour que les tâches s'exécutent plus rapidement.

  • Augmentez la valeur de l'option de configuration Airflow [celery_broker_transport_options]visibility_timeout.

    Par conséquent, le planificateur attend plus longtemps qu'une tâche soit terminée avant de la considérer comme une tâche zombie. Cette option est particulièrement utile pour les tâches de longue durée qui durent plusieurs heures. Si la valeur est trop faible (par exemple, 3 heures), le planificateur considère les tâches qui s'exécutent pendant 5 ou 6 heures comme "bloquées" (tâches zombies).

  • Augmentez la valeur de l'option de configuration Airflow [core]killed_task_cleanup_time.

    Une valeur plus longue donne plus de temps aux nœuds de calcul Airflow pour terminer leurs tâches correctement. Si la valeur est trop faible, les tâches Airflow peuvent être interrompues brusquement, sans avoir le temps de terminer leur travail correctement.

Résoudre les problèmes liés aux signaux SIGTERM

Les signaux SIGTERM sont utilisés par Linux, Kubernetes, le programmateur Airflow et Celery pour mettre fin aux processus responsables de l'exécution des nœuds de calcul ou des tâches Airflow.

Plusieurs raisons peuvent expliquer l'envoi de signaux SIGTERM dans un environnement :

  • Une tâche est devenue une tâche zombie et doit être arrêtée.

  • Le planificateur a détecté un doublon d'une tâche et envoie les signaux Terminating instance et SIGTERM à la tâche pour l'arrêter.

  • Dans l'autoscaling horizontal des pods, le plan de contrôle GKE envoie des signaux SIGTERM pour supprimer les pods qui ne sont plus nécessaires.

  • Le planificateur peut envoyer des signaux SIGTERM au processus DagFileProcessorManager. Ces signaux SIGTERM sont utilisés par le planificateur pour gérer le cycle de vie du processus DagFileProcessorManager et peuvent être ignorés sans risque.

    Exemple :

    Launched DagFileProcessorManager with pid: 353002
Sending Signals.SIGTERM to group 353002. PIDs of all processes in the group: []
Sending the signal Signals.SIGTERM to group 353002
Sending the signal Signals.SIGTERM to process 353002 as process group is missing.

  • Condition de course entre le rappel de battement de cœur et les rappels de sortie dans le local_task_job, qui surveille l'exécution de la tâche. Si le signal de présence détecte qu'une tâche a été marquée comme réussie, il ne peut pas faire la différence entre une tâche qui a réellement réussi et une tâche qu'Airflow a été invité à considérer comme réussie. Néanmoins, il mettra fin à un exécuteur de tâches sans attendre qu'il se ferme.

    Vous pouvez ignorer ces signaux SIGTERM sans problème. La tâche est déjà à l'état "Réussie" et l'exécution de l'ensemble de l'exécution du DAG ne sera pas affectée.

    L'entrée de journal Received SIGTERM. est la seule différence entre la sortie normale et l'arrêt de la tâche dans l'état "Réussie".

    Condition de concurrence entre les rappels de battement de cœur et de sortie
    Figure 2. Concurrence entre les rappels de signal de présence et de sortie (cliquez pour agrandir)

  • Un composant Airflow utilise plus de ressources (CPU, mémoire) que ce qui est autorisé par le nœud de cluster.

  • Le service GKE effectue des opérations de maintenance et envoie des signaux SIGTERM aux pods qui s'exécutent sur un nœud qui va être mis à niveau.

    Lorsqu'une instance de tâche est arrêtée avec SIGTERM, les entrées de journal suivantes s'affichent dans les journaux d'un nœud de calcul Airflow ayant exécuté la tâche :

    {local_task_job.py:211} WARNING - State of this instance has been externally
set to queued. Terminating instance. {taskinstance.py:1411} ERROR - Received
SIGTERM. Terminating subprocesses. {taskinstance.py:1703} ERROR - Task failed
with exception

Solutions possibles :

Ce problème se produit lorsqu'une VM exécutant la tâche manque de mémoire. Cela n'est pas lié aux configurations Airflow, mais à la quantité de mémoire disponible pour la VM.

  • Dans Cloud Composer 2, vous pouvez attribuer davantage de ressources de processeur et de mémoire aux nœuds de calcul Airflow.

  • Vous pouvez réduire la valeur de l'option de configuration Airflow [celery]worker_concurrency. Cette option détermine le nombre de tâches exécutées simultanément par un nœud de calcul Airflow donné.

Pour en savoir plus sur l'optimisation de votre environnement, consultez Optimiser les performances et les coûts de l'environnement.

Requêtes Cloud Logging pour découvrir les raisons des redémarrages ou des expulsions de pods

Les environnements Cloud Composer utilisent des clusters GKE comme couche d'infrastructure de calcul. Dans cette section, vous trouverez des requêtes utiles qui peuvent vous aider à identifier les raisons des redémarrages ou des expulsions des nœuds de calcul ou des programmeurs Airflow.

Vous pouvez ajuster les requêtes présentées plus loin de la manière suivante :

  • Vous pouvez spécifier la chronologie requise dans Cloud Logging. Par exemple, les six dernières heures ou les trois derniers jours. Vous pouvez également définir votre propre période.

  • Vous devez spécifier le nom du cluster de votre environnement dans CLUSTER_NAME.

  • Vous pouvez limiter la recherche à un pod spécifique en ajoutant POD_NAME.

Découvrir les conteneurs redémarrés

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"will be restarted"
    resource.labels.cluster_name="CLUSTER_NAME"

Autre requête pour limiter les résultats à un pod spécifique :

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"will be restarted"
    resource.labels.cluster_name="CLUSTER_NAME"
    "POD_NAME"

Découvrez les conteneurs arrêtés en raison d'un événement de saturation de la mémoire.

    resource.type="k8s_node"
    log_id("events")
    (jsonPayload.reason:("OOMKilling" OR "SystemOOM")
      OR jsonPayload.message:("OOM encountered" OR "out of memory"))
    severity=WARNING
    resource.labels.cluster_name="CLUSTER_NAME"

Autre requête pour limiter les résultats à un pod spécifique :

    resource.type="k8s_node"
    log_id("events")
    (jsonPayload.reason:("OOMKilling" OR "SystemOOM")
      OR jsonPayload.message:("OOM encountered" OR "out of memory"))
    severity=WARNING
    resource.labels.cluster_name="CLUSTER_NAME"
    "POD_NAME"

Découvrir les conteneurs qui ont cessé de s'exécuter

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"ContainerDied"
    severity=DEFAULT
    resource.labels.cluster_name="CLUSTER_NAME"

Autre requête pour limiter les résultats à un pod spécifique :

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"ContainerDied"
    severity=DEFAULT
    resource.labels.cluster_name="CLUSTER_NAME"
    "POD_NAME"

Impact des opérations de mise à jour ou de mise à niveau sur les exécutions de tâches Airflow

Les opérations de mise à jour ou de mise à niveau interrompent les tâches Airflow en cours d'exécution, sauf si une tâche est exécutée en mode différable.

Nous vous recommandons d'effectuer ces opérations lorsque vous prévoyez un impact minimal sur l'exécution des tâches Airflow et de configurer des mécanismes de nouvelle tentative appropriés dans vos DAG et tâches.

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 Airflow a été interrompue par Negsignal.SIGKILL

Il arrive que votre tâche utilise plus de mémoire que celle allouée au nœud de calcul Airflow. Dans ce cas, il peut être interrompu par Negsignal.SIGKILL. Le système envoie ce signal pour éviter une consommation de mémoire supplémentaire qui pourrait avoir un impact sur l'exécution d'autres tâches Airflow. L'entrée de journal suivante peut s'afficher dans le journal du nœud de calcul Airflow :

{local_task_job.py:102} INFO - Task exited with return code Negsignal.SIGKILL

Negsignal.SIGKILL peut également s'afficher sous la forme du code -9.

Solutions possibles :

  • worker_concurrency inférieur de nœuds de calcul Airflow.

  • Augmentez la quantité de mémoire disponible pour les nœuds de calcul Airflow.

  • Gérez les tâches gourmandes en ressources dans Cloud Composer à l'aide de KubernetesPodOperator ou GKEStartPodOperator pour isoler les tâches et personnaliser l'allocation des ressources.

  • Optimisez vos tâches pour utiliser moins de mémoire.

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

Il peut parfois y avoir des erreurs subtiles dans les DAG qui entraînent une situation où le programmeur Airflow peut planifier l'exécution des tâches, le processeur DAG peut analyser le fichier DAG, mais le nœud de calcul Airflow ne parvient pas à exécuter les tâches du DAG en raison d'erreurs de programmation dans le fichier DAG. Cela peut entraîner une situation où une tâche Airflow est marquée comme Failed et où il n'y a pas de journal de son exécution.

Solutions :

  • Vérifiez dans les journaux des nœuds de calcul Airflow qu'aucune erreur n'a été générée par un nœud de calcul Airflow en raison d'un DAG manquant ou d'erreurs d'analyse de DAG.

  • Augmentez les paramètres liés à l'analyse des DAG :

    • Augmentez [dagbag-import-timeout][ext-airflow-dagrun-import-timeout] à au moins 120 secondes (ou plus, si nécessaire).

    • Augmentez dag-file-processor-timeout à au moins 180 secondes (ou plus, si nécessaire). Cette valeur doit être supérieure à dagbag-import-timeout.

  • Consultez également Résoudre les problèmes liés au processeur de DAG.

La tâche échoue sans émettre de journaux en raison de la pression exercée sur les ressources

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

...
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 du pod

Les pods Google Kubernetes Engine sont soumis au cycle de vie des pods Kubernetes et à l'éviction des pods. Les pics de tâches sont la cause la plus courante 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 nœud sur lequel ce pod est exécuté.

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 la console Google Cloud , 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 Détails de l'environnement s'ouvre.

  3. Accédez à l'onglet Journaux.

  4. Affichez les journaux des nœuds de calcul Airflow individuels sous Tous les journaux > Journaux Airflow > Nœuds de calcul.

Symptôme :

  1. Dans la console Google Cloud , 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.

Solution :

  • Augmentez les limites de mémoire pour les nœuds de calcul Airflow.

  • Consultez les journaux des pods airflow-worker pour identifier les causes d'éviction. Pour en savoir plus sur la récupération des journaux 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.

  • Évitez de télécharger des fichiers inutiles sur le système de fichiers local des nœuds de calcul Airflow.

    La capacité du système de fichiers local des nœuds de calcul Airflow est limitée. Un nœud de calcul Airflow peut disposer de 1 à 10 Go de stockage. Lorsque l'espace de stockage est épuisé, le plan de contrôle GKE évince le pod de nœud de calcul Airflow. Cela fait échouer toutes les tâches que le nœud de calcul évincé exécutait.

    Exemples d'opérations problématiques :

    • Télécharger des fichiers ou des objets et les stocker localement dans un nœud de calcul Airflow. Stockez plutôt ces objets directement dans un service adapté, tel qu'un bucket Cloud Storage.
    • Accéder aux grands objets du dossier /data à partir d'un nœud de calcul Airflow. Le worker Airflow télécharge l'objet dans son système de fichiers local. Implémentez plutôt vos DAG de sorte que les fichiers volumineux soient traités en dehors du pod de nœud de calcul Airflow.

L'exécution du DAG ne se termine pas dans le délai prévu

Symptôme :

Il arrive parfois qu'une exécution de DAG ne se termine pas, car les tâches Airflow sont bloquées et l'exécution de DAG dure plus longtemps que prévu. Dans des conditions normales, les tâches Airflow ne restent pas indéfiniment à l'état "En file d'attente" ou "En cours d'exécution", car Airflow dispose de procédures de délai d'attente et de nettoyage qui permettent d'éviter cette situation.

Correctif :

  • Utilisez le paramètre dagrun_timeout pour les DAG. Par exemple : dagrun_timeout=timedelta(minutes=120). Par conséquent, chaque exécution de DAG doit être terminée dans le délai d'expiration de l'exécution de DAG. Pour en savoir plus sur les états des tâches Airflow, consultez la documentation Apache Airflow.

  • Utilisez le paramètre Délai d'exécution des tâches pour définir un délai d'inactivité par défaut pour les tâches qui s'exécutent en fonction des opérateurs Apache Airflow.

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.

Ne planifiez pas les DAG générés de manière programmatique en même temps.

La génération d'objets DAG de manière programmatique à partir d'un fichier DAG est une méthode efficace pour créer de nombreux DAG similaires qui ne présentent que de petites différences.

Il est important de ne pas planifier l'exécution de tous ces DAG immédiatement. Il est fort probable que les nœuds de calcul Airflow ne disposent pas de suffisamment de ressources de processeur et de mémoire pour exécuter toutes les tâches planifiées en même temps.

Pour éviter les problèmes de planification des DAG programmatiques :

  • Augmentez la simultanéité des nœuds de calcul et faites évoluer votre environnement afin qu'il puisse exécuter plus de tâches simultanément.
  • Générez des DAG de manière à répartir uniformément leurs planifications dans le temps, afin d'éviter de planifier des centaines de tâches en même temps. Les nœuds de calcul Airflow auront ainsi le temps d'exécuter toutes les tâches planifiées.

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

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

L'exception "perte de connexion au serveur Postgres pendant la requête" est générée pendant l'exécution de la tâche ou juste après

Les exceptions Lost connection to Postgres 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 Postgres. Le délai avant expiration de la connexion dans les environnements Cloud Composer est d'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 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.

Contrôler le temps d'exécution des DAG, des tâches et des exécutions parallèles du même DAG

Si vous souhaitez contrôler la durée d'exécution d'un DAG spécifique, vous pouvez utiliser le paramètre de DAG dagrun_timeout. Par exemple, si vous estimez qu'une seule exécution de DAG (que l'exécution se termine par un succès ou un échec) ne doit pas durer plus d'une heure, définissez ce paramètre sur 3 600 secondes.

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

Si vous souhaitez contrôler le nombre d'exécutions de DAG actives pour un DAG spécifique, vous pouvez utiliser l'option de configuration Airflow [core]max-active-runs-per-dag.

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

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

Cloud Composer s'exécute sur une infrastructure distribuée. Cela signifie que des problèmes temporaires peuvent apparaître de temps en temps et interrompre l'exécution de vos tâches Airflow.

Dans ce cas, les messages d'erreur suivants peuvent s'afficher dans les journaux des nœuds de calcul Airflow :

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

ou

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

Ces problèmes intermittents 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 ne vous affectent pas si vos tâches Airflow sont idempotentes et que vous avez configuré des nouvelles tentatives. Vous pouvez également envisager de définir des intervalles de maintenance.

Une autre raison de ces erreurs peut être le manque de ressources dans le cluster de votre environnement. Dans ce cas, vous pouvez faire évoluer ou optimiser votre environnement comme décrit dans les instructions Faire évoluer les environnements ou Optimiser votre environnement.

Une exécution de DAG est marquée comme réussie, mais aucune tâche n'a été exécutée

Si une exécution de DAG execution_date est antérieure à la start_date du DAG, il est possible que des exécutions de DAG n'aient aucune exécution de tâche, mais qu'elles soient tout de même marquées comme réussies.

Exécution de DAG réussie sans tâches exécutées
Figure 3. Exécution de DAG réussie sans tâches exécutées (cliquez pour agrandir)

Cause

Cela peut se produire dans les cas suivants :

  • Une incohérence est due à la différence de fuseau horaire entre execution_date et start_date du DAG. Cela peut se produire, par exemple, lorsque vous utilisez pendulum.parse(...) pour définir start_date.

  • Le start_date du DAG est défini sur une valeur dynamique, par exemple airflow.utils.dates.days_ago(1).

Solution

  • Assurez-vous que execution_date et start_date utilisent le même fuseau horaire.

  • Spécifiez un start_date statique et combinez-le avec catchup=False pour éviter d'exécuter des DAG avec des dates de début passées.

Symptômes d'une base de données Airflow fortement sollicitée

Pour en savoir plus, consultez Symptômes d'une base de données Airflow surchargée.

Étapes suivantes