AWS ELB 间歇性 502 网关超时错误

Question

我在部署在 3 个 EC2 实例上的 node.js 应用程序前面有一个 ELB。

我已经开始观察到间歇性 HTTP 502 Bad Gateway 错误。

以下是我的访问日志的摘录。这些 502 错误没有模式，所以我无法缩小原因？

是ELB 问题还是应用程序问题？

访问日志可以帮助我解决这个问题吗？

这发生在每 100 个请求中有 5 个请求

*type*                     https    
*timestamp*                2019-05-08T14:50:11.438405Z  
*elb*                      <my-elb>
*client:port*              clientIp:port
*target:port*              targetIp:port
*request_processing_time*  0    
*target_processing_time*.  2.596    
*response_processing_time* -1   
*elb_status_code*          502  
*target_status_code*       -    
*received_bytes*           792  
*sent_bytes*               293  
*request*                  POST https://app/app-url/2.0/resourcepath/id/abc?queryParamA=abc&queryParamB=false&queryParamC=6b84c34 HTTP/1.1  
*user_agent*               Apache-CXF/3.2.5 
*ssl_cipher*               ssl-cipher
*ssl_protocol*             TLSv1.2  
*target_group_arn*         arn
*trace_id*                 traceId
*domain_name*              cool-domain-name
*chosen_cert_arn*          session-reused   
*matched_rule_priority*    0    
*request_creation_time*    2019-05-08T14:50:08.841000Z  
*actions_executed*         forward  
*redirect_url*             -    
*error_reason*             -

Answer 1

确保您的节点服务器 keepAliveTimeout 大于 ELB 空闲超时。 ELB 和 ALB 不喜欢目标机器关闭连接。要检测这一点，您可以检查 elb 日志，您可能会看到响应时间为 -1 和 502。“-1”表示目标直接拒绝了请求。

Answer 2

下面是一个参考链接： https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-502-issues

其中最常见的是后端keep-alive小于ELB，ELB保持连接打开而后端关闭它，当ELB使用相同的TCP连接时，它会被RESET。

Answer 3

ELB 上的 502 通常表明存在应用程序/服务器问题。 ELB 与应用服务器通信时出现问题。检查应用程序日志是否有重新启动或其他错误。

根据 RFC：

10.5.3 502 网关错误
服务器在充当网关或代理时，在尝试满足请求时从其访问的上游服务器接收到无效响应。

可能的原因是空的或不完整的标头或响应正文，由断开的连接引起。还要在应用程序日志中查找 500 个服务器错误。

在您的情况下，应用服务器崩溃可能会导致 ELB 上出现 502 错误。

见

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Answer 4

确保在 ALB/ELB 之后不使用 Apache 的事件 MPM 模块（默认）。它动态关闭连接。试试工人 MPM。

Answer 5

检查您的目标群体并确保健康检查工作正常。在我们的例子中，我们有一个损坏的健康检查，将所有节点标记为不健康。我们具有自动缩放功能，因此可以动态地从组中添加/删除节点（取决于当前负载）。

然后 AWS 负载均衡器的这种奇怪行为开始了（来自官方文档 https://docs.aws.amazon.com/elasticloadbalancing/latest/application/elb-ag.pdf）：

如果目标组中至少有一个运行良好的目标，负载均衡器只会将请求路由到运行良好的目标。如果目标组仅包含不正常的目标，负载均衡器会将请求路由到不正常的目标。

由于这种行为，我们没有意识到运行状况检查已被破坏，发生 502 的请求被路由到刚刚被添加到目标组/从中删除的节点。修复运行状况检查解决了该问题。