因此,我一直在尝试调整我的自动缩放配置和 Cloudwatch 警报,试图让所有实例保持平稳而不是咆哮。
我似乎无法摆脱这种不断反复的循环。CPU 使用率上升,引入一个实例,CPU 使用率下降,终止一个实例。反复进行。
我目前以 3 x 1 分钟间隔的平均 CPU >= 40% 为依据设置警报。也许我可以根据其他情况设置?CPU 是一个棘手的问题,因为当此图出现峰值(高)时,我可以看到一些实例有空闲的 CPU,因此平均值被单个实例提高了。
我发现有些人的请求数是 502,而我的请求数是 200。显然我希望这个数字保持一致,并且不要总是出现这种峰值。
提前致谢。
编辑1:我已经将 Cloudwatch 指标调整为 2 分钟内 CPU 使用率为 20%,并且还发现了一个 nginx 错误可能也归因于一些额外的负载。当前图表如下所示。
编辑2:负载监控所以好多了。请参阅下面的负载警报。我收到警报的频率大大降低,一切都运行得更加顺畅。
这是我每分钟在 cron 中运行的操作;
/usr/local/bin/aws cloudwatch put-metric-data --namespace="NS" --metric-name="GroupLoad" --value `cat /proc/loadavg | awk '{print $1}'` --dimensions AutoScalingWebGroup=NS-WebGroup
答案1
而不是基于 AutoScaling中央处理器尝试服务器负载。
AWS AutoScaling 可以对任何 CloudWatch 指标进行操作,并且您可以编写自己的自定义 CloudWatch 指标。
有关 AutoScaling 如何工作的更多信息:http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/as-scale-based-on-demand.html
创建自定义指标
http://aws.amazon.com/blogs/aws/amazon-cloudwatch-user-defined-metrics/
CloudWatch 指标的范围在命名空间内,并可进一步限定最多 10 个维度。例如,可以跟踪一对应用程序(“App1”和“App2”)的延迟,同时保持值彼此隔离:
$ mon-put-data -namespace App1 -metric-name Latency -value 104
$ mon-put-data -namespace App2 -metric-name Latency -value 120