Amazon EC2 Auto Scaling CPU 利用率警报 - 数据不足

Posted 2023-03-04

【中文标题】Amazon EC2 Auto Scaling CPU 利用率警报 - 数据不足

【英文标题】：Amazon EC2 AutoScaling CPUUtilization Alarm- INSUFFICIENT DATA

【发布时间】：2012-11-01 04:06:43

【问题描述】：

所以我一直在 Python 中使用 Boto 来尝试配置基于 CPUUtilization 的自动缩放，或多或少与此示例中指定的完全一致： http://boto.readthedocs.org/en/latest/autoscale_tut.html

但是 CloudWatch 中的两个警报都只报告：

状态详情：状态于 2012 年 11 月 12 日更改为“INSUFFICIENT_DATA” 世界标准时间 16:30。原因：未选中：初始警报创建

自动缩放工作正常，但警报根本没有获取任何 CPUUtilization 数据。有什么我可以尝试的想法吗？

编辑：实例本身报告 CPU 利用率数据，只是当我尝试在 CloudWatch 中以编程方式在 python 中或在界面中创建警报时却没有。还启用了详细监控以防万一...

谢谢！

【问题讨论】：

不幸的是，我可以让我的警报工作的唯一方法是在 AWS 控制台中构建它，使用 CLI 获取所有属性，然后将这些属性复制到 CloudFormation - 我不认为文档仅此一项就足以直接进入 CloudFormation 或类似领域。

【参考方案1】：

来自 AWS 的 official answer 是这样的：

您好，转换为 INSUFFICIENT_DATA 存在固有延迟 状态（仅）作为警报等待一段时间以补偿 指标生成延迟。对于 60 秒周期的警报， 转换到 I_D 状态之前的延迟将在 5 到 10 之间 分钟。

约翰。

显然这是一个临时状态，很可能会自行解决。

【讨论】：

一整天都是这样 - 已经与 AWS 支持聊天了几个小时，但他们无处可去...

呃！好吧，你知道它是如何处理该死的指标生成延迟的......希望我能提供更多帮助。

【参考方案2】：

我不确定后端发生了什么，但是如果您比较警报历史记录，您会看到 AWS 删除了“单位”列，如果您只是修改警报而不进行任何更改，如 at7000ft 所说。所以删除脚本的单位列。

【讨论】：

这是使用 C# sdk 唯一对我有用的东西 - 必须删除 'Unit = StandardUnit.Seconds' - 然后一切正常

【参考方案3】：

确保警报的命名空间是“AWS/EC2”。

我知道这是在最初的问题之后很长时间，但如果其他人通过谷歌找到这个问题，我遇到了同样的问题，结果证明我设置了警报的命名空间不正确。

【讨论】：

+1 这真的很重要。如果没有该警报，则会陷入 INSUFFICIENT_DATA 状态。谢谢！

【参考方案4】：

需要发布与创建警报相同的单位的数据。如果您没有指定一个，它将是一个<None> 单位。

单位可以在aws put-metric-data和aws-put-metric-alarm中指定--unit <value>

单位<value>可以是：

秒 字节 位 百分比 计数 字节/秒（每秒字节数） 比特/秒（比特每秒） Count/Second（每秒计数） 无（未指定单位时的默认值）

单位也是区分大小写的，请在脚本中注意这一点。

对于 CPUUtilization，您可以使用百分比。

将第一个数据集发送到您的警报后（对于未详细监控的实例，最多可能需要 5 分钟），警报将切换到 OK 或 ALARM 状态，而不是 INSUFFICIENT_DATA 状态。

【参考方案5】：

对于使用 CloudFormation 创建的 RDS CPUUtilization > 60 警报，我在 CloudWatch 中显示了相同的 INSUFFICIENT_DATA 警报状态。 （“原因：未选中：初始警报创建”显示在详细信息下）。这是一个非常粗略的修复，但我发现通过选择警报，单击修改按钮，然后单击保存按钮（不更改任何内容），警报进入 OK 状态并且一切都是文件。

【参考方案6】：

我遇到了这个问题。确保您用于创建警报的指标名称与实际指标名称匹配。

您可以列出您的指标：

aws cloudwatch list-metrics --namespace=<NAMESPACE, e.g. System/Linux, etc>

找到指标和 MetricName。确保为该指标配置了警报。

【参考方案7】：

据我所知，默认公制分辨率为 5 分钟（如果您付费或类似情况，可以降低到 1 分钟），因此如果您的闹钟的测量周期低于此值，那么它会保留永久处于INSUFFICIENT_DATA 状态。在我的例子中，我有一个 1 分钟的 CPU 利用率测量周期，将其更改为 5 分钟可以解决状态问题。

【参考方案8】：

我遇到了类似的问题，虽然我可以在 GUI 中看到指标，但我的警报一直处于 INSUFFICIENT_DATA 状态。

出现这种情况，因为我在创建警报时为指标指定了错误的单位。没有报告错误，但它从未变为绿色。

如果您不确定，最好避免指定它，AWS 会在后台进行正确的匹配。

【参考方案9】：

有一个目录 /var/tmp/aws-mon/ 包含几个文件。一个是实例 ID。我所在的实例是从 AMI 创建的，该文件保留了旧的实例 ID。我刚刚对其进行了编辑并确保 /var/tmp/aws-mon/placement/availability-zone 也是正确的。警报几乎立即变为 OK。

【参考方案10】：

也遇到了这个问题，但出于不同的原因：我在 Cloudformation 模板中传递了 ES 集群 ARN 而不是域名。很郁闷