Question

有没有其他人看到他们的弹性beanstalk应用程序的零星健康检查失败了？

我使用ELB来提供GraphQL API。我在一个t2.micro实例上运行docker配置，监视间隔设置为1分钟。它设置为在重负载下最多可扩展到4个实例。数据存储使用Amazon RDS（PostgreSQL，非公开可用，db.t2.micro）。

以下是我的ELB活动页面中的最新值：

2018-05-23 08:24:11 UTC-0600    INFO
Environment health has transitioned from Severe to Ok.

2018-05-23 08:23:11 UTC-0600    WARN
Environment health has transitioned from Ok to Severe. None of the instances are sending data.

2018-05-21 06:28:13 UTC-0600    INFO
Environment health has transitioned from Severe to Ok.

2018-05-21 06:27:13 UTC-0600    WARN
Environment health has transitioned from Ok to Severe. 85.7 % of the requests are erroring with HTTP 4xx.

2018-05-18 14:10:51 UTC-0600    INFO
Environment health has transitioned from Severe to Ok.

自从我几个月前部署我的应用程序以来，我偶尔会看到HTTP 4XX警告。我之前从未见过None of the instances are sending data警告。我的应用程序日志中没有看到任何匹配的4XX错误。

不确定这是否正常，或者我是否有错误配置的内容。 Amazon Compute在其服务承诺部分here中公布了99.99％的SLA级别。我应该期待在以下范围内看到停机时间：

每日：8.6s
每周：1分0.5秒
每月：4分23.0秒
每年：52m 35.7s

我在外部健康状况检查中没有看到任何错误（我使用UptimeRobot，它每隔五分钟轮询我的API健康端点并搜索关键字）。我的应用程序日志中没有任何错误。

如果其他人看到了闪烁的健康状况，并找到了缓解这种情况的方法（或者至少为什么会发生这种情况），我将不胜感激。谢谢你的阅读！

Answer 1

我经常看到在低流量实例上的一分钟失败，例如测试环境。每次我调查时，4XX错误都来自端口扫描程序或其他一些恶意请求。由于非产品实例上的流量较低，因此触发85.7％的请求并不会花费太多时间。＆＃34; - 例如，七个请求中可能只有六个。

如果ELB日志中的4XX错误未显示在应用程序日志中，则可能会看到错误。默认情况下禁用ELB日志记录，但您可以将其打开并登录到S3。

最简单的方法是通过将安全组中的IP列入白名单来限制对应用程序的访问。但是，如果您的应用程序需要面向公众，那么您可以选择一些解决问题的方法：

如果请求来自单个IP地址，您可以使用VPC中的ACL阻止它。
如果请求来自多个IP地址，则可能会阻止它们，如果存在任何一致的模式，例如他们尝试访问的URI，关联的用户代理等。但是，您需要启用WAF。
只是忽略警告 - 它们很可能是无害的，一旦你有更多的流量，它们就会与其他噪音融为一体。

Answer 2

Brian对于原因是正确的-我每天都从端口扫描程序中看到这一点-并列出了一些明智的选择，只是指出，根据https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/health-enhanced-rules.html，Elastic Beanstalk现在有一个相对较新的规则来忽略4xx错误作为另一个选择

一个警告是，您可能会由于配置问题或应用程序错误而错过4xx错误。

AWS Elastic Beanstalk零星失败的健康检查

2 个答案: