ALB健康检查异常排查方法

问题描述

ALB实例的监听对应的健康检查状态显示异常。

问题原因

解决方案

首次配置健康检查出现异常

原因一：健康检查参数设置错误

1. 登录应用型负载均衡ALB控制台。

2. 在顶部菜单栏，选择ALB实例所属的地域。

3. 在左侧导航栏，选择应用型负载均衡 ALB > 服务器组。

4. 在服务器组页面，找到目标ALB实例挂载的服务器组，然后单击服务器组ID。

5. 在服务组详情页面，在健康检查区域单击编辑健康检查。

6. 在编辑健康检查对话框，检查健康检查参数设置是否正常，建议按照默认提供的健康检查参数进行设置。

   更多信息，请参见配置和管理健康检查。

原因二：监听端口问题

1. 登录应用型负载均衡ALB控制台。

2. 在顶部菜单栏，选择ALB实例所属的地域。

3. 在左侧导航栏，选择应用型负载均衡 ALB > 服务器组。

4. 在服务器组页面，找到目标ALB实例挂载的服务器组，然后单击服务器组ID。

5. 在服务器组详情页，单击后端服务器页签，查看并记录后端服务器端口。

6. 在服务组详情页面，单击详细信息页签，在健康检查区域单击编辑健康检查。在编辑健康检查对话框，查看并记录健康检查参数。

7. 登录后端服务器，使用nc或curl命令对后端服务器进行探测。

   关于如何登录ECS，请参见ECS远程连接操作指南。

   # nc命令：
   echo -e "[$Method] [$PATH] [$VERSION]\r\nHost: [$Domain]\r\n\r\n" | nc -t [$IP] [$Port] #格式
   echo -e "HEAD /index.html HTTP/1.0\r\nHost: www.example.org\r\n\r\n" | nc -t 127.0.0.1 80 #示例
   # curl命令：
   curl -X [$Method] -H "Host: [$Domain]" -I http://[$IP]:[$Port][$PATH]  #格式
   curl -X HEAD --http1.0 -H "Host: www.example.org" -I http://127.0.0.1:80/index.html #示例

   说明

   • [$Method]为该服务器组设置的健康检查方法。

   • [$PATH]为该服务器组设置的健康检查路径。

   • [$VERSION]为该服务器组设置的健康检查中HTTP协议的版本，例如HTTP/1.0。

   • [$Domain]为该服务器组设置的健康检查域名，如果该值为“-----”，说明默认使用各后端ECS实例的内网IP为域名，可以使用[$IP]代替。

   • [$IP]为后端ECS实例内网IP地址。

   • [$Port]为该服务器组设置的健康检查的探测端口，如果没有手动配置过健康检查端口，默认使用的是后端ECS实例端口，如果配置了健康检查端口，则使用配置的健康检查端口。

8. 查看命令执行结果的状态码，结合业务判断返回的状态码是否属于正常情况下的返回。

   • 如果判断返回的状态码是属于正常情况下的返回，且该状态码未在健康检查中配置，请修改健康检查的健康状态返回码。

   • 如果判断返回的状态码异常，请参见下表进行排查。下表列出了可能返回的HTTP状态码及排查方法。

     状态码	描述	排查方法
     400	客户端HTTP请求格式异常	请参考以下方法逐一排查： HTTP头部格式错误，例如content length为空、HTTP请求发送到HTTPS端口等。请检查HTTP请求的格式。 若业务逻辑本身固定返回400等4xx状态码，可在健康检查配置的健康状态返回码中勾选4xx，将4xx状态码视为正常返回，避免因特定业务返回码导致后端节点被健康检查剔除。
     403	禁止访问。ALB本身不会主动返回403状态码，403错误通常由后端Web服务的配置引起	检查后端服务（如Nginx、Tomcat）是否配置了针对特定来源IP或请求特征的拦截规则。若后端服务对健康检查请求的来源设置了拦截，会导致健康检查持续返回403，请调整后端服务的访问控制配置以放通健康检查请求。
     404	未找到目标资源，通常由健康检查路径与后端实际可用路径不匹配导致	请参考以下方法排查： 检查后端网关程序（如Nginx）实际对外暴露的接口路径前缀（例如/api/v1），确保健康检查配置的检查路径与后端实际可访问的资源路径一致。 如果通过IP直接访问后端服务返回正常，但通过域名访问返回404，通常是后端服务按域名（Host头）进行虚拟主机匹配所致，请核实健康检查配置的检查域名与后端服务的域名配置一致。
     405	健康检查请求方法不支持	请检查后端服务是否支持健康检查的请求方法。
     500	服务器内部错误，无法完成请求	请检查后端服务的业务逻辑。
     503	服务器暂时不可用	请检查后端服务的业务逻辑或负载是否过高。

配置成功后健康检查出现异常

原因一：安全类防护软件问题

因为ALB通过内部保留地址段中的IP地址与后端ECS实例通信，ALB的该地址段被屏蔽会导致健康检查异常，ALB将无法正常工作。本文以Iptables检查100.64.0.0/10为例介绍。

