使用 Amazon CloudWatch 警报 - Amazon CloudWatch
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

使用 Amazon CloudWatch 警报

您可以在 中创建指标警报复合警报CloudWatch。

  • 指标警报监控单个 CloudWatch 指标,或基于 CloudWatch 指标监控数学表达式的结果。警报根据指标或表达式在多个时间段内相对于某阈值的值执行一项或多项操作。操作可以是向 Amazon SNS 主题发送通知,执行 Amazon EC2 操作或 Auto Scaling 操作,或创建 Systems Manager OpsItem。

  • 复合警报包括一个规则表达式,该表达式考虑您已创建的其他警报的警报状态。只有当规则的所有条件都得到满足时,复合警报才会进入 ALARM(警报)状态。在复合警报的规则表达式中指定的警报可以包括指标警报和其他复合警报。

    使用复合警报可以减少警报噪音。您可以创建多个指标警报,还可以创建复合警报并仅为复合警报设置警报。例如,只有当所有底层指标警报都处于 ALARM(警报)状态时,复合警报才可能进入 ALARM(警报)状态。

    复合警报可以在其更改状态时发送 Amazon SNS 通知,并在其进入 ALARM 状态时创建 Systems Manager OpsItems,但无法执行 EC2 操作或 Auto Scaling 操作。

您可以向 CloudWatch 控制面板添加警报,并以可视化方式监控它们。当某个警报位于控制面板上时,如果它处于 ALARM 状态,则会变成红色,便于您主动监控其状态。

警报仅在警报改变状态时调用操作。例外情况是包含 Auto Scaling 操作的警报。对于 Auto Scaling 操作,警报将继续每分钟调用一次操作,警报将保持新状态。

注意

CloudWatch 不会测试或验证您指定的操作,也不会检测因试图调用不存在的操作而导致的任何 Amazon EC2 Auto Scaling 或 Amazon SNS 错误。请确保您的警报操作存在。

指标警报状态

指标警报可能具有以下几种状态:

  • OK – 指标或表达式在定义的阈值范围内。

  • ALARM – 指标或表达式超出定义的阈值。

  • INSUFFICIENT_DATA – 警报刚刚启动,指标不可用,或者指标没有足够的数据以确定警报状态。

评估警报

创建警报时,您指定三个设置,以支持 CloudWatch 评估何时更改警报状态:

  • Period (时间段) 是为创建警报的各个数据点而对该指标或表达式进行评估的时间长度。它以秒为单位。如果选择一分钟作为周期,则警报每分钟评估一次指标。

  • 评估期 是确定警报状态时要评估的最近评估期或数据点的数量。

  • Datapoints to Alarm (触发警报的数据点数) 是评估期内为使警报变为 ALARM 状态而必须超出阈值的数据点数。超出阈值的数据点不必是连续的,它们只需都在最近的几个(具体数目等于评估期)数据点之内。

在下图中,指标警报的警报阈值设置为三个单位。Evaluation Period (评估期)Datapoints to Alarm (触发警报的数据点数) 均为 3。也就是说,如果最近三个连续评估期中的所有现有数据点都高于阈值,则警报将变为 ALARM 状态。在该图中,在第三个到第五个时间段发生了这种情况。在第六个时间段,值下降到阈值以下,因此其中一个时间段未超出阈值,并且警报状态恢复为 OK。 在第九个时间段内,再次超出阈值,但仅在一个周期内超出阈值。因此,警报状态保持为 OK


        触发警报的警报阈值

当您将 Evaluation Periods (评估期)Datapoints to Alarm (触发警报的数据点数) 配置为不同的值时,您将设置“M out of N”警报。 Datapoints to Alarm (触发警报的数据点数) 为 (“M”),Evaluation Periods (评估期) 为 (“N”)。评估间隔等于数据点数乘以评估期时长。例如,如果为 1 分钟的评估期配置 4 个数据点( 最大为 5 个数据点),则评估间隔为 5 分钟。如果为 10 分钟的评估期配置 3 个数据点(最大为 3 个数据点),则评估间隔为 30 分钟。

注意

如果创建警报后不久便有数据点缺失,并且该指标在您创建警报之前便已报告给 CloudWatch,则 CloudWatch 在评估警报时会检索从创建警报之前算起的最近数据点。

配置 CloudWatch 警报处理缺失数据的方式

