有没有其他人看到他们的 Elastic Beanstalk 应用程序偶尔会出现运行状况检查失败的情况？
我正在使用 ELB 来提供 GraphQL API。我在单个 t2.micro 实例上运行 docker 配置，监控间隔设置为 1 分钟。它设置为在重负载时最多扩展到 4 个实例。 Datastore 使用 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 在其服务 promise 部分 here 中宣传 99.99% 的 SLA 级别. 我预计会出现以下范围内的停机时间:
- 每日:8.6 秒
- 每周:1 米 0.5 秒
- 每月:4 分钟 23.0 秒
- 每年:52 米 35.7 秒
我在外部健康检查中没有发现任何错误(我使用 UptimeRobot，它每五分钟轮询一次 API 的健康端点并搜索关键字)。我在我的应用程序日志中没有看到任何错误。
如果其他人看到闪烁的健康状况并找到缓解这种情况的方法(或者至少为什么会发生这种情况)，我将不胜感激一些建议。感谢阅读!
最佳答案
我经常看到在低流量实例(例如测试环境)上出现一分钟故障。每次我调查时，4XX 错误都来自端口扫描器或其他一些恶意请求。由于非产品实例上的流量很低，触发“85.7% 的请求”并不需要太多——例如，可能只有七个请求中的六个。
如果 4XX 错误未显示在您的应用程序日志中，您可能会在 ELB 日志中看到它们。 ELB 日志记录默认情况下处于禁用状态，但您可以将其打开并登录到 S3。
最简单的方法是通过在您的安全组中将 IP 列入白名单来限制对您的应用程序的访问。但是，如果您的应用程序需要面向公众，那么您有几个解决问题的选项:
- 如果请求来自单个 IP 地址，您可以使用 VPC 中的 ACL 阻止它。
- 如果请求来自多个 IP 地址，并且存在任何一致的模式(例如他们尝试访问的 URI、关联的用户代理等)，您或许可以阻止它们。但是，您需要启用 WAF。
- 只需忽略警告 - 它们很可能是无害的，一旦您的流量增加，它们就会混入其余的噪音中。
关于performance - AWS Elastic Beanstalk 偶尔会失败的健康检查，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50491705/