AWS Glue作业超时失效、手动停止失败及日志中断问题咨询

可能原因 #

• Glue作业的超时计时仅在作业进入RUNNING状态后生效，如果作业驱动节点失去心跳、进入僵死状态，控制平面无法完成超时校验，就不会主动终止作业。
• 如果你使用的是Flex弹性执行类型的Glue作业，每次作业被资源抢占重试时都会重置超时计时器，多次重试的总运行时长会远高于设置的单轮超时阈值。
• 作业级别的超时配置被工作流、触发器的上层配置覆盖，或者参数提交时拼写错误导致超时设置未生效。

修复方案 #

• 非必要场景关闭Flex弹性执行，或者将作业最大重试次数设置为1，避免重试导致超时累加。
• 升级Glue运行版本到4.0及以上，官方优化了无响应作业的超时判定逻辑，无心跳的作业会在超时阈值到达后被强制终止。
• 额外配置CloudWatch告警监控作业运行时长，超过阈值后通过Lambda调用StopJobRun API强制停止作业，补充原生超时机制的缺陷。

• 你的Spark驱动节点已经进入僵死状态：最常见的情况是驱动OOM、死锁或者无限阻塞在S3/数据库等IO操作上，进程停止运行所有代码，自然不会执行print()输出日志，也不会上报日志到CloudWatch。你提到错误日志仅比普通日志晚24秒停止，符合驱动突然僵死的特征。
• 驱动节点上的CloudWatch日志代理进程崩溃，导致日志无法正常上传，这种情况可以尝试查看Glue作业的S3日志路径（如果开启了S3日志导出），确认后续是否还有日志生成。
• 日志量超过CloudWatch单流吞吐量上限被限流，这种情况在错误日志中会有明确的限流报错提示，可以直接检查最后几条错误日志确认。

优化建议 #

• 替换print()为Python标准logging库输出日志，配置日志强制刷写，避免缓冲导致日志丢失。
• 调大驱动内存配置（--driver-memory参数），排查作业的数据倾斜问题，避免驱动因负载过高僵死。

可能原因 #

Glue控制平面发送停止指令后，需要等待驱动节点返回停止确认信号。如果驱动已经僵死、所在EC2资源已经被回收，或者节点清理临时shuffle文件时出现IO阻塞，就无法返回确认信号，作业会一直卡在Stopping状态。

解决方案 #

• 优先通过AWS CLI调用aws glue stop-job-run --job-name <作业名称> --run-id <异常作业的Run ID>触发强制停止，该指令优先级高于GUI停止操作，大部分场景下可以终止卡住的作业。
• 如果调用API后24小时仍未变为Stopped状态，可提交AWS支持工单让后台工程师强制清理该运行记录，普通用户没有权限直接删除卡在停止中的作业记录。
• 此类卡在Stopping状态的作业不会实际产生计算费用，也不会占用作业并发配额，无特殊需求也可以不处理，Glue后台会在7天后自动清理过期的作业运行记录。

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