AWS AutoScaling 未向上扩展答案

【问题标题】：AWS AutoScaling Not Scaling UpAWS AutoScaling 未向上扩展
【发布时间】：2014-08-29 20:17:58
【问题描述】：

我已经设置了一个 AWS AutoScaling 组。如果平均负载高于 65%，则有 2 个警报以增加服务器数量，如果低于 35%，则减少服务器数量。不确定最终数字是多少，但这是我最初使用的。我在 linux 服务器上运行了yes >& /dev/null 命令，负载很快上升到 100%（由 linux top 命令报告），但没有启动新实例，因为我认为警报没有触发。 Auto Scaler 计算/检索的 CPU 平均负载究竟如何？

作为实验，我还终止了对来自服务器的 AWS ping 命令的响应，因此 AWS 认为它不健康。服务器被终止并启动了一个新的。因此，我知道由于“健康”原因，服务器的启动/终止正在 Auto Scaler 中工作。

我还应该查看什么来诊断问题？
就 Auto Scaler 而言，我向服务器施加压力的方式不是“正确”方式吗？
是否使用了不同的基准？

【问题讨论】：

请添加有关您的闹钟设置的更多详细信息。 “yes >& /dev/null”会加载整个 CPU 吗？
我正在使用 t1.micro 实例，它只有 1 个 cpu，linux“top”命令报告的负载为 100%。当负载 >= 65% 时，警报设置为将实例增加 1。 AutoScaler 如何确定实际的实例负载？
警报具有阈值和超过此阈值触发的周期数。 cloudwatch 控制台中有方便的图表，可以帮助您了解正在发生的事情

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

【解决方案1】：

[这是评论而非答案]

您可以在 aws cli 中使用 set-alarm-state 来触发警报

aws cloudwatch set-alarm-state --alarm-name "myalarm" --state-value ALARM --state-reason "testing purposes"

这样您就可以轻松地测试它们。如果您仍然有问题，那么也许您可以发布输出

aws cloudwatch describe-alarms --alarm-names "myalarm"

【讨论】：

【解决方案2】：

注意：两个实例的平均负载应该超过 65%，然后才会启动新实例。因此，在您的情况下，两个实例的负载必须超过 65%。只有这样 AutoScaling Group 才会启动一个新实例。

您可以使用 BeesWithMachineGuns、Loadrunner 和其他负载测试工具等工具来增加服务器的负载，使其超过 65%。

建议：检查您在 Cloudwatch 指标上的服务器负载，而不是从服务器内部（使用顶部）。这将使您清楚地了解 AWS 如何计算您的实例负载。

【讨论】：