MWAA运行一段时间后出现CloudWatch日志ResourceNotFoundException求助

针对你遇到的500+任务DAG运行一段时间后无法读取CloudWatch日志、提示日志流不存在的问题，结合实例规格影响报错出现时间的表现，核心排查与解决方向如下：

1. CloudWatch日志流数量超限触发自动删除 #

CloudWatch日志组默认最多允许10000个日志流，你的DAG单次运行就生成500+日志流，反复运行后会快速逼近上限。达到上限后，CloudWatch会自动删除最早创建的日志流，但Airflow元数据库中仍保留这些已删除日志流的引用，导致读取时报错。小实例因为Worker节点更少，日志流复用率低，会更快触达上限。

• 解决措施：
  • 给对应CloudWatch日志组设置日志保留策略（比如30天），自动清理过期日志流；
  • 在MWAA环境配置中修改airflow.cfg参数：启用remote_log_cleanup_interval（建议设为24小时），让Airflow定期清理无效的日志引用；
  • 拆分大DAG：将500+任务拆分为多个小DAG，分散日志流的生成压力。

2. MWAA Worker日志代理（fluentd）长期运行异常 #

MWAA依赖fluentd推送任务日志到CloudWatch，Worker节点长时间运行后，fluentd可能出现内存泄漏或进程僵死，导致新任务无法创建日志流，或旧日志流元数据同步失败。大实例资源充足，fluentd能维持更久的稳定运行，所以报错出现时间更晚。

• 排查与解决：
  • 查看MWAA的Worker日志组，搜索fluentd关键词，检查是否有日志流创建失败的报错；
  • 配置MWAA自动扩缩容：设置合理的min_workers和max_workers，利用自动扩缩容销毁旧Worker节点，重建新节点以重置fluentd进程；
  • 升级MWAA到最新版本，AWS会定期修复日志代理的稳定性问题。

3. Airflow元数据库日志引用未同步清理 #

Airflow元数据库（PostgreSQL）中存储了任务日志的CloudWatch日志流信息，但当日志流被CloudWatch自动删除后，元数据库中的引用未及时更新，导致Airflow尝试读取已不存在的日志流。

• 解决措施：
  • 手动清理元数据库过期记录：备份数据库后，执行SQL删除超过保留期的task_instance和log表数据；
  • 在airflow.cfg中开启clean_up_task_logs = True，让Airflow定期清理无效的日志引用。

4. 实例规格导致日志代理资源耗尽 #

小型实例的CPU/内存有限，即使任务本身资源已清理，fluentd长期运行的资源累积也可能导致日志流创建请求失败。

• 解决措施：
  • 监控Worker节点的fluentd进程资源占用：通过CloudWatch指标查看Worker节点的CPUUtilization、MemoryUtilization，重点关注fluentd的资源消耗；
  • 适当提升Worker实例规格，或增加Worker节点数量，分散日志代理的负载。

快速验证步骤 #

1. 查看对应CloudWatch日志组的日志流总数，确认是否接近10000上限；
2. 在CloudWatch中搜索报错任务的日志流名称，确认是否已被删除；
3. 查看MWAAScheduler日志，定位报错的具体任务和日志流信息，缩小排查范围。

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