# 配置 CloudWatch 告警处理缺失数据的方式
<a name="alarms-and-missing-data"></a>

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

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

与每个告警始终处于三种状态之一类似，向 CloudWatch 报告的每个特定数据点将属于以下三个类别之一：
+ 未违例（在阈值范围内）
+ 违例（超出阈值）
+ 缺失

对于每个告警，您可以指定 CloudWatch 将缺失数据点视为以下任一项：
+ `notBreaching` – 将缺失数据点视为“良好”，并在阈值范围内
+ `breaching` – 将缺失数据点视为“不良”，并超出阈值
+ `ignore`（忽略）– 保持当前告警状态
+ `missing`（缺失）– 如果告警评估范围内的所有数据点都缺失，则告警将转变为“INSUFFICIENT\$1DATA（数据不足）”状态。

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

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

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

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

## 在数据缺失时如何评估告警状态
<a name="alarms-evaluating-missing-data"></a>

每当告警评估是否更改状态时，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\$1DATA（数据不足）”状态。

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

第 5 行表示告警评估的特殊情况，称为*提前告警状态*。有关更多信息，请参阅 [避免提前转换到告警状态](#CloudWatch-alarms-avoiding-premature-transition)。

在下一个表中，**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 行表示告警评估的特殊情况，称为*提前告警状态*。有关更多信息，请参阅下文。

### 避免提前转换到告警状态
<a name="CloudWatch-alarms-avoiding-premature-transition"></a>

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 告警中缺失的数据
<a name="mi-missing-data-treatment"></a>

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

 就配置的缺失数据处理而言，缺失数据场景及其对告警评估的影响与标准指标告警相同。请参阅 [配置 CloudWatch 告警处理缺失数据的方式](#alarms-and-missing-data)。

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

Metrics Insights 告警的缺失数据场景发生在以下情况下：
+  时间序列中的单个数据点不存在。
+  对多个时间序列进行评估时，出现一个或多个时间序列消失的情况。
+  查询未检索到任何时间序列。

 缺失数据场景通过以下方式影响告警评估：
+  为了评估时间序列，会对时间序列中的每个数据点进行缺失数据处理。例如，如果针对时间序列查询了 3 个数据点，但实际只收到了 1 个数据点，则接下来将按照所配置的缺失数据配置来补全 2 个数据点。
+  如果查询不再检索到时间序列，则无论对缺失数据进行何种处理，该时间序列都将转换为 `OK`。与贡献者级别上的 `OK` 转换相关的告警操作已执行，并且 `StateReason` 指明上述贡献者并未被找到，并附带了这样一条消息：“针对此贡献者未返回任何数据”。告警的状态将取决于被查询检索到的其他贡献者的状态。
+  在告警级别，如果查询返回空结果（即根本没有时间序列），则无论设置了哪种缺失数据处理，告警都将转换为 `INSUFFICIENT_DATA`。