Les tâches de flux d'air restent bloquées à l'état "en file d'attente" et ne s'exécutent jamais
J'utilise Airflow v1.8.1 et j'exécute tous les composants (travailleur, Web, fleur, planificateur) sur kubernetes & Docker . J'utilise Celery Executor avec Redis et mes tâches ressemblent à ceci:
(start) -> (do_work_for_product1)
├ -> (do_work_for_product2)
├ -> (do_work_for_product3)
├ …
Donc, la tâche start a plusieurs aval. Et je configure la configuration liée à la simultanéité comme ci-dessous:
parallelism = 3
dag_concurrency = 3
max_active_runs = 1
Ensuite, lorsque je lance ce DAG manuellement (je ne suis pas sûr que cela ne se produise jamais dans le cadre d'une tâche planifiée), certains en aval sont exécutés, mais d'autres restent bloqués au statut "en file d'attente".
Si j'efface la tâche de l'interface utilisateur administrative, elle est exécutée . Il n'y a pas de journal de travail (après avoir traité certains premiers flux en aval, il ne génère aucun journal).
Journal du serveur Web (pas sûr que worker exiting est lié)
/usr/local/lib/python2.7/dist-packages/flask/exthook.py:71: ExtDeprecationWarning: Importing flask.ext.cache is deprecated, use flask_cache instead.
.format(x=modname), ExtDeprecationWarning
[2017-08-24 04:20:56,496] [51] {models.py:168} INFO - Filling up the DagBag from /usr/local/airflow_dags
[2017-08-24 04:20:57 +0000] [27] [INFO] Handling signal: ttou
[2017-08-24 04:20:57 +0000] [37] [INFO] Worker exiting (pid: 37)
Il n'y a pas non plus de journal des erreurs sur le planificateur. Et un certain nombre de tâches bloquées changent à chaque fois que j'essaie.
Parce que j'utilise aussi Docker, je me demande si c'est lié: https://github.com/puckel/docker-airflow/issues/94 Mais jusqu'à présent, aucun indice.
Quelqu'un at-il été confronté à un problème similaire ou a-t-il une idée de ce que je peux enquêter sur ce problème ...?
Le blocage des tâches est très probablement un bug. Pour le moment (<= 1.9.0alpha1), cela peut arriver lorsqu'une tâche ne peut même pas démarrer sur le travailleur (distant). Cela se produit par exemple dans le cas d'un travailleur surchargé ou de dépendances manquantes.
Ce patch devrait résoudre ce problème.
Il est utile d’explorer pourquoi vos tâches n’obtiennent pas un état RUNNING. Se fixer lui-même à cet état est la première chose que fait une tâche. Normalement, le serveur se connecte avant de commencer à s'exécuter et signale également des erreurs. Vous devriez pouvoir trouver des entrées dans le journal tâche.
edit: comme indiqué dans les commentaires sur la question initiale, au cas où un flux d’air ne pourrait pas exécuter une tâche, c’est quand il ne peut pas écrire aux emplacements requis. Cela le rend incapable de continuer et les tâches resteraient bloquées. Le correctif résout ce problème en échouant la tâche du planificateur.
Nous avons une solution et voulons la partager ici avant que 1.9 ne devienne officiel. Merci pour les mises à jour de Bolke de Bruin sur 1.9. Dans ma situation antérieure à la version 1.9, nous utilisons actuellement la version 1.8.1 afin d’exécuter un autre DAG pour effacer la tâche dans queue state si elle y reste plus de 30 minutes.
Je travaille sur la même image de docker puckel. Mon problème a été résolu par:
Remplacement
result_backend = db+postgresql://airflow:airflow@postgres/airflow
avec
celery_result_backend = db+postgresql://airflow:airflow@postgres/airflow
que je pense est mis à jour dans le dernier pull par puckel. Le changement a été annulé en février 2018 et votre commentaire a été fait en janvier.
Veuillez essayer la commande airflow scheduler, airflow worker.
Je pense que airflow worker appelle chaque tâche, airflow scheduler appelle entre deux tâches.