所以我一直在使用Python中的Boto尝试基于CPUUtilization配置自动调节，或多或少与此示例中指定的完全相同： http://boto.readthedocs.org/en/latest/autoscale_tut.html
然而，CloudWatch中的两个警报都只报告：
州详细信息：州于2012/11/12更改为“INSUFFICIENT_DATA” 16:30 UTC原因：未选中：初始警报创建
自动缩放工作正常，但警报根本没有获取任何CPUUtilization数据。对于我可以尝试的任何想法？
编辑：实例本身报告CPU利用率数据，当我尝试在CloudWatch中以编程方式在python或界面中创建警报时。为了以防万一，还启用了详细的监控......
谢谢！
答案 0 :(得分：11)
来自AWS的official answer如下：
嗨，过渡到INSUFFICIENT_DATA存在固有的延迟 状态（仅）作为警报等待一段时间来补偿 度量生成延迟。对于具有60秒周期的警报， 转换到I_D状态之前的延迟将在5到10之间 分钟。
约翰。
显然这是一个临时状态，可能会自行解决。
答案 1 :(得分：5)
我不确定后端发生了什么，但是如果您比较警报历史记录，您将看到AWS删除“单位”列，如果您只是修改警报而没有任何更改，因为at7000ft说。因此，请删除脚本的单位列。
答案 2 :(得分：3)
确保警报的命名空间为“AWS / EC2”。
我知道这是在原始问题之后的很长一段时间，但是如果其他人通过Google发现这个问题，我遇到了同样的问题，结果我错误地设置了警报的命名空间。
答案 3 :(得分：2)
需要使用用于创建警报的相同单位发布数据。如果您没有指定一个，则它将是<None>单位。
可以使用aws put-metric-data
aws-put-metric-alarm和--unit <value>中指定单位
单位<value>可以是：
单位也区分大小写，请在脚本中小心。
对于CPUUtilization，您可以使用百分比。
将第一个数据集发送到您的警报后（非详细监控实例最多可能需要5分钟），警报将切换到OK或ALARM状态而不是INSUFFICIENT_DATA状态。
答案 4 :(得分：1)
我在CloudWatch中显示相同的INSUFFICIENT_DATA警报状态以获取RDS CPUUtilization＆gt;使用CloudFormation创建了60个警报。 （“原因：未选中：初始警报创建”显示在详细信息下）。这是一个非常粗略的修复但我发现通过选择警报，单击修改按钮，然后单击保存按钮（不更改任何内容），警报进入OK状态，一切都是文件。
答案 5 :(得分：1)
我有这个问题。确保用于创建警报的度量标准名称与实际度量标准名称匹配。
您可以使用以下网址列出指标：
aws cloudwatch list-metrics --namespace=<NAMESPACE, e.g. System/Linux, etc>
查找指标和MetricName。确保为该指标配置了警报。
答案 6 :(得分：1)
据我所知，默认度量标准分辨率是5分钟（如果您付费可以降低到1分钟，或者类似的话），所以如果您的闹钟的测量时间段低于此值，那么它将永久保持INSUFFICIENT_DATA状态。在我的情况下，我对CPU利用率进行了1分钟的测量，并将其更改为5分钟，这已经解决了状态问题。
答案 7 :(得分：0)
目录/ var / tmp / aws-mon /包含几个文件。一个是instance-id。我所使用的实例是从AMI创建的，该文件保留了旧的实例ID。我刚编辑它并确保/ var / tmp / aws-mon / placement / availability-zone也是正确的。警报几乎立即变为OK。
答案 8 :(得分：0)
我遇到了类似的问题，我的警报一直处于INSUFFICIENT_DATA状态，尽管我可以在GUI中看到指标。
出现这种情况，因为我在创建警报时为度量指定了错误的单位。没有报告任何错误，但它从未成为绿色。
如果您不确定，最好避免指定它，AWS将在后台进行正确的匹配。
答案 9 :(得分：0)
也遇到了此问题，但由于另一个原因：我在Cloudformation模板中通过了ES群集ARN而不是域名。真令人沮丧