没有从 ELB 到 Auto Scaling 实例之一的流量
我们使用 Auto Scaling，它对我们来说效果很好，但今天早上发生了一些事情。 由于某种原因，其中一个实例的 CPU 利用率约为 %0，这给同一可用区中的其余实例带来了 100% 的 CPU 利用率，并且它没有扩展，因为所有实例的平均 CPU 利用率约为 %70 while 触发器应在达到 %80 时启动新实例。还使用了 ELB 实例运行状况检查，但此 %0 实例运行状况良好。
是否可以配置 Auto Scaling 来删除此类实例？ 我们不想设置任何自定义 cronjobs 来进行检查。
We use Auto Scaling and it works pretty good for us, but this morning something happened to it.
CPU Utilization of one of the Instances was about %0 for some reason which brought %100 of CPU Utilization to the rest of Instances in the same Availability Zone and it didn't scale up, because Average CPU Utilization of all Instances was about %70 while trigger should start new Instance when %80 is hit. ELB Instance health check is used as well, but this %0 Instance was healthy.
Is it possible to configure Auto Scaling to remove such Instances?
We don't want to setup any custom cronjobs for check ups.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
更新2
是的，请参见下文 - 根据您的评论，您已经正确完成了此操作。
鉴于您的配置显然是正确的（意味着 Auto Scaling 和/或 ELB 存在相应问题），恐怕无法通过主动关闭未使用的实例或促进< em>as-set-instance-health，正如我在下面的最初答案中已经建议的那样 - 前者是 tribalcrossing 对 ELB - 不健康的实例会 OOS，然后也会自动从 ELB 中删除，这似乎可以解决您的情况：
更新1
您指的是哪个健康指标？您又如何得出实例健康的结论？
重要的是要认识到，自动扩展和 ELB 以不同的方式衡量健康实例，请参阅 alighafour 对 自动缩放不会对不健康的实例做出反应：
AWS 团队对链接问题 ELB-Unhealthy 的答复进一步详细介绍了这种差异采取 OOS 的实例然后自动从 ELB 中删除（这实际上解决了一个相反的问题）：
结论
看起来上述场景可能确实适用于您的体验：ELB 停止向您的实例发送流量，因为 ELB 运行状况检查失败，而 Auto Scaling 运行状况检查没有发现实例存在问题；例如，如果 ELB 运行状况检查探测 Apache 提供的网页，但由于任何原因（例如 Apache 崩溃或其他原因）而无法响应，则可能会发生这种情况。
解决方案
您需要配置Auto Scaling 策略，使其健康决策基于 EC2 健康状态和 ELB 健康状态，如下所述在为 Elastic Load Balancing 创建运行状况检查部分 维持当前的缩放级别：
完成此配置后，一旦 ELB 运行状况检查失败，实例就会被视为不健康，如下所示好吧，它将相应地被替换。
初步答复
不幸的是，请参阅 AWS 团队对 如何在模板中设置多个触发器的响应：
另一种方法可能是通过 as-set-instance-health 实施自定义解决方案，如 维持当前的扩展级别：
Update 2
Yes, see below - according to your comments you have done this correctly already.
Given your configuration is apparently correct (implying a respective issue with Auto Scaling and/or ELB), I'm afraid that it is not possible to avoid a custom solution by actively shutting unused instances down or facilitating as-set-instance-health, as already suggested in my initial answer below - the former is suggested by tribalcrossing's answer to ELB-Unhealthy instances taken OOS then removed from ELB automatically as well, which seems to address your situation:
Update 1
Which health indicator are you referring to and how did you conclude the instance being healthy in turn?
It is important to realize, that Autoscaling and ELB measure healthy instances differently, see alighafour's response to Autoscaling not reacting to unhealthy instances:
This difference is further detailed in the AWS team's response to the linked question ELB-Unhealthy instances taken OOS then removed from ELB automatically (which addresses an inverse issue actually):
Conclusion
It looks like the aforementioned scenario might apply to your experience indeed: ELB stopped sending traffic to your instance, because the ELB health check failed, while the Auto Scaling health check didn't see a problem with the instance as such; this might happen for example, if the ELB health check probes an Apache served webpage, which fails to respond for whatever reason (e.g. an Apache crash or else).
Solution
You need to configure the Auto Scaling Policy to base its health decision on both, the EC2 health status and the ELB health status, as outlined in section Creating a Health Check for Elastic Load Balancing within Maintaining Current Scaling Level:
With this configuration in place, the instance is going to be considered unhealthy as soon as the ELB health check fails as well, and it will be replaced accordingly.
Initial Answer
Unfortunately not, see e.g. the AWS team response to How to set Multiple Triggers in Template:
An alternative approach could be to implement a custom solution via as-set-instance-health, as mentioned in section Custom Health Check within Maintaining Current Scaling Level :