我们使用 Auto Scaling，它对我们来说效果很好，但今天早上发生了一些事情。由于某种原因，其中一个实例的 CPU 利用率约为 %0，这将 %100 的 CPU 利用率带到了同一可用区中的其余实例，并且它没有扩大，因为所有实例的平均 CPU 利用率约为 %70而触发器应该在 %80 被命中时启动新的实例。也使用了 ELB 实例运行状况检查，但此 %0 实例运行状况良好。
是否可以配置 Auto Scaling 以删除此类实例？我们不想为检查设置任何自定义 cronjobs。
问问题
1497 次
1 回答
5
更新 2
是否可以配置 Auto Scaling 以删除此类实例？
是的，见下文 - 根据您的评论，您已经正确完成了此操作。
我们不想为检查设置任何自定义 cronjobs。
鉴于您的配置显然是正确的（暗示Auto Scaling和/或 ELB 的相应问题），恐怕无法通过主动关闭未使用的实例或促进as-set-instance-health来避免自定义解决方案，正如我在下面的初始答案中已经建议的那样- tribalcrossing 对ELB-Unhealthy 实例的回答建议了前者，该实例采用 OOS 然后也自动从 ELB中删除，这似乎解决了您的情况：
我们运行一个每 5 分钟触发一次的 cronjob，以扫描 ELB 中的所有服务器，以检查它是否已启动超过 5 分钟并且不健康。当我们找到一个时，我们将其关闭。我们已经遇到了“死”实例卡在 ELB 中并抛出触发自动缩放操作的监控指标的问题，而 cronjob 为我们解决了这个问题。
更新 1
也使用了 ELB 实例运行状况检查，但此 %0 实例运行状况良好。
您指的是哪个运行状况指标，以及您如何依次得出实例运行状况良好的结论？
重要的是要意识到，Autoscaling 和 ELB 测量健康实例的方式不同，请参阅 alighafour 对 Autoscaling 的响应，而不是对不健康的实例做出反应：
ELB 在应用层进行检查，而在机器层进行自动缩放检查。
这种差异在 AWS 团队对链接问题ELB-Unhealthy instances taken OOS then removed from ELB automatically（实际上解决了一个相反的问题）的回答中进一步详细说明：
自动缩放正在查看实例的健康状况——如果数据显示实例不健康，他们就会关闭实例。届时他们会将其从 ELB 中取出，然后关闭该实例。
另一方面，ELB 通过读入文件或连接到端口来进行应用程序健康检查。如果应用程序在一定数量的这些检查中失败，实例会继续运行，但 ELB 不会向它发送任何新流量。ELB 继续执行健康检查 - 如果应用程序实例再次变得健康，它将开始将流量路由到它。ELB 不会从 ELB 注册中删除实例- 它只是停止向其发送流量，直到它再次健康为止。[强调我的]
结论
看起来上述场景可能确实适用于您的体验：ELB 停止向您的实例发送流量，因为ELB 健康检查失败，而Auto Scaling 健康检查没有发现实例存在问题；例如，如果 ELB 运行状况检查探测 Apache 服务的网页，该网页由于任何原因（例如 Apache 崩溃或其他）而无法响应，则可能会发生这种情况。
解决方案
您需要配置Auto Scaling 策略，使其健康决策基于 EC2 健康状况和ELB 健康状况，如在维护当前扩展级别内为 Elastic Load Balancing 创建健康检查 部分所述：
默认情况下，Auto Scaling 对所有 Auto-Scaling 托管实例使用 Amazon EC2 运行状况。要同时使用 Elastic Load Balancer 的运行状况检查，请将组的 HealthCheckType 属性设置为 ELB：
% as-update-autoscaling-group myGroup –-health-check-type ELB
有了这个配置，一旦 ELB 健康检查失败，实例就会被认为是不健康的，并将相应地替换它。
初步答案
一个 Auto Scaling 组是否可以有多个触发器？
不幸的是，请参阅 AWS 团队对如何在模板中设置多个触发器的响应：
遗憾的是，Auto Scaling 服务仅允许每个 Auto Scaling 组使用 1 个触发器，因此我们目前不支持在模板中为同一组设置多个触发器。
另一种方法是通过as-set-instance-health实施自定义解决方案，如维护当前扩展级别中的自定义运行状况检查部分所述：
如果您有自己的健康检查系统，则可以将其与 Auto Scaling 集成。使用 SetInstanceHealth 将实例的运行状况信息直接从您的系统发送到 Auto Scaling。
于 2012-02-15T02:32:35.147 回答