气流网络服务器不能打开DAG？

Question

在气流网络服务器UI中无法打开DAG时出现问题。

有一点需要注意的是，DAG最初是在尝试运行时导致超时错误，所以我已经编辑了airflow.cfg文件，使其具有行.

dagbag_import_timeout = 300

在做了这个改变之后，跑..。

airflow list_dags

可以看到该守护进程成功构建。

然后转到webserver，刷新UI中的dag，将DAG状态切换到" on "，单击DAG尝试查看图形视图。

要么得到关于超时的消息就像..。

中断DAG: /home/气流/气流/dags/mydag.py超时，PID: 44818

(尽管dag在airflow list_dags命令中看起来构建得很成功)或者see服务器页面显示了一些浏览器错误，比如“页面没有发送数据”，在重新加载之后，我看到DAG已经关闭(在这两种情况下，airflow-webserver.log中都没有问题的迹象)。我甚至注意到，通常运行速度相当快的其他达格，现在运行速度要慢得多。

由于dag似乎能够在手动运行airflow list_dags时构建，而不是在when服务器中构建，我认为也许我需要更改一个webserver超时吐露，例如。

# 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定义本身并不是非常直接和特定于应用程序，因此在发布之前，需要尝试将其解析为一些耸人听闻和可读性更强的东西。尽管这仍然不能解释为什么在气流list_dags期间，dag看起来会生成，但不会在why服务器中构建。

按照我所能测量的，对airflow list_dags命令(只使用time实用程序运行)进行计时，只要有一个更改，时差是.

before change: real 1m31.201s
after change: real  2m39.744s

更新：

经过更多的调试后，我怀疑问题最终是与with服务器有关。始终能够在运行气流list_dags时构建进程，但当其他dag运行时，无法单击webserver /out超时错误中的守护进程。当没有其他dag正在运行时，能够在see服务器中查看进程(树和图)，但返回到主屏幕时，会看到与以前相同的“坏掉的DAG；. Timeout，PID: 1234”错误

Answer 1

对气流list_dags命令(仅与时间实用程序一起运行)进行计时，无论是否更改，时间差是.

before change: real 1m31.201s
after change: real  2m39.744s

查看airflow.cfg文件中与webserver和超时值(特别是超时值< 2m39s)相关的任何内容，其中秒数小于新的进程构建时间。

# Number of seconds the webserver waits before killing gunicorn master that doesn't respond
web_server_master_timeout = 120

# Number of seconds the gunicorn webserver waits before timing out on a worker
web_server_worker_timeout = 120
...
# The amount of time (in secs) webserver will wait for initial handshake
# while fetching logs from other worker machine
log_fetch_timeout_sec = 5

运行webserver (不是作为deamon进程)并监视输出，当它试图用新修改的dag填充dab包时，我看到gnuicorn工作人员的错误，如.

[2020-01-16 11:12:22 -1000] [137034] [CRITICAL] WORKER TIMEOUT (pid:137039)
[2020-01-16 11:12:22 -1000] [137034] [CRITICAL] WORKER TIMEOUT (pid:137040)
[2020-01-16 11:12:22 -1000] [137034] [CRITICAL] WORKER TIMEOUT (pid:137041)
[2020-01-16 11:12:22 -1000] [137034] [CRITICAL] WORKER TIMEOUT (pid:137042)
[2020-01-16 11:12:22 -1000] [137039] [INFO] Worker exiting (pid: 137039)
[2020-01-16 11:12:22 -1000] [137041] [INFO] Worker exiting (pid: 137041)
[2020-01-16 11:12:22 -1000] [137042] [INFO] Worker exiting (pid: 137042)
[2020-01-16 11:12:22 -1000] [137040] [INFO] Worker exiting (pid: 137040)

web_server_worker_timeout 将从120更改为300 (5分钟)，并测试访问pop服务器中修改的问题数据(树和图形视图)的速度似乎要快得多(在最初启动后，在pop服务器中看到超时错误继续弹出后)，问题似乎得到了修复。

注意，中仍然会弹出超时错误(有时会刷新主页)(尽管在when服务器日志中找不到)。不完全确定这个问题的基本机制是什么，希望在评论中有任何进一步的解释，但问题似乎在这一点上是固定的。我还注意到，在修改了问题进程之后，所有的dag似乎都运行得更慢了。在运行下一个任务之前，似乎需要更多的时间(并将其更改为占用更少的填充时间似乎可以修复)。目前还不清楚如何解决这些问题，所以如果有任何建议，我们将不胜感激。

更新

在重新启动服务器之后，只要没有其他进程同时运行，DAG就会完全正常运行。这可能的潜在原因(因为似乎没有其他的傻瓜有这个问题)。

Answer 2

如果可能的话，也请分享您的数据定义。

在我头上，我想你还没有启动气流调度器

$ airflow scheduler

以及webserver (在单独的终端中，如果您还没有去守护它)。

气流scheduler和webserver必须同时运行，这样您才能运行dags并查看webserver的进展情况。

Answer 3

我也有类似的问题，在我的例子中，它是依赖服务没有运行。我的任务依赖于MongoDB和redis，并且它没有运行，所以我只是启动它们，之后没有出现更多的错误。