有时,并非指标的每个预期数据点都会报告给 CloudWatch。例如,当连接中断、服务器出现故障或指标设计为仅间歇性地报告数据时,可能会发生这种情况。

您可以通过 CloudWatch 指定在评估警报时如何处理缺失的数据点。这可帮助您配置警报,使其仅在适合所监控的数据类型时进入 ALARM 状态。您可以在缺失数据不表示出现问题时避免误报。

与每个警报始终处于三种状态之一类似,向 CloudWatch 报告的每个特定数据点将属于以下三个类别之一:

  • 未超出 (在阈值范围内)

  • 超出 (超出阈值)

  • 缺失

对于每个警报,您可以指定 CloudWatch 将缺失数据点视为以下任一项:

  • notBreaching – 将缺失数据点视为“良好”,并在阈值范围内

  • breaching – 将缺失数据点视为“不好”,并超出阈值

  • ignore – 保持当前警报状态

  • missing – 如果缺少警报评估范围中的所有数据点,则警报将转换为 INSUFFICIENT_DATA。

最佳选择取决于指标的类型。对于持续报告数据的指标(例如,实例的 CPUUtilization),您可能希望将缺失数据点视为 breaching,因为它们可能表示出现了问题。但是,对于仅在出现错误时生成数据点的指标(例如 ThrottledRequests 中的 Amazon DynamoDB),您应将缺失数据视为 notBreaching。 默认行为是 missing

为您的警报选择最佳选项可防止不必要和误导性的警报条件更改,还可以更准确地指示您的系统的运行状况。

在数据缺失时如何评估警报状态

每当警报评估是否更改状态时,CloudWatch 都会尝试检索比指定为 Evaluation Periods (评估期) 的数量更多的数据点。它尝试检索的数据点的确切数量取决于警报期限长度,以及它是基于标准分辨率指标,还是基于高分辨率指标。它尝试检索的数据点的时间范围是评估范围

一旦 CloudWatch 检索这些数据点,便会发生以下情况:

  • 如果评估范围内的数据点没有缺失,CloudWatch 将根据最近收集的数据点来评估警报。评估的数据点数等于警报的评估期。不需要评估范围中更远处返回的额外数据点,并且这些数据点将被忽略。

  • 如果评估范围内的一些数据点缺失,但从评估范围内成功检索的现有数据点的总数等于或超过警报的 Evaluation Periods (评估期),则 CloudWatch 将根据已成功检索的最新真实数据点评估警报状态,包括评估范围内较远的必需额外数据点。在此情况下,您针对如何处理缺失数据而设置的值便没有必要,并且将被忽略。

  • 如果评估范围内的一些数据点缺失,并且检索到的实际数据点数低于警报的 Evaluation Periods (评估期) 数量,则 CloudWatch 将使用您为如何处理缺失数据指定的结果填充缺失数据点,然后评估警报。但是,评估范围内的所有真实数据点都包含在评估中。CloudWatch 尽可能少地使用缺失数据点。

注意

该行为的一种特殊情况是,在指标流停止后的一段时间内,CloudWatch 警报可能会反复重新评估最后一组数据点。如果警报在指标流即将停止之前更改了状态,这种重新评估可能会导致警报更改状态并重新执行操作。要缓解此行为,请使用较短时间段。

下表阐明了警报评估行为的示例。在第一个表中,Datapoints to Alarm (触发警报的数据点数)Evaluation Periods (评估期) 均为 3。CloudWatch 在评估警报时会检索最近的 5 个数据点,以防最近的 3 个数据点中有一些数据点缺失。5 是警报的评估范围。

列 1 显示最近的 5 个数据点,因为评估范围为 5。这些数据点与右侧的最新数据点一起显示。0 是未超出阈值的数据点,X 是超出阈值的数据点,而 - 是缺失数据点。

第 2 列显示 3 个必需数据点中有多少个缺失。即使评估了最近的 5 个数据点,也只需要 3 个(Evaluation Periods (评估期间) 的设置)来评估警报状态。第 2 列中的数据点数是必须“填写”的数据点数(使用有关处理丢失数据的方式的设置)。

在 3-6 列中,列标题是处理缺失数据可能的值。这些列中的行显示了为处理缺失数据的每个可能方法设置的警报状态。

数据点 必须填充的数据点数 MISSING IGNORE BREACHING NOT BREACHING

0 - X - X

0

OK

OK

OK

OK

- - - - 0

2

OK

OK

OK

OK

