AWS Elastic Beanstalk 运行状况检查偶尔失败

Question

还有其他人看到他们的 Elastic 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 宣传其服务承诺部分中的 SLA 级别为 99.99% 。我预计会出现以下范围内的停机时间：

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

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

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

Answer 1

我经常看到低流量实例（例如测试环境）出现一分钟故障。每次我调查时，4XX 错误都是来自端口扫描器或其他一些恶意请求。由于非生产实例上的流量较低，因此不需要太多就能触发“85.7% 的请求”，例如，可能只有七个请求中的六个。

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

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

1. 如果请求来自单个 IP 地址，您可以使用 VPC 中的 ACL 阻止它。
2. 如果请求来自多个 IP 地址，并且存在任何一致的模式（例如它们尝试访问的 URI、关联的用户代理等），您也许能够阻止它们。但是，您需要启用 WAF。
3. 只需忽略这些警告即可 - 它们很可能是无害的，一旦流量增加，它们就会与其他噪音混合在一起。