气流调度程序定期抱怨没有心跳
Airflow scheduler periodically complains no heartbeat
遇到气流 (v1.10.5) 网络服务器会抱怨的问题...
The scheduler does not appear to be running. Last heartbeat was received 45 minutes ago.
但是检查调度程序守护进程(通过airflow scheduler -D
启动)可以看到...
[airflow@airflowetl airflow]$ cat airflow-scheduler.pid
64186
[airflow@airflowetl airflow]$ ps -aux | grep 64186
airflow 64186 0.0 0.1 663340 67796 ? S 15:03 0:00 /usr/bin/python3 /home/airflow/.local/bin/airflow scheduler -D
airflow 94305 0.0 0.0 112716 964 pts/4 R+ 16:01 0:00 grep --color=auto 64186
一段时间后,错误消息再次消失)。
即使在重新启动网络服务器和调度程序后,这种情况也会断断续续地频繁发生。
airflow-scheduler.err
文件是空的,.out 和 .log 文件看起来无害(需要更多时间来深入查看)。
运行 终端中的调度程序实时查看提要,一切似乎 运行 都很好,直到我在 dag 执行过程中看到此输出
[2019-11-29 15:51:57,825] {__init__.py:51} INFO - Using executor SequentialExecutor
[2019-11-29 15:51:58,259] {dagbag.py:90} INFO - Filling up the DagBag from /home/airflow/airflow/dags/my_dag_file.py
弹出此消息后,我可以在网络上看到 UI 出现调度程序心跳错误消息。 (奇怪的是,这里kill掉scheduler进程并不会产生web中的heartbeat报错信息UI)。检查调度程序进程,我看到...
[airflow@airflowetl airflow]$ ps -aux | grep scheduler
airflow 3409 0.2 0.1 523336 67384 ? S Oct24 115:06 airflow scheduler -- DagFileProcessorManager
airflow 25569 0.0 0.0 112716 968 pts/4 S+ 16:00 0:00 grep --color=auto scheduler
airflow 56771 0.0 0.1 662560 67264 ? S Nov26 4:09 airflow scheduler -- DagFileProcessorManager
airflow 64187 0.0 0.1 662564 67096 ? S Nov27 0:00 airflow scheduler -- DagFileProcessorManager
airflow 153959 0.1 0.1 662568 67232 ? S 15:01 0:06 airflow scheduler -- DagFileProcessorManager
IDK 这是否正常。
有人知道这里会发生什么或如何解决吗?
更新:
认为问题可能是有未删除的旧调度程序进程仍在 运行ning...
[airflow@airflowetl airflow]$ kill -9 3409 36771
bash: kill: (36771) - No such process
[airflow@airflowetl airflow]$ ps -aux | grep scheduler
airflow 56771 0.0 0.1 662560 67264 ? S Nov26 4:09 airflow scheduler -- DagFileProcessorManager
airflow 64187 0.0 0.1 662564 67096 ? S Nov27 0:00 airflow scheduler -- DagFileProcessorManager
airflow 153959 0.0 0.1 662568 67232 ? S Nov29 0:06 airflow scheduler -- DagFileProcessorManager
airflow 155741 0.0 0.0 112712 968 pts/2 R+ 15:54 0:00 grep --color=auto scheduler
注意输出中的所有不同开始时间。
做 kill -9 56771 64187 ...
然后重新 运行 宁 airflow scheduler -D
似乎没有解决问题。
注意:在任务无法将文件从 FTP 位置移动到 HDFS 位置后,调度程序似乎一直停止 运行ning...
hadoop fs -Dfs.mapr.trace=debug -get \
ftp://$FTP_CLIENT:$FTP_PASS@$FTP_IP/$FTP_DIR"$TABLENAME.TSV" \
$PROJECT_HOME/tmp/"$TABLENAME.TSV"
# see
当我使用与调度程序不同的 AIRFLOW_HOME
启动网络服务器时出现此错误。确保网络服务器和调度程序使用相同的 Airflow 主目录,例如 运行
export AIRFLOW_HOME='/path/to/the/airflow_home'
在 运行 网络服务器和调度程序之前。
好像找到问题了。
有一段代码像...
hadoop fs -Dfs.mapr.trace=debug -get \
ftp://$FTP_CLIENT:$FTP_PASS@$FTP_IP/$FTP_DIR"$TABLENAME.TSV" \
$PROJECT_HOME/tmp/"$TABLENAME.TSV" \
| hadoop fs -moveFromLocal $PROJECT_HOME/tmp/"$TABLENAME.TSV" "$DATASTORE"
改为
hadoop fs -Dfs.mapr.trace=debug -get \
ftp://$FTP_CLIENT:$FTP_PASS@$FTP_IP/$FTP_DIR"$TABLENAME.TSV" \
$PROJECT_HOME/tmp/"$TABLENAME.TSV"
hadoop fs -moveFromLocal $PROJECT_HOME/tmp/"$TABLENAME.TSV" "$DATASTORE"
不知道为什么,但是用这种方式使用管道似乎有问题,不知道为什么,但我怀疑它与延迟问题有关在写入 -moveFromLocal
之前必须从本地临时目录读取时(因为当 运行 在 shell 中手动执行命令时会得到类似的 'file not found' 错误,当与管道)。
也不确定为什么这会导致气流调度器出现问题,但是自从更改后 运行 现在已经多次执行该任务并且没有再次看到调度器错误,所以不确定该怎么做做到这一点。
如果有人能解释其中的任何怪异之处,请告诉我,以使这个答案更加完整。会继续调试更新
遇到气流 (v1.10.5) 网络服务器会抱怨的问题...
The scheduler does not appear to be running. Last heartbeat was received 45 minutes ago.
但是检查调度程序守护进程(通过airflow scheduler -D
启动)可以看到...
[airflow@airflowetl airflow]$ cat airflow-scheduler.pid
64186
[airflow@airflowetl airflow]$ ps -aux | grep 64186
airflow 64186 0.0 0.1 663340 67796 ? S 15:03 0:00 /usr/bin/python3 /home/airflow/.local/bin/airflow scheduler -D
airflow 94305 0.0 0.0 112716 964 pts/4 R+ 16:01 0:00 grep --color=auto 64186
一段时间后,错误消息再次消失)。
即使在重新启动网络服务器和调度程序后,这种情况也会断断续续地频繁发生。
airflow-scheduler.err
文件是空的,.out 和 .log 文件看起来无害(需要更多时间来深入查看)。
运行 终端中的调度程序实时查看提要,一切似乎 运行 都很好,直到我在 dag 执行过程中看到此输出
[2019-11-29 15:51:57,825] {__init__.py:51} INFO - Using executor SequentialExecutor
[2019-11-29 15:51:58,259] {dagbag.py:90} INFO - Filling up the DagBag from /home/airflow/airflow/dags/my_dag_file.py
弹出此消息后,我可以在网络上看到 UI 出现调度程序心跳错误消息。 (奇怪的是,这里kill掉scheduler进程并不会产生web中的heartbeat报错信息UI)。检查调度程序进程,我看到...
[airflow@airflowetl airflow]$ ps -aux | grep scheduler
airflow 3409 0.2 0.1 523336 67384 ? S Oct24 115:06 airflow scheduler -- DagFileProcessorManager
airflow 25569 0.0 0.0 112716 968 pts/4 S+ 16:00 0:00 grep --color=auto scheduler
airflow 56771 0.0 0.1 662560 67264 ? S Nov26 4:09 airflow scheduler -- DagFileProcessorManager
airflow 64187 0.0 0.1 662564 67096 ? S Nov27 0:00 airflow scheduler -- DagFileProcessorManager
airflow 153959 0.1 0.1 662568 67232 ? S 15:01 0:06 airflow scheduler -- DagFileProcessorManager
IDK 这是否正常。
有人知道这里会发生什么或如何解决吗?
更新:
认为问题可能是有未删除的旧调度程序进程仍在 运行ning...
[airflow@airflowetl airflow]$ kill -9 3409 36771
bash: kill: (36771) - No such process
[airflow@airflowetl airflow]$ ps -aux | grep scheduler
airflow 56771 0.0 0.1 662560 67264 ? S Nov26 4:09 airflow scheduler -- DagFileProcessorManager
airflow 64187 0.0 0.1 662564 67096 ? S Nov27 0:00 airflow scheduler -- DagFileProcessorManager
airflow 153959 0.0 0.1 662568 67232 ? S Nov29 0:06 airflow scheduler -- DagFileProcessorManager
airflow 155741 0.0 0.0 112712 968 pts/2 R+ 15:54 0:00 grep --color=auto scheduler
注意输出中的所有不同开始时间。
做 kill -9 56771 64187 ...
然后重新 运行 宁 airflow scheduler -D
似乎没有解决问题。
注意:在任务无法将文件从 FTP 位置移动到 HDFS 位置后,调度程序似乎一直停止 运行ning...
hadoop fs -Dfs.mapr.trace=debug -get \
ftp://$FTP_CLIENT:$FTP_PASS@$FTP_IP/$FTP_DIR"$TABLENAME.TSV" \
$PROJECT_HOME/tmp/"$TABLENAME.TSV"
# see
当我使用与调度程序不同的 AIRFLOW_HOME
启动网络服务器时出现此错误。确保网络服务器和调度程序使用相同的 Airflow 主目录,例如 运行
export AIRFLOW_HOME='/path/to/the/airflow_home'
在 运行 网络服务器和调度程序之前。
好像找到问题了。 有一段代码像...
hadoop fs -Dfs.mapr.trace=debug -get \
ftp://$FTP_CLIENT:$FTP_PASS@$FTP_IP/$FTP_DIR"$TABLENAME.TSV" \
$PROJECT_HOME/tmp/"$TABLENAME.TSV" \
| hadoop fs -moveFromLocal $PROJECT_HOME/tmp/"$TABLENAME.TSV" "$DATASTORE"
改为
hadoop fs -Dfs.mapr.trace=debug -get \
ftp://$FTP_CLIENT:$FTP_PASS@$FTP_IP/$FTP_DIR"$TABLENAME.TSV" \
$PROJECT_HOME/tmp/"$TABLENAME.TSV"
hadoop fs -moveFromLocal $PROJECT_HOME/tmp/"$TABLENAME.TSV" "$DATASTORE"
不知道为什么,但是用这种方式使用管道似乎有问题,不知道为什么,但我怀疑它与延迟问题有关在写入 -moveFromLocal
之前必须从本地临时目录读取时(因为当 运行 在 shell 中手动执行命令时会得到类似的 'file not found' 错误,当与管道)。
也不确定为什么这会导致气流调度器出现问题,但是自从更改后 运行 现在已经多次执行该任务并且没有再次看到调度器错误,所以不确定该怎么做做到这一点。
如果有人能解释其中的任何怪异之处,请告诉我,以使这个答案更加完整。会继续调试更新