配置 CloudWatch 告警处理缺失数据的方式 - Amazon CloudWatch
在数据缺失时如何评估告警状态CloudWatch Metrics Insights 告警中缺失的数据

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

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

您可以通过 CloudWatch 指定在评估告警时如何处理缺失的数据点。这可帮助您对告警进行配置，使其仅在适合所监控的数据类型时变为 ALARM（告警）状态。您可以避免在缺失数据没有指示问题时进行误报。

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

  • 未违例（在阈值范围内）

  • 违例（超出阈值）

  • 缺失

对于每个告警，您可以指定 CloudWatch 将缺失数据点视为以下任一项：

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

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

  • ignore（忽略）– 保持当前告警状态

  • missing（缺失）– 如果告警评估范围内的所有数据点都缺失，则告警将转变为“INSUFFICIENT_DATA（数据不足）”状态。

最佳选择取决于指标的类型和警报的用途。例如，如果您使用持续报告数据的指标创建应用程序回滚警报，您可能需要将缺失数据点视为超出阈值，因为它可能表示出错了。但对于仅在错误发生时生成数据点的指标（如 Amazon DynamoDB 中的 ThrottledRequests），应将缺失数据视为 notBreaching。默认行为是 missing。

重要

如果缺失指标数据点，则在 Amazon EC2 指标上配置的警报可能会暂时进入 INSUFFICIENT_DATA 状态。这种情况很少见，但在指标报告中断时可能会发生，即使在 Amazon EC2 实例运行正常的情况下也是如此。对于配置为采取停止、终止、重启或恢复操作的 Amazon EC2 指标的警报，我们建议您将这些警报配置为将缺失的数据视为 missing，并使这些警报仅在处于 ALARM 状态时被触发。

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

重要

评估 AWS/DynamoDB 命名空间中的指标的告警默认会忽略缺失的数据。如果您为告警处理缺失数据的方式选择了不同选项，则可以覆盖此选项。当 AWS/DynamoDB 指标包含缺失数据时，评估该指标的告警仍将保持其当前状态。

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

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

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

  • 如果评估范围内的数据点没有缺失，CloudWatch 将根据最近收集的数据点来评估告警。评估的数据点数等于告警的 Evaluation Periods（评估期）。在评估范围内，不需要额外的数据点，因此它们将被忽略。

  • 如果评估范围内的一些数据点缺失，但是从评估范围内成功检索的现有数据点的总数等于或超过告警的 Evaluation Periods（评估期），则 CloudWatch 将根据已成功检索的最近现有数据点来评估告警状态，包括从更远的评估范围内获得的必要的额外数据点。在此情况下，您针对如何处理缺失数据而设置的值便没有必要，并且将被忽略。

  • 如果评估范围内的一些数据点缺失，并且检索的实际数据点数量少于 Evaluation Periods（评估期）的告警数量，则 CloudWatch 将在缺失数据点中填写您针对如何处理缺失数据而指定的结果，然后评估该告警。但是，评估范围内的所有实时数据点都包含在评估中。CloudWatch 尽可能少地使用缺失数据点。

注意

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

下表阐明了告警评估行为的示例。在第一个表中，Datapoints to Alarm（触发告警的数据点数）和 Evaluation Periods（评估期）均为 3。CloudWatch 在评估告警时会检索最近的 5 个数据点，以防最近的 3 个数据点中的某些数据点丢失。5 为告警的评估范围。

由于评估范围为 5，因此第 1 列显示最近的 5 个数据点。数据点显示为：右侧为最近的数据点，0 是未违例数据点，X 是违例数据点，而 - 是缺失数据点。

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

在第 3 – 6 列中，列标题是如何处理缺少数据的可能值。这些列中显示了为处理缺失数据的每种可能方法设置的告警状态。

数据点 必须填写的数据点数 缺失 忽略 违例 未违例

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

保留当前状态

ALARM

OK

在上表的第二行中，即使将缺失数据视为违例，告警也会保持 OK（正常）状态，因为一个现有的数据点未违例，并且该数据点与两个被视为违例的缺失数据点一起进行评估。下次评估该告警时，如果数据仍缺失，它将变为 ALARM（告警）状态，因为未违例数据点不再处于评估范围内。

第三行（所有五个最新数据点都缺失）说明了缺失数据处理方式的各种设置对告警状态的影响。如果缺失的数据点被视为违例，告警将进入“ALARM（告警）”状态，而如果它们被视为未违例，则告警进入“OK（正常）”状态。如果忽略缺少的数据点，告警将保留缺失数据点之前的当前状态。如果缺少的数据点被认为已缺失，则告警没有足够的最新真实数据来进行评估，并变为“INSUFFICIENT_DATA（数据不足）”状态。

