Длительная задача Airflow неправильно помечается как сбойная из-за несоответствия имени хоста

Question

У меня есть длительная задача 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 позволил переопределить имя хоста, но я не могу сказать, является ли это подходящим решением в этом случае, так как ни один из рабочих, кажется, не умер или изменился во время выполнения задачи , Является ли нормальным выполнение переназначенной задачи другому работнику? И если да, то почему Источник воздушного потока не справляется с задачей в случае несоответствия имени хоста?

Answer 1

Я думаю, что основной причиной может быть известная проблема с потоком воздуха, из-за которой планировщик может попытаться повторно выполнить задачу через некоторое время.В случае, если задача переходит к другим работникам, имя хоста задачи будет обновлено до нового, в случае если предыдущий работник выполнит задачу, имя хоста будет другим и возникнет ошибка.Если кластер занят (учитывая, что задача занимает 2 часа, скорее всего), ваша задача может быть поставлена ​​в очередь на долгое время, прежде чем ее заберет рабочий.

Некоторые идеи, которые могут решить эту проблему:

• Увеличение visibility_timeout
• Увеличение worker_concurrency, чтобы рабочий мог обрабатывать больше задач
• Увеличение количества узлов для увеличения числа рабочих

В любом случае, это довольно сложно устранить, не проверяя журналы и среду, поэтому, если это все еще происходит, не стесняйтесь обращаться в службу поддержки GCP .