NLB 目标群体健康检查失控

NLB Target Group health checks are out of control

我有一个网络负载均衡器和一个关联的目标组,该目标组配置为对 EC2 实例进行健康检查。问题是我看到大量的健康检查请求;每秒多次。

检查之间的 default interval 应该是 30 秒,但它们出现的频率比应有的频率高出大约 100 倍。

我的堆栈是在 CloudFormation 中构建的,我尝试覆盖 HealthCheckIntervalSeconds,但没有任何效果。有趣的是,当我尝试在控制台中手动更改间隔时,我发现这些值显示为灰色:

这是模板的相关部分,我尝试更改间隔的部分被注释掉了:

NLB:
  Type: "AWS::ElasticLoadBalancingV2::LoadBalancer"
  Properties:
    Type: network
    Name: api-load-balancer
    Scheme: internal
    Subnets: 
      - Fn::ImportValue: PrivateSubnetA
      - Fn::ImportValue: PrivateSubnetB
      - Fn::ImportValue: PrivateSubnetC

NLBListener:
  Type : AWS::ElasticLoadBalancingV2::Listener
  Properties:
    DefaultActions:
      - Type: forward
        TargetGroupArn: !Ref NLBTargetGroup
    LoadBalancerArn: !Ref NLB
    Port: 80
    Protocol: TCP

NLBTargetGroup:
  Type: AWS::ElasticLoadBalancingV2::TargetGroup
  Properties:
    # HealthCheckIntervalSeconds: 30
    HealthCheckPath: /healthcheck
    HealthCheckProtocol: HTTP
    # HealthyThresholdCount: 2
    # UnhealthyThresholdCount: 5
    # Matcher:
    #   HttpCode: 200-399
    Name: api-nlb-http-target-group
    Port: 80
    Protocol: TCP 
    VpcId: !ImportValue PublicVPC

我的 EC2 实例位于私有子网中,无法从外部世界访问。 NLB 是内部的,因此如果不通过 API 网关就无法访问它们。 API 网关没有配置 /healthcheck 端点,因此排除了来自 AWS 网络外部的任何 activity,就像人们手动 ping 端点一样。

这是从 CloudWatch 获取的我的应用程序日志示例,应用程序应该处于空闲状态:

07:45:33 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:33 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:33 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:33 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:34 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:34 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:34 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:35 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:35 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:35 {"label":"Received request URL","value":"/healthcheck","type":"trace"}

我通常每秒收到 3 到 6 个请求,所以我想知道这是否只是网络负载均衡器的工作方式,而 AWS 仍然没有记录(或者我没有找到它),否则我将如何解决此问题。

更新:这已在相关 aws forum post 上得到回答,确认这是网络负载平衡器的正常行为,并引用了它们的分布式特性作为原因。无法配置自定义间隔。目前,文档仍然过时并另有说明。


这要么是 NLB 目标组中的错误,要么是 documentation 不正确的正常行为。我得出这个结论是因为:

  • 我确认健康检查来自 NLB
  • 配置选项在控制台上显示为灰色
    • 推断 AWS 知道或施加了此限制
  • others
  • 观察到相同的结果
  • 该文档专门针对网络负载均衡器
  • AWS 文档通常会引导您进行无意义的追逐

在这种情况下,我认为这可能是被错误记录的正常行为,但没有办法验证这一点,除非来自 AWS 的人可以,而且几乎不可能得到关于 issue like this 的答案AWS 论坛。

能够配置设置或至少更新文档会很有用。

聚会有点晚了。但对我有用的是让我的 (C++) 服务启动一个专用于来自 ELB 的健康检查的线程。线程等待套接字连接,然后等待从套接字中读取;或遇到错误。然后它关闭套接字并返回等待下一个健康检查 ping。这比让 ELB 一直访问我的流量端口要便宜得多。它不仅让我的代码认为它受到了攻击,它还启动了所有后勤工作,以及为真正的客户提供服务所需的一切。

编辑: 只想在 2021 年 9 月分享这方面的更新。如果您使用的是 NLB,您可能会收到类似这样的电子邮件:

We are contacting you regarding an upcoming change to your Network Load Balancer(s). Starting on September 9, 2021, we will upgrade NLB's target health checking system. The upgraded system offers faster failure identification, improves target health state accuracy, and allows ELB to weight out of impacted Availability Zones during partial failure scenarios.

As a part of this update, you may notice that there is less health check traffic to backend targets, reducing the targets NetworkIn/Out metrics, as we have removed redundant health checks.

我希望这应该可以解决目标在使用 NLB 时接受许多健康检查的问题。

上一个回答:

这里是 AWS 员工。为了详细说明已接受的答案,您可能会看到大量健康检查请求的原因是 NLB 使用多个分布式健康检查程序来评估目标健康状况。这些健康检查器中的每一个都会在您指定的时间间隔内向目标发出请求,但所有这些健康检查器都会在该时间间隔内向目标发出请求,因此您将看到来自每个分布式探测器的一个请求。然后根据成功探测的数量评估目标运行状况。

您可以在“查看 Route 53 健康检查”下阅读另一位 AWS 员工在此处撰写的非常详细的解释:https://medium.com/@adhorn/patterns-for-resilient-architecture-part-3-16e8601c488e

我对健康检查的建议是将健康检查编码得非常轻。很多人错误地让他们的健康检查过载以同时执行诸如检查后端数据库或 运行 其他检查之类的事情。理想情况下,负载均衡器的健康检查只是返回一个像“OK”这样的短字符串。在这种情况下,您的代码处理健康检查请求所需的时间应该少于一毫秒。如果您遵循此模式,那么偶尔突发的 6-8 次健康检查请求不应使您的流程超载。