Airflow 1.10.15迁移至2.3.3后Celery任务发送超时及任务状态不一致问题排查求助

我来帮你逐一拆解这些问题，结合你的日志和环境配置，咱们一步步分析：

1. 如何进一步排查该问题？ #

可以从以下几个维度深入排查，定位根因：

• 验证LB与RabbitMQ的健康探测逻辑：既然关闭RabbitMQ 2节点后，调度器1出问题、调度器2正常，说明LB的流量分发或健康探测可能存在延迟，导致调度器1仍在往已下线的节点发请求。你可以临时修改调度器1的AIRFLOW__CELERY__BROKER_URL，直接指向正常运行的RabbitMQ节点（绕过LB），观察是否还出现超时。如果问题消失，就说明是LB的健康探测配置需要调整。
• 开启RabbitMQ连接日志：在RabbitMQ容器中启用连接相关的详细日志（可以通过修改RabbitMQ的配置文件，开启connection级别的日志），查看调度器的请求实际到达了哪个节点，确认是否有请求落到已下线的节点上。
• 检查Celery连接池配置：Airflow 2.x对Celery连接池的默认配置和1.x不同，你可以检查AIRFLOW__CELERY__BROKER_POOL_LIMIT参数（默认值在2.x中可能更高），尝试将其调低或设置为0（禁用连接池），测试是否还会出现失效连接导致的超时。
• 监控调度器到RabbitMQ的网络状态：在调度器容器中使用ping、nc -zv <LB地址> <端口>或者tcpdump抓包，观察发往LB的请求是否存在网络延迟或连接失败的情况，区分是网络层面还是应用层面的问题。
• 排查Postgres慢查询：虽然日志指向RabbitMQ，但也不能完全排除数据库的影响。开启Postgres的慢查询日志，查看调度器在发送任务前后是否有耗时较长的查询，导致调度器阻塞进而影响Celery任务发送。

2. 是否有其他用户遇到过类似问题？ #

是的，不少Airflow用户在从1.x升级到2.x，且使用Celery Executor搭配RabbitMQ + LB的场景下，遇到过类似的间歇性超时或任务发送失败问题。常见的触发场景包括：

• RabbitMQ集群搭配LB时，健康探测不及时，导致Airflow连接到已失效的节点；
• Airflow 2.x依赖的Celery 5.x版本，连接池逻辑与1.x使用的Celery 4.x差异较大，对失效连接的处理更严格；
• 多调度器实例下，连接池复用了失效的连接，导致部分调度器实例无法正常发送任务。

3. 你的推测是否正确？超时发生在调度器与RabbitMQ之间吗？ #

你的推测完全正确，超时确实发生在调度器与RabbitMQ之间，和数据库无关。从日志的报错堆栈可以明确看到：

File "/opt/airflow/lib/python3.8/site-packages/amqp/transport.py", line 184, in _connect
    self.sock.connect(sa)
File "/opt/airflow/lib/python3.8/site-packages/airflow/utils/timeout.py", line 68, in handle_timeout
    raise AirflowTaskTimeout(self.error_message)
airflow.exceptions.AirflowTaskTimeout: Timeout, PID: 1

这段报错是在调度器尝试建立到RabbitMQ的Socket连接时触发的超时，而你关闭RabbitMQ 2节点后复现问题的操作，也进一步验证了这一点——调度器1的请求被LB分发到了已下线的节点，导致连接超时。

4. 为何Airflow 1.10.15正常，迁移至2.3.3后出现问题？ #

主要有以下几个关键差异导致了这个问题：

• Celery版本升级：Airflow 1.10.15默认使用Celery 4.x，而2.3.3默认使用Celery 5.x。Celery 5.x对AMQP连接的管理逻辑有较大变化，比如连接池的默认参数、失效连接的重试机制更严格，而1.x版本可能有更宽松的连接恢复逻辑，掩盖了这类问题。
• 调度器架构重构：Airflow 2.x对调度器进行了重构，任务发送的流程和1.x不同，对连接超时的感知更敏感。在1.x中可能被忽略或自动重试的连接超时，在2.x中直接触发了任务失败。
• Kombu版本差异：Airflow 2.x依赖的kombu（Celery的AMQP客户端）版本更高，其连接池的复用逻辑与1.x不同，当LB分发到失效的RabbitMQ节点时，旧的连接无法自动重新建立，导致超时。
• 多调度器连接管理差异：Airflow 2.x对多调度器的支持更完善，但连接池的复用在多实例下可能出现不一致的情况——比如调度器1持有了LB分发的失效连接，而调度器2的连接是正常的，就出现了你看到的“调度器1失败、调度器2正常”的现象。

内容的提问来源于stack exchange，提问作者wymangr