- - - - -

3

INSUFFICIENT_DATA

保留当前状态

ALARM

OK

0 X X - X

0

ALARM

ALARM

ALARM

ALARM

- - X - -

2

ALARM

Retain current state

ALARM

OK

在上表的第二行中,即使将缺失数据视为超出阈值,警报也会保持 OK 状态,因为一个现有的数据点未超出阈值,并且该数据点与两个被视为超出阈值的缺失数据点一起进行评估。下次评估此警报时,如果数据仍缺失,它将转到 ALARM,因为未超出阈值的数据点将不再在评估范围内。

第三行(所有 5 个最新数据点都缺失)说明了处理缺失数据的各种设置如何影响警报状态。如果缺失数据点被视为超出阈值,警报将进入 ALARM 状态,而如果警报被视为未超出阈值,则警报将进入 OK 状态。如果忽略缺失数据点,则警报将保留缺失数据点之前具有的当前状态。此外,如果仅将缺失数据点视为缺失,则警报没有足够的最新真实数据进行评估,并进入 INSUFFICIENT_DATA。

在第四行中,警报在所有情况下都会变为 ALARM 状态,因为最近的三个数据点超出阈值,并且警报的 Evaluation Periods (评估期)Datapoints to Alarm (触发警报的数据点数) 均设置为 3。在这种情况下,将忽略缺失数据点,并且不需要有关如何评估缺失数据的设置,因为有 3 个实际数据点需要评估。

第 5 行表示警报评估的特殊情况,称为预置警报状态。有关更多信息,请参阅避免提前转换到警报状态

在下一个表中,Period (时间段) 再次设置为 5 分钟,并且 Datapoints to Alarm (触发警报的数据点数) 为 2,而 Evaluation Periods (评估期) 为 3。这是“N 中的 M”警报,其中 M 为 2,N 为 3。

评估范围为 5。这是最近检索到的数据点的最大数目,可以在某些数据点丢失的情况下使用这些数据点。

数据点 缺失数据点数 MISSING IGNORE BREACHING NOT BREACHING

0 - X - X

0

ALARM

ALARM

ALARM

ALARM

0 0 X 0 X

0

ALARM

ALARM

ALARM

ALARM

0 - X - -

1

OK

OK

ALARM

OK

- - - - 0

2

OK

OK

ALARM

OK

- - - - X

2

ALARM

保留当前状态

ALARM

OK

在第 1 行和第 2 行中,警报始终变为“警报”状态,因为有 3 个最新数据点中的 2 个数据点超出阈值。在第 2 行中,不需要评估范围中的两个最旧数据点,因为三个最近数据点都不能缺失,因此这两个较旧的数据点将被忽略。

在第 3 行和第 4 行中,只有当缺失数据被视为超出阈值时,警报才会进入“警报”状态,在这种情况下,两个最新的缺失数据点将被视为超出阈值。在第 4 行中,这两个被视为超出阈值的缺失数据点提供两个必需的超出阈值数据点来触发 ALARM 状态。

第 5 行表示警报评估的特殊情况,称为预置警报状态。有关更多信息,请参阅以下部分。

避免提前转换到警报状态

CloudWatch 警报评估包括尝试避免误报的逻辑,即在数据间歇性时,警报提前进入 ALARM(警报)状态。上一节的表中第 5 行中显示的示例说明了此逻辑。在这些行中,在以下示例中,Evaluation Periods (评估期) 为 3,评估范围为 5 个数据点。Datapoints to Alarm (触发警报的数据点数) 为 3,但 M 示例除外,其中 Datapoints to Alarm (触发警报的数据点数) 为 2。

假设警报的最新数据为 - - - - X,带有四个缺失数据点,然后有一个超出阈值的数据点作为最新数据点。由于下一个数据点可能不超出阈值,因此当数据为 - - - - X- - - X -Datapoints to Alarm (触发警报的数据点数) 为 3 时,警报不会立即进入 ALARM 状态。这样,当下一个数据点未超出阈值并导致数据成为 - - - X O- - X - O 时,可以避免误报。

但是,如果最后几个数据点为 - - X - -,则警报将进入 ALARM 状态,即使缺失数据点被视为缺失也是如此。这是因为,当评估期内最早的可用超出阈值数据点至少与 Datapoints to Alarm (触发警报的数据点数) 值一样旧,并且所有其他更新的数据点超出阈值或丢失时,警报将始终进入 ALARM 状态。在这种情况下,即使可用的数据点总数低于 M(Datapoints to Alarm (触发警报的数据点数)),警报也会进入 ALARM 状态。

