Airflow任务无日志却失败，多次重试可启动的技术求助

问题描述 #

我们的Airflow集群出现DAG执行失败但无任何日志输出的情况，手动重试3-4次后DAG能正常启动。使用pdiOperator（Pentaho Data Integration），每个DAG会在Kubernetes中生成独立Pod执行，推测失败发生在PDI日志生成前，但具体原因未知。Scheduler和Worker的日志中没有任何错误标记。

环境配置 #

• Airflow v2.3.1，Kubernetes部署（2个Web节点、2个Worker、2个Scheduler）
• Celery Executor，单Worker并发数9，双Worker总并发18
• 自定义pdiOperator（Pentaho Data Integration）
• RabbitMQ 3.8.19，Kubernetes部署
• PostgreSQL 13作为元数据库，部署在独立本地机器
• 所有Pod包含git-sync容器，用于同步DAG代码

已尝试的无效方案 #

• 调整dagbag_import_timeout为300、dag_file_processor_timeout为350：正常运行约1个月后问题复现
• 调整上述两个参数为600和650：正常运行1周后问题再次复现
• 在Scheduler、Worker、Web Pod启动前设置60秒延迟（对应Helm Chart的initialstartupdelay参数），怀疑git-sync未完成DAG代码同步，但无效果

排查方向与解决建议 #

1. Kubernetes Pod生命周期排查 #

因为每个DAG用独立Pod执行，失败时无日志，优先检查Pod的运行细节：

• 执行kubectl describe pod <pod-name>查看失败Pod的Events，重点排查镜像拉取失败、CPU/内存资源不足、ServiceAccount权限不足、网络连接异常（无法访问PDI服务或元数据库）等问题
• 检查Pod的启动/存活探针配置：如果探针超时或失败，Kubernetes会直接终止Pod，可能导致PDI日志还未生成就被清理

2. Celery与RabbitMQ通信排查 #

即使Scheduler和Worker日志无错误，也可能存在短暂的消息队列异常：

• 监控RabbitMQ的队列状态：查看是否有消息堆积、连接数波动，确认Celery Worker能稳定消费队列
• 检查Worker节点的资源使用：如果Worker节点CPU/内存过载，可能导致任务接收后无法及时初始化，最终超时被标记为失败
• 调整Celery任务超时参数：比如task_time_limit、task_soft_time_limit，给任务足够的启动缓冲时间

3. PDI Operator初始化阶段排查 #

针对推测的"PDI日志生成前失败"，重点强化初始化阶段的日志采集：

• 在pdiOperator代码中添加初始化日志：比如打印环境变量、PDI作业文件路径、数据库连接参数等，即使PDI未启动，也能通过Airflow任务日志看到初始化是否正常
• 检查Pod内PDI依赖：确认是否缺少PDI运行所需的依赖库、配置文件，或git-sync同步的DAG代码中PDI作业文件是否完整（可能存在同步中断导致文件缺失）

4. Airflow元数据库与调度逻辑排查 #

• 检查PostgreSQL的连接状态：是否存在短暂的连接超时或锁等待，导致Scheduler无法更新任务状态、Worker无法获取任务信息
• 调整Scheduler的min_file_process_interval参数：降低DAG文件扫描频率，避免Scheduler资源占用过高影响任务调度
• 确认DAG的retries和retry_delay配置：手动重试有效说明任务本身可执行，可设置自动重试覆盖偶发的环境问题

5. Git-sync同步可靠性排查 #

• 查看git-sync容器日志：kubectl logs <pod-name> -c git-sync，确认每次Pod启动时DAG代码是否完全同步，是否有拉取失败、文件冲突等问题
• 配置git-sync重试机制：设置max-sync-retries参数，确保代码同步失败时自动重试，直到同步完成

总结 #

这类偶发无日志失败的问题，核心是捕捉失败瞬间的Pod状态和初始化阶段日志。建议先在pdiOperator中添加初始化日志，同时持续监控Kubernetes Pod的Events和资源使用，逐步缩小排查范围。

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