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目标组中的错误,也可能是文档不正确的正常行为.我得出这个结论是因为:
在这种情况下,我认为可能是正常行为被错误地记录,但是没有办法验证除非来自AWS的人可以,并且几乎不可能在aws论坛上得到这样的问题的答案.
能够配置设置或者至少更新文档会很有用.
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 个健康检查请求,不应使您的进程过载。
归档时间: |
|
查看次数: |
7346 次 |
最近记录: |