Airflow 2.1.4任务随机收到SIGTERM信号无重试直接失败问题咨询

故障常见诱因 #

• 版本已知Bug：Airflow 2.1.2~2.1.4版本存在CeleryExecutor任务失败判定逻辑缺陷，当任务收到SIGTERM信号退出时，默认不会将这类退出判定为可重试失败，即使配置了retries参数也不会触发重试逻辑，该问题在2.2.0版本才被官方修复。
• Worker节点资源超限：3个Worker节点如果出现CPU、内存使用率过高，系统OOM Killer会主动杀掉占用资源过高的Airflow任务进程，发送SIGTERM信号；此时任务上下文还未同步到元数据库，调度器无法识别为可重试状态，直接标记为失败，且日志还没来得及完整刷写就被终止，会出现运行日志内容异常的情况。
• RabbitMQ队列异常：RabbitMQ出现连接抖动、消息超时、队列堆积时，Celery会主动终止长时间未ACK的任务并发送SIGTERM，若状态未正确回写MySQL元数据库，也会导致重试逻辑不触发。
• 升级过程元数据不一致：从2.1.2升级到2.1.4时未完整执行airflow db upgrade命令，导致task_instance等核心表的字段缺失、状态流转逻辑异常，重试规则不生效。
• Celery配置不合理：未开启task_acks_late、task_reject_on_worker_lost参数，Worker失联后任务直接标记为失败，不会重新入队重试。

排查解决步骤 #

• 优先确认是否命中版本Bug：
  若暂时无法升级到2.2.0以上稳定版本，可手动修改CeleryExecutor的退出码判定逻辑，将SIGTERM对应的退出码143加入可重试退出码列表；同时在DAG默认参数中新增retry_on_failure = True、retry_exponential_backoff = True配置，强制触发重试。
• 排查Worker节点资源：
  查看所有Worker节点的系统日志（/var/log/syslog或/var/log/messages），搜索oom-killer关键词，确认是否有Airflow相关进程被系统杀掉的记录。若存在OOM情况，可调低Celery Worker的并发数（celery worker --concurrency参数），或升级Worker节点硬件配置；同时将worker_heartbeat_sec参数从默认30秒调整为60秒，避免网络波动导致心跳超时、任务被误杀。
• 排查RabbitMQ与Celery配置：
  检查RabbitMQ日志是否有连接断开、队列溢出记录，调整Celery的broker连接配置，在airflow.cfg中添加如下参数：

  [celery]
  task_acks_late = True
  task_reject_on_worker_lost = True
  broker_transport_options = {"max_retries": 3, "interval_start": 0, "interval_step": 0.2, "interval_max": 0.5}
  

  避免队列抖动导致任务被误终止。
• 核对元数据与配置有效性：
  重新执行一次airflow db upgrade命令，确认无报错；检查单个任务的运行配置，确认是否存在任务级retries参数覆盖了DAG默认配置的情况；将logging_flush_interval参数调小到5秒，保证异常时日志能完整刷写，方便后续定位问题。

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