

# 告警静音规则
<a name="alarm-mute-rules"></a>

 告警静音规则是 CloudWatch 的一项功能，它为您提供了一种在预定义的时间窗口内自动静音告警操作的机制。当您创建静音规则时，您可以指定特定的时间段，并指定其操作将被静音的目标告警。CloudWatch 将继续监控并评估告警状态，同时防止在预期的操作事件期间出现不必要的通知或自动告警操作。

 告警静音规则可帮助您管理关键操作场景，在这些场景中，告警操作可能并非必要或会造成干扰。例如，在计划的维护时段内，您可以阻止自动告警操作，此时您的系统处于有意离线状态或正遭遇预期问题，这样您就可以在不中断的情况下进行维护工作。对于非工作时间（如周末或节假日）的操作，您可以在无需立即做出响应的情况下将非关键的告警操作静音，从而减少告警噪声以及对运营团队的无用通知。在测试环境中，静音规则能让您在负载测试等场景中暂时将告警操作静音。在这些场景中，预期会有较高的资源使用量或较高的错误率，但并不需要立即采取行动。当您的团队积极排除问题时，静音规则可防止重复的告警操作被触发，这有助于您集中精力解决问题，而不会被冗余的告警通知所干扰。

## 定义告警静音规则
<a name="defining-alarm-mute-rules"></a>

 告警静音规则可以通过以下方式定义：**规则**和**目标**。
+  **规则**：定义应将告警操作静音的时间窗口。规则由三个属性组成：
  +  **表达式**：定义静音时段何时开始以及如何重复。您可以使用两种类型的表达式：
    +  **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 账户中的所有静音规则。您可以使用静音规则属性（如规则名称）搜索特定的静音规则。

## 静音规则状态
<a name="mute-rule-status"></a>

 告警静音规则创建后，可以处于以下三种状态之一：
+  **SCHEDULED**：根据配置的时间窗口表达式，静音规则将在未来的某个时间生效。
+  **ACTIVE**：根据配置的时间窗口表达式，静音规则当前处于活动状态，并且正在主动将目标告警操作静音。
+  **EXPIRED**：该静音规则未来将不再处于 SCHEDULED 或 ACTIVE 状态。这种情况发生在静音窗口结束后的一次性静音规则中，或者配置了结束时间戳且该时间已过去时的重复静音规则中。

## 静音规则对告警的影响
<a name="effects-of-mute-rules"></a>

 在活动的静音窗口期间，当目标告警更改状态并配置了操作时，CloudWatch 会将这些操作静音，使其无法执行。静音仅适用于告警操作，这意味着可以继续评估告警，状态更改在 CloudWatch 控制台中可见，但 Amazon Simple Notification Service 通知、Amazon Elastic Compute Cloud 自动扩缩操作或 Amazon EC2 操作等配置的操作将无法执行。在整个静音期间，CloudWatch 会继续正常评估告警状态，您可以通过告警历史记录查看此信息。

 当静音窗口结束时，如果目标告警仍处于告警状态（OK/ALARM/INSUFFICIENT\$1DATA），CloudWatch 会自动重新触发在该窗口期间静音的告警操作。这样可以确保在计划中的静音期结束后，针对持续存在的问题执行告警操作，从而保持监控系统的完整性。

**注意**  
 将告警静音时：  
 与目标告警相关的所有操作均会被静音 
 与所有告警状态（OK、ALARM 和 INSUFFICIENT\$1DATA）关联的操作将被静音 

## 查看和管理已静音的告警
<a name="viewing-managing-muted-alarms-link"></a>

有关查看和管理静音告警的信息，请参阅 [查看和管理已静音的告警](viewing-managing-muted-alarms.md)。

# 告警静音规则的工作原理
<a name="alarm-mute-rules-behaviour"></a>

以下场景说明了告警静音规则如何影响目标警报，以及告警操作是如何被静音或执行的。

**注意**  
 将告警静音会使与所有告警状态相关的操作静音，包括 OK、ALARM 和 INSUFFICIENT\$1DATA。下图所示的行为适用于与所有告警状态相关的操作。
 当您将 Metrics Insights 告警静音时，该告警的所有贡献者指标系列也会自动被静音。

## 场景：当静音规则处于活动状态时，告警操作被静音
<a name="scenario-actions-muted-during-active-rule"></a>

考虑到
+ 告警已针对其 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 操作

## 场景：静音规则处于活动状态时告警动作被静音，并在静音窗口后被重新触发
<a name="scenario-action-retriggered-after-mute"></a>

考虑到
+ 告警已针对其 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）

## 场景：多个重叠的告警静音规则
<a name="scenario-multiple-overlapping-rules"></a>

考虑到
+ 告警已针对其 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）

## 场景：当静音规则更新结束静音窗口时，将执行静音告警操作
<a name="scenario-rule-update-ends-mute"></a>

考虑到
+ 告警已针对其 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 时）中被移除，则告警将立即被取消静音。

## 场景：如果在静音窗口期间更新告警动作，则会执行新操作
<a name="scenario-actions-updated-during-mute"></a>

考虑到
+ 告警已针对其 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 时）将不会执行任何操作

## 常见应用场景的计划示例
<a name="common-use-cases"></a>

 以下各示例介绍如何为常见应用场景配置实践窗口表达式。

 **场景 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 日的整周告警静音。