Не удается включить DAG в пользовательском интерфейсе веб-сервера воздушного потока.
Следует отметить, что изначально рассматриваемая группа доступности баз данных вызывала ошибки тайм-аута при попытке запуска, поэтому я отредактировал файл airflow.cfg, чтобы в нем была строка ...
dagbag_import_timeout = 300
Теперь после внесения этого изменения, запустив ...
airflow list_dags
, вы увидите, что dag успешно создан.
Затем перейдите на веб-сервер, обновите sh dag в пользовательском интерфейсе, измените статус DAG на «Вкл.», Нажмите на DAG, чтобы попытаться увидеть представление графика.
Либо получите сообщение о превышении времени, как ...
Сломанный DAG: [/ home / airflow / airflow /dags/mydag.py] Тайм-аут, PID: 44818
(несмотря на то, что dag, похоже, успешно строится во время команды airflow list_dags) или на странице веб-сервера отображается какая-то ошибка браузера, например "страница не отправила данные "и после перезагрузки я вижу, что группа доступности баз данных была отключена (в любом случае в airflow-webserver.log нет признаков проблемы). Я даже заметил, что другие dag, которые обычно работают довольно быстро, теперь работают намного медленнее.
Из-за того, что dag, по-видимому, может собираться при запуске airflow list_dags вручную, но не на веб-сервере, Я думаю, что, возможно, мне нужно изменить одну из конфигураций тайм-аута веб-сервера, например,
# Number of seconds the webserver waits before killing gunicorn master that doesn't respond
web_server_master_timeout = ...
# Number of seconds the gunicorn webserver waits before timing out on a worker
web_server_worker_timeout = ...
...
log_fetch_timeout_sec = ...
...
, но недостаточно для изучения основных механизмов воздушного потока, чтобы определить, как они могут быть связаны.
Больше информации отладки, если это поможет:
[root@airflowetl airflow]# ps -aux | grep webserver
airflow 16740 0.8 0.2 782620 134804 ? S 15:17 0:06 [ready] gunicorn: worker [airflow-webserver]
airflow 29758 2.3 0.2 756164 108644 ? S 15:26 0:03 [ready] gunicorn: worker [airflow-webserver]
airflow 33820 14.8 0.1 724788 78036 ? S 15:29 0:01 gunicorn: worker [airflow-webserver]
airflow 33854 26.7 0.1 724784 78032 ? S 15:29 0:01 gunicorn: worker [airflow-webserver]
airflow 33855 26.5 0.1 724816 78064 ? S 15:29 0:01 gunicorn: worker [airflow-webserver]
root 34072 0.0 0.0 112712 968 pts/0 S+ 15:29 0:00 grep --color=auto webserver
airflow 91174 1.6 0.1 735708 82468 ? S 14:14 1:14 /usr/bin/python3 /home/airflow/.local/bin/airflow webserver -D
airflow 91211 0.0 0.1 355040 53472 ? S 14:14 0:01 gunicorn: master [airflow-webserver]
У кого-либо с большим опытом воздушного потока есть какие-либо идеи, почему это могло случиться и как это исправить? (Может быть, какой-нибудь конфиг тайм-аута airflow.cfg, который мне следует расширить)?
Обновление:
После дальнейшей отладки проблема, похоже, связана с конкретной задачей, которая настраивается / создается в даг. Само определение DAG не очень прямолинейно и очень специфично для приложения c, поэтому нужно постараться разобрать его немного во что-то чувственное и читабельное перед публикацией. Хотя это по-прежнему не объясняет, почему dag, по-видимому, создается во время list_dags воздушного потока, а не в веб-сервере.
Идем с тем, что я могу измерить, синхронизируя команду airflow list_dags (просто запускается с утилитой time) с одним изменением и без него разница во времени составляет ...
before change: real 1m31.201s
after change: real 2m39.744s
Обновление:
После дополнительной отладки, я подозреваю, что проблема в конечном итоге связана с веб-сервером. Всегда в состоянии создать ярлык при запуске airflow list_dags, но , когда работают другие ярлыки , не может нажать на ярлык в веб-сервере без выдаваемых ошибок времени ожидания. Когда никакие другие теги не работают , способные просматривать тег (дерево и график) на веб-сервере, но при возврате к главному экрану увидеть то же самое "Broken DAG; ... Timeout, PID: 1234 "ошибка, как и раньше