在第四行，告警转到 ALARM（告警）状态，因为三个最近的数据点违例，而告警的 Evaluation Periods（评估期）和 Datapoints to Alarm（触发告警的数据点数）都设为 3。在这种情况下，缺失的数据点将被忽略，并且不需要缺失数据评估方式的设置，因为有 3 个实际数据点需要评估。

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

在下一个表中，Period（时间段）再次设置为 5 分钟，并且 Datapoints to Alarm（触发告警的数据点数）为 2，而 Evaluation Periods（评估期）为 3。这是 2（最大为 3），M（最大为 N）告警。

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

数据点 缺失数据点数 缺失 忽略 违例 未违例

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 行中，告警始终处于“ALARM（告警）”状态，因为 3 个最近的数据点中有 2 个违例。在第 2 行中，不需要评估范围内的两个最早的数据点，因为 3 个最近的数据点中无一缺失，因此这两个较旧的数据点将被忽略。

在第 3 行和第 4 行中，只有当缺失的数据被视为违例时，告警才会进入“ALARM（告警）”状态，在这种情况下，两个最近丢失的数据点都被视为违例。在第 4 行中，这两个被视为违例的缺失数据点提供了两个触发“ALARM（告警）”状态所必要的违例数据点。

第 5 行表示告警评估的特殊情况，称为提前告警状态。有关更多信息，请参阅下文。

避免提前转换到告警状态

CloudWatch 告警评估包括用于尝试避免误报的逻辑，当数据出现间歇性时，告警会提前进入告警状态。上一节表中的第 5 行中显示的示例说明了这种逻辑。在这些行中，以及在以下示例中，Evaluation Periods（评估期）为 3，评估范围为 5 个数据点。Datapoints to Alarm（触发告警的数据点数）为 3，M（最大为 N）示例除外，其中 Datapoints to Alarm（触发告警的数据点数）为 2。

假设告警的最新数据是 - - - - X，其中有四个缺失的数据点，然后一个违例数据点作为最新的数据点。由于下一个数据点可能未违例，因此当数据处于 - - - - X 或者 - - - X -，且 Datapoints to Alarm（触发告警的数据点数）为 3 时，告警不会立即进入“ALARM（告警）”状态。这样，当下一个数据点未违例并导致数据为 - - - X O 或者 - - X - O 时，误报得以避免。

但是，如果最后几个数据点是 - - X - -，即使缺失的数据点被视为缺失，告警也会进入“ALARM（告警）”状态。这是因为根据告警的设计，当在数据点数量 Evaluation Periods（评估期）间最早的可用的违例数据点至少与 Datapoints to Alarm（触发告警的数据点数）的值同样早，并且所有其他较新的数据点都违例或缺失时，告警都会进入“ALARM（告警）”状态。在这种情况下，即使可用数据点的总数小于 M（Datapoints to Alarm（触发告警的数据点数）），告警也会进入“ALARM（告警）”状态。

此告警逻辑也适用于 M（最大为 N）告警。如果评估范围内最早的违例数据点至少与 Datapoints to Alarm（触发告警的数据点数）的值同样早，并且所有最新的数据点均违例或缺失，则无论 M 值（Datapoints to Alarm（触发告警的数据点数））如何，告警都会进入“ALARM（告警）”状态。

CloudWatch Metrics Insights 告警中缺失的数据

基于聚合到单个时间序列的 Metrics Insights 查询的告警

就配置的缺失数据处理而言，缺失数据场景及其对告警评估的影响与标准指标告警相同。请参阅 配置 CloudWatch 告警处理缺失数据的方式。

基于 Metrics Insights 查询的告警，会生成多个时间序列

Metrics Insights 告警的缺失数据场景发生在以下情况下：

  • 时间序列中的单个数据点不存在。

  • 对多个时间序列进行评估时，出现一个或多个时间序列消失的情况。

  • 查询未检索到任何时间序列。

缺失数据场景通过以下方式影响告警评估：

  • 为了评估时间序列，会对时间序列中的每个数据点进行缺失数据处理。例如，如果针对时间序列查询了 3 个数据点，但实际只收到了 1 个数据点，则接下来将按照所配置的缺失数据配置来补全 2 个数据点。

  • 如果查询不再检索到时间序列，则无论对缺失数据进行何种处理，该时间序列都将转换为 OK。与贡献者级别上的 OK 转换相关的告警操作已执行，并且 StateReason 指明上述贡献者并未被找到，并附带了这样一条消息：“针对此贡献者未返回任何数据”。告警的状态将取决于被查询检索到的其他贡献者的状态。

  • 在告警级别，如果查询返回空结果（即根本没有时间序列），则无论设置了哪种缺失数据处理，告警都将转换为 INSUFFICIENT_DATA。