AWS ALB针对ECS服务周期性无明显原因健康检查失败的排查咨询

这种无明显业务影响但周期性触发的ALB健康检查502失败确实挺头疼的，我之前也碰到过类似的场景，给你分享几个实用的排查方向：

• 先确认健康检查请求是否真的到达后端实例
  你提到Nginx日志里没看到失败请求，那得先搞清楚请求到底有没有过来。可以在ECS实例上用tcpdump抓包验证：

  sudo tcpdump -i any port <你的健康检查端口> and host <ALB的IP前缀/段>
  

  如果抓不到ALB的健康检查请求，那问题大概率在网络层面——比如安全组是否允许ALB的IP段访问实例端口？NACL有没有拦截？如果用的是awsvpc网络模式，ENI的配置是否正常？

• 排查Nginx的日志和配置细节
  先检查Nginx的access_log配置，有没有可能把ALB健康检查的请求过滤掉了？比如有些配置会忽略ELB-HealthChecker/2.0这个User-Agent的请求，导致日志没记录。另外，看看Nginx的超时设置：proxy_connect_timeout、proxy_read_timeout会不会太短，刚好在健康检查的时间窗口触发超时？如果健康检查路径不是专门的静态页面，而是走uWSGI的动态接口，那Nginx转发到uWSGI的配置有没有问题？

• 深入检查uWSGI的运行状态
  虽然业务没中断，但uWSGI的worker可能偶尔出现短暂卡住的情况。可以开启uWSGI的stats功能，在配置里加：

  stats-server = 127.0.0.1:9191
  

  然后用uwsgitop或者curl http://127.0.0.1:9191查看实时状态，看看有没有worker长时间处于busy状态，或者频繁重启的情况。同时检查uWSGI的日志，有没有OOM、连接池耗尽之类的异常信息。

• 监控ECS实例的资源波动
  周期性问题往往和资源波动有关，去CloudWatch里拉取ECS实例的CPUUtilization、MemoryUtilization指标，看看健康检查失败的时间点有没有对应的资源峰值。另外磁盘IO也不能忽略——比如定时日志切割、备份操作可能导致磁盘繁忙，暂时影响服务响应速度。

• 开启ALB自身的访问日志
  这一步很关键！ALB的日志会详细记录健康检查的请求和失败原因，比如是target-unhealthy、connection-timeout还是其他原因。之前你可能没开启这个日志，赶紧开启后，对应失败时间点去分析日志，能直接缩小排查范围。

• 手动模拟健康检查请求
  在ECS实例上或者同VPC的机器里，手动发送和ALB完全一致的健康检查请求：

  curl -I -A "ELB-HealthChecker/2.0" http://localhost:<端口>/<健康检查路径>
  

  多跑几次，尤其是在健康检查失败的时间段，看看会不会偶尔出现502，这样能验证是服务本身的偶发问题，还是ALB层面的问题。

• 排查ECS任务的调度事件
  看看ECS的任务事件日志，有没有和健康检查失败时间点对应的任务重启、实例替换记录？比如ECS的任务健康检查和ALB的健康检查是否有冲突？或者实例进入维护窗口导致暂时不可用？

备注：内容来源于stack exchange，提问作者Dustin Oprea