此警报逻辑也适用于 N 个警报中的 M 个。如果 Evaluation Periods (评估期) 数量期间最早的超出阈值数据点至少与 Evaluation Periods (评估期) 的值一样旧,并且所有较新的数据点超出阈值或丢失,则警报将进入 ALARM 状态,而无论 M 值如何(Datapoints to Alarm (触发警报的数据点))。

高精度警报

如果对高精度指标设置警报,您可以指定 10 秒或 30 秒时间段的高精度警报,也可以设置 60 秒的任意倍数时间段的定期警报。高精度警报的费用较高。有关高精度指标的更多信息,请参阅发布自定义指标

针对数学表达式的警报

您可以针对基于一个或多个 CloudWatch 指标的数学表达式的结果设置警报。用于警报的数学表达式可以包含多达 10 个指标。每个指标都必须使用相同的时间段。

对于基于数学表达式的警报,您可以指定您希望 CloudWatch 在评估警报时如何对待基础指标的缺失数据点。

基于数学表达式的警报无法执行 Amazon EC2 操作。

有关指标数学表达式和语法的更多信息,请参阅使用指标数学

基于百分位数的 CloudWatch 警报和小数据样本

当您将某个百分位数设置为某个警报的统计数据时,您可以指定在没有数量足以进行有效的统计评估的数据时执行什么操作。您仍然可以选择让警报评估统计数据,并可以更改警报状态。或者,您也可以让警报在样本大小过小时忽略指标,并等到有足够的数据来实现统计显着性时对样本进行评估。

对于介于 0.5(含)和 1.00(不含)之间的百分位数,将在评估期内数据点的数量少于 10/(1 个百分位)时使用此设置。例如,如果 p99 百分位上某个警报的样本数少于 1000 个,则会使用此设置。对于 0 和 0.5(不含)之间的百分位数,当数据点的数量少于 10/百分位数时,将使用此设置。

CloudWatch 警报的常见功能

以下功能适用于所有 CloudWatch 警报:

  • 您最多可以为每个 AWS 账户在每个区域中创建 5000 个警报。要创建或更新警报,请使用 CloudWatch 控制台、PutMetricAlarm API 操作或 中的 put-metric-alarmAWS CLI 命令。

  • 警报名称必须仅包含 ASCII 字符。

  • 您可以使用 CloudWatch 控制台、DescribeAlarms API 操作或 中的 describe-alarms 命令列出任何或所有当前配置的警报,并列出处于特定状态的任何警报。AWS CLI

  • 您可以使用 CloudWatch 控制台、DisableAlarmActions 和 API 操作或 EnableAlarmActions 中的 disable-alarm-actionsenable-alarm-actions 命令禁用和启用警报。AWS CLI

  • 您可以使用 中的 SetAlarmState API 操作或 set-alarm-state 命令将警报设置为任何状态来测试警报。AWS CLI此短暂状态变更只会持续到下一个警报比较发生之时。

  • 您可以在创建自定义指标之前为该自定义指标创建警报。为了使警报有效,必须在警报定义中包含自定义指标的所有维度以及指标命名空间和指标名称。为此,您可以使用 PutMetricAlarm API 操作或 中的 put-metric-alarmAWS CLI 命令。

  • 您可以使用 CloudWatch 控制台、DescribeAlarmHistory API 操作或 中的 describe-alarm-history 命令查看警报的历史记录。AWS CLI 将警报历史记录保留两周。CloudWatch每个状态转换都标有一个唯一的时间戳。个别情况下,一个状态变更的历史记录可能显示多个通知。通过时间戳可以确认独特的状态变更。

  • 警报的评估期数乘以每个评估期的长度不能超过一天。

注意

在特定情况下,某些 AWS 资源不会向 CloudWatch 发送指标数据。

例如,Amazon EBS 可能不会发送未附加到 Amazon EC2 实例的可用卷的指标数据,因为该卷没有要监控的指标活动。如果为此类指标设置了警报,您可能会注意到其状态更改为 INSUFFICIENT_DATA。 这可能表示您的资源处于不活动状态,并不一定意味着出现了问题。您可以指定每个警报如何处理丢失数据。有关更多信息,请参阅配置 CloudWatch 警报处理缺失数据的方式