我有一个长期运行的Cloud Composer Airflow任务，它使用KubernetesPodOperator启动了一项工作。有时，它会在大约两个小时后成功完成，但是更多时候，它会在Airflow工作程序日志中被标记为失败，并显示以下错误：
[2019-06-24 18:49:34,718] {jobs.py:2685} WARNING - The recorded hostname airflow-worker-xxxxxxxxxx-aaaaa does not match this instance's hostname airflow-worker-xxxxxxxxxx-bbbbb
Traceback (most recent call last):
File "/usr/local/bin/airflow", line 7, in <module>
exec(compile(f.read(), __file__, 'exec'))
...
File "/usr/local/lib/airflow/airflow/jobs.py", line 2686, in heartbeat_callback
raise AirflowException("Hostname of job runner does not match")
airflow.exceptions.AirflowException: Hostname of job runner does not match
将任务标记为失败后，实际的KubernetesPodOperator作业仍然成功完成，没有任何错误。日志中引用的两个工作线程airflow-worker-xxxxxxxxxx-aaaaa和airflow-worker-xxxxxxxxxx-bbbbb仍在运行。
此Airflow PR使得可以覆盖主机名，但是在这种情况下，我无法确定这是否是一个合适的解决方案，因为在任务运行期间似乎没有工人死亡或被改变。将正在运行的任务重新分配给其他工人是否正常？如果是这样，为什么Airflow source在主机名不匹配的情况下使任务失败？
答案 0 :(得分：0)
我认为根本原因可能是已知的气流问题，该问题使调度程序在一段时间后尝试重新交付任务。如果任务转到其他工作程序，则该任务的主机名将更新为新的主机名，如果以前的工作程序完成了该任务，则该主机名将有所不同，并且将出现错误。如果集群很忙（可能要花2个小时才能完成任务），那么您的任务可能会排队很长时间，然后才被工作人员接走。
一些可以解决此问题的想法：
visibility_timeout worker_concurrency，以便工作人员可以处理更多任务无论如何，如果不检查日志和环境就很难对它进行故障排除，因此，如果这种情况仍在发生，请随时与GCP support联系。