AWS ELB与ASG负载不均问题：新扩容EC2实例CPU利用率为0

哎，这个场景我太熟悉了，之前帮好几个朋友排查过类似问题，大概率是下面这几个环节出了状况，咱们一个个拆解：

1. 新实例没通过ELB健康检查 #

这是最常见的原因！ELB只会把流量转发到健康状态的实例上，哪怕ASG已经把实例创建出来了，如果实例没通过ELB的健康检查，就会被排除在流量池外。

• 你可以先去ELB的目标组里看看3、4号实例的状态：如果显示「不健康」或者「初始中」，那就是问题所在。
• 可能的细节：
  • 健康检查的路径设置不合理，比如需要应用完全初始化完成才能返回200，但新实例还在加载依赖、启动服务，导致健康检查失败。
  • 健康检查的超时/间隔时间设置太短，比如实例需要1分钟才能启动服务，但健康检查30秒就判定失败，直接把实例踢出去了。
  • ASG的健康检查和ELB不同步：ASG可能认为实例已经就绪（比如EC2状态是running），但ELB还没通过健康检查，所以流量不会过来。

2. 会话粘滞（粘性会话）设置过强 #

如果你的ELB开了会话粘滞功能，而且超时时间设置得很长，就会出现旧会话一直粘在1、2号实例上的情况：

• 比如压测工具复用了同一个会话Cookie，所有请求都被ELB转发到最初的实例，新实例根本接不到新请求。
• 或者你设置了「基于应用的粘性会话」，应用层的会话机制导致用户请求一直绑定到老实例，新实例只能等新的无Cookie请求进来，但压测场景下可能没有新用户。

3. 新实例的应用初始化太慢 #

哪怕EC2实例显示running，应用本身可能还没完全启动：

• 比如你的应用需要下载大体积的依赖包、初始化数据库连接池、加载缓存数据，这个过程可能需要几分钟，在这期间实例根本无法处理请求，ELB健康检查自然通不过，也就没流量。
• 去新实例的应用日志里看看，是不是有启动慢的迹象，比如卡在某个初始化步骤。

4. 负载均衡算法或权重配置问题 #

• 如果你修改了ELB的默认轮询算法，比如用了「最小连接数」，但1、2号实例的长连接一直没释放，ELB会认为它们的连接数还没到阈值，继续往那边发流量。
• 或者你给老实例设置了更高的权重，ELB会优先把流量分配给权重高的实例，导致新实例接不到多少请求。

5. 网络/安全组配置问题 #

• 新实例的安全组没有开放ELB的访问端口：比如ELB需要访问实例的80/443端口，但新实例的安全组只允许老的IP段访问，拒绝了ELB的流量，导致健康检查失败，无法转发请求。
• 子网的NACL（网络访问控制列表）限制了ELB和新实例之间的通信，比如入站/出站规则没开对应端口。

快速排查步骤 #

1. 打开ELB控制台，查看目标组的实例健康状态，确认3、4号实例是否健康。
2. 检查健康检查的配置：路径、预期响应码、超时/间隔时间。
3. 查看会话粘滞的设置，是否开启以及超时时间长度。
4. 登录新实例，查看应用启动日志，确认服务是否正常运行。
5. 检查新实例的安全组和子网NACL，确保ELB能正常访问实例的服务端口。

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