如何排查故障并改善Cloud Composer的运行健康度？

一、基础运行资源瓶颈排查 #

• 核查GKE集群节点指标：查看对应集群工作节点的CPU、内存、本地磁盘使用率，若指标持续高于85%，会直接触发健康检查失败，阻塞所有DAG的调度与执行。
• 检查Airflow核心Pod状态：确认scheduler、worker、webserver三类Pod无CrashLoopBackOff、反复重启问题，若存在异常可直接查看Pod日志定位根因，常见问题包括元数据库连接溢出、依赖包冲突、存储挂载失败。
• 排查Airflow元数据库负载：120个DAG长期运行会累积大量任务实例、日志元数据，若未配置定期清理策略，会导致支撑元数据存储的Cloud SQL实例资源耗尽，调度器停止工作。可执行SQL命令SELECT COUNT(*) FROM task_instance;查看元数据量级，超过100万行建议优先清理30天以上的历史任务元数据。

二、DAG负载与业务逻辑排查 #

• 核查Worker并发上限：每个Python Operator运行时会拉起独立进程处理pandas数据，若同一时间调度的DAG数超过Worker并发上限，会导致任务排队超时，进一步触发健康检查阈值。可临时下调worker_concurrency参数，验证健康状态是否恢复。
• 排查任务堆积连锁影响：若GSC令牌失效后大量任务集中失败，未配置合理的重试、超时规则的情况下，失败任务会占满Worker进程与调度器资源，最终导致集群夯住。可先清空当前运行中的任务队列，更新凭证后单独测试1-2个DAG，验证业务逻辑是否正常。
• 核查下游存储写入权限：若近期调整过Composer服务账号权限，导致写入GCS Bucket、BigQuery分区表的权限被收回，所有DAG都会在写入步骤报错，快速耗尽集群资源。可通过Cloud Audit Logs筛选对应服务账号的权限拒绝日志确认。

三、修复与优化建议 #

• 临时恢复方案：若确认是资源不足导致的异常，可先升级Composer节点配置、增加Worker节点数量，重启Scheduler、Worker组件，观察健康状态是否恢复为绿色。
• 长期优化方案：配置DAG并发限流规则、元数据定期清理任务、GSC API调用的熔断与降级逻辑，同时可将pandas数据处理逻辑迁移到Serverless服务执行，降低Composer Worker的资源压力。

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