Airflow(MWAA)任务遭SIGTERM终止且被外部设为成功的解决咨询

问题核心分析 #

从日志来看，任务终止的直接触发点是任务实例状态被外部设置为success，进而触发SIGTERM信号终止进程。你已尝试增加Worker数量但未解决，说明问题根源并非Worker数量不足，更可能是单Worker内存资源不足、任务资源配置不合理，或是MWAA调度逻辑出现异常状态更新。

具体解决方案 #

1. 升级Worker内存规格而非仅增加数量 #

MWAA的Worker数量增加不代表单Worker内存足够支撑任务运行：

• 切换至更高规格的Worker实例类型（比如从m5.large升级到m5.xlarge），提升单Worker的可用内存上限
• 调整worker_memory_mb参数，明确分配给每个Worker的内存资源，避免因单Worker内存耗尽导致任务状态被异常更新

2. 优化任务自身的内存消耗 #

• 对频繁出问题的任务做内存分析，用memory_profiler工具定位内存泄漏点，比如清理大对象、避免全局变量累积、优化数据处理逻辑
• 给任务配置task_memory_limit参数，限制单任务的内存使用上限，防止单个任务耗尽Worker资源引发状态异常

3. 调整Airflow调度相关配置 #

• 增大worker_timeout参数值，延长Worker超时判定时间，避免任务因执行时间略长被误判为异常
• 降低max_active_tasks_per_worker数值，减少单Worker同时运行的任务数，缓解资源竞争
• 调整task_heartbeat_sec参数的间隔，确保Scheduler能及时同步任务状态，避免因心跳延迟误标记任务为成功

4. 排查元数据库与Scheduler状态更新逻辑 #

• 检查MWAA关联的PostgreSQL元数据库性能，确保状态更新操作无延迟或错误，防止Scheduler读取到错误的任务状态
• 查看CloudWatch中的Scheduler日志，确认是否存在版本兼容性bug或逻辑错误，导致任务被错误标记为成功

5. 任务级别的容错配置 #

• 给关键任务添加重试机制，配置retries和retry_delay参数，即使任务被意外终止也能自动重试恢复
• 配置on_failure_callback回调函数，捕获SIGTERM导致的失败，记录详细上下文日志并触发告警，加快问题定位速度

关键日志排查点 #

你的日志中核心触发行：

WARNING - State of this instance has been externally set to success. Terminating instance.

需重点确认：

• 是否存在外部脚本、API调用手动修改任务状态
• Scheduler是否存在版本bug，导致错误更新任务状态

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