1. 登录问题后端ECS实例，执行以下命令，查看filter表的所有规则。

   iptables -nL

   如果返回类似以下信息，说明后端ECS实例禁止ALB内网地址段请求。

   [root@xxx Z ~]# iptables -nL
   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination
   DROP       all  --  100.64.0.0/10        0.0.0.0/0
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination
   Chain OUTPUT (policy ACCEPT)
   target     prot opt source               destination
   Chain L (0 references)
   target     prot opt source               destination

2. 执行以下命令，删除此规则即可。

   iptables -t filter -D INPUT -s 100.64.0.0/10 -j DROP

3. 执行以下命令，确认没有禁止ALB内网地址段请求。

   iptables -nL

除iptables规则外，还需检查以下安全配置，确保ALB健康检查流量能够正常到达后端服务：

1. 检查后端服务器的端口监听状态：确认后端服务器正在监听服务器组中配置的后端端口（例如80端口）。可执行以下命令查看端口监听情况：

   netstat -tlnp | grep <端口号>
   # 或使用ss命令：
   ss -tlnp | grep <端口号>

   若端口未处于监听状态（LISTEN），请检查后端服务是否已正常启动。

2. 检查后端ECS安全组入方向规则：确保安全组入方向规则已放通以下来源的访问，否则ALB健康检查探测包可能被安全组拦截：

   • 授权对象（源地址）：升级后的ALB实例为其Local IP所在的交换机网段；升级前的ALB实例为100.64.0.0/10网段

   • 协议：TCP

   • 端口范围：服务器组中配置的后端服务端口

原因二：路由配置错误问题

当ALB实例使用的内网地址段100.64.0.0/10在后端ECS上的路由配置错误时，也会导致ALB实例收不到健康检查探测的数据包，造成健康检查异常。本文以Linux下的route命令为例，检查路由配置情况。

1. 登录问题后端ECS实例，执行以下命令，检查当前系统的路由配置情况。

   route -n

   若您发现存在路由条目的Destination为100.64.0.0，Genmask为255.192.0.0，且Gateway没有指向对应网卡的默认网关（当Destination为0.0.0.0时，Gateway显示的信息就是默认网关），则该路由配置错误。

   [root@test-server2 ~]# route -n
   Kernel IP routing table
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   0.0.0.0         <eth0的默认网关>  0.0.0.0         UG    100    0        0 eth0
   xxx             xxx             xxx             xxx   xxx    xxx      xxx xxx
   100.64.0.0      0.0.0.0         255.192.0.0     U     0      0        0 eth0

2. 执行以下命令，删除配置错误的100.64.0.0/10路由。

   route del -net 100.64.0.0/10

原因三：后端ECS实例负载过高

当后端ECS实例资源不足时，服务器可能无法在健康检查超时时间内响应探测请求，从而导致健康检查异常。资源不足既可能是系统整体过载，也可能是连接泄漏等具体问题逐渐耗尽系统资源所致，可参考以下两个子场景进行排查。

子场景一：系统资源过载

当CPU、内存或磁盘I/O等系统资源被占满时，服务器来不及响应健康检查探测。参见Linux实例负载高问题排查和异常处理，查看是否是服务器负载过高导致的问题。

子场景二：连接泄漏导致资源耗尽（CLOSE_WAIT堆积）

如果后端ECS上存在大量处于TCP CLOSE_WAIT状态的连接，通常是由于后端应用程序（例如使用jsvc.exec托管的Java服务）在处理完请求后，未主动调用close()方法释放连接，导致连接长期处于CLOSE_WAIT状态并持续堆积。CLOSE_WAIT连接过多会占用系统资源，可能影响健康检查的正常响应。

排查步骤：

1. 登录后端ECS，执行以下命令查看当前CLOSE_WAIT连接数量：

   netstat -an | grep CLOSE_WAIT | wc -l

2. 如果CLOSE_WAIT连接数量持续增长或异常偏高，请检查后端应用代码或服务配置，确保应用在请求处理完成后正确执行连接关闭操作（如调用close()或shutdown()方法）。对于使用连接池的框架，请检查连接池的空闲超时和回收配置。

常见问题

为什么后端服务器收到的健康检查请求频率很高？

ALB采用多可用区分布式集群架构，集群内所有转发节点均会独立向后端服务器发送健康检查探测请求。因此，后端实际接收到的健康检查请求频率为：单节点检查频率 × 节点数量。例如，若健康检查间隔设置为5秒，集群中存在10个转发节点，则后端每5秒约收到10次健康检查请求，即近2次/秒。这是ALB的正常设计行为，并非异常。

如需降低后端收到的健康检查请求频率，可参考以下方法：

1. 适当增大健康检查间隔（取值范围：1~50秒）或健康阈值，减少单位时间内的探测次数。但请注意，间隔越长，异常节点被检测和剔除所需的时间越长，可能影响故障检测的时效性，需结合业务对可用性的要求进行权衡。

2. 将健康检查协议改为TCP四层健康检查：ALB仅执行TCP握手，不发送HTTP请求，对后端应用资源消耗更低，适合对健康检查请求频率敏感的场景。