# 复合警报
<a name="alarm-combining"></a>

借助 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 函数与其他逻辑运算符结合，可用于更复杂的监控场景。

# 警报抑制
<a name="alarm-suppression"></a>

复合告警动作抑制功能使您能够暂时禁用告警动作，而无需删除或修改告警配置。这在计划内维护、部署或调查已知问题时非常有用。

通过复合告警操作抑制，您可以将告警定义为抑制器告警。抑制器告警可防止复合告警采取行动。例如，您可以指定表示支持资源状态的抑制器告警。如果支持资源关闭，则抑制器告警会阻止复合告警发送通知。

## 何时使用告警抑制
<a name="alarm-suppression-use-cases"></a>

适合使用告警抑制的常见情况：
+ 应用程序的维护窗口
+ 应用程序部署
+ 正在进行的事件调查
+ 测试和开发活动

## 抑制器告警的工作原理
<a name="alarm-suppression-how-it-works"></a>

您可以在配置复合告警时指定抑制器告警。任何告警都可以用作抑制器告警。当抑制器告警的状态从 `OK` 变为 `ALARM` 时，其复合告警停止执行操作。当抑制器告警的状态从 `ALARM` 变为 `OK` 时，其复合告警恢复执行操作。

复合警报允许您在多个警报中获得运行状况的聚合视图，因此存在一些预计会触发这些警报的常见情况。例如，在应用程序的维护时段或调查正在发生的事件时。在这种情况下，您可能需要抑制复合警报的操作，以防止不必要的通知或创建新的事件工单

 通过复合告警操作抑制，您可以将告警定义为抑制器告警。抑制器告警可防止复合告警采取行动。例如，您可以指定表示支持资源状态的抑制器告警。如果支持资源关闭，则抑制器告警会阻止复合告警发送通知。复合告警操作抑制功能可帮助您降低警报噪音，从而减少管理告警的时间，将更多的时间集中在操作上。

 您可以在配置复合告警时指定抑制器告警。任何告警都可以用作抑制器告警。当抑制器告警的状态从 `OK` 变为 `ALARM` 时，其复合告警停止执行操作。当抑制器告警的状态从 `ALARM` 变为 `OK` 时，其复合告警恢复执行操作。

### `WaitPeriod` 和 `ExtensionPeriod`
<a name="Create_Composite_Alarm_Suppression_Wait_Extension"></a>

 指定抑制器告警时，需要设置参数 `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 个时间单位。

#### 示例
<a name="example_scenarios"></a>

 **示例 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` 将被丢弃。

## 动作抑制和静音规则
<a name="action-suppression-and-mute-rules"></a>

 当针对一个复合告警同时启用动作抑制规则和告警静音规则时，静音规则将优先生效，并会抑制所有告警动作。静音窗口结束后，复合告警的动作抑制配置会根据抑制器告警状态以及所配置的等待或延长时间来决定是否执行相关动作。有关告警静音规则的更多信息，请参阅 [告警静音规则](alarm-mute-rules.md)。