我之前也碰到过类似的Elastic Beanstalk健康状态频繁切换的问题，结合你的配置（Docker部署GraphQL API、t2.micro实例、RDS PostgreSQL）和症状，分享一些实际排查过的方向和缓解方法：

一、先从健康检查配置本身入手 #

• 检查健康检查端点的响应效率：t2.micro是突发性能实例，高负载下CPU credits很容易耗尽，导致健康检查端点响应超时。ELB默认的健康检查超时时间是5秒，如果你的/health端点需要做DB连接校验这类操作，高负载时很可能超过这个阈值。建议：
  • 把ELB健康检查的Timeout参数调整到10-15秒，同时保持Interval为1分钟不变；
  • 简化健康检查端点，尽量只返回200 OK，不要在里面执行复杂的业务逻辑或DB查询——如果需要校验DB，可以单独做异步监控，不要绑定到健康检查上。
• 确认协议与端口匹配：确保ELB健康检查使用的协议（HTTP/HTTPS）、端口和Docker容器暴露的端口完全一致。比如Docker映射了8080端口，但ELB健康检查用了80端口，就会出现偶发的无响应。

二、针对“无实例发送数据”的排查 #

• 扩容时的实例预热问题：当环境从1台扩容到4台时，新实例需要拉取Docker镜像、启动应用、建立RDS连接，这个过程可能需要1-2分钟，但ELB默认会在实例启动后立刻开始健康检查。如果实例还没完全就绪，就会被判定为“无数据发送”。建议在Elastic Beanstalk的Auto Scaling配置里，把Instance Warmup设置为2-3分钟，让新实例完全初始化后再纳入健康检查范围。
• EC2实例的资源瓶颈：t2.micro的CPU credits耗尽后，实例性能会骤降，甚至出现短暂的网络中断。去CloudWatch查看CPUCreditBalance指标，如果这个值经常降到0，说明实例资源不够用。可以考虑换成t3.micro（无CPU credit限制），或者提前触发扩容——比如把扩容阈值从CPU 80%降到50%，避免实例被压垮。

三、关于“85.7%请求返回HTTP 4xx”但日志无记录的问题 #

• ELB健康检查请求被统计为4xx：很多时候，ELB的健康检查请求如果不符合应用的路由规则（比如/health端点需要认证，或者路由配置错误），会返回401/404，但这些请求可能没被你的应用日志记录（比如Nginx日志默认过滤了ELB的健康检查IP）。建议：
  • 开启ELB的访问日志（存储到S3），查看这些4xx请求的具体路径和来源IP；
  • 调整应用的路由规则，允许ELB的健康检查IP段无认证访问/health端点。
• WAF或安全组的偶发拦截：如果你的ELB配置了WAF，可能存在规则误判，偶发拦截了健康检查请求。可以暂时关闭WAF测试，或者查看CloudWatch里的WAF日志，确认是否有拦截记录。

四、长期优化建议 #

• 升级RDS实例类型：db.t2.micro同样是突发性能实例，高负载时会成为瓶颈，导致应用响应变慢。可以升级到db.t3.micro，或者开启RDS性能Insights，查看慢查询日志，优化GraphQL的查询语句（比如解决N+1查询问题）。
• 调整Auto Scaling策略：不要只依赖CPU使用率作为扩容触发条件，结合请求延迟、队列长度等多指标设置扩容规则。同时把缩容的冷却时间设长一点（比如5分钟），避免刚扩容的实例马上被缩容，导致环境不稳定。
• 开启增强型健康报告：在Elastic Beanstalk环境配置里开启Enhanced Health Reporting，这样能看到更详细的健康检查失败原因（比如实例超时、返回错误码还是无响应），而不是只看到笼统的警告。

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