【问题标题】:Amazon EC2 AutoScaling CPUUtilization Alarm- INSUFFICIENT DATAAmazon EC2 Auto Scaling CPU 利用率警报 - 数据不足
【发布时间】: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 或类似领域。

标签: amazon-ec2 amazon-web-services boto autoscaling amazon-cloudwatch


【解决方案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-dataaws-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 而不是域名。很郁闷

              【讨论】:

                猜你喜欢
                • 2021-05-21
                • 2018-11-18
                • 2017-11-08
                • 2011-11-22
                • 2011-11-24
                • 1970-01-01
                • 2018-04-16
                • 2011-12-14
                • 2018-09-23
                相关资源
                最近更新 更多