AirflowException: Falha no comando do aipo - O nome do host registrado não corresponde ao nome do host desta instância

Estou executando o Airflow em um ambiente em cluster executando em duas instâncias do AWS EC2. Um para mestre e outro para o trabalhador. O nó do trabalhador, porém, lança periodicamente esse erro ao executar "$ airflow worker":

[2018-08-09 16:15:43,553] {jobs.py:2574} WARNING - The recorded hostname ip-1.2.3.4 does not match this instance's hostname ip-1.2.3.4.eco.tanonprod.comanyname.io
Traceback (most recent call last):
  File "/usr/bin/airflow", line 27, in <module>
    args.func(args)
  File "/usr/local/lib/python3.6/site-packages/airflow/bin/cli.py", line 387, in run
    run_job.run()
  File "/usr/local/lib/python3.6/site-packages/airflow/jobs.py", line 198, in run
    self._execute()
  File "/usr/local/lib/python3.6/site-packages/airflow/jobs.py", line 2527, in _execute
    self.heartbeat()
  File "/usr/local/lib/python3.6/site-packages/airflow/jobs.py", line 182, in heartbeat
    self.heartbeat_callback(session=session)
  File "/usr/local/lib/python3.6/site-packages/airflow/utils/db.py", line 50, in wrapper
    result = func(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/airflow/jobs.py", line 2575, in heartbeat_callback
    raise AirflowException("Hostname of job runner does not match")
airflow.exceptions.AirflowException: Hostname of job runner does not match
[2018-08-09 16:15:43,671] {celery_executor.py:54} ERROR - Command 'airflow run arl_source_emr_test_dag runEmrStep2WaiterTask 2018-08-07T00:00:00 --local -sd /var/lib/airflow/dags/arl_source_emr_test_dag.py' returned non-zero exit status 1.
[2018-08-09 16:15:43,681: ERROR/ForkPoolWorker-30] Task airflow.executors.celery_executor.execute_command[875a4da9-582e-4c10-92aa-5407f3b46d5f] raised unexpected: AirflowException('Celery command failed',)
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/airflow/executors/celery_executor.py", line 52, in execute_command
    subprocess.check_call(command, shell=True)
  File "/usr/lib64/python3.6/subprocess.py", line 291, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'airflow run arl_source_emr_test_dag runEmrStep2WaiterTask 2018-08-07T00:00:00 --local -sd /var/lib/airflow/dags/arl_source_emr_test_dag.py' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.6/dist-packages/celery/app/trace.py", line 382, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/usr/lib/python3.6/dist-packages/celery/app/trace.py", line 641, in __protected_call__
    return self.run(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/airflow/executors/celery_executor.py", line 55, in execute_command
    raise AirflowException('Celery command failed')
airflow.exceptions.AirflowException: Celery command failed

Quando esse erro ocorre, a tarefa é marcada como com falha no Airflow e, portanto, falha no meu DAG quando nada realmente deu errado na tarefa.

Estou usando o Redis como minha fila e o postgreSQL como meu meta-banco de dados. Ambos são externos como serviços da AWS. Estou executando tudo isso no ambiente da minha empresa, e é por isso que o nome completo do servidor éip-1.2.3.4.eco.tanonprod.comanyname.io. Parece que ele quer esse nome completo em algum lugar, mas não tenho idéia de onde preciso corrigir esse valor para que ele fiqueip-1.2.3.4.eco.tanonprod.comanyname.io em vez de apenasip-1.2.3.4.

A coisa realmente estranha sobre esse problema é que nem sempre acontece. Parece acontecer aleatoriamente de vez em quando quando executo o DAG. Também está ocorrendo em todos os meus DAGs esporadicamente, por isso não é apenas um DAG. Eu acho estranho, porém, como é esporádico, porque isso significa que outras tarefas executadas estão lidando com o endereço IP, seja lá o que for.

Nota: Alterei o endereço IP real para 1.2.3.4 por questões de privacidade.

Responda:

https://github.com/apache/incubator-airflow/pull/2484

Esse é exatamente o problema que estou tendo e outros usuários do Airflow nas instâncias do AWS EC2 também estão enfrentando.

questionAnswers(1)

yourAnswerToTheQuestion