所以，我一直在使用博托在Python基于CPU利用率，如本例中指定或多或少与尝试，并配置自动缩放： http://boto.readthedocs.org/en/latest/autoscale_tut.html
然而，在双方的CloudWatch警报只报告：
状态详细信息：状态变为“INSUFFICIENT_DATA”在二零一二年十一月十二日16:30 UTC。 原因：未选中：初始创建报警
自动缩放工作正常，但警报并不拿起任何CPU利用率数据。 任何想法的东西，我可以试试吗？
编辑：实例本身报告的CPU利用率数据，只是没有当我尝试创建CloudWatch的警报，编程在python或接口。 详细的监控也被激活以防万一......
谢谢！
在官方的回答从AWS是这样的：
您好，有在转换到状态INSUFFICIENT_DATA（仅）作为报警等待一段时间，以补偿度量产生延迟的固有延迟。 对于具有60秒期间的警报，过渡到I_D状态之前的延迟将是5和10分钟之间。
约翰。
显然，这是一种临时状态，可能会自行解决。
我不知道发生了什么事在后端，但如果你比较报警历史记录，您将看到AWS删除“单位”栏，如果你只是修改报警没有任何变化at7000ft说。 所以删除脚本的单位列。
确保报警的命名空间是“AWS / EC2”。
我知道这是原来的问题后，很长一段时间，但在其他情况下，通过谷歌找到这一点，我有同样的问题，它原来我设置报警的命名空间不正确。
它需要与用于创建报警同一单位发布的数据。 如果没有指定，这将是一个<None>单位。
单元可以在规定的aws put-metric-data和aws-put-metric-alarm与--unit <value>
单元<value>可以是：
单位也区分大小写的，要小心约在您的脚本。
对于CPU利用率，可以使用百分比。
第一个数据集被发送到你的报警后（这可能需要长达5分钟无详细信息的监控实例），报警器就会切换到正常或报警状态，而不是INSUFFICIENT_DATA之一。
我有同样的INSUFFICIENT_DATA报警状态显示在CloudWatch的与CloudFormation创建RDS的CPU利用率> 60报警。 （“原因：未选中：初始报警创作”下的细节显示出来）。 这是一个非常粗略的修复，但我发现，通过选择报警，点击修改按钮，然后保存按钮（在不改变任何东西）警报响起到OK状态，一切文件。
我有这个问题。 请确保您使用创建报警的指标名称实际指标名称相匹配。
您可以列出您的指标有：
aws cloudwatch list-metrics --namespace=<NAMESPACE, e.g. System/Linux, etc>
查找在公制和MetricName。 确保您的报警配置为该指标。
据我所知，缺省度量分辨率为5分钟（可降低到如果你付出了1分钟，或者类似的东西），所以如果你报警的测量周期比低，那么它会永久的留INSUFFICIENT_DATA状态。 就我而言，我对CPU利用率1分钟测量周期，并更改到5分钟以上的固定状态的问题。
有一个目录/ var / tmp目录/ AWS-MON /包含几个文件。 一个是实例的编号。 我是在实例是从一个AMI创建这个文件保留了旧的实例ID。 我刚刚编辑它，并确保在/ var / tmp目录/ AWS-MON /位置/可用性区也是正确的。 报警变成OK几乎瞬间。
我有一个类似的问题，我的闹钟是不断INSUFFICIENT_DATA状态，虽然我可以看到在GUI的度量。
出来这一点，因为我指定了错误的单位进行度量，当我创建了警钟。 报道没有错误回来，但它从来没有成为绿色。
更好地避免指定它，如果你不知道，和AWS会做正确的匹配的背景。
也碰到了这个问题，但出于不同的原因：我通过ES集群ARN，而不是域名在我Cloudformation模板。 这是非常令人沮丧
