NLB目标群体健康检查失控

Mil*_*les 15 amazon-ec2 amazon-web-services amazon-elb aws-cloudformation

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

检查之间的默认间隔应该是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
Run Code Online (Sandbox Code Playgroud)

我的EC2实例位于私有子网中,无法访问外部世界.NLB是内部的,因此没有通过API网关就无法访问它们.API网关没有/healthcheck配置端点,因此可以排除来自AWS网络外部的任何活动,例如手动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"}
Run Code Online (Sandbox Code Playgroud)

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

Mil*_*les 21

更新:这已在相关的aws论坛帖子上得到解答,该帖子确认它是网络负载均衡器的正常行为,并引用其分布式性质作为原因.无法配置自定义间隔.此时,文档仍然过时,另有说明.


这可能是NLB目标组中的错误,也可能是文档不正确的正常行为.我得出这个结论是因为:

  • 我确认健康检查来自NLB
  • 配置选项在控制台上显示为灰色
    • 推断AWS了解或强加了此限制
  • 其他人也观察到了同样的结果
  • 该文档专门用于网络负载均衡器
  • AWS文档通常会引导您进行疯狂的追逐

在这种情况下,我认为可能是正常行为被错误地记录,但是没有办法验证除非来自AWS的人可以,并且几乎不可能在aws论坛上得到这样的问题的答案.

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

  • Fwiw 我只有 1 个听众,但仍然出现这种行为 (3认同)
  • 似乎您添加到 NLB 的侦听器越多,运行状况检查就越困难。如果您只使用 1 个侦听器,则不会出现这种 ddos​​ 行为 (2认同)

nat*_*eck 11

编辑:现在只是想在 2021 年 9 月分享有关此的更新。如果您使用的是 NLB,您应该会收到类似于以下内容的电子邮件:

我们正在就即将对您的网络负载均衡器进行的更改与您联系。从 2021 年 9 月 9 日开始,我们将升级 NLB 的目标健康检查系统。升级后的系统提供更快的故障识别,提高目标健康状态的准确性,并允许 ELB 在部分故障情况下权衡受影响的可用区。

作为此更新的一部分,您可能会注意到后端目标的运行状况检查流量减少,从而减少了目标 NetworkIn/Out 指标,因为我们删除了冗余运行状况检查。

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

上一个答案:

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

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

我对健康检查的建议是将健康检查编码得非常轻。很多人都犯了一个错误,即过载他们的健康检查来做检查后端数据库或运行其他检查之类的事情。理想情况下,负载均衡器的健康检查除了返回一个像“OK”这样的短字符串之外什么都不做。在这种情况下,您的代码应该需要不到一毫秒的时间来为健康检查请求提供服务。如果您遵循此模式,那么偶尔会出现 6-8 个健康检查请求,不应使您的进程过载。

  • “偶尔爆发 6-8 个健康检查请求” -> 似乎变得更糟,每秒连续 6-8 个请求,定期爆发接近 20 个请求/秒。即使是轻微的运行状况检查也会以不必要的高速率显着影响较小实例类型的 CPU 消耗。 (5认同)
  • 我遇到的问题是我尝试负载平衡的服务具有非常详细的日志记录,无法减少它。持续的治疗检查(每秒大约 5 次)很快就填满了我的日志。这非常令人沮丧,让我试图找到一些古怪的替代方案来避免使用 NLB。为什么需要这样工作???它不需要像这样向我的服务发送垃圾邮件来确定它是否健康。 (4认同)
  • 但是,非常轻的运行状况检查不太有用,我不确定是否包括不仅仅是检查进程正在运行和接受连接的“错误”。与数据库连接一样,磁盘空间检查是另一个有用的检查。 (3认同)