ECS Fargate服务停止上报指标但任务健康运行，求故障原因

故障概况 #

我们的ECS集群中某服务部署了2个task，10:05起服务指标完全停止上报，13:45强制重启服务后指标恢复。故障期间表现出以下矛盾现象：

核心异常现象 #

• 所有task保持运行状态，健康检查状态显示正常
• 应用日志持续生成，但存在部分用户可访问、自身无法访问的差异
• API请求分化：部分调用正常，部分返回504 Gateway timeout
• 应用健康端点实际返回504，但负载均衡器（LB）仍标记实例健康
• task自前一日起一直稳定运行

相关指标截图 #

可能的根因分析 #

1. LB健康检查配置失效 #

LB的健康检查规则大概率与应用实际健康状态脱节：

• 健康检查路径未指向真正的业务健康端点，或检查阈值（超时/重试）设置过宽，导致即使应用健康端点返回504，LB仍判定实例健康，持续分发流量。
• 这种情况下，流量会被分配到已出现异常的task，部分请求因task资源耗尽或处理能力下降超时，而部分请求（如旧连接复用）仍能正常响应，进而出现访问差异。

2. 应用连接池耗尽 #

应用的数据库/HTTP连接池被占满，新请求无法获取连接导致504，但已建立的连接仍能处理请求：

• task进程未崩溃，所以LB健康检查（仅探测进程存活或简单端口监听）显示正常，日志也能持续生成。
• 指标收集可能因无法与应用建立新连接获取指标数据，导致指标中断。

3. LB会话粘性导致的访问差异 #

如果LB开启了会话粘性，你的请求被固定到了异常task上，而其他用户的请求被分发到正常task，就会出现“自己无法访问但部分用户正常”的情况。同时LB健康检查未及时探测到异常task的健康状态变化。

4. 指标收集组件故障 #

CloudWatch Agent或其他指标收集工具出现异常，无法从task抓取指标，但这只能解释指标中断，无法覆盖504和访问差异，更可能是伴随问题。

排查建议 #

• 优先核对LB健康检查配置：确认检查路径、端口、超时时间是否匹配应用健康端点，查看LB的健康检查日志，确认是否有探测失败但未标记实例不健康的情况。
• 检查应用日志中的连接池指标：查看连接数、等待队列长度，确认是否存在资源耗尽。
• 临时关闭LB会话粘性，测试自身访问是否恢复，验证粘性是否是访问差异的原因。
• 查看ECS集群的网络日志：确认安全组、NACLs是否有临时变更，排除网络层面的阻塞。

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