没有持续警报的 AWS EC2 自动扩展？答案

【问题标题】：AWS EC2 autoscaling without constant alarms?没有持续警报的 AWS EC2 自动扩展？
【发布时间】：2016-11-14 05:07:34
【问题描述】：

我为自动缩放组创建了以下两个警报：

如果“CPUUtilization >= 75%”更改为状态 ALARM，则向上扩展 1 个实例
如果“CPUUtilization >= 30%”变为状态OK，则缩小 1 个实例

如果负载低于 30%，我已选择在 OK 上触发缩减事件，以便在 Cloudwatch 中不会有恒定的警报。另一方面，这正是问题所在。当发生高档事件时，该组的平均负载在 30% 到 75% 之间，状态设置为 ALARM。

是否有任何方法可以配置 Cloudwatch 以正确触发扩展和缩减事件，而不会在扩展发生后保持 ALARM 状态？

【问题讨论】：

不应该是这样的：CPUUtilization
当 CPU >= 30% 时会触发警报，所以当状态变为 OK（当 CPU
@kev 你找到什么了吗？我也想要一个更好的解决方案。
@musiKk 很遗憾没有

标签： amazon-web-services amazon-ec2 autoscaling

【解决方案1】：

“Scale down”操作应该设置为“CPUUtilization

【讨论】：

如果我这样做，我会让机器不断地旋转。假设我有 1 台 CPU = 80% 的机器 -> 放大 -> 2 台 40% 的机器 -> 缩小 -> 回到 1 台 80% 的机器，等等。
我在生产环境中有一个运行组，其工作方式如下： Cloudwatch 中有一个警报，阈值为 CPUUtilization >= 70 for 10 minutes ，因此如果 CPUUtilization >= 70 则状态为 ALARM , 如果 CPUUtilization
那也行不通。假设我最多有 4 个盒子。从一个 80% ALARM 的盒子开始 -> 启动所有 4 个盒子，每个盒子 20% 负载。每 5 分钟移除一个盒子，直到 2 个盒子剩下 40%，这仍然可以，所以另一个盒子被移除。这将我们带回到一个 80% 的盒子，整个过程重新开始。你的方法适用于突发负载，但如果你确定你会在半小时内回到低于 70% 的一个盒子。
如果您总是有一台机器超过 80%，请考虑以下两个选项中的至少一个：a) 使用更大/更好的机器，以便最初的 CPU 使用率更低，或 b) 使用基本最小值2-3 台机器总是从较低的 CPU 使用率开始运行。在我们的案例中，我们必须同时使用垂直和水平缩放，以开始安全且低 CPU 使用率。
扩展策略和报警周期应该基于负载和应用负载的性质。例如：如果负载是突发性的并且寿命很短，您可以更积极地扩展和缩减，如果负载增加更加渐进，您的扩展策略应该更加保守。此外，使用简单扩展策略的冷却期（或使用步进或目标跟踪扩展策略的预热期）可用于防止频繁的扩展和扩展活动。