# 概念 CloudWatch 告警会监控各项指标，并在阈值被突破时触发相应操作。了解告警如何评估数据和对条件进行响应对于有效监控至关重要。 **Topics** + [告警数据查询](alarm-data-queries.md) + [告警评估](alarm-evaluation.md) + [PromQL 警报](alarm-promql.md) + [复合警报](alarm-combining.md) + [告警操作](alarm-actions.md) + [告警静音规则](alarm-mute-rules.md) + [限制](alarm-limits.md) # 告警数据查询 CloudWatch 告警可以监控各种数据来源。根据您的监控需求选择适当的查询类型。 ## 指标 监控单个 CloudWatch 指标。这是跟踪资源性能的最常见告警类型。有关指标的更多信息，请参阅 [CloudWatch 指标概念](cloudwatch_concepts.md)。 有关更多信息，请参阅 [根据静态阈值创建 CloudWatch 告警](ConsoleAlarms.md)。 ## 指标数学 您可以针对基于一个或多个 CloudWatch 指标的数学表达式的结果设置告警。用于告警的数学表达式可以包含多达 10 个指标。每个指标都必须使用相同的时间段。 对于基于数学表达式的告警，您可以指定您希望 CloudWatch 如何对待缺失数据点。在这种情况下，如果数学表达式没有返回该数据点的值，则认为该数据点缺失。 基于数学表达式的告警无法执行 Amazon EC2 操作。 有关指标数学表达式和语法的更多信息，请参阅 [将数学表达式与 CloudWatch 指标结合使用](using-metric-math.md)。 有关更多信息，请参阅 [根据指标数学表达式创建 CloudWatch 告警](Create-alarm-on-metric-math-expression.md)。 ## 指标洞察 CloudWatch Metrics Insights 查询支持使用类 SQL 语法进行大规模指标查询。您可以针对任何 Metrics Insights 查询创建告警，包括返回多个时间序列的查询。此功能极大地扩展了监控选择。在基于 Metrics Insights 查询创建告警时，该告警会随着受监控资源组中资源的增减而自动调整。只需创建一次告警，任何符合查询定义和筛选条件的资源都会在其相应指标可用时加入告警监控范围。对于多时间序列查询，每个返回的时间序列都会成为告警的影响因素，从而实现更精细且更具动态的监控。 以下是 CloudWatch Metrics Insights 告警的两个主要使用案例： + 异常检测与聚合监控 基于返回单个聚合时间序列的 Metrics Insights 查询创建告警。此方法适用于监控基础设施或应用程序聚合指标的动态告警场景。例如，您可以监控所有实例的最大 CPU 使用率，且告警阈值会随着实例集的扩展自动调整。 要创建聚合监控告警，请使用以下查询结构： ``` SELECT FUNCTION(metricName) FROM SCHEMA(...) WHERE condition; ``` + 按资源的实例集监控 创建一个可监控多个时间序列的告警，其中每个时间序列都作为一个影响因素独立运行，并拥有各自的状态。当任何影响因素进入“ALARM”状态，告警就会激活，从而触发资源特定的操作。例如，监控多个 RDS 实例之间的数据库连接，防止连接被拒绝。 要监控多个时间序列，请使用以下查询结构： ``` SELECT AVG(DatabaseConnections) FROM AWS/RDS WHERE condition GROUP BY DBInstanceIdentifier ORDER BY AVG() DESC; ``` 创建多时间序列告警时，查询中必须包含两个关键子句： + 一个 `GROUP BY` 子句，用于定义如何构造时间序列及确定查询将生成的时间序列数量 + 一个 `ORDER BY` 子句，用于对指标进行确定性排序，使告警能够首先评估最重要的信号 这些子句对于准确评估告警至关重要。`GROUP BY` 子句会将数据拆分为独立的时间序列（例如按实例 ID 拆分），而 `ORDER BY` 子句可确保这些时间序列在告警评估期间按优先顺序得到一致处理。 有关如何创建多时序告警的更多信息，请参阅 [基于多时间序列 Metrics Insights 查询创建告警](multi-time-series-alarm.md)。 ## 日志组指标筛选条件 您可以根据日志组指标筛选条件创建告警。使用指标筛选条件，您可以在日志数据发送到 CloudWatch 时查找其中的字词和模式。有关更多信息，请参阅《Amazon CloudWatch Logs 用户指南》中的 [使用筛选条件从日志事件创建指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)**。 有关如何根据日志组指标筛选条件创建告警的更多信息，请参阅 [根据日志触发警报](Alarm-On-Logs.md)。 ## PromQL 您可以创建一个警报，该警报使用 Prometheus 查询语言（PromQL）即时查询来监控通过 CloudWatch OTLP 端点摄取到的指标。 有关 PromQL 警报的工作原理的更多信息，请参阅 [PromQL 警报](alarm-promql.md)。 有关如何创建 PromQL 警报的更多信息，请参阅[使用 PromQL 查询创建警报](Create_PromQL_Alarm.md)。 ## 外部数据来源 您可以创建警报，监控源自非 CloudWatch 中的数据来源的指标。有关创建与这些其他数据来源的连接的更多信息，请参阅[查询源自其他数据来源的指标](MultiDataSourceQuerying.md)。 有关如何根据连接的数据来源创建告警的更多信息，请参阅 [基于连接的数据来源创建警报](Create_MultiSource_Alarm.md)。 # 告警评估 ## 指标告警状态 指标告警可能具有以下几种状态： + `OK` – 指标或表达式在定义的阈值范围内。 + `ALARM` – 指标或表达式超出定义的阈值。 + `INSUFFICIENT_DATA`（数据不足） – 告警刚刚启动，指标不可用，或者指标没有足够的数据以确定告警状态。 ## 告警评估状态 除了告警状态外，每个告警都有一个评估状态，用于提供告警评估过程的相关信息。可能会出现以下状态： + `PARTIAL_DATA`：表示由于配额限制，无法检索到所有可用数据。有关更多信息，请参阅 [如何处理部分数据](cloudwatch-metrics-insights-alarms-partial-data.md)。 + `EVALUATION_ERROR`：表示告警设置中存在需要审查和更正的配置错误。有关更多详细信息，请参阅告警的 StateReason 字段。 + `EVALUATION_FAILURE`：表示 CloudWatch 出现临时问题。我们建议在问题得到解决之前进行手动监控 您可以在控制台的告警详细信息中查看评估状态，也可以使用 `describe-alarms` CLI 命令或 `DescribeAlarms` API 来查看评估状态。 ## 告警评估设置 创建告警时，请指定三个设置，以启用 CloudWatch 评估在何时更改告警状态： + **时间段**是为了创建警报的各个数据点，而评估指标或表达式所用的时间长度。它以秒为单位。 + **Evaluation Periods（评估期）**是确定告警状态时要评估的最近时间段或数据点的数量。 + **Datapoints to Alarm（触发告警的数据点数）**是评估期内必须违例才能触发告警变为 `ALARM`（告警）状态的数据点数量。超出阈值的数据点不必是连续的，但它们必须全部在等于 **Evaluation Period**（评估期）的最近几个数据点范围内。 对于任何一分钟或更长的时间段，每分钟评估一次告警，评估基于**周期**和**评估周期**定义的时段。例如，如果**周期**为 5 分钟（300 秒），**评估周期**为 1，则在第 5 分钟结束时，告警将根据从 1 到 5 分钟的数据进行评估。然后，在第 6 分钟结束时，根据第 2 分钟到 6 分钟的数据对告警进行评估。 如果警报周期为 10 秒、20 秒或 30 秒，则每 10 秒评估一次警报。有关更多信息，请参阅 [高精度告警](#high-resolution-alarms)。 如果评估周期数乘以每个评估周期的长度得到的结果超过一天，则每小时评估一次警报。有关如何评估此类多天告警的更多详细信息，请参阅 [评估多天警报的示例](#evaluate-multiday-alarm)。 在下图中，指标告警的阈值设置为三个单位。**Evaluation Periods（评估期）**和 **Datapoints to Alarm（触发告警的数据点数）**均为 3。也就是说，在最近三个连续评估期中的所有现有数据点都高于阈值时，告警就会变为 `ALARM`（告警）状态。在该图中，在第三个到第五个时间段发生了这种情况。在第六个时间段，数值降至阈值以下，因此其中一个时间段被评估为未违例，且告警状态恢复为 `OK`（正常）。在第九个时间段，再次超出阈值，但仅一个时间段超出阈值。因此，告警状态保持为 `OK`（正常）。 ![\[触发告警的阈值\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/alarm_graph.png) 在将 **Evaluation Periods（评估期）**和 **Datapoints to Alarm（触发告警的数据点数）**配置为不同的值时，您将设置“M（最大为 N）”告警。**告警的数据点数**为（“M”），**评估期**为（“N”）。评估周期是指评估次数乘以每个周期长度所得的数值。例如，如果为 1 分钟的评估期配置 4 个数据点（最大为 5 个数据点），则评估间隔为 5 分钟。如果为 10 分钟的评估期配置 3 个数据点（最大为 3 个数据点），则评估间隔为 30 分钟。 **注意** 如果创建告警后不久便有数据点缺失，并且该指标在您创建告警之前便已报告给 CloudWatch，则 CloudWatch 在评估告警时会检索从创建告警之前算起的最近数据点。 ## 高精度告警 如果对高精度指标设置告警，则您可以指定 10 秒、20 秒或 30 秒时长的高精度告警。高精度告警的费用较高。有关高精度指标的更多信息，请参阅 [发布自定义指标](publishingMetrics.md)。 ## 评估多天警报的示例 如果评估周期数乘以每个评估周期的长度得到的结果超过一天，则警报为多天警报。多天警报每小时评估一次。在评估多天警报时，CloudWatch 在评估时仅考虑截至当前小时 00 分的指标。 例如，假设有一个警报会监测每隔 3 天在 10:00 运行一次的作业。 1. 10:02，作业失败 1. 在 10:03，警报会进行评估并保持 `OK` 状态，原因是评估只考虑截至 10:00 的数据。 1. 在 11:03，警报会考虑 11:00 之前的数据并转为 `ALARM` 状态。 1. 您在 11:43 更正了错误，作业现在成功运行。 1. 12:03，警报再次进行评估，检测到作业正在成功运行，然后返回到 `OK` 状态。 # 配置 CloudWatch 告警处理缺失数据的方式 有时，并非指标的每个预期数据点都会报告到 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` 指标包含缺失数据时，评估该指标的告警仍将保持其当前状态。 ## 在数据缺失时如何评估告警状态 每当告警评估是否更改状态时，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 行表示告警评估的特殊情况，称为*提前告警状态*。有关更多信息，请参阅下文。 ### 避免提前转换到告警状态 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 告警处理缺失数据的方式](#alarms-and-missing-data)。 **基于 Metrics Insights 查询的告警，会生成多个时间序列** Metrics Insights 告警的缺失数据场景发生在以下情况下： + 时间序列中的单个数据点不存在。 + 对多个时间序列进行评估时，出现一个或多个时间序列消失的情况。 + 查询未检索到任何时间序列。 缺失数据场景通过以下方式影响告警评估： + 为了评估时间序列，会对时间序列中的每个数据点进行缺失数据处理。例如，如果针对时间序列查询了 3 个数据点，但实际只收到了 1 个数据点，则接下来将按照所配置的缺失数据配置来补全 2 个数据点。 + 如果查询不再检索到时间序列，则无论对缺失数据进行何种处理，该时间序列都将转换为 `OK`。与贡献者级别上的 `OK` 转换相关的告警操作已执行，并且 `StateReason` 指明上述贡献者并未被找到，并附带了这样一条消息：“针对此贡献者未返回任何数据”。告警的状态将取决于被查询检索到的其他贡献者的状态。 + 在告警级别，如果查询返回空结果（即根本没有时间序列），则无论设置了哪种缺失数据处理，告警都将转换为 `INSUFFICIENT_DATA`。 # 如何处理部分数据 ## 如何评估 Metrics Insights 查询的部分数据 如果用于告警的 Metrics Insights 查询匹配的指标超过 10,000 个，则根据该查询找到的前 10,000 个指标评估告警。这意味着根据部分数据评估告警。 您可以使用以下方法来确定 Metrics Insights 告警目前是否正在根据部分数据评估其告警状态： + 在控制台中，如果您选择一个告警来查看 **Details**（详细信息）页面，则该页面上会显示 **Evaluation warning: Not evaluating all data**（评估警告：未评估所有数据）消息。 + 当您使用 [describe-alarms](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/describe-alarms.html?highlight=describe%20alarms) AWS CLI 命令或 [DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html) API 时，您会在 `EvaluationState` 字段中看到值 `PARTIAL_DATA`。 当 Amazon EventBridge 进入部分数据状态时，告警还会将事件发布到 Amazon EventBridge，这样您就可以创建 EventBridge 规则来监视这些事件。在这些事件中，`evaluationState` 字段的值为 `PARTIAL_DATA`。示例如下： ``` { "version": "0", "id": "12345678-3bf9-6a09-dc46-12345EXAMPLE", "detail-type": "CloudWatch Alarm State Change", "source": "aws.cloudwatch", "account": "123456789012", "time": "2022-11-08T11:26:05Z", "region": "us-east-1", "resources": [ "arn:aws:cloudwatch:us-east-1:123456789012:alarm:my-alarm-name" ], "detail": { "alarmName": "my-alarm-name", "state": { "value": "ALARM", "reason": "Threshold Crossed: 3 out of the last 3 datapoints [20000.0 (08/11/22 11:25:00), 20000.0 (08/11/22 11:24:00), 20000.0 (08/11/22 11:23:00)] were greater than the threshold (0.0) (minimum 1 datapoint for OK -> ALARM transition).", "reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2022-11-08T11:26:05.399+0000\",\"startDate\":\"2022-11-08T11:23:00.000+0000\",\"period\":60,\"recentDatapoints\":[20000.0,20000.0,20000.0],\"threshold\":0.0,\"evaluatedDatapoints\":[{\"timestamp\":\"2022-11-08T11:25:00.000+0000\",\"value\":20000.0}]}", "timestamp": "2022-11-08T11:26:05.401+0000", "evaluationState": "PARTIAL_DATA" }, "previousState": { "value": "INSUFFICIENT_DATA", "reason": "Unchecked: Initial alarm creation", "timestamp": "2022-11-08T11:25:51.227+0000" }, "configuration": { "metrics": [ { "id": "m2", "expression": "SELECT SUM(PartialDataTestMetric) FROM partial_data_test", "returnData": true, "period": 60 } ] } } } ``` 如果告警查询包含的 GROUP BY 语句最初返回 500 个以上的时间序列，则将根据该查询找到的前 500 个时间序列对告警进行评估。但是，如果您使用的是 ORDER BY 子句，则将对该查询找到的所有时间序列进行排序，并根据您的 ORDER BY 子句，将具有最高值或最低值的前 500 个时间序列用于评估告警。 ## 如何评估来自多数据来源告警的部分数据 如果 Lambda 函数返回部分数据： + 继续根据返回的数据点来对警报进行评估。 + 您可以使用以下方法来确定 Lambda 函数目前是否正在根据部分数据评估其警报状态： + 在控制台中，选择警报，然后选择**详细信息**页面。如果该页面上显示**评估警告：未评估所有数据**，则表示正在对部分数据进行评估。 + 如果您在使用 `describe-alarms` AWS CLI 命令或 DescribeAlarms API 时在 `EvaluationState` 字段中看到值 `PARTIAL_DATA`，则表示正在对部分数据进行评估。 + 警报在进入部分数据状态时，其还会将事件发布到 Amazon EventBridge。 # 基于百分位数的告警和小数据样本 当您将某个百分位数设置为某个告警的统计数据时，您可以指定在没有数量足以进行有效的统计评估的数据时所执行的操作。您仍然可以选择让告警评估统计数据，并可以更改告警状态。或者，您也可以让告警在样本大小过小时忽略指标，并等到有足够的数据来实现统计显着性时对样本进行评估。 对于介于 0.5（含）和 1.00（不含）之间的百分位数，将在评估期内数据点的数量少于 10/（1 个百分位）时使用此设置。例如，如果 p99 百分位上某个告警的样本数少于 1000 个，则会使用此设置。对于 0 和 0.5（不含）之间的百分位数，当数据点的数量少于 10/百分位数时，将使用此设置。 # PromQL 警报 PromQL 警报使用 Prometheus 查询语言（PromQL）即时查询来监控指标。该查询选择通过 CloudWatch OTLP 端点摄取到的指标，该查询返回的所有匹配时间序列都被视为违规。警报会定期评估查询，并以*贡献者*的身份独立跟踪每个违规的时间序列。 有关使用 OpenTelemetry 摄取指标的信息，请参阅 [OpenTelemetry](CloudWatch-OpenTelemetry-Sections.md)。 ## PromQL 警报的工作原理 PromQL 警报按照 `EvaluationInterval` 定义的周期性计划评估 PromQL 即时查询。该查询仅返回满足条件的时间序列。返回的每个时间序列都是*贡献者*，由其唯一的属性集标识。 警报使用基于持续时间的状态转换： + 如果查询返回贡献者，该贡献者将被视为*违规*。如果该贡献者在 `PendingPeriod` 指定的持续时间内继续违规，则会转换为 `ALARM` 状态。 + 如果查询停止返回贡献者，该贡献者将被视为*恢复*。如果贡献者在 `RecoveryPeriod` 指定的持续时间内一直缺席，则会转换回 `OK` 状态。 当至少有一名贡献者违规的时间超过待处理周期限时，警报将处于 `ALARM` 状态。所有贡献者都恢复后，警报将恢复为 `OK` 状态。 ## PromQL 警报配置 PromQL 警报配置有以下参数： + **PendingPeriod** 是贡献者在转换为 `ALARM` 状态之前必须持续违规的时间（以秒为单位）。这相当于 Prometheus 警报规则的 `for` 持续时间。 + **RecoveryPeriod** 是贡献者在转换回 `OK` 状态之前必须停止违规的持续时间（以秒为单位）。这相当于 Prometheus 警报规则的 `keep_firing_for` 持续时间。 + **EvaluationInterval** 是警报评估 PromQL 查询的频率（以秒为单位）。 要创建 PromQL 警报，请参阅[使用 PromQL 查询创建警报](Create_PromQL_Alarm.md)。 # 复合警报 借助 CloudWatch，您可以将多个警报组合成一个*复合警报*，从而针对整个应用程序或一组资源创建汇总的运行状况聚合指标。复合警报可通过监控其他警报的状态来确定其状态。您可以定义规则，以使用布尔逻辑来组合这些受监控警报的状态。 您可以仅在聚合级别执行操作，使用复合警报来减少警报噪音。例如，您可以创建一个复合警报，在触发任何与 Web 服务器相关的警报时向 Web 服务器团队发送通知。当其中任何一个警报进入“ALARM”状态时，复合警报会自行进入“ALARM”状态，并向您的团队发送通知。如果与您的 Web 服务器相关的其他警报也进入“ALARM”状态，则您的团队不会收到过多的新通知，因为复合警报已经将当前情况告知团队成员。 您还可以使用复合警报来创建复杂的警报条件，并仅在满足许多不同条件时才执行操作。例如，您可以创建一个复合警报，将 CPU 警报和内存警报结合在一起，并且只有在 CPU 和内存警报都触发时才通知您的团队。 **使用复合警报** 使用复合警报时，您有两个选项： + 配置您只想在复合警报级别执行的操作，并在不执行任何操作的情况下创建底层受监控警报 + 在复合警报级别配置一组不同的操作。例如，如果问题普遍存在，复合警报操作可能会让其他团队参与进来。 复合警报仅可执行以下操作： + 通知 Amazon SNS 主题 + 调用 Lambda 函数 + 在 Systems Manager Ops Center 中创建 OpsItems + 在 Systems Manager Incident Manager 中创建事件 **注意** 复合警报中的所有基础警报都必须与复合警报位于相同的账户和区域中。但是，如果您在 CloudWatch 跨账户可观测性监控账户中设置复合告警，则基础告警可以监视不同源账户和该监控账户本身的指标。有关更多信息，请参阅 [CloudWatch 跨账户可观测性](CloudWatch-Unified-Cross-Account.md)。 单个复合告警可以监控 100 个基础告警，150 个复合告警可以监控单个基础告警。 **规则表达式** 所有复合告警都包含规则表达式。规则表达式告诉复合告警要监控哪些其他告警并确定其状态。规则表达式可以同时引用指标告警和复合告警。当您在规则表达式中引用告警时，您可以为告警指定一个函数，用于确定告警将处于以下三种状态中的哪一种： + 告警 如果告警处于 ALARM 状态，则 ALARM ("alarm-name or alarm-ARN") 为 TRUE。 + OK 如果告警处于 OK 状态，则 OK ("alarm-name or alarm-ARN") 为 TRUE。 + INSUFFICIENT\$1DATA 如果指定的告警处于 INSUFFICIENT\$1DATA 状态，则 INSUFFICIENT\$1DATA ("alarm-name or alarm-ARN") 为 TRUE。 **注意** TRUE 始终计算为 TRUE，FALSE 始终计算为 FALSE。 **警报引用** 引用警报时，无论是使用警报名称还是 ARN，规则语法都支持在警报名称或 ARN 两侧带或不带引号 (")。 + 如果指定时不带引号，则警报名称或 ARN 不得包含空格、圆括号或逗号。 + 如果指定时带引号，则*包含*双引号 (") 的警报名称或 ARN 必须使用反斜杠转义字符 (\$1) 将 " 括起来，以便正确解释引用。 **语法** 用于将多个警报组合成一个复合警报的表达式语法，基于布尔逻辑和函数。下表描述了规则表达式中可用的运算符和函数： | 运算符/函数 | 说明 | | --- | --- | | AND | 逻辑 AND 运算符。当所有指定条件均为 TRUE 时，返回 TRUE。 | | OR | 逻辑 OR 运算符。当至少一个指定条件为 TRUE 时，返回 TRUE。 | | NOT | 逻辑 NOT 运算符。当指定条件为 FALSE 时，返回 TRUE。 | | AT\$1LEAST | 当达到最低数量或特定百分比的指定警报处于所需状态时，会返回 TRUE 的函数。格式：AT\$1LEAST(M, STATE\$1CONDITION, (alarm1, alarm2, ...alarmN))，其中 M 可以是绝对数字或百分比（例如 50%），STATE\$1CONDITION 可以是 ALARM、OK、INSUFKIENT\$1DATA、NOT ALARM、NOT OK 或 NOT INSUFFICIENT\$1DATA。 | 您可以使用圆括号对条件进行分组，以控制复杂表达式中的评估顺序。 **表达式示例** 请求参数 `AlarmRule` 支持使用逻辑运算符 `AND`、`OR` 和 `NOT`，以及 `AT_LEAST` 函数，这样您就可以将多个函数组合成一个表达式。以下示例表达式显示了如何在复合告警中配置基础告警： + `ALARM(CPUUtilizationTooHigh) AND ALARM(DiskReadOpsTooHigh)` 该表达式指定复合告警仅在 `CPUUtilizationTooHigh` 和 `DiskReadOpsTooHigh` 处于 `ALARM` 状态时进入 `ALARM` 状态。 + `AT_LEAST(2, ALARM, (WebServer1CPU, WebServer2CPU, WebServer3CPU, WebServer4CPU))` 该表达式规定，当 4 个 Web 服务器 CPU 警报中至少有 2 个处于 `ALARM` 状态时，复合警报将进入 `ALARM` 状态。这样，您就可以根据受影响资源的阈值触发警报，而无需要求所有资源或仅一个资源处于警报状态。 + `AT_LEAST(50%, OK, (DatabaseConnection1, DatabaseConnection2, DatabaseConnection3, DatabaseConnection4))` 该表达式规定，当至少 50% 的数据库连接警报处于 `OK` 状态时，复合警报会进入 `ALARM` 状态。使用百分比，可在添加或删除受监控警报时动态调整规则。 + `ALARM(CPUUtilizationTooHigh) AND NOT ALARM(DeploymentInProgress)` 该表达式指定复合告警在 `CPUUtilizationTooHigh` 处于 `ALARM` 且 `DeploymentInProgress` 处于 `ALARM` 状态时进入 `ALARM` 状态。这是一个复合告警的示例，它降低了部署时段内的告警噪音。 + `AT_LEAST(2, ALARM, (AZ1Health, AZ2Health, AZ3Health)) AND NOT ALARM(MaintenanceWindow)` 该表达式规定，如果 3 个可用区运行状况警报中至少有 2 个处于 `ALARM` 状态，并且维护时段警报不处于 `ALARM` 状态，复合警报将进入 `ALARM` 状态。此例将 AT\$1LEAST 函数与其他逻辑运算符结合，可用于更复杂的监控场景。 # 警报抑制 复合告警动作抑制功能使您能够暂时禁用告警动作，而无需删除或修改告警配置。这在计划内维护、部署或调查已知问题时非常有用。 通过复合告警操作抑制，您可以将告警定义为抑制器告警。抑制器告警可防止复合告警采取行动。例如，您可以指定表示支持资源状态的抑制器告警。如果支持资源关闭，则抑制器告警会阻止复合告警发送通知。 ## 何时使用告警抑制 适合使用告警抑制的常见情况： + 应用程序的维护窗口 + 应用程序部署 + 正在进行的事件调查 + 测试和开发活动 ## 抑制器告警的工作原理 您可以在配置复合告警时指定抑制器告警。任何告警都可以用作抑制器告警。当抑制器告警的状态从 `OK` 变为 `ALARM` 时，其复合告警停止执行操作。当抑制器告警的状态从 `ALARM` 变为 `OK` 时，其复合告警恢复执行操作。 复合警报允许您在多个警报中获得运行状况的聚合视图，因此存在一些预计会触发这些警报的常见情况。例如，在应用程序的维护时段或调查正在发生的事件时。在这种情况下，您可能需要抑制复合警报的操作，以防止不必要的通知或创建新的事件工单 通过复合告警操作抑制，您可以将告警定义为抑制器告警。抑制器告警可防止复合告警采取行动。例如，您可以指定表示支持资源状态的抑制器告警。如果支持资源关闭，则抑制器告警会阻止复合告警发送通知。复合告警操作抑制功能可帮助您降低警报噪音，从而减少管理告警的时间，将更多的时间集中在操作上。 您可以在配置复合告警时指定抑制器告警。任何告警都可以用作抑制器告警。当抑制器告警的状态从 `OK` 变为 `ALARM` 时，其复合告警停止执行操作。当抑制器告警的状态从 `ALARM` 变为 `OK` 时，其复合告警恢复执行操作。 ### `WaitPeriod` 和 `ExtensionPeriod` 指定抑制器告警时，需要设置参数 `WaitPeriod` 和 `ExtensionPeriod`。这些参数可防止复合告警在抑制器告警改变状态时意外执行操作。使用 `WaitPeriod` 补偿当抑制器告警从 `OK` 变为 `ALARM` 时发生的任何延迟。例如，如果抑制器告警在 60 秒内从 `OK` 变为 `ALARM`，则将 `WaitPeriod` 设置为 60 秒。 ![\[WaitPeriod 内的操作抑制\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/example1border.png) 在图像中，复合告警在 t2 时从 `OK` 变为 `ALARM`。`WaitPeriod` 在 t2 时开始并在 t8 时结束。这使抑制器告警有时间在 t4 时从状态 `OK` 变为 `ALARM`，然后在 `WaitPeriod` 在 t8 时到期时抑制复合告警的操作。 使用 `ExtensionPeriod` 补偿当抑制器告警变为 `OK` 后复合告警变为 `OK` 时发生的任何延迟。例如，如果复合告警在抑制器告警变为 `OK` 的 60 秒内变为 `OK`，则将 `ExtensionPeriod` 设置为 60 秒。 ![\[ExtensionPeriod 内的操作抑制\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/example2border.png) 在图像中，抑制器告警在 t2 时从 `ALARM` 变为 `OK`。`ExtensionPeriod` 在 t2 时开始并在 t8 时结束。这使得复合告警有时间从 `ALARM` 变为 `OK`，然后 `ExtensionPeriod` 在 t8 时到期。 复合告警在 `WaitPeriod` 和 `ExtensionPeriod` 变为活动状态时不执行操作。当 `ExtensionPeriod` 和 `WaitPeriod` 变为非活动状态时，复合告警基于其当前状态执行操作。我们建议您将每个参数的值设置为 60 秒，因为每分钟评估一次指标告警。您可以将参数设置为任意整数（以秒为单位）。 以下示例更详细地描述了 `WaitPeriod` 和 `ExtensionPeriod` 如何防止复合告警意外执行操作。 **注意** 在以下示例中，`WaitPeriod` 配置为 2 个时间单位，`ExtensionPeriod` 配置为 3 个时间单位。 #### 示例 **示例 1：操作在 `WaitPeriod` 后未被抑制** ![\[操作抑制的第一个示例\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/example3border.png) 在图像中，复合告警在 t2 时状态从 `OK` 变为 `ALARM`。`WaitPeriod` 在 t2 时开始并在 t4 时结束，因此它可以阻止复合告警执行操作。`WaitPeriod` 在 t4 时到期后，复合告警会执行操作，因为抑制器告警仍处于 `OK` 状态。 **示例 2：操作在 `WaitPeriod` 到期前被告警抑制** ![\[操作抑制的第二个示例\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/example4border.png) 在图像中，复合告警在 t2 时状态从 `OK` 变为 `ALARM`。`WaitPeriod` 在 t2 时开始并在 t4 时结束。这使抑制器告警有时间在 t3 时从状态 `OK` 变为 `ALARM`。因为抑制器告警的状态在 t3 时从 `OK` 变为 `ALARM`，从 t2 开始的 `WaitPeriod` 将被丢弃，抑制器告警现在会阻止复合告警执行操作。 **示例 3：操作被 `WaitPeriod` 抑制时的状态转换** ![\[操作抑制的第三个示例\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/example5border.png) 在图像中，复合告警在 t2 时状态从 `OK` 变为 `ALARM`。`WaitPeriod` 在 t2 时开始并在 t4 时结束。这使抑制器告警有时间改变状态。复合告警在 t3 时变回 `OK`，所以在 t2 时开始的 `WaitPeriod` 被丢弃。新的 `WaitPeriod` 在 t3 时开始并在 t5 时结束。新的 `WaitPeriod` 在 t5 时到期后，复合告警将执行操作。 **Example 4: State transition when actions are suppressed by alarm**（示例 4：操作被告警抑制时的状态转换） ![\[操作抑制的第四个示例\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/cwasexamplefourborder.png) 在图像中，复合告警在 t2 时状态从 `OK` 变为 `ALARM`。抑制器告警已经处于 `ALARM` 状态。抑制器告警可防止复合告警执行操作。 **示例 5：操作在 `ExtensionPeriod` 后未被抑制** ![\[操作抑制的第五个示例\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/example7border.png) 在图像中，复合告警在 t2 时状态从 `OK` 变为 `ALARM`。`WaitPeriod` 在 t2 时开始并在 t4 时结束。这使抑制器告警有时间在 t3 时从状态 `OK` 变为 `ALARM`，然后在 t6 前抑制复合告警的操作。因为抑制器告警的状态在 t3 时从 `OK` 变为 `ALARM`，从 t2 开始的 `WaitPeriod` 将被丢弃。在 t6 时，抑制器告警变为 `OK`。`ExtensionPeriod` 在 t6 时开始并在 t9 时结束。`ExtensionPeriod` 到期后，复合告警将执行操作。 **示例 6：操作被 `ExtensionPeriod` 抑制时的状态转换** ![\[操作抑制的第六个示例\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/cwasexamplesixrborder.png) 在图像中，复合告警在 t2 时状态从 `OK` 变为 `ALARM`。`WaitPeriod` 在 t2 时开始并在 t4 时结束。这使抑制器告警有时间在 t3 时从状态 `OK` 变为 `ALARM`，然后在 t6 前抑制复合告警的操作。因为抑制器告警的状态在 t3 时从 `OK` 变为 `ALARM`，从 t2 开始的 `WaitPeriod` 将被丢弃。在 t6 时，抑制器告警变回 `OK`。`ExtensionPeriod` 在 t6 时开始并在 t9 时结束。当复合告警在 t7 时变回 `OK` 时，`ExtensionPeriod` 被丢弃，并且新的 `WaitPeriod` 在 t7 时开始并在 t9 时结束。 **提示** 如果您更换操作抑制器告警，则任何活动的 `WaitPeriod` 或 `ExtensionPeriod` 将被丢弃。 ## 动作抑制和静音规则 当针对一个复合告警同时启用动作抑制规则和告警静音规则时，静音规则将优先生效，并会抑制所有告警动作。静音窗口结束后，复合告警的动作抑制配置会根据抑制器告警状态以及所配置的等待或延长时间来决定是否执行相关动作。有关告警静音规则的更多信息，请参阅 [告警静音规则](alarm-mute-rules.md)。 # 告警操作 您可以指定告警在“OK（正常）”、“ALARM（告警）”和“INSUFFICIENT\$1DATA（数据不足）”状态之间更改状态时所执行的操作。 要过渡到这三种状态中的每一种，大多数操作都可以设置。除自动扩缩操作外，这些操作仅在状态转换时会发生，如果该情况持续数小时或数天，则不会再次执行。 以下是受支持的告警操作： + 通过使用 Amazon Simple Notification Service 主题通知一个或多个订阅用户。订阅用户既可以是应用程序，也可以是个人。 + 调用 Lambda 函数。这是在警报状态变化时自动执行自定义操作的最简单方法。 + 基于 EC2 指标的警报还可以执行 EC2 操作，例如停止、终止、重启或恢复 EC2 实例。 + 警报还可以执行操作来扩展自动扩缩组。 + 告警可以在 Systems Manager Ops Center 中创建 OpsItems，或在 AWS Systems Manager Incident Manager 中创建事件。只有在告警进入“ALARM（告警）”状态时才能执行这些操作。 + 警报进入 ALARM 状态时可启动调查。 警报还会在更改状态时向 Amazon EventBridge 发出事件，您可以将 Amazon EventBridge 设置为针对这些状态更改触发其他操作。 ## 告警操作和通知 下表显示了针对各类告警所执行的操作及其在多个时间序列（或贡献者）告警情况下的表现： | 操作类型 | Metrics Insights 多时间序列警报支持 | PromQL 警报支持 | 更多信息 | | --- | --- | --- | --- | | SNS 通知 | 影响因素级别 | 影响因素级别 | [Amazon SNS event destinations](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html) | | EC2 操作（停止、终止、重启、恢复） | 不支持 | 不支持 | [停止、终止、重启或恢复 EC2 实例](UsingAlarmActions.md) | | Auto Scaling 操作 | 不支持 | 不支持 | [Amazon EC2 Auto Scaling 的阶梯式扩展策略与简单扩展策略](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html) | | Systems Manager OpsItem 创建 | 告警级别 | 不支持 | [Configure CloudWatch alarms to create OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) | | Systems Manager Incident Manager 事件 | 告警级别 | 不支持 | [Creating incidents automatically with CloudWatch alarms](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html#incident-tracking-auto-alarms) | | Lambda 函数调用 | 影响因素级别 | 影响因素级别 | [从警报中调用 Lambda 函数](alarms-and-actions-Lambda.md) | | CloudWatch 调查功能调查 | 告警级别 | 不支持 | [从警报启动 CloudWatch 调查](Start-Investigation-Alarm.md) | 警报通知的内容因警报类型而异： + 单指标告警通知内容同时包含状态原因和详细的状态原因数据，会显示导致状态变化的具体数据点。 + Metrics Insights 多时间序列警报会为每个贡献者提供简化的状态原因，不会包含详细状态原因数据块。 + PromQL 警报的通知中不包含状态原因或状态原因数据。 **Example 通知内容示例** 单指标告警通知包含详细的数据： ``` { "stateReason": "Threshold Crossed: 3 out of the last 3 datapoints [32.6 (03/07/25 08:29:00), 33.8 (03/07/25 08:24:00), 41.0 (03/07/25 08:19:00)] were greater than the threshold (31.0)...", "stateReasonData": { "version": "1.0", "queryDate": "2025-07-03T08:34:06.300+0000", "startDate": "2025-07-03T08:19:00.000+0000", "statistic": "Average", "period": 300, "recentDatapoints": [41, 33.8, 32.6], "threshold": 31, "evaluatedDatapoints": [ { "timestamp": "2025-07-03T08:29:00.000+0000", "sampleCount": 5, "value": 32.6 } // Additional datapoints... ] } } ``` 多时间序列 Metrics Insights 告警 SNS 通知（以贡献者为例）： ``` { "AlarmName": "DynamoDBInsightsAlarm", "NewStateValue": "ALARM", "NewStateReason": "Threshold Crossed: 1 datapoint was less than the threshold (1.0). The most recent datapoint which crossed the threshold: [0.0 (01/12/25 13:34:00)].", "StateChangeTime": "2025-12-01T13:42:04.919+0000", "OldStateValue": "OK", "AlarmContributorId": "6d442278dba546f6", "AlarmContributorAttributes": { "TableName": "example-dynamodb-table-name" } // Additional information... } ``` 贡献者的 PromQL 警报 SNS 通知示例： ``` { "AlarmName": "HighCPUUsageAlarm", "NewStateValue": "ALARM", "StateChangeTime": "2025-12-01T13:42:04.919+0000", "OldStateValue": "OK", "AlarmContributorId": "1d502278dcd546a1", "AlarmContributorAttributes": { "team": "example-team-name" } // Additional information... } ``` ## 将告警操作静音 告警静音规则使您能够在预定义的时间窗口（例如维护期间或发生操作事件时）内自动将告警操作静音。CloudWatch 继续监控告警状态，同时阻止不必要的通知。有关更多信息，请参阅 [告警静音规则](alarm-mute-rules.md)。 **静音规则与禁用告警操作** 告警静音规则会在预定时间段内暂时将操作静音，并在窗口结束时自动取消静音。相比之下，`DisableAlarmActions` API 会永久禁用告警操作，直到您手动调用 `EnableAlarmActions`。`EnableAlarmActions` API 不会将由活动静音规则静音的告警取消静音。 **注意** 将告警静音并不会阻止 CloudWatch 向亚 Amazon EventBridge 发送告警创建、更新、删除和状态更改的告警事件。 # 告警静音规则 告警静音规则是 CloudWatch 的一项功能，它为您提供了一种在预定义的时间窗口内自动静音告警操作的机制。当您创建静音规则时，您可以指定特定的时间段，并指定其操作将被静音的目标告警。CloudWatch 将继续监控并评估告警状态，同时防止在预期的操作事件期间出现不必要的通知或自动告警操作。 告警静音规则可帮助您管理关键操作场景，在这些场景中，告警操作可能并非必要或会造成干扰。例如，在计划的维护时段内，您可以阻止自动告警操作，此时您的系统处于有意离线状态或正遭遇预期问题，这样您就可以在不中断的情况下进行维护工作。对于非工作时间（如周末或节假日）的操作，您可以在无需立即做出响应的情况下将非关键的告警操作静音，从而减少告警噪声以及对运营团队的无用通知。在测试环境中，静音规则能让您在负载测试等场景中暂时将告警操作静音。在这些场景中，预期会有较高的资源使用量或较高的错误率，但并不需要立即采取行动。当您的团队积极排除问题时，静音规则可防止重复的告警操作被触发，这有助于您集中精力解决问题，而不会被冗余的告警通知所干扰。 ## 定义告警静音规则 告警静音规则可以通过以下方式定义：**规则**和**目标**。 + **规则**：定义应将告警操作静音的时间窗口。规则由三个属性组成： + **表达式**：定义静音时段何时开始以及如何重复。您可以使用两种类型的表达式： + **Cron 表达式**：使用标准的 cron 语法创建重复的静音窗口。此方法非常适合定期维护计划，例如每周系统更新或每日备份操作。Cron 表达式使您能够指定复杂的重复模式，包括一周中的特定天数、月数或时间。 *cron 表达式的语法* ``` ┌───────────── minute (0 - 59) │ ┌───────────── hour (0 - 23) │ │ ┌───────────── day of the month (1 - 31) │ │ │ ┌───────────── month (1 - 12) (or JAN-DEC) │ │ │ │ ┌───────────── day of the week (0 - 6) (0 or 7 is Sunday, or MON-SUN) │ │ │ │ │ │ │ │ │ │ * * * * * ``` + 所有字段都将支持字符 `*`、`,`、`-`。 + 英文名称可用于 `month`（JAN-DEC）和 `day of week`（SUN-SAT）字段 + **At 表达式**：将 at 表达式用于一次性静音窗口。此方法非常适合在已知时间发生一次的计划内操作事件。 ``` Syntax: `at(yyyy-MM-ddThh:mm)` ``` + **持续时间**：指定静音规则激活后的持续时间。必须以 ISO-8601 格式指定持续时间，最短为 1 分钟（PT1M），最长为 15 天（P15D）。 + **时区**：使用标准时区标识符（例如“America/Los\$1Angeles”或“Europe/London”），指定根据表达式应用静音窗口所在的时区。 + **目标**：指定告警名称列表，其操作将在定义的时间窗口内静音。您可以在目标列表中包括指标告警和复合告警。 您可以选择包含开始和结束时间戳，以为静音窗口提供额外的边界。开始时间戳可确保静音规则不会在特定日期和时间之前激活，而结束时间戳则可防止在指定日期和时间之后应用规则。 有关以编程方式创建告警静音规则的更多信息，请参阅 [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html)。 **注意** 目标告警必须与创建静音规则时处于同一 AWS 账户和同一 AWS 区域中。 一条告警静音规则最多可以按告警名称锁定 100 个告警。 CloudWatch 控制台包含一个专门的“告警静音规则”选项卡，可集中管理您的 AWS 账户中的所有静音规则。您可以使用静音规则属性（如规则名称）搜索特定的静音规则。 ## 静音规则状态 告警静音规则创建后，可以处于以下三种状态之一： + **SCHEDULED**：根据配置的时间窗口表达式，静音规则将在未来的某个时间生效。 + **ACTIVE**：根据配置的时间窗口表达式，静音规则当前处于活动状态，并且正在主动将目标告警操作静音。 + **EXPIRED**：该静音规则未来将不再处于 SCHEDULED 或 ACTIVE 状态。这种情况发生在静音窗口结束后的一次性静音规则中，或者配置了结束时间戳且该时间已过去时的重复静音规则中。 ## 静音规则对告警的影响 在活动的静音窗口期间，当目标告警更改状态并配置了操作时，CloudWatch 会将这些操作静音，使其无法执行。静音仅适用于告警操作，这意味着可以继续评估告警，状态更改在 CloudWatch 控制台中可见，但 Amazon Simple Notification Service 通知、Amazon Elastic Compute Cloud 自动扩缩操作或 Amazon EC2 操作等配置的操作将无法执行。在整个静音期间，CloudWatch 会继续正常评估告警状态，您可以通过告警历史记录查看此信息。 当静音窗口结束时，如果目标告警仍处于告警状态（OK/ALARM/INSUFFICIENT\$1DATA），CloudWatch 会自动重新触发在该窗口期间静音的告警操作。这样可以确保在计划中的静音期结束后，针对持续存在的问题执行告警操作，从而保持监控系统的完整性。 **注意** 将告警静音时： 与目标告警相关的所有操作均会被静音 与所有告警状态（OK、ALARM 和 INSUFFICIENT\$1DATA）关联的操作将被静音 ## 查看和管理已静音的告警 有关查看和管理静音告警的信息，请参阅 [查看和管理已静音的告警](viewing-managing-muted-alarms.md)。 # 告警静音规则的工作原理 以下场景说明了告警静音规则如何影响目标警报，以及告警操作是如何被静音或执行的。 **注意** 将告警静音会使与所有告警状态相关的操作静音，包括 OK、ALARM 和 INSUFFICIENT\$1DATA。下图所示的行为适用于与所有告警状态相关的操作。 当您将 Metrics Insights 告警静音时，该告警的所有贡献者指标系列也会自动被静音。 ## 场景：当静音规则处于活动状态时，告警操作被静音 考虑到 + 告警已针对其 ALARM 状态配置了操作 + 告警静音规则计划在 t1 到 t5 之间处于活动状态，以告警为目标 ![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-1.png) + 在 **t0** 时：告警处于 OK 状态，静音规则状态为 SCHEDULED + 在 **t1** 时：静音规则状态变为 ACTIVE + 在 **t2** 时：告警转换到 ALARM 状态，操作被静音，因为告警已被静音规则有效静音。 + 在 **t4** 时：当静音规则仍处于活动状态时，告警恢复到 OK 状态 + 在 **t5** 时：静音规则变为非活动状态，但由于告警现在处于 OK 状态，因此不会执行任何 ALARM 操作 ## 场景：静音规则处于活动状态时告警动作被静音，并在静音窗口后被重新触发 考虑到 + 告警已针对其 ALARM 状态配置了操作 + 告警静音规则计划在 t1 到 t5 之间处于活动状态，以告警为目标 ![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-2.png) + 在 **t0** 时：告警处于 OK 状态，静音规则状态为 SCHEDULED + 在 **t1** 时：静音规则状态变为 ACTIVE + 在 **t2** 时：告警转换到 ALARM 状态，操作被静音，因为告警已被静音规则有效静音。 + 在 **t4** 时：静音窗口变为非活动状态，告警仍处于 ALARM 状态 + 在 **t5** 时：执行告警动作，因为静音窗口已结束，且告警仍处于最初被静音时的状态（ALARM） ## 场景：多个重叠的告警静音规则 考虑到 + 告警已针对其 ALARM 状态配置了操作 考虑到有两条静音规则， + 告警静音规则 1：将从 t1 到 t5 的告警静音 + 告警静音规则 2：将从 t3 到 t9 的告警静音 ![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-3.png) + 在 **t0** 时，告警处于 OK 状态，两个静音规则均处于 SCHEDULED 状态 + 在 **t1** 时：第一条静音规则变为 ACTIVE + 在 **t2** 时：告警转变为 ALARM 状态，操作被静音 + 在 **t3** 时：第二条静音规则变为 ACTIVE + 在 **t5** 时：第一条静音规则变为非活动状态，但告警操作仍处于静音状态，因为第二条静音规则仍处于活动状态 + 在 **t8** 时：执行告警动作，因为第二个静音窗口已结束，且告警仍处于最初被静音时的状态（ALARM） ## 场景：当静音规则更新结束静音窗口时，将执行静音告警操作 考虑到 + 告警已针对其 ALARM 状态配置了操作 + 告警静音规则计划在 t1 到 t8 之间处于活动状态，以告警为目标 ![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-4.png) + 在 **t0** 时：告警处于 OK 状态，静音规则为 SCHEDULED 状态 + 在 **t1** 时：静音规则变为 ACTIVE + 在 **t2** 时：告警转变为 ALARM 状态，操作被静音 + 在 **t6** 时：静音规则配置被更新，使得时间窗口在 t6 时结束。由于静音规则不再处于活动状态，告警操作将在 t6 时立即执行。 **注意** 同样的行为也适用， 如果在 t6 时删除了静音规则。删除静音规则将会立即取消告警的静音。 如果告警从静音规则目标（在 t6 时）中被移除，则告警将立即被取消静音。 ## 场景：如果在静音窗口期间更新告警动作，则会执行新操作 考虑到 + 告警已针对其 ALARM 状态配置了操作 + 告警静音规则计划在 t1 到 t8 之间处于活动状态，以告警为目标 ![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-5.png) + 在 **t0** 时：告警处于 OK 状态，静音规则为 SCHEDULED 状态。SNS 操作在告警处于 ALARM 状态下被配置。 + 在 **t1** 时：静音规则变为 ACTIVE + 在 **t2** 时：告警转变为 ALARM 状态，配置的 SNS 操作被静音 + 在 **t6** 时：告警配置被更新，以移除 SNS 操作并添加 Lambda 操作 + 在 **t8** 时：执行配置为告警的 lambda 操作，因为静音窗口已结束，且告警仍处于最初被静音时的状态（ALARM） **注意** 如果在静音窗口期间（如上述示例中的 t6 时）移除了所有告警动作，则在静音窗口结束时（如上述示例中的 t8 时）将不会执行任何操作 ## 常见应用场景的计划示例 以下各示例介绍如何为常见应用场景配置实践窗口表达式。 **场景 1：在计划维护时段内将告警动作静音**：按可预测的计划进行的定期维护活动，例如在服务被有意设置为不可用或处于降级运行模式时进行系统或数据库的更新。 + 包含持续时间 `PT4H` 的 Cron 表达式 `0 2 * * SUN`：每周日凌晨 2:00 至早上 6:00 将告警静音，以进行每周系统维护。 + 包含持续时间 `PT6H` 的 Cron 表达式 `0 1 1 * *`：在每月第一天凌晨 1:00 至早上 7:00 将告警静音，以进行每月数据库维护。 **场景 2：在非工作时间将非关键告警静音**：在不需要立即关注的周末或节假日期间，减少告警疲劳。 + 包含持续时间 `P2DT12H` 的 Cron 表达式 `0 18 * * FRI`：每个周末从星期五下午 6:00 到星期一上午 6:00 将告警静音。 **场景 3：在日常备份操作期间将性能告警静音**：每日自动备份过程会暂时提高资源利用量，并可能在可预测的时间窗口内触发与性能相关的告警。 + 包含持续时间 `PT2H` 的 Cron 表达式 `0 23 * * *`：在夜间备份操作期间，在每天晚上 11:00 至凌晨 1:00 将告警静音，因为这些操作会暂时增加磁盘 I/O 和 CPU 利用率。 **场景 4：在有效的故障排除会话期间将重复的告警静音**：在团队积极调查和解决问题时暂时将告警操作静音，以防止通知干扰，便于集中解决具体问题。 + 包含持续时间 `PT4H` 的 At 表达式 `at(2024-05-10T14:00)`：在 2024 年 5 月 10 日下午 2:00 至下午 6:00 的活跃事件响应会话中，将告警静音。 **场景 5：在计划中的公司停机期间将告警操作静音**：一次性延长维护期或全公司范围的停机，其中所有系统都有意长时间离线。 + 包含持续时间 `P7D` 的 At 表达式 `at(2024-12-23T00:00)`：在公司年度停机期间，将 2024 年 12 月 23 日至 29 日的整周告警静音。 # 限制 ## 常规 CloudWatch 配额 有关适用于告警的常规 CloudWatch 服务配额的信息，请参阅 [CloudWatch 服务配额](cloudwatch_limits.md)。 ## 基于 Metrics Insights 查询的告警适用的限制 使用 CloudWatch Metrics Insights 告警时，请注意以下功能限制： + 每个区域每个账户使用 Metrics Insights 查询产生的告警默认为 200 个 + 只能使用最近 3 小时的数据来评估告警的情况。但告警详情页图表支持可视化展示最长两周的数据 + 对多个时间序列进行评估的警报会将 ALARM 中的贡献者数量限制为 100 个 + 假设查询检索到 150 个时间序列： + 如果 ALARM 中的贡献者少于 100 个（例如 95 个），则 `StateReason` 将为“被评估为 ALARM 的 150 个时间序列中的 95 个” + 如果 ALARM 中有超过 100 个贡献者（例如 105 个），则 `StateReason` 将是“被评估为 ALARM 的 100 多个时间序列” + 此外，如果属性的数量太大，ALARM 中的贡献者数量可以限制在 100 个以内。 + Metrics Insights 对分析或返回的最大时间序列数量的限制适用 + 在告警评估期间，`EvaluationState` 将设置为 `PARTIAL_DATA`，以满足以下限制： + 如果 Metrics Insights 查询返回超过 500 个时间序列。 + 如果 Metrics Insights 查询匹配的指标超过 10000 个。 有关 CloudWatch 服务配额与限制的更多信息，请参阅 [CloudWatch Metrics Insights 服务配额](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-limits.html)。 ## 基于 PromQL 查询的警报适用的限制 使用 CloudWatch PromQL 警报时，请注意以下功能限制： + 对多个时间序列进行评估的警报会将 ALARM 中的贡献者数量限制为 100 个 + 如果 ALARM 中的贡献者少于 100 个（例如 95 个），则 `StateReason` 将为“被评估为 ALARM 的 95 个时间序列” + 如果 ALARM 中有超过 100 个贡献者（例如 105 个），则 `StateReason` 将是“被评估为 ALARM 的 100 多个时间序列” + 此外，如果属性的数量太大，ALARM 中的贡献者数量可以限制在 100 个以内。 + PromQL 查询对分析或返回的最大时间序列数量的限制适用 + 在警报评估期间，如果 PromQL 查询返回的时间序列超过 500 个，则 `EvaluationState` 将设置为 `PARTIAL_DATA`。 ## 基于连接的数据来源适用于告警的限制 + 当 CloudWatch 评估警报时，即使警报的时间长于一分钟，也会每分钟评估一次。要使警报起作用，Lambda 函数必须能够返回从任何一分钟开始的时间戳列表，而不仅仅是周期长度的倍数。这些时间戳必须相隔一个周期长度。 因此，如果 Lambda 查询的数据来源只能返回周期长度的倍数的时间戳，则该函数应对获取的数据“重新采样”以匹配 `GetMetricData` 请求所期望的时间戳。 例如，每分钟评估一个周期为五分钟的警报，使用五分钟的窗口，每次偏移一分钟。在本例中： + 对于在 12:15:00 进行的警报评估，CloudWatch 预计数据点的时间戳为 `12:00:00`、`12:05:00` 和 `12:10:00`。 + 然后，对于在 12:16:00 进行的警报评估，CloudWatch 预计数据点的时间戳为 `12:01:00`、`12:06:00` 和 `12:11:00`。 + 当 CloudWatch 评估警报时，Lambda 函数返回的与预期时间戳不一致的任何数据点都将被丢弃，并使用剩余的预期数据点对警报进行评估。例如，当在 `12:15:00` 对警报进行评估时，其期望的数据的时间戳为 `12:00:00`、`12:05:00` 和 `12:10:00`。如果收到时间戳为 `12:00:00`、`12:05:00`、`12:06:00` 和 `12:10:00` 的数据，则 `12:06:00` 的数据将被丢弃，CloudWatch 会使用其他时间戳评估警报。 然后，在 `12:16:00` 的下一次评估中，其期望的数据的时间戳为 `12:01:00`、`12:06:00` 和 `12:11:00`。如果只有时间戳为 `12:00:00`、`12:05:00` 和 `12:10:00` 的数据，则所有这些数据点都将在 12:16:00 被忽略，警报会根据您指定的警报处理缺失数据的方式转换状态。有关更多信息，请参阅 [告警评估](alarm-evaluation.md)。 + 我们建议您创建这些警报，以便在其转换为 `INSUFFICIENT_DATA` 状态时采取行动，因为无论您设置警报以何种方式处理缺失数据，多个 Lambda 函数失败用例都会将警报转换为 `INSUFFICIENT_DATA`。 + 如果 Lambda 函数返回一个错误： + 如果在调用 Lambda 函数时出现权限问题，则警报会根据您在创建警报时指定的缺失数据处理方式，开始进行缺失数据转换。 + 任何其他来自 Lambda 函数的错误都会导致警报转换为 `INSUFFICIENT_DATA`。 + 如果 Lambda 函数请求的指标有一定的延迟，以至于最后一个数据点总是缺失，则应采用相应的解决方法。您可以创建 M 个警报（共 N 个）或延长警报的评估周期。有关 M 个警报（共 N 个）的更多信息，请参阅 [告警评估](alarm-evaluation.md)。