# 使用 Amazon CloudWatch 告警
您可以创建警报，这些警报监视指标，当超出阈值时，它们会发送通知或者对您所监控的资源自动进行更改。例如，您可以监控您的 Amazon EC2 实例的 CPU 使用率以及磁盘读写情况，然后使用此数据确定您是否应启动其它实例来处理增加的负载。您还可以使用此数据停止未完全利用的实例以节省开支。
您可以在 Amazon CloudWatch 中创建*指标*警报和*复合*警报。
您可以在 Metrics Insights 查询上创建警报，这些查询使用 AWS 资源标签对指标进行筛选和分组。要将标签与警报结合使用，请在 [https://console.aws.amazon.com/connect/](https://console.aws.amazon.com/connect/) 上选择**设置**。在 **CloudWatch 设置**页面的**针对遥测启用资源标签**下，选择**启用**。如果是能自动适应标记策略的上下文感知监控，请使用 AWS 资源标签在 Metrics Insights 查询上创建警报。这样，您就可以监控所有标有特定应用程序或环境的资源。
+ *指标告警*可监控单个 CloudWatch 指标，或基于 CloudWatch 指标监控数学表达式的结果。告警根据指标或表达式在多个时间段内相对于某阈值的值执行一项或多项操作。操作可以是向 Amazon SNS 主题发送通知、执行 Amazon EC2 操作或 Amazon EC2 Auto Scaling 操作、在 CloudWatch 调查中启动调查，或在 Systems Manager 中创建 OpsItem 或事件。
+ *PromQL 警报*通过对经由 CloudWatch OTLP 端点摄取到的指标进行 Prometheus 查询语言（PromQL）即时查询来监控指标。该警报以贡献者的身份跟踪个人违规时间序列，并使用基于持续时间的待定和恢复周期来控制状态转换。有关更多信息，请参阅 [PromQL 警报](alarm-promql.md)。
+ *复合告警*包括一个规则表达式，该表达式考虑您已创建的其他告警的告警状态。只有当规则的所有条件都得到满足时，复合告警才会进入“ALARM（告警）”状态。在复合告警的规则表达式中指定的告警可以包括指标告警和其他复合告警。
使用复合告警可以减少告警噪音。您可以创建多个指标告警，还可以创建复合告警并仅为复合告警设置提示。例如，只有当所有底层指标告警都处于“ALARM（告警）”状态时，复合告警才可能进入“ALARM（告警）”状态。
复合警报可以在改变状态时发送 Amazon SNS 通知，并且可以在进入 ALARM 状态时创建调查、Systems Manager OpsItems 或事件，但无法执行 EC2 操作或 Auto Scaling 操作。
**注意**
您可以在您的 AWS 账户中创建任意数量的警报。
您可以为控制面板添加警报，以便监控与接收跨多个区域的 AWS 资源和应用程序的提醒。为控制面板添加警报以后，该警报会在处于 `INSUFFICIENT_DATA` 状态时变成灰色，在 `ALARM` 状态时变成红色。当处于 `OK` 状态时，警报没有颜色显示。
您还可以在 CloudWatch 控制台的导航面板中通过 *Favorites and recents*（收藏夹和最近记录）选项收藏最近访问过的警报。*Favorites and recents*（收藏夹和最近记录）选项中有对应的列，分别显示您收藏的警报和最近访问过的警报。
告警仅在告警状态更改时才会调用操作。使用 Auto Scaling 操作的告警除外。对于 Auto Scaling 操作，告警会在告警保持新状态时以每分钟一次的频率持续调用操作。
告警可以在同一账户中监视指标。如果您在 CloudWatch 控制台中启用了跨账户功能，则还可以创建告警，以监视其他 AWS 账户。不支持创建跨账户复合告警。支持创建使用数学表达式的跨账户告警，但跨账户告警不支持 `ANOMALY_DETECTION_BAND`、`INSIGHT_RULE` 和 `SERVICE_QUOTA` 函数。
**注意**
CloudWatch 不会测试或验证您指定的操作，也不会检测因试图调用不存在的操作而导致的任何 Amazon EC2 Auto Scaling 或 Amazon SNS 错误。请确保您的告警操作存在。
# 概念
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)。
# 开始使用
**Topics**
+ [创建警报](Create-Alarms.md)
+ [根据警报更改执行操作](Acting_Alarm_Changes.md)
+ [配置告警静音规则](alarm-mute-rules-configure.md)
# 创建警报
**Topics**
+ [根据静态阈值创建 CloudWatch 告警](ConsoleAlarms.md)
+ [根据指标数学表达式创建 CloudWatch 告警](Create-alarm-on-metric-math-expression.md)
+ [根据异常检测创建 CloudWatch 告警](Create_Anomaly_Detection_Alarm.md)
+ [基于多时间序列 Metrics Insights 查询创建告警](multi-time-series-alarm.md)
+ [基于连接的数据来源创建警报](Create_MultiSource_Alarm.md)
+ [使用 PromQL 查询创建警报](Create_PromQL_Alarm.md)
+ [根据日志触发警报](Alarm-On-Logs.md)
+ [创建复合告警](Create_Composite_Alarm.md)
# 根据静态阈值创建 CloudWatch 告警
您可以为告警选择一个要监视的 CloudWatch 指标，并为该指标选择阈值。如果该指标在指定数量的评估期内超出阈值，告警将变为 `ALARM`（告警）状态。
如果您创建告警的账户在 CloudWatch 跨账户可观测性中设置为监控账户，则可以设置告警以监测与该监控账户关联的源账户中的指标。有关更多信息，请参阅 [CloudWatch 跨账户可观测性](CloudWatch-Unified-Cross-Account.md)。
**根据单个指标创建告警**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms（警报）**和 **All alarms（所有警报）**。
1. 选择**创建警报**。
1. 选择 **Select Metric（选择指标）**。
1. 请执行以下操作之一：
+ 选择包含所需指标的服务命名空间。继续选择所显示的选项，以缩小选择范围。在显示指标列表时，选中所需的指标旁边的复选框。
+ 在搜索框中，输入指标名称、账户 ID、账户标签、维度或资源 ID。接下来，选择其中的一个结果并继续，直到显示指标列表。选中所需的指标旁边的复选框。
1. 选择 **Graphed metrics**（绘制的指标）选项卡。
1. 在 **Statistic（统计数据）**下，选择其中的一个统计数据或预定义百分比值，或者指定一个自定义百分比值（例如 **p95.45**）。
1. 在 **Period（时间段）**下，选择告警的评估期。评估告警时，每个时间段都聚合到一个数据点。
在创建告警时，您还可以选择是在左侧还是右侧显示 Y 轴图例。该首选项仅在创建告警时使用。
1. 选择**选择指标**。
将显示 **Specify metric and conditions（指定指标和条件）**页面，其中显示一个图表以及有关您选择的指标和统计数据的其他信息。
1. 在**条件**下面，指定以下内容：
1. 对于 **Whenever *metric* is（每当指标）**，指定指标是必须大于、小于还是等于阈值。在**于...** 下面，指定阈值。
1. 选择**其他配置**。对于**触发警报的数据点数**，指定必须有多少个评估期（数据点）处于 `ALARM` 状态才能触发警报。如果此处的两个值匹配，则会创建一个告警；如果多个连续评估期违例，该告警将变为 `ALARM`（告警）状态。
要创建“M（最大为 N）”告警，为第一个值指定的数字应小于为第二个值指定的数字。有关更多信息，请参阅 [告警评估](alarm-evaluation.md)。
1. 对于**缺失数据处理**，选择在缺失某些数据点时的警报行为。有关更多信息，请参阅 [配置 CloudWatch 告警处理缺失数据的方式](alarms-and-missing-data.md)。
1. 如果警报将百分比值作为监控的统计数据，将显示**样本数少的百分比**框。使用它来选择是评估还是忽略采样率低的案例。如果选择**忽略 (保持警报状态)**，在样本大小太小时，将始终保持当前警报状态。有关更多信息，请参阅 [基于百分位数的告警和小数据样本](percentiles-with-low-samples.md)。
1. 选择**下一步**。
1. 在**通知**下面，选择一个在警报处于 `ALARM`、`OK` 或 `INSUFFICIENT_DATA` 状态时通知的 SNS 主题。
要使告警为相同告警状态或不同告警状态发送多个通知，请选择**添加通知**。
在 CloudWatch 跨账户可观测性中，您可以选择向多个 AWS 账户发送通知。例如，同时向监控账户和源账户发送通知。
要让警报不发送通知，请选择**删除**。
1. 要让警报执行 Auto Scaling、EC2、Lambda、调查或 Systems Manager 操作，请选择相应的按钮，然后选择警报状态和要执行的操作。警报只有在进入 ALARM 状态时才能执行 Systems Manager 操作和调查操作。有关 Systems Manager 操作的更多信息，请参阅[将 CloudWatch 配置为通过告警创建 OpsItems ](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)和[事件创建](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
要让警报启动调查，请选择**添加调查操作**，然后选择调查组。有关 的更多信息，请参阅 [CloudWatch 调查](Investigations.md)。
**注意**
要创建执行 SSM Incident Manager 操作的告警，您必须具有特定的权限。有关更多信息，请参阅 [AWS Systems Manager Incident Manager 的基于身份的策略示例](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html)。
1. 在完成后，选择**下一步**。
1. 输入警报的名称和说明。名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。然后选择**下一步**。
1. 在 **Preview and create** 下面，确认具有所需的信息和条件，然后选择 **Create alarm**。
您还可以将警报添加到控制面板。有关更多信息，请参阅 [将警报添加到 CloudWatch 控制面板](add_alarm_dashboard.md)。
# 根据指标数学表达式创建 CloudWatch 告警
指标告警用于评估您根据单个指标或指标数学表达式（将一个或多个指标组合或转换成一个时间序列）所定义的时间序列，此类时间序列可提供更符合您独特需求的洞察数据。要基于指标数学表达式创建告警，请选择表达式中要使用的一个或多个 CloudWatch 指标。然后，指定表达式、阈值和评估期。
无法创建基于 **SEARCH（搜索）**表达式的告警。只有基于 Metrics Insights SQL 查询的告警才能在多个时间序列上运行。
**根据指标数学表达式创建告警**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择 **Alarms**（告警），然后选择 **All alarms**（所有告警）。
1. 选择**创建警报**。
1. 选择 **Select Metric**（选择指标），然后执行以下操作之一:
+ 从 **AWS namespaces**（命名空间）下拉列表或 **Custom namespaces**（自定义命名空间）下拉列表中，选择命名空间。选择命名空间后，您可以继续选择选项，直到显示指标列表，您可以在其中选择正确指标旁边的复选框。
+ 使用搜索框查找指标、账户 ID、维度或资源 ID。输入指标、维度或资源 ID 后，您可以继续选择选项，直到显示指标列表，您可以在其中选择正确指标旁边的复选框。
1. （可选）如果要向指标数学表达式添加另一个指标，您可以使用搜索框查找特定指标。您可以向指标数学表达式添加多达 10 个指标。
1. 选择 **Graphed metrics**（绘制的指标）选项卡。对于您之前添加的每个指标，请执行以下操作:
1. 在 **Statistic**（统计数据）列中，选择下拉菜单。在下拉菜单中，选择一个预定义的统计数据或百分位数。使用下拉菜单中的搜索框指定自定义百分位数。
1. 在 **Period**（时间段）列下，选择下拉菜单。在下拉菜单中，选择一个预定义的评估期。
在创建告警时，您可以指定 Y 轴图例是在左侧还是右侧显示。
**注意**
在 CloudWatch 评估告警时，时间段会聚合到单个数据点中。
1. 选择 **Add math**（添加数学）下拉菜单，然后从预定义的指标数学表达式列表中选择 **Start with an empty expression**（从空表达式开始）。
选择 **Start with an empty expression**（从空表达式开始）之后，系统将显示一个数学表达式框，您可以在其中应用或编辑数学表达式。
1. 在数学表达式框中，输入数学表达式，然后选择 **Apply**（应用）。
选择 **Apply**（应用）之后，**Label**（标注）列旁边会显示一个 **ID** 列。
要将一个指标或另一个指标数学表达式的结果用作当前数学表达式公式的一部分，您可以使用 **ID** 列下显示的值。要更改 **ID** 值，您可以选择当前值旁边的笔和纸图标。新值必须以小写字母开头，并且可以包含数字、字母和下划线符号。将 **ID** 值更改为更明显的名称也可以使告警图表更易于理解。
有关可用于指标数学的函数的信息，请参阅 [指标数学语法和函数](using-metric-math.md#metric-math-syntax)。
1. （可选）在新数学表达式的公式中，使用指标和其他数学表达式的结果添加更多数学表达式。
1. 当您具有要用于告警的表达式时，请清除页面上每个其他表达式和每个指标左侧的复选框。只应选中要用于告警的表达式旁边的复选框。您为告警选择的表达式必须生成单个时间序列，并且仅在图表上显示一行。然后选择 **Select metric（选择指标）**。
将显示 **Specify metric and conditions（指定指标和条件）**页面，其中显示一个图表以及有关您选择的数学表达式的其他信息。
1. 对于 **Whenever *expression* is（每当表达式）**，指定表达式是必须大于、小于还是等于阈值。在**于...** 下面，指定阈值。
1. 选择**其他配置**。对于**触发警报的数据点数**，指定必须有多少个评估期（数据点）处于 `ALARM` 状态才能触发警报。如果此处的两个值匹配，则会创建一个告警；如果多个连续评估期违例，该告警将变为 `ALARM`（告警）状态。
要创建“M（最大为 N）”告警，为第一个值指定的数字应小于为第二个值指定的数字。有关更多信息，请参阅 [告警评估](alarm-evaluation.md)。
1. 对于**缺失数据处理**，选择在缺失某些数据点时的警报行为。有关更多信息，请参阅 [配置 CloudWatch 告警处理缺失数据的方式](alarms-and-missing-data.md)。
1. 选择**下一步**。
1. 在**通知**下面，选择一个在警报处于 `ALARM`、`OK` 或 `INSUFFICIENT_DATA` 状态时通知的 SNS 主题。
要使告警为相同告警状态或不同告警状态发送多个通知，请选择**添加通知**。
要让警报不发送通知，请选择**删除**。
1. 要让告警执行 Auto Scaling、Amazon EC2、Lambda 或 Systems Manager 操作，请选择相应的按钮，然后选择告警状态和要执行的操作。如果您选择 Lambda 函数作为警报操作，则需要指定函数名称或 ARN，并且可以选择该函数的特定版本。
告警只有在进入“ALARM（告警）”状态时才能执行 Systems Manager 操作。有关 Systems Manager 操作的更多信息，请参阅[将 CloudWatch 配置为通过告警创建 OpsItems ](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)和[事件创建](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
**注意**
要创建执行 SSM Incident Manager 操作的告警，您必须具有特定的权限。有关更多信息，请参阅 [AWS Systems Manager Incident Manager 的基于身份的策略示例](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html)。
1. 在完成后，选择**下一步**。
1. 输入警报的名称和说明。然后选择**下一步**。
名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
1. 在 **Preview and create** 下面，确认具有所需的信息和条件，然后选择 **Create alarm**。
您还可以将警报添加到控制面板。有关更多信息，请参阅 [将警报添加到 CloudWatch 控制面板](add_alarm_dashboard.md)。
# 根据异常检测创建 CloudWatch 告警
您可以根据 CloudWatch 异常检测来创建告警，该异常检测可以分析过去的指标数据并创建预期值模型。预期值会考虑指标中的典型每小时、每日和每周模式。
您需要为异常检测阈值设置一个值，然后 CloudWatch 在模型中使用该阈值来确定指标值的“正常”范围。阈值越高，所产生的“正常”值的范围越大。
您可以选择当指标值高于预期值范围、低于预期值范围，或出现二者情况之一时是否触发告警。
您还可以针对单个指标和指标数学表达式的输出创建异常检测告警。您可以使用这些表达式来创建能可视化异常检测范围的图表。
在设置为 CloudWatch 跨账户可观测性的账户中，除了监控账户中的指标外，您还可以在源账户的指标中创建异常检测器。
有关更多信息，请参阅 [使用 CloudWatch 异常检测](CloudWatch_Anomaly_Detection.md)。
**注意**
如果您出于可视化目的已在 Metrics（指标）控制台中对某个指标使用了异常检测，并针对该指标创建了异常检测告警，则您为该告警设置的阈值不会更改您为可视化设置的阈值。有关更多信息，请参阅 [创建图表](graph_a_metric.md#create-metric-graph)。
**创建基于异常检测的告警**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms（警报）**和 **All alarms（所有警报）**。
1. 选择**创建警报**。
1. 选择 **Select Metric（选择指标）**。
1. 请执行以下操作之一：
+ 选择包含您的指标的服务命名空间，然后继续选择相应选项，因为这些选项看起来会缩小您的选项范围。在显示指标列表时，选中您的指标旁边的复选框。
+ 在搜索框中，输入指标名称、维度或资源 ID。选择其中的一个结果，然后继续在选项显示时选择它们，直到显示指标列表为止。选中您的指标旁边的复选框。
1. 选择**绘制的指标**。
1. （可选）对于*统计数据*，选择下拉列表，然后选择一个预定义的统计数据或百分位数。您可以使用下拉列表中的搜索框指定自定义百分位数，如 **p95.45**。
1. （可选）对于*周期*，选择下拉列表，然后选择一个预定义的评估周期。
**注意**
当 CloudWatch 评估您的告警时，它会将该周期汇总为单个数据点。对于异常检测告警，评估周期必须是一分钟或更长时间。
1. 选择**下一步**。
1. 在***条件***下面，指定以下内容：
1. 选择 **Anomaly detection（异常检测）**。
如果针对此指标和统计数据的模型已存在，则 CloudWatch 在屏幕顶部的图中显示异常检测范围的预览。创建警报后，实际异常检测范围出现在图中可能需要 15 分钟。在此之前，您看到的范围是异常检测范围的近似值。
**提示**
要在更长的时间范围内查看屏幕顶部的图表，请选择屏幕右上方的 **Edit**（编辑）。
如果此指标和统计的模型不存在，CloudWatch 在您完成创建警报后生成异常检测范围。对于新模型，实际异常检测范围出现在图表中可能需要 3 个小时。新模型的训练可能需要两周时间，因此异常检测范围可以显示更准确的预期值。
1. 对于 **Whenever *metric* is**（每当指标为），指定何时触发告警。例如，每当指标大于、小于或超出范围（在任一方向）。
1. 对于 **Anomaly detection threshold（异常检测阈值）**，选择用于异常检测阈值的数字。数字越大，创建的“正常”值的范围就越大，也更能容忍指标变化。数字越小，创建的范围就越小，它将以较小的指标偏差进入 `ALARM` 状态。数字不一定是整数。
1. 选择**其他配置**。对于**触发警报的数据点数**，指定必须有多少个评估期（数据点）处于 `ALARM` 状态才能触发警报。如果此处的两个值匹配，则会创建一个告警；如果多个连续评估期违例，该告警将变为 `ALARM`（告警）状态。
要创建“M（最大为 N）”告警，为第一个值指定的数字应小于为第二个值指定的数字。有关更多信息，请参阅 [告警评估](alarm-evaluation.md)。
1. 对于 **Missing data treatment**（缺失数据处理），选择在缺失某些数据点时的告警行为。有关更多信息，请参阅 [配置 CloudWatch 告警处理缺失数据的方式](alarms-and-missing-data.md)。
1. 如果警报将百分比值作为监控的统计数据，将显示**样本数少的百分比**框。使用它来选择是评估还是忽略采样率低的案例。如果选择 **Ignore（maintain alarm state）**（忽略（保持警报状态）），在样本大小太小时，将始终保持当前警报状态。有关更多信息，请参阅 [基于百分位数的告警和小数据样本](percentiles-with-low-samples.md)。
1. 选择**下一步**。
1. 在**通知**下面，选择一个在警报处于 `ALARM`、`OK` 或 `INSUFFICIENT_DATA` 状态时通知的 SNS 主题。
要为相同告警状态或不同告警状态发送多个通知，请选择 **Add notification**（添加通知）。
如果不想告警发送通知，请选择 **Remove**（移除）。
1. 您可以将警报设置为在发生状态更改时执行 EC2 操作或调用 Lambda 函数，或在进入 ALARM 状态时创建 Systems Manager OpsItem 或事件。为此，请选择相应的按钮，然后选择警报状态和要执行的操作。
如果您选择 Lambda 函数作为警报操作，则需要指定函数名称或 ARN，并且可以选择该函数的特定版本。
有关 Systems Manager 操作的更多信息，请参阅[将 CloudWatch 配置为通过告警创建 OpsItems ](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)和[事件创建](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
**注意**
要创建执行 AWS Systems Manager Incident Manager 操作的警报，您必须具有特定的权限。有关更多信息，请参阅 [AWS Systems Manager Incident Manager 的基于身份的策略示例](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html)。
1. 选择**下一步**。
1. 在***名称和描述***下，输入警报的名称和描述，然后选择**下一步**。名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
**提示**
告警名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符
1. 在***预览和创建***下，确认警报的信息和条件正确，然后选择**创建警报**。
## 编辑异常检测模型
创建告警后，可以调整异常检测模型。您可以排除某些时间段，不在创建模型时使用。从训练数据中排除系统中断、部署和假日等异常事件至关重要。您还可以指定是否针对夏令时更改调整模型。
**针对警报编辑异常检测模型**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms（警报）**和 **All alarms（所有警报）**。
1. 选择警报的名称。如有必要，请使用搜索框来查找警报。
1. 选择**查看**，然后选择**在指标中**。
1. 在**详细信息**列中，选择 **ANOMALY\$1DETECTION\$1BAND** 关键字，然后在弹出窗口中选择**编辑异常检测模型**。
![\[随即会显示带 ANOMALY_DETECTION_BAND 弹出窗口的“图表化指标”选项卡。\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/Anomaly_Detection_Edit.PNG)
1. 要排除用于生成模型的时间段，请按**结束日期**选择日历图标。然后，选择或输入要从训练中排除的天数和时间，并选择 **Apply**（应用）。
1. 如果指标需要区分夏令时更改，请在 **Metric timezone**（指标时区）框中选择相应的时区。
1. 选择 **Update（更新）**。
## 删除异常检测模型
对警报使用异常检测会产生费用。作为最佳实践，如果警报不再需要异常检测模型，请先删除警报，然后删除模型。评估异常检测警报时，系统将代表您创建任何缺失的异常检测器。如果您删除模型而不删除告警，则告警会自动重新创建模型。
**删除警报**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms**（告警）和 **All alarms**（所有告警）。
1. 选择警报的名称。
1. 依次选择 **Actions（操作）**和 **Delete（删除）**。
1. 在确认框中，选择**删除**。
**要删除曾用于告警的异常检测模型**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择 **Metrics**（指标），然后选择 **All metrics**（所有指标）。
1. 选择 **Browse**（浏览），然后选择包含异常检测模型的指标。您可以在搜索框中搜索您的指标，也可以通过选择选项来选择您的指标。
+ （可选）如果要使用原始界面，请选择 **All metrics**（所有指标），然后选择包含异常检测模型的指标。您可以在搜索框中搜索您的指标，也可以通过选择选项来选择您的指标。
1. 选择 **Graphed metrics**（绘制的指标）。
1. 在**图表化指标**选项卡中，选择**详细信息**列中的 **ANOMALY\$1DETECTION\$1BAND** 关键字，然后在弹出窗口中选择**删除异常检测模型**。
![\[随即会显示带 ANOMALY_DETECTION_BAND 弹出窗口的“图表化指标”选项卡。\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/Anomaly_Detection_Edit.PNG)
+ （可选）如果要使用原始界面，请选择 **Edit model**（编辑模型）。系统会将您定向到新屏幕。在新屏幕上，选择 **Delete model**（删除模型），然后选择 **Delete**（删除）。
# 基于多时间序列 Metrics Insights 查询创建告警
您可以创建告警来监控资源实例集的多个时间序列。与仅针对单个实例触发操作的单实例告警不同，实例集监控告警可让您聚合多个资源的指标，并根据整个实例集的情况触发操作。
## 使用 AWS 管理控制台 设置多时间序列告警
此示例展示了如何创建可监控实例集中的内存利用率且在有两个以上的实例超过阈值时向您发出警报的告警。
**要创建多时间序列告警**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms**（告警）和 **All alarms**（所有告警）。
1. 选择**创建警报**。
1. 选择**选择指标**。
1. 在**指标**下输入 Metrics Insights 查询：
```
SELECT MAX(mem_used_percent)
FROM "CWAgent"
GROUP BY InstanceId
ORDER BY MAX() DESC
```
1. 选择**下一步**。
1. 在**条件**下面，指定以下内容：
+ 对于 **Threshold type（阈值类型）**，选择 **Static（静态）**。
+ 在**当指标**下选择**大于**，然后输入 **80**。
+ 在**告警数据点数**中输入 **2**。
1. 根据需要配置通知和操作。
1. 添加告警的名称和描述。
1. 选择**创建警报**。
此告警与单实例告警在多个方面存在差异：
+ 其通过使用指标查询同时监控多个时间序列。每当告警进行评估时，指标查询都会刷新，因此告警会随着资源的创建、暂停或删除而自动调整。
+ 对于每个超出阈值的影响因素，告警都会发送一个影响因素状态更改事件，该事件在 EventBridge 中的事件类型与告警状态更改事件不同。告警本身也会同步更改状态：只要至少有一个影响因素处于告警状态，告警就会进入告警状态。
+ 但是，某些操作（例如 SSM 事件）是在告警级别触发的。当告警中的影响因素列表发生变化时，将不会再重复此类操作。
此告警与聚合指标查询告警在多个方面存在差异：
+ 其使用 `GROUP BY` 子句而非监控聚合指标单独监控时间序列。
+ 其根据您按需求设置的粒度级别进行告警：例如，可针对每个 Amazon EC2 实例（这是 Amazon EC2 指标最细的粒度级别）触发告警，也可针对每张 Amazon RDS 表（基于某数据表上各类操作的聚合数据））触发告警，具体取决于您在 `GROUP BY` 子句中设置的字段
+ 其使用 `ORDER BY` 子句确定评估的优先级。
+ 对于每个超出阈值的影响因素，告警都会发送一个影响因素状态更改事件，该事件在 EventBridge 中的事件类型与告警状态更改事件不同。告警本身也会同步更改状态：只要至少有一个影响因素处于告警状态，告警就会进入告警状态。
+ 但是，某些操作（例如 SSM 事件）是在告警级别触发的。当告警中的影响因素列表发生变化时，将不会再重复此类操作。
# 基于连接的数据来源创建警报
您可以创建警报，监控源自非 CloudWatch 中的数据来源的指标。有关创建与这些其他数据来源的连接的更多信息，请参阅[查询源自其他数据来源的指标](MultiDataSourceQuerying.md)。
**针对您已连接的数据来源的指标创建警报**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Metrics**（指标）、**All metrics**（所有指标）。
1. 选择**多来源查询**选项卡。
1. 对于**数据来源**，选择要使用的数据来源。
1. 查询生成器会提示您输入查询所需的信息，以检索用于警报的指标。每个数据来源的工作流程都不同，并且这些工作流程都是针对数据来源量身定制的。例如，对于 Amazon Managed Service for Prometheus 和 Prometheus 数据来源，会出现一个带有查询助手的 PromQL 查询编辑器框。
1. 完成查询构造后，选择**图表查询**。
1. 如果样本图表看起来像您所期望的那样，请选择**创建警报**。
1. 出现**指定指标和条件**页面。如果您使用的查询生成多个时间序列，您会在页面顶部看到一个警告横幅。如果这样做，请在**聚合函数**中选择一个用于聚合时间序列的函数。
1. （可选）为警报添加**标签**。
1. 对于**每当 *your-metric-name* 为……**，选择**大于**、**大于/等于**、**小于/等于**或**小于**。然后，对于**相比……**，为您的阈值指定一个数值。
1. 选择**其他配置**。对于**触发警报的数据点数**，指定必须有多少个评估期（数据点）处于 `ALARM` 状态才能触发警报。如果此处的两个值匹配，则会创建一个告警；如果多个连续评估期违例，该告警将变为 `ALARM`（告警）状态。
要创建“M（最大为 N）”告警，为第一个值指定的数字应小于为第二个值指定的数字。有关更多信息，请参阅 [告警评估](alarm-evaluation.md)。
1. 对于 **Missing data treatment**（缺失数据处理），选择在缺失某些数据点时的告警行为。有关更多信息，请参阅 [配置 CloudWatch 告警处理缺失数据的方式](alarms-and-missing-data.md)。
1. 选择**下一步**。
1. 对于**通知**，选择当您的警报转换为 `ALARM`、`OK` 或 `INSUFFICIENT_DATA` 状态时要通知的 Amazon SNS 主题。
1. （可选）要为相同告警状态或不同告警状态发送多个通知，请选择 **Add notification**（添加通知）。
**注意**
我们建议您将警报设置为在进入**数据不足**状态以及进入**警报**状态时采取行动。这是因为连接到数据来源的 Lambda 函数的许多问题都可能导致警报转换为**数据不足**。
1. （可选）如果无需发送 Amazon SNS 通知，请选择**移除**。
1. 要让警报执行 Auto Scaling、Lambda 或 Systems Manager 操作，请选择相应的按钮，然后选择警报状态和要执行的操作。如果您选择 Lambda 函数作为警报操作，则需要指定函数名称或 ARN，并且可以选择该函数的特定版本。
告警只有在进入“ALARM（告警）”状态时才能执行 Systems Manager 操作。有关 Systems Manager 操作的更多信息，请参阅[将 CloudWatch 配置为通过告警创建 OpsItems ](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)和[事件创建](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
**注意**
要创建执行 SSM Incident Manager 操作的告警，您必须具有特定的权限。有关更多信息，请参阅 [AWS Systems Manager Incident Manager 的基于身份的策略示例](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html)。
1. 选择**下一步**。
1. 在**名称和描述**下，输入警报的名称和描述，然后选择**下一步**。名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
**提示**
警报名称只能包含 UTF-8 字符。不能包含 ASCII 控制字符。
1. 在**预览和创建**下，确认警报的信息和条件正确，然后选择**创建警报**。
# 使用 PromQL 查询创建警报
您可以创建 CloudWatch 警报，该警报使用 PromQL 即时查询来监控通过 CloudWatch OTLP 端点摄取到的指标。查询返回的所有匹配时间序列都被视为违规，警报会将每个违规的时间序列作为贡献者进行跟踪。有关 PromQL 警报的工作原理的更多信息，请参阅 [PromQL 警报](alarm-promql.md)。
## 使用 AWS 管理控制台 创建 PromQL 警报
此示例展示了如何创建可监控量规指标且在指标值低于 20 时向您发出提醒的警报。
**创建 PromQL 警报**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms**（告警）和 **All alarms**（所有告警）。
1. 选择**Create alarm（创建警报）**。
1. 为指标类型选择 **PromQL**。
1. 在**编辑器**模式下，输入 PromQL 查询：
```
my_gauge_metric < 20
```
1. 在**条件**下面，指定以下内容：
+ 在**评估间隔**中，选择 **1 minute** 以定义评估 PromQL 查询的频率。
+ 在**待处理周期**中，输入 **120**，这是贡献者进入 ALARM 状态之前必须处于违规状态的持续时间（以秒为单位）。
+ 在**恢复周期**中，输入 **300**，这是贡献者在进入 OK 状态之前不得违规的持续时间（以秒为单位）。
1. 根据需要配置通知和操作。
1. 添加告警的名称和描述。
1. 选择**下一步**。
1. 选择**创建警报**。
## 创建 PromQL 警报（AWS CLI）
使用 [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) API 操作创建 PromQL 警报。
**Example 创建 PromQL 警报，当量规指标降至 20 以下时会触发该警报**
```
aws cloudwatch put-metric-alarm \
--alarm-name MyPromQLAlarm \
--evaluation-criteria '{"PromQLCriteria":{"Query":"my_gauge_metric < 20"}}' \
--evaluation-interval 60
```
**Example 创建具有待处理周期的 PromQL 警报**
此警报在过渡到 `ALARM` 状态之前等待 300 秒（5 分钟），在恢复前等待 600 秒（10 分钟）。
```
aws cloudwatch put-metric-alarm \
--alarm-name HighLatencyAlarm \
--evaluation-criteria '{"PromQLCriteria":{"Query":"histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5","PendingPeriod":300,"RecoveryPeriod":600}}' \
--evaluation-interval 60
```
**Example 创建使用 SNS 通知操作的 PromQL 警报**
```
aws cloudwatch put-metric-alarm \
--alarm-name MyPromQLAlarmWithAction \
--evaluation-criteria '{"PromQLCriteria":{"Query":"my_gauge_metric < 20","PendingPeriod":0,"RecoveryPeriod":0}}' \
--evaluation-interval 60 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:MyTopic
```
## 通过 Query Studio 创建 PromQL 警报
此示例说明如何通过 Query Studio 创建 PromQL 警报，当某项服务的平均 HTTP 请求持续时间超过 500 毫秒时，该警报会向您发出提醒。
与将阈值配置为单独步骤的标准 CloudWatch 警报不同，PromQL 警报将警报条件（阈值）定义为查询本身的一部分。例如，比较运算符 (`>`) 和阈值 (`0.5`) 直接嵌入在 PromQL 表达式中。
**通过 Query Studio 创建 PromQL 警报**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在**指标**下方的导航窗格中，选择 **Query Studio（预览）**。
1. 从查询语言下拉菜单中选择 **PromQL**。
1. 使用以下模式之一构建查询：
+ 在**生成器**模式下，从**指标**字段中选择一个指标名称（例如 `http.server.request.duration`）。根据需要添加标签筛选器（例如 `@resource.service.name` = `my-api`）。要定义警报阈值，请选择**基本操作**（例如 `>`）并输入**数字**（例如 `0.5`）。
+ 在**代码**模式下，直接输入 PromQL 表达式，例如：
```
histogram_avg({"http.server.request.duration", "@resource.service.name"="my-api"}) > 0.5
```
1. 选择**运行**执行查询并验证查询是否返回预期结果。
1. 从操作菜单中选择**创建警报**。
1. 您将被重定向到 CloudWatch 警报创建页面，该页面预先填充了 PromQL 查询。
1. 在**条件**下面，指定以下内容：
+ 在**评估间隔**中，选择 **1 minute** 以定义评估 PromQL 查询的频率。
+ 在**待处理周期**中，输入 **60**，这是查询进入 ALARM 状态之前必须处于违规状态的持续时间（以秒为单位）。这意味着在警报触发之前，延迟必须超过阈值至少 60 秒。
+ 在**恢复周期**中，输入 **120**，这是查询进入 OK 状态之前不得违规的持续时间（以秒为单位）。这意味着在警报恢复之前，延迟必须保持在阈值以下至少 120 秒。
1. 根据需要配置通知和操作。
1. 添加告警的名称和描述。
1. 选择**下一步**。
1. 选择**创建警报**。
**注意**
PromQL 查询必须返回单个时间序列才能创建警报。如果查询返回多个时间序列，请在创建警报之前使用 `sum`、`avg` 或 `topk` 等聚合函数，将结果简化为单个序列。
# 根据日志触发警报
以下各节中的步骤说明了如何创建监测日志的 CloudWatch 警报。
## 根据日志组指标筛选条件创建 CloudWatch 告警
本节中的过程介绍如何根据日志组指标筛选器创建告警。使用指标筛选条件，您可以在日志数据发送到 CloudWatch 时查找其中的字词和模式。有关更多信息，请参阅《Amazon CloudWatch Logs 用户指南》中的 [使用筛选条件从日志事件创建指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)**。在根据日志组指标筛选器创建告警之前，您必须完成以下操作：
+ 创建日志组。有关更多信息，请参阅《Amazon CloudWatch Logs 用户指南》中的 [使用日志组和日志流](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#Create-Log-Group)**。
+ 创建指标筛选条件。有关更多信息，请参阅《Amazon CloudWatch Logs 用户指南》中的 [为日志组创建指标筛选条件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)**。
**要根据日志组指标筛选条件创建告警**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 从左侧导航窗格中，选择 **Logs**（日志），然后选择 **Log groups**（日志组）。
1. 选择包含您的指标筛选器的日志组。
1. 选择 **Metric filters**（指标筛选条件）。
1. 在指标筛选器选项卡中，选中要用于创建告警的指标筛选器对应的复选框。
1. 选择**创建警报**。
1. （可选）在 **Metric**（指标）下，编辑 **Metric name**（指标名称）、**Statistic**（统计数据）和 **Period**（周期）。
1. 在**条件**下面，指定以下内容：
1. 对于 **Threshold type**（阈值类型），选择 **Static**（静态）或 **Anomaly detection**（异常检测）。
1. 对于 **Whenever *your-metric-name* is . . .**（每当 your-metric-name . . .），选择 **Greater**（大于）、**Greater/Equal**（大于/等于）、**Lower/Equal**（小于/等于）或 **Lower**（小于）。
1. 对于 **than . . .**（相比 . . .），为您的阈值指定一个数值。
1. 选择**其他配置**。
1. 对于 **Data points to alarm**（触发告警的数据点数），指定多少数据点会触发您的告警进入 `ALARM` 状态。如果指定匹配的值，则如果多个连续评估期违例，该告警将变为 `ALARM` 状态。要创建 M-out-of-N（M（最大为 N））告警，为第一个值指定的数字应小于为第二个值指定的数字。有关更多信息，请参阅 [告警评估](alarm-evaluation.md)。
1. 对于 **Missing data treatment**（缺失数据处理），选择一个选项以指定在评估告警时如何应对缺失数据。
1. 选择**下一步**。
1. 对于 **Notification**（通知），选择当您的告警处于 `ALARM`、`OK` 或 `INSUFFICIENT_DATA` 状态时要通知的 Amazon SNS 主题。
1. （可选）要为相同告警状态或不同告警状态发送多个通知，请选择 **Add notification**（添加通知）。
1. （可选）要想不发送通知，请选择 **Remove**（删除）。
1. 要让警报执行 Auto Scaling、EC2、Lambda 或 Systems Manager 操作，请选择相应的按钮，然后选择警报状态和要执行的操作。如果您选择 Lambda 函数作为警报操作，则需要指定函数名称或 ARN，并且可以选择该函数的特定版本。
告警只有在进入“ALARM（告警）”状态时才能执行 Systems Manager 操作。有关 Systems Manager 操作的更多信息，请参阅[将 CloudWatch 配置为通过告警创建 OpsItems ](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)和[事件创建](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
**注意**
要创建执行 SSM Incident Manager 操作的告警，您必须具有特定的权限。有关更多信息，请参阅 [AWS Systems Manager Incident Manager 的基于身份的策略示例](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html)。
1. 选择**下一步**。
1. 对于**名称和描述**，输入告警的名称和描述。名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
1. 对于 **Preview and create**（预览并创建），确保您的配置正确，然后选择 **Create alarm**（创建警告）。
# 创建复合告警
本部分中的步骤说明了如何使用 CloudWatch 控制台创建复合告警。您还可以使用 API 或 AWS CLI 创建复合告警。有关更多信息，请参阅 [PutCompositeAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutCompositeAlarm.html) 或 [put-composite-alarm](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-composite-alarm.html)
**创建复合告警**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择 **Alarms**（告警），然后选择 **All alarms**（所有告警）。
1. 在告警列表中，选中要在规则表达式中引用的每个现有告警旁边的复选框，然后选择 **Create composite alarm**（创建复合告警）。
1. 在 **Specify composite alarm conditions**（指定复合告警条件）中，指定新复合告警的规则表达式。
**注意**
您从告警列表中选择的告警将自动列在 **Conditions**（条件）框中。默认情况下，`ALARM` 函数已指定给您的每个告警，并且每个告警都由逻辑运算符 `OR` 连接。
您可以使用以下子步骤修改规则表达式：
1. 您可以将每个告警的所需状态从 `ALARM` 更改为 `OK` 或 `INSUFFICIENT_DATA`。
1. 您可以将规则表达式中的逻辑运算符从 `OR` 更改为 `AND` 或 `NOT`，并且您可以添加括号来对函数进行分组。
1. 您可以在规则表达式中包含其他告警，也可以从规则表达式中删除告警。
**Example: Rule expression with conditions**（示例：带条件的规则表达式）
```
(ALARM("CPUUtilizationTooHigh") OR
ALARM("DiskReadOpsTooHigh")) AND
OK("NetworkOutTooHigh")
```
复合告警在 ALARM（“CPUUtilizationTooHigh”）或 ALARM（“DiskReadOpsTooHigh”）处于 `ALARM` 状态且同时 OK（“NetworkOutTooHigh”）处于 `OK` 状态时进入 `ALARM` 的情况下的示例规则表达式。
1. 在完成后，选择**下一步**。
1. 在 **Configure actions**（配置操作）下，您可以从以下选项中进行选择：
对于***Notification***（通知）
+ **Select an exisiting SNS topic**（选择一个现有的 SNS 主题）、**Create a new SNS topic**（创建新 SNS 主题），或者 **Use a topic ARN**（使用主题 ARN）定义将接收通知的 SNS 主题。
+ **Add notification**（添加通知），以便为相同告警状态或不同告警状态发送多个通知。
+ **Remove**（删除）以阻止您的告警发送通知或采取措施。
（可选）要让警报在状态更改时调用 Lambda 函数，请选择**添加 Lambda 操作**。然后指定函数名称或 ARN，也可以选择该函数的特定版本。
对于 ***Systems Manager action***（Systems Manager 操作）
+ **Add Systems Manager action**（添加 Systems Manager 操作），以便您的告警可以在进入 ALARM 状态时执行 SSM 操作。
要了解有关 Systems Manager 操作的更多信息，请参阅《AWS Systems Manager 用户指南》中的 [配置 CloudWatch 以从告警中创建 OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)** 和《Incident Manager 用户指南》中的 [事件创建](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)**。要创建执行 SSM Incident Manager 操作的告警，您必须具有正确的权限。有关更多信息，请参阅《Incident Manager 用户指南》中的 [AWS Systems Manager Incident Manager 的基于身份的策略示例](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html)**。
要让警报启动调查，请选择**添加调查操作**，然后选择调查组。有关 的更多信息，请参阅 [CloudWatch 调查](Investigations.md)。
1. 在完成后，选择**下一步**。
1. 在 **Add name and description**（添加名称和描述）下，为您的新复合告警输入告警名称和*可选*描述。名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
1. 在完成后，选择**下一步**。
1. 在 **Preview and create**（预览和创建）下，确认您的信息，然后选择 **Create composite alarm**（创建复合告警）。
**注意**
您可以创建一个复合告警循环，其中一个复合告警和另一个复合告警相互依赖。如果处于这种情况，则复合告警将停止被评估，并且您无法删除复合告警，因为它们相互依赖。要打破复合告警之间的依赖循环，最简单的方法是将您的其中一个复合告警中的函数 `AlarmRule` 更改为 `False`。
# 根据警报更改执行操作
CloudWatch 可以在发生两种类型的警报更改时通知用户：警报状态更改和警报配置更新。
当告警在进行评估时，其状态可能会变为其他状态，例如“ALARM”或“OK”。对于监控多个时间序列的 Metrics Insights 告警，每个时间序列（影响因素）只能处于“ALARM”或“OK”状态，绝不能处于 INSUFFICIENT\$1DATA 状态。这是因为只有在数据存在的情况下，时间序列才会存在。
此外，每当警报状态更改以及创建、删除或更新警报时，CloudWatch 都会将事件发送到 Amazon EventBridge。您可以编写 EventBridge 规则，从而在 EventBridge 收到这些事件时执行操作或通知您。
有关告警操作的更多信息，请参阅 [告警操作](alarm-actions.md)。
**Topics**
+ [将警报更改通知用户](Notify_Users_Alarm_Changes.md)
+ [从警报中调用 Lambda 函数](alarms-and-actions-Lambda.md)
+ [从警报启动 CloudWatch 调查](Start-Investigation-Alarm.md)
+ [停止、终止、重启或恢复 EC2 实例](UsingAlarmActions.md)
+ [告警事件和 EventBridge](cloudwatch-and-eventbridge.md)
# 将警报更改通知用户
本节说明了如何使用 AWS User Notifications 或 Amazon Simple Notification Service，来让用户收到有关警报更改的通知。
## 设置 AWS User Notifications
您可以使用 [AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) 来设置传输渠道，以用于接收有关 CloudWatch 警报状态更改和配置更改事件的通知。当事件与指定的规则匹配时，会收到通知。您可以通过多个渠道接收事件通知，包括电子邮件、[AWS Chatbot](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) 聊天通知或 [AWS 控制台移动应用程序推送通知](https://docs.aws.amazon.com/consolemobileapp/latest/userguide/managing-notifications.html)。您还可以在 [控制台通知中心](https://console.aws.amazon.com/notifications) 中查看通知。用户通知支持聚合，这可以减少在具体事件期间收到的通知数量。
您使用 AWS User Notifications 创建的通知配置不会计入您可以为每个目标警报状态配置的操作数量限制。当 AWS 用户通知服务对发送给 Amazon EventBridge 的事件进行匹配时，除非您指定高级筛选条件来将特定的警报或模式列入允许列表或拒绝列表，否则会针对您账户和选定区域中的所有警报发送通知。
以下高级筛选条件示例将对名为 `ServerCpuTooHigh` 的警报从“正常”变为“警报”的警报状态更改进行匹配。
```
{
"detail": {
"alarmName": ["ServerCpuTooHigh"],
"previousState": { "value": ["OK"] },
"state": { "value": ["ALARM"] }
}
}
```
您可以使用警报在 EventBridge 事件中发布的任何属性来创建筛选条件。有关更多信息，请参阅 [告警事件和 EventBridge](cloudwatch-and-eventbridge.md)。
## 设置 Amazon SNS 通知
您可以使用 Amazon Simple Notification Service 来发送应用程序到应用程序（A2A）消息和应用程序对人（A2P）消息，包括手机短信（SMS）和电子邮件。有关更多信息，请参阅 [Amazon SNS 事件目标](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html)。
对于警报可能处于的每种状态，您都可以将警报配置为向某个 SNS 主题发送消息。您为给定警报状态配置的每个 Amazon SNS 主题，都将计入您可以为该警报和状态配置的操作数量限制。您可以从账户中的任何警报向同一 Amazon SNS 主题发送消息，并为应用程序（A2A）和个人（A2P）消费端使用相同的 Amazon SNS 主题。由于此配置是在警报级别进行的，因此只有您配置的警报才会向所选的 Amazon SNS 主题发送消息。
首先，创建一个主题，然后订阅此主题。您可以选择将测试消息发布到此主题。有关示例，请参阅[使用 AWS 管理控制台 设置 Amazon SNS 主题](#set-up-sns-topic-console)。有关更多信息，请参阅 [Amazon SNS 入门](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)。
或者，如果您计划使用 AWS 管理控制台来创建 CloudWatch 警报，则可跳过此过程，因为您可在创建警报时创建主题。
创建 CloudWatch 警报时，您可以为任何警报目标状态添加操作。为您想要收到通知的状态添加 Amazon SNS 通知，然后选择您在上一步中创建的 Amazon SNS 主题，从而在警报进入选定状态时发送电子邮件通知。
**注意**
在创建 Amazon SNS 主题时，您可以选择将其设为*标准主题*或 *FIFO 主题*。CloudWatch 定会将所有告警通知发布到这两种类型的主题。但是，即使您使用 FIFO 主题，在极少数情况下，CloudWatch 也会不按顺序将通知发送到该主题。如果您使用 FIFO 主题，告警会将告警通知的消息组 ID 设置为告警的 ARN 的哈希值。
**Topics**
+ [防止混淆代理安全问题](#SNS_Confused_Deputy)
+ [使用 AWS 管理控制台 设置 Amazon SNS 主题](#set-up-sns-topic-console)
+ [使用 AWS CLI 设置 SNS 主题](#set-up-sns-topic-cli)
### 防止混淆代理安全问题
混淆代理问题是一个安全性问题，即不具有某操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。在 AWS 中，跨服务模拟可能会导致混淆代理问题。一个服务（*呼叫服务*）调用另一项服务（*所谓的服务*）时，可能会发生跨服务模拟。可以操纵调用服务，使用其权限以在其他情况下该服务不应有访问权限的方式对另一个客户的资源进行操作。为防止这种情况，AWS 提供可帮助您保护所有服务的数据的工具，而这些服务中的服务主体有权限访问账户中的资源。
建议在资源策略中使用 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) 和 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths) 全局条件上下文键，以限制 Amazon SNS 为其他服务提供的资源访问权限。使用 `aws:SourceArn` 来仅将一个资源与跨服务访问相关联。使用 `aws:SourceAccount` 来让该账户中的任何资源与跨服务使用相关联。使用 `aws:SourceOrgID` 来允许某组织内的任何账户中的任何资源与跨服务使用相关联。使用 `aws:SourceOrgPaths` 来将 AWS Organizations 路径内账户中的任何资源与跨服务使用相关联。有关使用和了解路径的更多信息，请参阅《IAM 用户指南》中的 [aws:SourceOrgPaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths)。
防范混淆代理问题最有效的方法是使用 `aws:SourceArn` 全局条件上下文键和资源的完整 ARN。如果不知道资源的完整 ARN，或者正在指定多个资源，请针对 ARN 未知部分使用带有通配符字符（`*`）的 `aws:SourceArn` 全局上下文条件键。例如 `arn:aws:servicename:*:123456789012:*`。
如果 `aws:SourceArn` 值不包含账户 ID，例如 Amazon S3 桶 ARN，您必须使用 `aws:SourceAccount` 和 `aws:SourceArn` 来限制权限。
要防范大规模混淆代理问题，请在基于资源的策略中将 `aws:SourceOrgID` 或 `aws:SourceOrgPaths` 全局条件上下文键与资源的组织 ID 或组织路径一起使用。包含 `aws:SourceOrgID` 或 `aws:SourceOrgPaths` 键的策略将自动包含正确的账户，并且当您在组织中添加、删除或移动账户时，无需手动更新策略。
`aws:SourceArn` 的值必须是发送通知的警报的 ARN。
以下示例演示如何在 CloudWatch 中使用 `aws:SourceArn` 和 `aws:SourceAccount` 全局条件上下文键来防范混淆代理问题。
```
{
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "cloudwatch.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-2:444455556666:MyTopic",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:cloudwatch:us-east-2:111122223333:alarm:*"
},
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}]
}
```
如果警报 ARN 包含任何非 ASCII 字符，请仅使用 `aws:SourceAccount` 全局条件键限制权限。
### 使用 AWS 管理控制台 设置 Amazon SNS 主题
首先，创建一个主题，然后订阅此主题。您可以选择将测试消息发布到此主题。
**创建 SNS 主题**
1. 通过 [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home) 打开 Amazon SNS 控制台。
1. 在 Amazon SNS 控制面板上的 **Common actions（常用操作）**下，选择 **Create Topic（创建主题）**。
1. 在 **Create new topic（创建新主题）**对话框中，为 **Topic name（主题名称）**输入主题的名称（例如 **my-topic**）。
1. 选择 **Create topic（创建主题）**。
1. 复制下一个任务的 **Topic ARN（主题 ARN）**（例如 arn:aws:sns:us-east-1:111122223333:my-topic）。
**订阅 SNS 主题**
1. 通过 [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home) 打开 Amazon SNS 控制台。
1. 在导航窗格中，依次选择 **Subscriptions（订阅）**、**Create subscription（创建订阅）**。
1. 在 **Create subscription（创建订阅）**对话框中，为 **Topic ARN（主题 ARN）**粘贴在上一任务中创建的主题 ARN。
1. 对于**协议**，选择**电子邮件**。
1. 对于 **Endpoint（端点）**，输入一个可用于接收通知的电子邮件地址，然后选择 **Create subscription（创建订阅）**。
1. 从您的电子邮件应用程序中，打开来自 AWS 通知的消息并确认您的订阅。
您的 Web 浏览器将显示来自 Amazon SNS 的确认响应。
**向 SNS 主题发布测试消息**
1. 通过 [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home) 打开 Amazon SNS 控制台。
1. 在导航窗格中，选择 **Topics（主题）**。
1. 在 **Topics（主题）**页面上，选择一个主题，然后选择 **Publish to topic（发布到主题）**。
1. 在 **Publish（发布消息）**页面中，为 **Subject（主题）**输入消息的主题行，并为 **Message（消息）**输入简短的消息。
1. 选择 **Publish Message（发布消息）**。
1. 查看电子邮件，确认您已收到消息。
### 使用 AWS CLI 设置 SNS 主题
首先，您创建一个 SNS 主题，然后将一条消息直接发布到该主题，以测试您是否正确配置了该主题。
**设置 SNS 主题**
1. 使用 [create-topic](https://docs.aws.amazon.com/cli/latest/reference/sns/create-topic.html) 命令创建主题，如下所示。
```
1. aws sns create-topic --name my-topic
```
Amazon SNS 返回具有以下格式的主题 ARN：
```
1. {
2. "TopicArn": "arn:aws:sns:us-east-1:111122223333:my-topic"
3. }
```
1. 使用 [subscribe](https://docs.aws.amazon.com/cli/latest/reference/sns/subscribe.html) 命令以通过您的电子邮件地址订阅该主题。如果订阅请求成功，您将收到一封确认电子邮件。
```
1. aws sns subscribe --topic-arn arn:aws:sns:us-east-1:111122223333:my-topic --protocol email --notification-endpoint my-email-address
```
Amazon SNS 将返回以下内容：
```
1. {
2. "SubscriptionArn": "pending confirmation"
3. }
```
1. 从您的电子邮件应用程序中，打开来自 AWS 通知的消息并确认您的订阅。
您的 Web 浏览器将显示来自 Amazon Simple Notification Service 的确认响应。
1. 使用 [list-subscriptions-by-topic](https://docs.aws.amazon.com/cli/latest/reference/sns/list-subscriptions-by-topic.html) 命令检查订阅。
```
1. aws sns list-subscriptions-by-topic --topic-arn arn:aws:sns:us-east-1:111122223333:my-topic
```
Amazon SNS 将返回以下内容：
```
1. {
2. "Subscriptions": [
3. {
4. "Owner": "111122223333",
5. "Endpoint": "me@mycompany.com",
6. "Protocol": "email",
7. "TopicArn": "arn:aws:sns:us-east-1:111122223333:my-topic",
8. "SubscriptionArn": "arn:aws:sns:us-east-1:111122223333:my-topic:64886986-bf10-48fb-a2f1-dab033aa67a3"
9. }
10. ]
11. }
```
1. （可选）使用 [publish](https://docs.aws.amazon.com/cli/latest/reference/sns/publish.html) 命令向主题发布测试消息。
```
1. aws sns publish --message "Verification" --topic arn:aws:sns:us-east-1:111122223333:my-topic
```
Amazon SNS 将返回以下内容。
```
1. {
2. "MessageId": "42f189a0-3094-5cf6-8fd7-c2dde61a4d7d"
3. }
```
1. 查看电子邮件，确认您已收到消息。
## 警报状态更改时的 Amazon SNS 通知架构
本节列举了警报状态更改时向 Amazon SNS 主题发送的通知的架构。
**指标警报状态更改时的架构**
```
{
"AlarmName": "string",
"AlarmDescription": "string",
"AWSAccountId": "string",
"AlarmConfigurationUpdatedTimestamp": "string",
"NewStateValue": "string",
"NewStateReason": "string",
"StateChangeTime": "string",
"Region": "string",
"AlarmArn": "string",
"OldStateValue": "string",
"OKActions": ["string"],
"AlarmActions": ["string"],
"InsufficientDataActions": ["string"],
"Trigger": {
"MetricName": "string",
"Namespace": "string",
"StatisticType": "string",
"Statistic": "string",
"Unit": "string or null",
"Dimensions": [
{
"value": "string",
"name": "string"
}
],
"Period": "integer",
"EvaluationPeriods": "integer",
"DatapointsToAlarm": "integer",
"ComparisonOperator": "string",
"Threshold": "number",
"TreatMissingData": "string",
"EvaluateLowSampleCountPercentile": "string or null"
}
}
```
**复合指标警报状态更改时的架构**
```
{
"AlarmName": "string",
"AlarmDescription": "string",
"AWSAccountId": "string",
"NewStateValue": "string",
"NewStateReason": "string",
"StateChangeTime": "string",
"Region": "string",
"AlarmArn": "string",
"OKActions": [String],
"AlarmActions": [String],
"InsufficientDataActions": [String],
"OldStateValue": "string",
"AlarmRule": "string",
"TriggeringChildren": [String]
}
```
# 从警报中调用 Lambda 函数
CloudWatch 警报可保证在给定状态变化时异步调用 Lambda 函数，但以下情况除外：
+ 当该函数不存在时。
+ 当 CloudWatch 未被授权调用该 Lambda 函数时。
如果 CloudWatch 无法访问 Lambda 服务或消息因其他原因被拒绝，CloudWatch 会不断重试，直到调用成功。Lambda 将消息加入队列并处理执行重试。有关这种执行模式的更多信息，包括有关 Lambda 如何处理错误的信息，请参阅《AWS Lambda 开发人员指南》中的 [Asynchronous invocation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html)。
可以调用同一账户中的 Lambda 函数，也可以调用其他 AWS 账户中的 Lambda 函数。
当您指定一个警报以调用 Lambda 函数作为警报操作时，您可以选择指定函数名称、函数别名或函数的特定版本。
当您将一个 Lambda 函数指定为警报操作时，必须为该函数创建一个资源策略，以允许 CloudWatch 服务主体调用该函数。
一种方法是使用 AWS CLI，如下例所示：
```
aws lambda add-permission \
--function-name my-function-name \
--statement-id AlarmAction \
--action 'lambda:InvokeFunction' \
--principal lambda.alarms.cloudwatch.amazonaws.com \
--source-account 111122223333 \
--source-arn arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name
```
或者，您可以创建一个类似于以下示例之一的策略，然后将其分配给该函数。
以下示例指定警报所在的账户，因此只有该账户（111122223333）中的警报才能调用该函数。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [{
"Sid": "AlarmAction",
"Effect": "Allow",
"Principal": {
"Service": "lambda.alarms.cloudwatch.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333"
}
}
}]
}
```
------
以下示例的范围较窄，仅允许指定账户中的指定警报调用该函数。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "AlarmAction",
"Effect": "Allow",
"Principal": {
"Service": "lambda.alarms.cloudwatch.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333",
"AWS:SourceArn": "arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name"
}
}
}]
}
```
------
我们不建议创建未指定来源账户的策略，因为此类策略容易受到混淆代理问题的影响。
## 将 Lambda 指标添加到 CloudWatch 调查中
您可以将 Lambda 指标添加到处于活动状态的 CloudWatch 调查中。在调查问题时，Lambda 指标可以提供有关函数性能和行为的宝贵洞察。例如，如果您正在调查应用程序性能问题，则持续时间、错误率或节流等 Lambda 指标可能有助于确定根本原因。
要将 Lambda 指标添加到 CloudWatch 调查中，请执行以下操作：
1. 通过 [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/) 打开 AWS Lambda 控制台。
1. 在**监控**部分中，找到该指标。
1. 打开指标的上下文菜单，依次选择**调查**、**添加到调查中**。然后，在**调查**窗格中，选择调查名称。
## 从 CloudWatch 发送到 Lambda 的事件对象
当您将一个 Lambda 函数配置为警报操作时，CloudWatch 会在调用 Lambda 函数时向该函数传送一个 JSON 有效负载。此 JSON 有效负载用作函数的事件对象。您可以从此 JSON 对象中提取数据并将其用于您的函数。以下是指标警报中事件对象的示例。
```
{
'source': 'aws.cloudwatch',
'alarmArn': 'arn:aws:cloudwatch:us-east-1:444455556666:alarm:lambda-demo-metric-alarm',
'accountId': '444455556666',
'time': '2023-08-04T12:36:15.490+0000',
'region': 'us-east-1',
'alarmData': {
'alarmName': 'lambda-demo-metric-alarm',
'state': {
'value': 'ALARM',
'reason': 'test',
'timestamp': '2023-08-04T12:36:15.490+0000'
},
'previousState': {
'value': 'INSUFFICIENT_DATA',
'reason': 'Insufficient Data: 5 datapoints were unknown.',
'reasonData': '{"version":"1.0","queryDate":"2023-08-04T12:31:29.591+0000","statistic":"Average","period":60,"recentDatapoints":[],"threshold":5.0,"evaluatedDatapoints":[{"timestamp":"2023-08-04T12:30:00.000+0000"},{"timestamp":"2023-08-04T12:29:00.000+0000"},{"timestamp":"2023-08-04T12:28:00.000+0000"},{"timestamp":"2023-08-04T12:27:00.000+0000"},{"timestamp":"2023-08-04T12:26:00.000+0000"}]}',
'timestamp': '2023-08-04T12:31:29.595+0000'
},
'configuration': {
'description': 'Metric Alarm to test Lambda actions',
'metrics': [
{
'id': '1234e046-06f0-a3da-9534-EXAMPLEe4c',
'metricStat': {
'metric': {
'namespace': 'AWS/Logs',
'name': 'CallCount',
'dimensions': {
'InstanceId': 'i-12345678'
}
},
'period': 60,
'stat': 'Average',
'unit': 'Percent'
},
'returnData': True
}
]
}
}
}
```
以下是复合警报中事件对象的示例。
```
{
'source': 'aws.cloudwatch',
'alarmArn': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:SuppressionDemo.Main',
'accountId': '111122223333',
'time': '2023-08-04T12:56:46.138+0000',
'region': 'us-east-1',
'alarmData': {
'alarmName': 'CompositeDemo.Main',
'state': {
'value': 'ALARM',
'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC',
'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}',
'timestamp': '2023-08-04T12:56:46.138+0000'
},
'previousState': {
'value': 'ALARM',
'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC',
'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}',
'timestamp': '2023-08-04T12:54:46.138+0000',
'actionsSuppressedBy': 'WaitPeriod',
'actionsSuppressedReason': 'Actions suppressed by WaitPeriod'
},
'configuration': {
'alarmRule': 'ALARM(CompositeDemo.FirstChild) OR ALARM(CompositeDemo.SecondChild)',
'actionsSuppressor': 'CompositeDemo.ActionsSuppressor',
'actionsSuppressorWaitPeriod': 120,
'actionsSuppressorExtensionPeriod': 180
}
}
}
```
# 从警报启动 CloudWatch 调查
可以从警报，或从 CloudWatch 警报历史记录的过去两周内的任何时间点启动调查。
有关 CloudWatch 调查的更多信息，请参阅 [CloudWatch 调查](Investigations.md)。
## 先决条件
从 CloudWatch 警报启动 CloudWatch 调查之前，必须为函数创建资源策略，以允许 CloudWatch 服务主体启动调查。要使用 AWS CLI 执行此操作，请使用类似于以下示例的命令：
```
aws aiops put-investigation-group-policy \
--identifier arn:aws:aiops:us-east-1:111122223333:investigation-group/investigation_group_id \
--policy "{\"Version\":\"2008-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"aiops.alarms.cloudwatch.amazonaws.com\"},\"Action\":[\"aiops:CreateInvestigation\",\"aiops:CreateInvestigationEvent\"],\"Resource\":\"*\",\"Condition\":{\"StringEquals\":{\"aws:SourceAccount\":\"111122223333\"},\"ArnLike\":{\"aws:SourceArn\":\"arn:aws:cloudwatch:us-east-1:111122223333:alarm:*\"}}}]}" \
--region eu-north-1
```
将示例值替换为您的 AWS 账户 ID、区域和调查组 ID。
**从 CloudWatch 警报启动调查**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在左侧导航窗格中，依次选择**警报**和**所有警报**。
1. 选择警报的名称。
1. 在警报历史记录中选择要调查的时间段。
1. 依次选择**调查**、**启动新的调查**。
1. 在**新调查标题**中，输入调查的名称。然后选择**开始调查**。
CloudWatch 调查助手会启动并扫描您的遥测数据，查找可能与这种情况相关的数据。
1. 在 CloudWatch 控制台的导航窗格中，选择**调查**，然后选择您刚刚启动的调查名称。
**调查发现**部分以自然语言显示警报状态及其触发原因的摘要。
1. （可选）在警报图表中，右键单击，然后选择深入查看警报或其监视的指标。
1. 在屏幕右侧，选择**建议**选项卡。
随即显示 CloudWatch 调查发现的其他遥测数据清单，内含可能与调查有关的遥测数据。这些调查发现可能包括其他指标和 CloudWatch Logs Insights 查询结果。CloudWatch 调查根据警报运行了这些查询。
+ 对于每个调查发现，选择**添加到调查发现**或**放弃**。
选择**添加到调查发现**后，遥测数据会添加到**调查发现**部分，CloudWatch 调查功能会使用此信息来指导其进一步的扫描和建议。
+ 对于 CloudWatch Logs Insights 查询结果，要更改或编辑查询并重新运行，请打开结果的上下文（右键单击）菜单，然后选择**在 Logs Insights 中打开**。有关更多信息，请参阅[使用 CloudWatch Logs Insights 分析日志数据](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)。
要运行不同的查询，进入 Logs Insights 页面时，选择使用查询助手，就能够使用自然语言来形成查询。有关更多信息，请参阅[使用自然语言生成和更新 CloudWatch Logs Insights 查询](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs-Insights-Query-Assist.html)。
+ （可选）如果您知道另一项 AWS 服务中的遥测数据可能适用于此调查，请转到该服务的控制台，将该遥测数据添加到此调查中。
1. CloudWatch 调查还可能将假设添加到**建议**选项卡的列表中。这些假设由调查得出，以自然语言显示。
对于每个假设，选择**添加到调查发现**或**放弃**。
1. 您认为已经完成调查并找到了问题的根本原因时，请选择**概述**选项卡，然后选择**调查摘要**。然后，CloudWatch 调查会以自然语言汇总由调查得出的重要调查发现和假设。
# 停止、终止、重启或恢复 EC2 实例
利用 Amazon CloudWatch 告警操作，您可创建自动停止、终止、重启或恢复 EC2 实例的告警。当不再需要某个实例运行时，您可使用停止或终止操作来帮助您节省资金。如果发生了系统损害，您可使用重启和恢复操作自动重启这些实例或将它们恢复到新硬件上。
在许多情况下，您可能需要自动终止或停止实例。例如，您可能拥有专用于批工资单处理作业或科学计算任务的实例，这些实例在运行一段时间后就完成了其工作。与其让这些实例空闲（并产生费用），不如将其停止或终止以帮助节省开支。使用停止警报操作和终止警报操作的主要区别是，停止的警报可以在以后需要运行时轻松重启。您还可以保留相同的实例 ID 和根卷。而终止的实例则无法重新启动。如此就必须启动一个新的实例。
您可以向为 Amazon EC2 每个实例指标设置的任何告警添加停止、终止或重启操作，这些指标包括 Amazon CloudWatch 提供的基本和详细监控指标（在亚马逊云科技/EC2 命名空间中），以及包含“InstanceId=”维度的任何自定义指标，只要 InstanceId 值引用有效运行的 Amazon EC2 实例。您还可以将恢复操作添加到针对任何 Amazon EC2 每个实例指标设置的告警中，但以下情况除外：`StatusCheckFailed_Instance`。
**重要**
如果缺失指标数据点，则在 Amazon EC2 指标上配置的警报可能会暂时进入 INSUFFICIENT\$1DATA 状态。这种情况很少见，但在指标报告中断时可能会发生，即使在 Amazon EC2 实例运行正常的情况下也是如此。对于配置为采取停止、终止、重启或恢复操作的 Amazon EC2 指标的警报，我们建议您将这些警报配置为将缺失的数据视为 `missing`，并使这些警报仅在处于 ALARM 状态时被触发。
有关如何配置 CloudWatch 对已设置警报的缺失指标执行操作的更多信息，请参阅 [配置 CloudWatch 告警处理缺失数据的方式](alarms-and-missing-data.md)。
要设置可重启、停止或终止实例的 CloudWatch 告警操作，您必须使用服务相关的 IAM 角色 *AWSServiceRoleForCloudWatchEvents*。AWSServiceRoleForCloudWatchEvents IAM 角色允许 AWS 代表您执行告警操作。
要为 CloudWatch Events 创建服务相关角色，请使用以下命令：
```
aws iam create-service-linked-role --aws-service-name events.amazonaws.com
```
**控制台支持**
您可使用 CloudWatch 控制台或 Amazon EC2 控制台创建告警。本文档中的程序使用 CloudWatch 控制台。有关使用 Amazon EC2 控制台的过程，请参阅《*Amazon EC2 用户指南*》中的[创建停止、终止、重启或恢复实例的警报](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingAlarmActions.html)。
**权限**
如果您使用 AWS Identity and Access Management (IAM) 账户来创建或修改执行 EC2 操作或 Systems Manager OpsItem 操作的告警，您必须拥有 `iam:CreateServiceLinkedRole` 权限。
**Topics**
+ [在 Amazon CloudWatch 告警中添加停止操作](#AddingStopActions)
+ [在 Amazon CloudWatch 告警中添加终止操作](#AddingTerminateActions)
+ [在 Amazon CloudWatch 告警中添加重启操作](#AddingRebootActions)
+ [在 Amazon CloudWatch 告警中添加恢复操作](#AddingRecoverActions)
+ [查看已触发的告警和操作的历史记录](#ViewAlarmHistory)
## 在 Amazon CloudWatch 告警中添加停止操作
可以创建当达到一定阈值后停止 Amazon EC2 实例的警报。例如，您可能运行了开发或测试实例而偶尔忘记将其关闭。可以创建当平均 CPU 使用率低于 10% 达 24 小时时触发的警报，同时告知其为空闲并不再使用。可以根据需要调整阈值、时长和时间段，还可以添加 SNS 通知，以便您在触发警报后能够收到电子邮件。
可以停止或终止将 Amazon Elastic Block Store 卷用作根设备的 Amazon EC2 实例，但只能终止将实例存储用作根设备的实例。
**使用 Amazon CloudWatch 控制台创建停止空闲实例的告警**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms（警报）**和 **All alarms（所有警报）**。
1. 选择**创建警报**。
1. 选择 **Select Metric（选择指标）**。
1. 对于 **AWS 命名空间**，请选择 **EC2**。
1. 执行以下操作：
1. 选择 **Per-Instance Metrics**（每个实例的指标）。
1. 选择包含正确实例和 **CPUUtilization** 指标的行中的复选框。
1. 选择**绘成图表的指标**选项卡。
1. 对于统计数据，选择 **Average（平均值）**。
1. 选择时间段（例如 **1 Hour**）。
1. 选择**选择指标**。
1. 在 **Conditions**（条件）下，执行以下操作：
1. 选择 **Static**（静态）。
1. 在 **Whenever CPUUtilization is**（每当 CPUUtilization）下，选择 **Lower**（降低）。
1. 对于 **than**（比较），键入 **10**。
1. 选择**下一步**。
1. 在 **Notification** 下，为 **Send notification to** 选择一个现有 SNS 主题或创建一个新 SNS 主题。
要创建 SNS 主题，请选择 **New list（新列表）**。对于**发送通知到**，键入 SNS 主题的名称（例如“Stop\$1EC2\$1Instance”）。对于 **Email list (电子邮件列表)**，请键入警报变为 `ALARM` 状态时将通知发送到的电子邮件地址列表（以逗号分隔）。将向每个电子邮件地址发送一封主题订阅确认电子邮件。您必须先确认订阅，然后才能将通知发送到电子邮件地址。
1. 选择 **Add EC2 Action**（添加 EC2 操作）。
1. 对于 **Alarm state trigger**（告警状态触发器），选择 **In alarm**（在告警中）。对于 **Take the following action**（请执行以下操作），选择 **Stop this instance**（停止此实例）。
1. 选择**下一步**。
1. 输入警报的名称和说明。名称只能包含 ASCII 字符。然后选择**下一步**。
1. 在 **Preview and create** 下面，确认具有所需的信息和条件，然后选择 **Create alarm**。
## 在 Amazon CloudWatch 告警中添加终止操作
可以创建当达到一定阈值时自动终止 EC2 实例的警报 (只要该实例未启用终止保护)。例如，某个实例已经完成工作，您不再需要此实例而希望将其终止。如果可能在之后使用该实例，则应该选择停止而不是终止。有关为实例启用和禁用终止保护的信息，请参阅《Amazon EC2 用户指南》**中的[为实例启用终止保护](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_ChangingDisableAPITermination.html)。
**使用 Amazon CloudWatch 控制台创建终止空闲实例的告警**
1. 通过以下网址打开 CloudWatch 控制台：[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。
1. 在导航窗格中，依次选择 **Alarms** 和 **Create Alarm**。
1. 对于 **Select Metric** 步骤，执行以下操作：
1. 在 **EC2 Metrics** 下，选择 **Per-Instance Metrics**。
1. 选择包含实例和 **CPUUtilization** 指标的行。
1. 对于统计数据，选择 **Average（平均值）**。
1. 选择时间段（例如 **1 Hour**）。
1. 选择**下一步**。
1. 对于 **Define Alarm** 步骤，执行以下操作：
1. 在 **Alarm Threshold** 下，键入警报的唯一名称 (例如“Terminate EC2 instance”) 和警报的描述 (例如“Terminate EC2 instance when CPU is idle for too long”)。警报名称必须仅包含 ASCII 字符。
1. 在**每当**下，为 **是**选择 **<** 并键入 **10**。对于**对于**，键入 **24** 作为连续时段数。
**Alarm Preview（告警预览）**下会显示阈值的图形表示。
1. 在 **Notification** 下，为 **Send notification to** 选择一个现有 SNS 主题或创建一个新 SNS 主题。
要创建 SNS 主题，请选择 **New list（新列表）**。对于**发送通知到**，键入 SNS 主题的名称（例如“Terminate\$1EC2\$1Instance”）。对于 **Email list (电子邮件列表)**，请键入警报变为 `ALARM` 状态时将通知发送到的电子邮件地址列表（以逗号分隔）。将向每个电子邮件地址发送一封主题订阅确认电子邮件。您必须先确认订阅，然后才能将通知发送到电子邮件地址。
1. 选择 **EC2 Action**。
1. 对于**每当此警报**，请选择**状态为“警报”**。对于 **Take this action**，选择 **Terminate this instance**。
1. 选择**创建警报**。
## 在 Amazon CloudWatch 告警中添加重启操作
您可创建监控 Amazon EC2 实例并自动重启此实例的 Amazon CloudWatch 警报。在实例运行状况检查失败时，推荐重启警报操作（与恢复警报操作相反，该操作适合系统运行状况检查失败的情况）。实例重启相当于操作系统重启。在许多情况下，只需要几分钟时间即可重启您的实例。重启实例时，其仍驻留在相同的物理主机上，因此您的实例将保留其公有 DNS 名称、私有 IP 地址及其实例存储卷上的任何数据。
重启实例不会启动新的实例计费时间，这与停止并重新启动您的实例不同。有关重新启动实例的更多信息，请参阅《Amazon EC2 用户指南》**中的[重启实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html)。
**重要**
为了避免重启操作与恢复操作之间的竞争情况，请避免为重启警报和恢复警报设置相同的评估期。我们建议您将重启警报设置为 3 个 1 分钟的评估期。
**使用 Amazon CloudWatch 控制台创建重启实例的告警**
1. 通过以下网址打开 CloudWatch 控制台：[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。
1. 在导航窗格中，依次选择 **Alarms** 和 **Create Alarm**。
1. 对于 **Select Metric** 步骤，执行以下操作：
1. 在 **EC2 Metrics** 下，选择 **Per-Instance Metrics**。
1. 选择包含实例和 **StatusCheckFailed\$1Instance** 指标的行。
1. 对于统计数据，选择 **Minimum**。
1. 选择时间段（例如 **1 Minute**）。
1. 选择**下一步**。
1. 对于 **Define Alarm** 步骤，执行以下操作：
1. 在 **Alarm Threshold** 下，键入警报的唯一名称 (例如“Reboot EC2 instance”) 和警报的描述 (例如“Reboot EC2 instance when health checks fail”)。警报名称必须仅包含 ASCII 字符。
1. 在**每当**下，为**是**选择 **>** 并键入 **0**。对于**对于**，键入 **3** 作为连续时段数。
**Alarm Preview（告警预览）**下会显示阈值的图形表示。
1. 在 **Notification** 下，为 **Send notification to** 选择一个现有 SNS 主题或创建一个新 SNS 主题。
要创建 SNS 主题，请选择 **New list（新列表）**。对于**发送通知到**，键入 SNS 主题的名称（例如“Reboot\$1EC2\$1Instance”）。对于 **Email list (电子邮件列表)**，请键入警报变为 `ALARM` 状态时将通知发送到的电子邮件地址列表（以逗号分隔）。将向每个电子邮件地址发送一封主题订阅确认电子邮件。您必须先确认订阅，然后才能将通知发送到电子邮件地址。
1. 选择 **EC2 Action**。
1. 对于**每当此警报**，请选择**状态为“警报”**。对于 **Take this action**，选择 **Reboot this instance**。
1. 选择**创建警报**。
## 在 Amazon CloudWatch 告警中添加恢复操作
您可以创建 Amazon CloudWatch 警报用于监控 Amazon EC2 实例，并且在实例受损（由于发生底层硬件故障或需要 AWS 参与才能修复的问题）时自动恢复实例。无法恢复终止的实例。恢复的实例与原始实例相同，包括实例 ID、私有 IP 地址、弹性 IP 地址以及所有实例元数据。
当 `StatusCheckFailed_System` 告警触发且恢复操作启动时，您在创建告警及相关恢复操作时所选择的 Amazon SNS 主题将向您发出通知。在实例恢复过程中，实例将在重启时迁移，并且内存中的所有数据都将丢失。当该过程完成后，会向您已配置警报的 SNS 主题发布信息。任何订阅此 SNS 主题的用户都将收到一封电子邮件通知，其中包括恢复尝试的状态以及任何进一步的指示。您会注意到，实例在已恢复的实例上重启。
恢复操作仅适用于 `StatusCheckFailed_System`，而不能用于 `StatusCheckFailed_Instance`。
导致系统状态检查出现故障的问题示例包括：
+ 网络连接丢失
+ 系统电源损耗
+ 物理主机上的软件问题
+ 物理主机上影响到网络连接状态的硬件问题
只有某些实例类型支持恢复操作。有关支持的实例类型和其他要求的更多信息，请参阅[恢复实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)和[要求](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html#requirements-for-recovery)。
**重要**
为了避免重启操作与恢复操作之间的竞争情况，请避免为重启警报和恢复警报设置相同的评估期。我们建议您将恢复警报设置为 2 个 1 分钟的评估期，并将重启警报设置为 3 个 1 分钟的评估期。
**使用 Amazon CloudWatch 控制台创建恢复实例的告警**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms（警报）**和 **All alarms（所有警报）**。
1. 选择**创建警报**。
1. 选择**选择指标**并执行以下操作：
1. 选择**EC2 指标**、**每个实例的指标**。
1. 选择包含实例和 **StatusCheckFailed\$1System** 指标的行，然后选择**选择指标**。
1. 对于统计数据，选择 **Minimum**。
1. 选择时间段（例如 **1 Minute**）。
**重要**
为了避免重启操作与恢复操作之间的竞争情况，请避免为重启警报和恢复警报设置相同的评估期。我们建议您将恢复警报设置为 2 个 1 分钟的评估期。
1. 对于**条件**，执行以下操作：
1. 在**阈值类型**下，选择**静态**。
1. 在**每当**下，选择**大于**，然后对于**比...** 输入 **0**。
1. 选择**其他配置**，然后在**待警报的数据点**中指定 2 个（**共** 2 个）。
1. 选择**下一步**。
1. 在**通知**下，执行以下操作：
1. 对于 **Alarm state trigger**（告警状态触发器），选择 **In alarm**（在告警中）。
1. 对于**发送通知到如下 SNS 主题**，选择一个现有 SNS 主题或创建一个新 SNS 主题。
1. 选择 **Add EC2 Action**（添加 EC2 操作）。
1. 对于 **Alarm state trigger**（告警状态触发器），选择 **In alarm**（在告警中）。
1. 对于**请执行以下操作**，选择**恢复此实例**。
1. 选择**下一步**。
1. 对于**警报名称**，输入警报的唯一名称（例如，**Recover EC2 instance**）和警报描述（例如，**Recover EC2 instance when health checks fail**）。警报名称必须仅包含 ASCII 字符。
1. 选择**下一步**。
1. 选择**创建警报**。
## 查看已触发的告警和操作的历史记录
您可以在 Amazon CloudWatch 控制台中查看警报和操作历史记录。Amazon CloudWatch 会保留最近 30 天的警报和操作历史记录。
**要查看已触发的警报和操作的历史记录**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择 **Alarms (警报)**，然后选择一个警报。
1. 要查看最近的状态转换以及时间和指标值，请选择**详细信息**。
1. 要查看最近的历史记录条目，请选择 **History (历史记录)**。
# 告警事件和 EventBridge
每当 CloudWatch 告警被创建、更新、删除或更改告警状态时，CloudWatch 都会将事件发送到 Amazon EventBridge。您可以使用 EventBridge 和这些事件来编写规则，这些规则会在告警更改状态时采取措施，例如通知您。有关更多信息，请参阅[什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
CloudWatch 保证向 EventBridge 传送告警状态更改事件。
## 告警状态更改事件
本节旨在介绍告警状态发生变化时发送到 EventBridge 的示例事件。选择选项卡可查看不同类型的告警状态更改事件。
------
#### [ Single Metric Alarm ]
单个指标告警更改状态时生成的事件。这些事件包含带有告警评估结果的 `state` 和 `previousState` 字段。
```
{
"version": "0",
"id": "c4c1c1c9-6542-e61b-6ef0-8c4d36933a92",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-02T17:04:40Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh"
],
"detail": {
"alarmName": "ServerCpuTooHigh",
"configuration": {
"description": "Goes into alarm when server CPU utilization is too high!",
"metrics": [
{
"id": "30b6c6b2-a864-43a2-4877-c09a1afc3b87",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "CPUUtilization",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
]
},
"previousState": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [0.0666851903306472 (01/10/19 13:46:00)] was not greater than the threshold (50.0) (minimum 1 datapoint for ALARM -> OK transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-01T13:56:40.985+0000\",\"startDate\":\"2019-10-01T13:46:00.000+0000\",\"statistic\":\"Average\",\"period\":300,\"recentDatapoints\":[0.0666851903306472],\"threshold\":50.0}",
"timestamp": "2019-10-01T13:56:40.987+0000",
"value": "OK"
},
"state": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [99.50160229693434 (02/10/19 16:59:00)] was greater than the threshold (50.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-02T17:04:40.985+0000\",\"startDate\":\"2019-10-02T16:59:00.000+0000\",\"statistic\":\"Average\",\"period\":300,\"recentDatapoints\":[99.50160229693434],\"threshold\":50.0}",
"timestamp": "2019-10-02T17:04:40.989+0000",
"value": "ALARM"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Metric Math Alarm ]
指标数学告警更改状态时生成的事件。这些事件包含 `configuration` 字段中的数学表达式详细信息。
```
{
"version": "0",
"id": "2dde0eb1-528b-d2d5-9ca6-6d590caf2329",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-02T17:20:48Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh"
],
"detail": {
"alarmName": "TotalNetworkTrafficTooHigh",
"configuration": {
"description": "Goes into alarm if total network traffic exceeds 10Kb",
"metrics": [
{
"expression": "SUM(METRICS())",
"id": "e1",
"label": "Total Network Traffic",
"returnData": true
},
{
"id": "m1",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "NetworkIn",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "m2",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "NetworkOut",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
}
]
},
"previousState": {
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2019-10-02T17:20:03.642+0000",
"value": "INSUFFICIENT_DATA"
},
"state": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [45628.0 (02/10/19 17:10:00)] was greater than the threshold (10000.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-02T17:20:48.551+0000\",\"startDate\":\"2019-10-02T17:10:00.000+0000\",\"period\":300,\"recentDatapoints\":[45628.0],\"threshold\":10000.0}",
"timestamp": "2019-10-02T17:20:48.554+0000",
"value": "ALARM"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Anomaly Detection Alarm ]
异常检测告警更改状态时生成的事件。这些事件包含 `reasonData` 字段的上限和下限阈值。
```
{
"version": "0",
"id": "daafc9f1-bddd-c6c9-83af-74971fcfc4ef",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-03T16:00:04Z",
"region": "us-east-1",
"resources": ["arn:aws:cloudwatch:us-east-1:123456789012:alarm:EC2 CPU Utilization Anomaly"],
"detail": {
"alarmName": "EC2 CPU Utilization Anomaly",
"state": {
"value": "ALARM",
"reason": "Thresholds Crossed: 1 out of the last 1 datapoints [0.0 (03/10/19 15:58:00)] was less than the lower thresholds [0.020599444741798756] or greater than the upper thresholds [0.3006915352732461] (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-03T16:00:04.650+0000\",\"startDate\":\"2019-10-03T15:58:00.000+0000\",\"period\":60,\"recentDatapoints\":[0.0],\"recentLowerThresholds\":[0.020599444741798756],\"recentUpperThresholds\":[0.3006915352732461]}",
"timestamp": "2019-10-03T16:00:04.653+0000"
},
"previousState": {
"value": "OK",
"reason": "Thresholds Crossed: 1 out of the last 1 datapoints [0.166666666664241 (03/10/19 15:57:00)] was not less than the lower thresholds [0.0206719426210418] or not greater than the upper thresholds [0.30076870222143803] (minimum 1 datapoint for ALARM -> OK transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-03T15:59:04.670+0000\",\"startDate\":\"2019-10-03T15:57:00.000+0000\",\"period\":60,\"recentDatapoints\":[0.166666666664241],\"recentLowerThresholds\":[0.0206719426210418],\"recentUpperThresholds\":[0.30076870222143803]}",
"timestamp": "2019-10-03T15:59:04.672+0000"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
},
"configuration": {
"description": "Goes into alarm if CPU Utilization is out of band",
"metrics": [{
"id": "m1",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 60,
"stat": "Average"
},
"returnData": true
}, {
"id": "ad1",
"expression": "ANOMALY_DETECTION_BAND(m1, 0.8)",
"label": "CPUUtilization (expected)",
"returnData": true
}]
}
}
}
```
------
#### [ Composite Alarm ]
复合指标告警更改状态时生成的事件。这些事件包含 `actionsSuppressedBy` 和 `actionsSuppressedReason` 字段中的抑制信息。
```
{
"version": "0",
"id": "d3dfc86d-384d-24c8-0345-9f7986db0b80",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-22T15:57:45Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"actionsSuppressedReason": "Actions suppressed by WaitPeriod",
"value": "ALARM",
"reason": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:SuppressionDemo.EventBridge.FirstChild transitioned to ALARM at Friday 22 July, 2022 15:57:45 UTC",
"reasonData": "{\"triggeringAlarms\":[{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh\",\"state\":{\"value\":\"ALARM\",\"timestamp\":\"2022-07-22T15:57:45.394+0000\"}}]}",
"timestamp": "2022-07-22T15:57:45.394+0000"
},
"previousState": {
"value": "OK",
"reason": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:SuppressionDemo.EventBridge.Main was created and its alarm rule evaluates to OK",
"reasonData": "{\"triggeringAlarms\":[{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh\",\"state\":{\"value\":\"OK\",\"timestamp\":\"2022-07-14T16:28:57.770+0000\"}},{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh\",\"state\":{\"value\":\"OK\",\"timestamp\":\"2022-07-14T16:28:54.191+0000\"}}]}",
"timestamp": "2022-07-22T15:56:14.552+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Multi Time Series Alarm ]
告警贡献者或告警更改状态时生成的事件。告警贡献者状态更改事件包含告警贡献者的 ID 和属性以及最近突破阈值的数据点。告警状态更改事件会提供有关导致告警状态发生变化的贡献者的数量及其状态原因的概要信息。
**告警贡献者示例**
```
{
"version": "0",
"id": "6d226bbc-07f0-9a31-3359-1736968f8ded",
"detail-type": "CloudWatch Alarm Contributor State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2025-12-01T13:42:04Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:DynamoDBInsightsAlarm"
],
"detail": {
"alarmName": "DynamoDBInsightsAlarm",
"alarmContributor": {
"id": "6d442278dba546f6",
"attributes": {
"TableName": "example-dynamodb-table-name"
}
},
"state": {
"value": "ALARM",
"reason": "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)].",
"timestamp": "2025-12-01T13:42:04.919+0000"
},
"configuration": {
"metrics": [
{
"id": "m1",
"expression": "SELECT AVG(ConsumedWriteCapacityUnits) FROM \"AWS/DynamoDB\" GROUP BY TableName ORDER BY MAX() DESC",
"returnData":true,
"period": 60
}
],
"description": "Metrics Insights alarm for DynamoDB ConsumedWriteCapacity per TableName"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
**告警示例**
```
{
"version": "0",
"id": "80ddd249-dedf-7c4d-0708-0eb78132dd78",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2025-12-01T13:42:04Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:DynamoDBInsightsAlarm"
],
"detail": {
"alarmName": "DynamoDBInsightsAlarm",
"state": {
"value": "ALARM",
"reason": "6 out of 6 time series evaluated to ALARM",
"timestamp": "2025-12-01T13:42:04.919+0000"
},
"previousState": {
"value": "INSUFFICIENT_DATA",
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2025-12-01T13:40:50.600+0000"
},
"configuration": {
"metrics": [
{
"id": "m1",
"expression": "SELECT AVG(ConsumedWriteCapacityUnits) FROM \"AWS/DynamoDB\" GROUP BY TableName ORDER BY MAX() DESC",
"returnData": true,
"period": 60
}
],
"description": "Metrics Insights alarm for DynamoDB ConsumedWriteCapacity per TableName"
}
}
}
```
------
## 告警配置更改事件
本节旨在介绍告警配置发生变化时发送到 EventBridge 的示例事件。配置更改包括创建、更新或删除告警。
------
#### [ Creation Events ]
创建新告警时生成的事件。这些事件包含 `configuration` 字段中的初始告警配置，并且 `operation` 设置为“创建”。
**复合告警示例**
```
{
"version": "0",
"id": "91535fdd-1e9c-849d-624b-9a9f2b1d09d0",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:06:22Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "create",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:22.289+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"alarmName": "ServiceAggregatedAlarm",
"description": "Aggregated monitor for instance",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:22.289+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**具有抑制器的复合告警示例**
```
{
"version": "0",
"id": "454773e1-09f7-945b-aa2c-590af1c3f8e0",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T13:59:46Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "create",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:46.425+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
#### [ Update Events ]
修改现有告警时生成的事件。这些事件同时包含 `configuration` 和 `previousConfiguration` 字段，可显示具体更改的内容。
**指标告警示例**
```
{
"version": "0",
"id": "bc7d3391-47f8-ae47-f457-1b4d06118d50",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:06:34Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh"
],
"detail": {
"alarmName": "ServerCpuTooHigh",
"operation": "update",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:13.757+0000"
},
"configuration": {
"evaluationPeriods": 1,
"threshold": 80,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [
{
"id": "86bfa85f-b14c-ebf7-8916-7da014ce23c0",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
],
"alarmName": "ServerCpuTooHigh",
"description": "Goes into alarm when server CPU utilization is too high!",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:34.267+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
},
"previousConfiguration": {
"evaluationPeriods": 1,
"threshold": 70,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [
{
"id": "d6bfa85f-893e-b052-a58b-4f9295c9111a",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
],
"alarmName": "ServerCpuTooHigh",
"description": "Goes into alarm when server CPU utilization is too high!",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:13.757+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**具有抑制器的指标告警示例**
```
{
"version": "0",
"id": "4c6f4177-6bd5-c0ca-9f05-b4151c54568b",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T13:59:56Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "update",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"value": "ALARM",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 360,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:56.290+0000",
"okActions": [],
"alarmActions": [], Remove
"insufficientDataActions": []
},
"previousConfiguration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:46.425+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
#### [ Deletion Events ]
删除告警时生成的事件。这些事件包含最终的告警配置，并且 `operation` 设置为“删除”。
**指标数学告警示例**
```
{
"version": "0",
"id": "f171d220-9e1c-c252-5042-2677347a83ed",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:07:13Z",
"region": "us-east-*",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh"
],
"detail": {
"alarmName": "TotalNetworkTrafficTooHigh",
"operation": "delete",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:17.672+0000"
},
"configuration": {
"evaluationPeriods": 1,
"threshold": 10000,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [{
"id": "m1",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "NetworkIn",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "m2",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "NetworkOut",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "e1",
"expression": "SUM(METRICS())",
"label": "Total Network Traffic",
"returnData": true
}
],
"alarmName": "TotalNetworkTrafficTooHigh",
"description": "Goes into alarm if total network traffic exceeds 10Kb",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:17.672+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**带有抑制器的指标数学告警示例**
```
{
"version": "0",
"id": "e34592a1-46c0-b316-f614-1b17a87be9dc",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T14:00:01Z",
"region": "us-east-*",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "delete",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"value": "ALARM",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 360,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:56.290+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
# 配置告警静音规则
本部分中的步骤说明了如何使用 CloudWatch 控制台创建告警静音规则。您还可以使用 API 或 AWS CLI 创建告警静音规则。有关更多信息，请参阅 [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html)。
**要创建告警静音规则**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择**告警**，然后选择**静音规则**选项卡
1. 单击**创建告警静音规则**按钮，这将打开向导
1. 在**告警静音规则详细信息**部分下，输入告警静音规则的名称以及可选的描述
1. 在**计划模式**部分下，选择一次性计划或定期计划
1. 如果您选择单次计划，
1. 选择时区以应用静音计划
1. 选择开始日期和时间，以定义静音规则的生效时间
1. 选择结束日期和时间，以定义静音规则的过期时间
1. 如果您选择定期计划，将有两个选项。要么使用控制台表单，要么使用 cron 表达式来配置定期时间计划。
1. 在**计划创建类型**下，选择“指定日期、时间和重复发生”以使用控制台表单
1. 选择时区以应用静音规则
1. 选择**开始日期和时间**，以定义静音规则的生效时间
1. 选择**持续时间**，以定义静音规则启用后应持续多长时间
1. 选择**重复**，以定义计划应如何重复，例如每天、每月、每个周末或一周中的特定日期。
1. 选择可选的**直到**，以定义静音时间表的到期时间。默认选项为“无限期”
1. 在**计划创建类型**下，选择“从 cron 表达式中设置”，以使用 cron 表达式配置计划
1. 在 **Cron 表达式**部分下，输入所需的 cron 表达式值。
1. 选择**持续时间**，以定义静音规则启用后应持续多长时间
1. 在可选的**时间范围**部分下，输入可选的开始和结束日期和时间，以定义静音计划的生效和过期时间。
1. 在**目标告警**部分下，从下拉列表中选择要应用此静音规则的告警
1. 在**为静音规则设置标签**部分下，将标签附加到您的告警静音规则。标签是应用于资源的密钥值对，用于保存有关该资源的元数据。有关更多信息，请参阅[什么是标签？](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html)
1. 选择**创建告警静音规则**按钮以创建静音规则
## 快速静音
可按以下方式为告警设置短时间静音：
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择**告警**
1. 从列表中选择要静音的告警
1. 在**操作**菜单下，选择**静音**
1. 在**快速静音**部分下，选择预定义的时间段 15 分钟、1 小时、3 小时，或者选择**静音直到**以设置所需的时间段
1. 单击**确认**，立即将告警静音，持续至选定时间段结束
## 在现有静音规则中添加告警
可以按照以下方式在现有的静音规则中添加告警，
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择**告警**
1. 从列表中选择要静音的告警
1. 在**操作**菜单下，选择**静音**
1. 选择**应用现有静音规则**，这将打开向导
1. 从下拉列表中选择选择需要添加告警的静音规则
1. 单击**应用**
**注意**
告警详情页面还提供快速静音和向现有静音规则添加告警的选项。详细信息页面中的**静音规则**选项卡显示与告警关联的所有静音规则。
# 管理警报
**Topics**
+ [编辑或删除 CloudWatch 警报](Edit-CloudWatch-Alarm.md)
+ [隐藏 Auto Scaling 警报](hide-autoscaling-alarms.md)
+ [警报和标记](CloudWatch_alarms_and_tagging.md)
+ [查看和管理已静音的告警](viewing-managing-muted-alarms.md)
# 编辑或删除 CloudWatch 警报
您可以编辑或删除现有告警。
您无法更改现有告警的名称。您可以复制一个告警，并为新告警指定不同的名称。要复制一个告警，请在告警列表中选中该告警名称旁边的复选框，然后选择 **Action（操作）**和 **Copy（复制）**。
**编辑告警**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms**（告警）和 **All alarms**（所有告警）。
1. 选择警报的名称。
1. 要添加或移除标签，请选择**标签**选项卡，然后选择**管理标签**。
1. 要编辑告警的其他部分，请依次选择**操作**、**编辑**。
将显示 **Specify metric and conditions（指定指标和条件）**页面，其中显示一个图表以及有关您选择的指标和统计数据的其他信息。
1. 要更改指标，请选择 **Edit（编辑）**，选择 **All metrics（全部指标）**选项卡，然后执行以下操作之一：
+ 选择包含所需指标的服务命名空间。继续选择所显示的选项，以缩小选择范围。在显示指标列表时，选中所需的指标旁边的复选框。
+ 在搜索框中，输入指标名称、维度或资源 ID，然后按 Enter。接下来，选择其中的一个结果并继续，直到显示指标列表。选中所需的指标旁边的复选框。
选择**选择指标**。
1. 要更改告警的其他内容，请选择相应的选项。要更改必须有多少个数据点违例以使告警变为 `ALARM`（告警）状态或更改缺失数据的处理方式，请选择 **Additional configuration（其他配置）**。
1. 选择**下一步**。
1. 在 **Notification（通知）**、**Auto Scaling action（Auto Scaling 操作）**和 **EC2 action（EC2 操作）**下，编辑在触发告警时执行的操作（可选）。然后选择**下一步**。
1. （可选）更改告警描述。
您无法更改现有告警的名称。您可以复制一个告警，并为新告警指定不同的名称。要复制一个告警，请在告警列表中选中该告警名称旁边的复选框，然后选择 **Action（操作）**和 **Copy（复制）**。
1. 选择**下一步**。
1. 在 **Preview and create（预览和创建）**下，确认具有所需的信息和条件，然后选择 **Update alarm（更新告警）**。
**更新使用 Amazon SNS 控制台创建的电子邮件通知列表**
1. 通过 [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home) 打开 Amazon SNS 控制台。
1. 在导航窗格中，选择 **Topics（主题）**，然后选择通知列表（主题）的 ARN。
1. 请执行以下操作之一：
+ 要添加电子邮件地址，请选择 **Create subscription（创建订阅）**。对于**协议**，选择**电子邮件**。对于 **Endpoint（端点）**，输入新收件人的电子邮件地址。选择 **Create subscription（创建订阅）**。
+ 要删除电子邮件地址，请选择 **Subscription ID（订阅 ID）**。选择 **Other subscription actions（其他订阅操作）**、**Delete subscriptions（删除订阅）**。
1. 选择 **Publish to topic（发布到主题）**。
**删除警报**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择**警报**。
1. 选中告警名称左侧的复选框，然后依次选择 **Actions（操作）**和 **Delete（删除）**。
1. 选择**删除**。
# 隐藏 Auto Scaling 警报
在 AWS 管理控制台 中查看您的警报时，您可以隐藏与 Amazon EC2 Auto Scaling 相关的警报。仅在 AWS 管理控制台 中提供了该功能。
**若要临时隐藏 Auto Scaling 警报**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms**（告警）和 **All alarms**（所有告警），然后选择 **Hide Auto Scaling alarms**（隐藏弹性伸缩告警）。
# 警报和标记
*标签*是键值对，可以帮助您对资源进行组织和分类。您还可以使用它们来限定用户权限的范围，方法是只授予用户访问或更改具有特定标签值的资源的权限。有关标记资源的更多一般信息，请参阅[标记 AWS 资源](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)
以下列表说明了标记如何与 CloudWatch 警报配合使用的一些详细信息。
+ 要能够设置或更新 CloudWatch 资源的标签，您必须登录拥有 `cloudwatch:TagResource` 权限的账户。例如，要创建警报并为其设置标签，除了 `cloudwatch:TagResource` 权限之外，您还必须拥有 `the cloudwatch:PutMetricAlarm ` 权限。建议您确保组织中要创建或更新 CloudWatch 资源的任何人都拥有 `cloudwatch:TagResource` 权限。
+ 标签可用于基于标签的授权控制。例如，IAM 用户或角色权限可以包含一些条件，根据其标签将 CloudWatch 调用限制为特定的资源。不过，请注意以下事项
+ 名称以 `aws:` 开头的标签不能用于基于标签的授权控制。
+ 复合警报不支持基于标签的授权控制。
# 查看和管理已静音的告警
**查看已静音的告警：**您可以通过 CloudWatch 控制台轻松识别哪些告警当前处于静音状态。在告警列表视图和各个告警详细信息页面中，当前处于静音状态（即当前被有效的静音规则所静音）的告警旁边会出现一个静音图标。此视觉指示器能帮助您快速了解当前哪些告警已被静音，直到静音窗口期结束。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_icon.png)
**告警时间表：**CloudWatch 告警控制台提供全面的时间线视图，显示您的告警操作何时被静音。该时间线不仅会显示告警状态的变化，还会同时显示静音时段，从而让您能够全面了解告警行为和静音操作的全过程。您可以使用此时间线来分析静音规则的有效性，并了解它们与您的操作活动的关系。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/alarm-mutes-timelineview.png)
**以编程方式检查告警静音状态：**要以编程方式确定告警当前是否静音，可以使用 [ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html) 将告警名称作为筛选条件。此 API 会返回影响指定告警的所有活动静音规则，允许您将静音状态检查集成到自动化工作流、监控控制面板或操作工具中。
例如：要检查名为“HighCPUAlarm”的告警当前是否处于静音状态，请调用 [ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html) API，并将筛选条件参数设置为告警名称。响应将包括针对该告警的所有静音规则，以及它们的当前状态（SCHEDULED、ACTIVE 或 EXPIRED）。
**告警历史记录：**每当告警操作由于激活的静音规则而被静音时，CloudWatch 就会向告警的历史记录日志中写入历史记录条目。这提供了告警何时被静音的完整审计跟踪记录，以帮助您了解静音事件的时间线，并将它们与操作活动关联起来。您可以通过 CloudWatch 控制台查看此历史记录，或者使用 [DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html) API 以编程方式检索它。
**注意**
当多个告警静音规则同时处于活动状态时，最近创建的静音规则名称将与其他活动的静音规则总数一起写入告警历史记录。
只有当告警状态在活动的静音窗口期间发生转换并且操作被阻止执行时，时间线才会显示静音周期。
**提示**
您可以使用 CloudWatch API 以编程方式管理告警静音规则。有关更多信息，请参阅 [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html)、[GetAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetAlarmMuteRule.html)、[ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html) 和 [DeleteAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DeleteAlarmMuteRule.html)。
## CloudWatch 告警的常见功能
以下功能适用于所有 CloudWatch 告警：
+ 您可以创建的告警数量没有限制。要创建或更新告警，请使用 CloudWatch 控制台、[PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) API 操作，或 AWS CLI 中的 [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) 命令。
+ 告警名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符
+ 您可以使用 CloudWatch 控制台、[DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html) API 操作，或 AWS CLI 中的 [describle-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html) 命令来列出任何或所有当前已配置的告警和列出任意特定状态的告警。
+ 您可以使用 [DisableAlarmActions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DisableAlarmActions.html) 和 [EnableAlarmActions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_EnableAlarmActions.html) API 操作或 AWS CLI 中的 [disable-alarm-actions](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/disable-alarm-actions.html) 和 [enable-alarm-actions](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/enable-alarm-actions.html) 命令来禁用或启用警报操作。
+ 您可以使用 [SetAlarmState](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_SetAlarmState.html) API 操作或 AWS CLI 中的 [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html) 命令将告警设为任意状态，以对其进行测试。此短暂状态变更只会持续到下一个告警比较发生之时。
+ 您可以在创建自定义指标之前为该自定义指标创建告警。为了使告警有效，必须在告警定义中包含自定义指标的所有维度以及指标命名空间和指标名称。要执行此操作，您可以使用 [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) API 操作，或 AWS CLI 中的 [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html)命令。
+ 您可以使用 CloudWatch 控制台、[DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html) API 操作，或 AWS CLI 中的 [describe-alarm-history](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarm-history.html) 命令查看告警的历史记录。CloudWatch 可将告警历史记录保存 30 天。每个状态转换都标有一个唯一的时间戳。个别情况下，一个状态变更的历史记录可能显示多个通知。通过时间戳可以确认独特的状态变更。
+ 您可以在 CloudWatch 控制台的导航面板中通过 *Favorites and recents*（收藏夹和最近记录）选项收藏最近访问过的警报，具体方法为：将鼠标悬停在您想要收藏的警报上方，然后选择它旁边的星号。
+ 警报有评估周期配额。评估周期的计算方式为用警报周期乘以所用的评估周期数。
+ 对于警报周期至少为一小时（3600 秒）的警报，最长评估周期为七天。
+ 对于周期较短的警报，最长评估周期为一天。
+ 使用自定义 Lambda 数据来源的警报的最长评估周期为一天。
**注意**
在特定情况下，某些 AWS 资源不会向 CloudWatch 发送指标数据。
例如，Amazon EBS 可能不会发送未附加到 Amazon EC2 实例的可用卷的指标数据，因为该卷没有要监控的指标活动。如果为此类指标设置了一个告警，您可能会注意到其状态变为 `INSUFFICIENT_DATA`（数据不足）。这可能表示资源处于不活动状态，并不一定表示出现了问题。您可以指定每个告警如何处理丢失数据。有关更多信息，请参阅 [配置 CloudWatch 告警处理缺失数据的方式](alarms-and-missing-data.md)。
# AWS 服务的最佳实践警报建议
CloudWatch 提供开箱即用的警报建议。我们建议您为其他 AWS 服务发布的指标创建此类 CloudWatch 警报。这些建议可以帮助您确定应为哪些指标设置警报，以遵循监控最佳实践。这些建议还建议了要设置的警报阈值。遵循这些建议可以帮助您避免错过对 AWS 基础设施的重要监控。
要查找警报建议，您可以使用 CloudWatch 控制台的“指标”部分，然后选择“警报建议”筛选开关。如果您在控制台中导航到“建议警报”，然后创建建议警报，CloudWatch 可以预先填充一些警报设置。对于某些建议警报，系统也会预先填充警报阈值。您还可以使用控制台下载建议警报的基础设施即代码警报定义，然后使用此代码在 AWS CloudFormation、AWS CLI 或 Terraform 中创建警报。
您还可以在 [建议的警报](Best_Practice_Recommended_Alarms_AWS_Services.md) 中查看推荐的警报列表。
您需要为自己创建的警报付费，费率与您在 CloudWatch 中创建的任何其他警报的费率相同。使用这些建议不会产生额外费用。有关更多信息，请参阅 [Amazon CloudWatch 定价](https://aws.amazon.com/cloudwatch/pricing/)。
## 查找并创建建议警报
按照以下步骤查找 CloudWatch 建议您为其设置警报的指标，并可以选择创建其中一种警报。第一个过程说明了如何查找包含建议警报的指标，以及如何创建其中一种警报。
您还可以批量下载 AWS 命名空间中所有建议警报的基础设施即代码警报定义，例如 `AWS/Lambda` 或 `AWS/S3`。本主题的后续部分中包含了这些说明。
**查找包含建议警报的指标，并创建单个建议警报**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Metrics**（指标）、**All metrics**（所有指标）。
1. 在**指标**表上方，选择**警报建议**。
指标命名空间列表经过筛选，仅包含具有警报建议且您账户中的服务将发布的指标。
1. 为服务选择命名空间。
此命名空间下的指标列表经过筛选，仅包括具有警报建议的指标。
1. 要查看指标的警报意图和建议阈值，请选择**查看详细信息**。
1. 要为其中一个指标创建警报，请执行以下操作之一：
+ 要使用控制台创建警报，请执行以下操作：
1. 选中指标的复选框，然后选择**图形化指标**选项卡。
1. 选择警报图标。
![\[从指标的图表创建警报\]](http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/monitoring/images/metric_graph_alarm.png)
随即出现警报创建向导，其中根据警报建议填入了指标名称、统计数据和时间段。如果建议包含特定阈值，则该值也会预先填充。
1. 选择**下一步**。
1. 在**通知**下面，选择当警报转换为 `ALARM`、`OK` 或 `INSUFFICIENT_DATA` 状态时要通知的 SNS 主题。
要使告警为相同告警状态或不同告警状态发送多个通知，请选择**添加通知**。
要让警报不发送通知，请选择**删除**。
1. 要让警报执行 Auto Scaling 或 EC2 操作，请选择相应的按钮，然后选择警报状态和要执行的操作。
1. 在完成后，选择**下一步**。
1. 输入警报的名称和说明。名称只能包含 ASCII 字符。然后选择**下一步**。
1. 在 **Preview and create** 下面，确认具有所需的信息和条件，然后选择 **Create alarm**。
+ 要下载基础设施即代码警报定义以在 AWS CloudFormation、AWS CLI 或 Terraform 中使用，请选择**下载警报代码**并选择所需格式。下载的代码将包含指标名称、统计数据和阈值的建议设置。
**下载针对 AWS 服务的所有建议警报的基础设施即代码警报定义**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Metrics**（指标）、**All metrics**（所有指标）。
1. 在**指标**表上方，选择**警报建议**。
指标命名空间列表经过筛选，仅包含具有警报建议且您账户中的服务将发布的指标。
1. 为服务选择命名空间。
此命名空间下的指标列表经过筛选，仅包括具有警报建议的指标。
1. **下载警报代码**会显示建议为该命名空间中的指标设置多少个警报。要下载所有建议警报的基础设施即代码警报定义，请选择**下载警报代码**，然后选择所需代码格式。
# 建议的警报
以下各节列出了我们建议您为其设置最佳实践警报的指标。对于每个指标，还会显示维度、警报意图、建议阈值、阈值理由、时间段长度和数据点数量。
某些指标可能会在列表中显示两次。当建议针对该指标的不同维度组合设置不同的警报时，就会发生这种情况。
**要发出警报的数据点数**是必须违例才能触发警报变为“ALARM”状态的数据点数量。**评估期**是评估警报时考虑的时期数量。如果这些数字相同，则只有在该连续时间段的数量超过阈值时，警报才会进入“ALARM”状态。如果**要发出警报的数据点数**低于**评估期**，则属于“M（最大为 N）”警报，并且警报将进入“ALARM”状态，前提是数据点的任何**评估期**集合内至少有**要发出警报的数据点数**个数据点违例。有关更多信息，请参阅 [告警评估](alarm-evaluation.md)。
**Topics**
+ [Amazon API Gateway](#ApiGateway)
+ [Amazon EC2 Auto Scaling](#AutoScaling)
+ [AWS Certificate Manager (ACM)](#CertificateManager)
+ [Amazon CloudFront](#CloudFront)
+ [Amazon Cognito](#Cognito)
+ [Amazon DynamoDB](#DynamoDB)
+ [Amazon EBS](#Recommended_EBS)
+ [Amazon EC2](#EC2)
+ [Amazon ElastiCache](#ElastiCache)
+ [Amazon ECS](#ECS)
+ [具有 Container Insights 的 Amazon ECS](#ECS-ContainerInsights)
+ [使用增强了可观测性的 Container Insights 的 Amazon ECS](#ECS-ContainerInsights_enhanced)
+ [Amazon EFS](#EFS)
+ [具有 Container Insights 的 Amazon EKS](#EKS-ContainerInsights)
+ [Amazon EventBridge 调度器](#Eventbridge-Scheduler)
+ [Amazon Kinesis Data Streams](#Kinesis)
+ [Lambda](#Lambda)
+ [Lambda Insights](#LambdaInsights)
+ [Amazon VPC (`AWS/NATGateway`)](#NATGateway)
+ [AWS 私有链接 (`AWS/PrivateLinkEndpoints`)](#PrivateLinkEndpoints)
+ [AWS 私有链接 (`AWS/PrivateLinkServices`)](#PrivateLinkServices)
+ [`Amazon RDS`](#RDS)
+ [`Amazon Route 53 Public Data Plane`](#Route53)
+ [`Amazon S3`](#S3)
+ [`S3ObjectLambda`](#S3ObjectLambda)
+ [Amazon SNS](#SNS)
+ [Amazon SQS](#SQS)
+ [Site-to-Site VPN](#VPN)
## Amazon API Gateway
**4XXError**
**维度：**ApiName、Stage
**警报描述：**此警报会检测高客户端错误率。这可能表明授权或客户端请求参数存在问题。这也可能意味着资源已被删除，或者客户端正在请求一个不存在的资源。请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致 4XX 错误的错误。此外，可以考虑启用详细的 CloudWatch 指标，以便按资源和方法查看此指标，并缩小错误来源的范围。超出配置的节流限制也可能导致错误。如果响应和日志报告的 429 错误率很高且出人意料，请按照[本指南](https://repost.aws/knowledge-center/api-gateway-429-limit)排查此问题。
**意图：**此警报可以检测 API Gateway 请求的高客户端错误率。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**建议阈值会检测何时总请求数中超过 5% 的请求会收到 4XX 错误。但是，您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。需要对经常发生的 4XX 错误发出警报。但是，将阈值设置得非常低可能会导致警报过于敏感。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**5XXError**
**维度：**ApiName、Stage
**警报描述：**此警报有助于检测高客户端错误率。这可能表明 API 后端、网络或 API 网关与后端 API 之间的集成存在问题。本[文档](https://repost.aws/knowledge-center/api-gateway-5xx-error)可以帮助您排查 5xx 错误的原因。
**意图：**此警报可以检测 API Gateway 请求的高服务器端错误率。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**建议阈值会检测何时总请求数中超过 5% 的请求会收到 5XX 错误。但是，您可以调整阈值以适应请求流量和可接受的错误率。您也可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。需要对经常发生的 5XX 错误发出警报。但是，将阈值设置得非常低可能会导致警报过于敏感。
**时间段：**60
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**计数**
**维度：**ApiName、Stage
**警报描述：**此警报有助于检测 REST API 阶段的低流量。这可能表示应用程序在调用 API 时存在问题，例如使用了错误的端点。这也可能表明 API 的配置或权限存在问题，导致客户端无法访问它。
**意图：**此警报可检测 REST API 阶段的意外低流量。如果您的 API 在正常条件下收到数量可预测且一致的请求，我们建议您创建此告警。如果您已启用详细的 CloudWatch 指标，并且可以预测每个方法和资源的正常流量，我们建议您创建备用警报，以便对每种资源和方法的流量下降进行更精细的监控。对于预计流量不稳定的 API，不建议使用此告警。
**统计数据：**SampleCount
**建议阈值：**取决于您的情况
**阈值理由：**根据历史数据分析设置阈值，以确定您的 API 的预期基准请求计数是多少。将阈值设置为非常高的值，可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反，将其设置为非常低的值可能会导致警报错过流量异常小的下降。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**计数**
**维度：**ApiName、Stage、Resource、Method
**警报描述：**此警报有助于检测阶段中 REST API 资源和方法的低流量。这可能表示应用程序在调用 API 时存在问题，例如使用了错误的端点。这也可能表明 API 的配置或权限存在问题，导致客户端无法访问它。
**意图：**此警报可检测阶段中 REST API 资源和方法的意外低流量。如果您的 API 在正常条件下收到数量可预测且一致的请求，我们建议您创建此告警。对于预计流量不稳定的 API，不建议使用此告警。
**统计数据：**SampleCount
**建议阈值：**取决于您的情况
**阈值理由：**根据历史数据分析设置阈值，以确定您的 API 的预期基准请求计数是多少。将阈值设置为非常高的值，可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反，将其设置为非常低的值可能会导致警报错过流量异常小的下降。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**计数**
**尺寸：**ApilD、Stage
**警报描述：**此警报有助于检测 HTTP API 阶段的低流量。这可能表示应用程序在调用 API 时存在问题，例如使用了错误的端点。这也可能表明 API 的配置或权限存在问题，导致客户端无法访问它。
**意图：**此警报可检测 HTTP API 阶段的意外低流量。如果您的 API 在正常条件下收到数量可预测且一致的请求，我们建议您创建此告警。如果您已启用详细的 CloudWatch 指标，并且可以预测每个路由的正常流量，我们建议您为此创建备用警报，以便对每个路由的流量下降进行更精细的监控。对于预计流量不稳定的 API，不建议使用此告警。
**统计数据：**SampleCount
**建议阈值：**取决于您的情况
**阈值理由：**根据历史数据分析设置阈值，以确定您的 API 的预期基准请求计数是多少。将阈值设置为非常高的值，可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反，将其设置为非常低的值可能会导致警报错过流量异常小的下降。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**计数**
**维度：**ApiId、Stage、Resource、Method
**警报描述：**此警报有助于检测阶段中 HTTP API 路由的低流量。这可能表示应用程序在调用 API 时存在问题，例如使用了错误的端点。这也可能表明 API 的配置或权限存在问题，导致客户端无法访问它。
**意图：**此警报可检测阶段中 HTTP API 路由的意外低流量。如果您的 API 在正常条件下收到数量可预测且一致的请求，我们建议您创建此告警。对于预计流量不稳定的 API，不建议使用此告警。
**统计数据：**SampleCount
**建议阈值：**取决于您的情况
**阈值理由：**根据历史数据分析设置阈值，以确定您的 API 的预期基准请求计数是多少。将阈值设置为非常高的值，可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反，将其设置为非常低的值可能会导致警报错过流量异常小的下降。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**IntegrationLatency**
**尺寸：**ApilD、Stage
**警报描述：**此警报有助于检测阶段中 API 请求是否存在高集成延迟。您可以将 `IntegrationLatency` 指标值与后端的相应延迟指标（例如 Lambda 集成的 `Duration` 指标）相关联。这有助于您确定 API 后端是否由于性能问题而花费更多时间来处理来自客户端的请求，或者初始化或冷启动是否存在其他开销。此外，请考虑为您的 API 启用 CloudWatch Logs，并检查日志中是否存在任何可能导致高延迟问题的错误。此外，可以考虑启用详细的 CloudWatch 指标来查看每个路由的此指标，从而帮助您缩小集成延迟来源的范围。
**意图：**此警报可以检测阶段中的 API Gateway 请求何时具有高集成延迟。我们建议针对 WebSocket API 设置此警报，并且认为它对于 HTTP API 来说是可选的，因为后者已经具有针对延迟指标的单独警报建议。如果您已启用详细的 CloudWatch 指标，并且每个路由的集成延迟性能要求不同，我们建议您创建备用警报，以便对每个路由的集成延迟进行更精细的监控。
**统计数据：**p90
**建议阈值：**2000.0
**阈值理由：**建议阈值并不适用于所有 API 工作负载。但是，您可以将其用作阈值的起点。然后，您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟，则可以设置更高的阈值以降低警报的敏感度。但是，如果预计 API 能够提供近乎实时的响应，请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟，然后用其相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**IntegrationLatency**
**维度：**Apild、Stage、Route
**警报描述：**此警报有助于检测阶段中路由的 WebSocket API 请求是否存在高集成延迟。您可以将 `IntegrationLatency` 指标值与后端的相应延迟指标（例如 Lambda 集成的 `Duration` 指标）相关联。这有助于您确定 API 后端是否由于性能问题而花费更多时间来处理来自客户端的请求，或者初始化或冷启动是否存在其他开销。此外，请考虑为您的 API 启用 CloudWatch Logs，并检查日志中是否存在任何可能导致高延迟问题的错误。
**意图：**此警报可以检测阶段中路由的 API Gateway 请求何时具有高集成延迟。
**统计数据：**p90
**建议阈值：**2000.0
**阈值理由：**建议阈值并不适用于所有 API 工作负载。但是，您可以将其用作阈值的起点。然后，您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟，则可以设置更高的阈值以降低告警的敏感度。但是，如果预计 API 能够提供近乎实时的响应，请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟，然后用其相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**延迟**
**维度：**ApiName、Stage
**警报描述：**此警报会检测阶段中的高延迟。确定 `IntegrationLatency` 指标值以检查 API 后端延迟。如果这两个指标基本一致，则 API 后端是导致延迟更高的来源，您应该调查其中是否存在问题。另外，请考虑启用 CloudWatch Logs 并检查是否存在可能导致高延迟的错误。此外，可以考虑启用详细的 CloudWatch 指标，以便按资源和方法查看此指标，并缩小延迟来源的范围。如果适用，请参阅[如何排查与 Lambda 集成的 API Gateway 请求中的高延迟问题？](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda)或[如何在 API Gateway 中解决边缘优化的 API 端点中的延迟问题？](https://repost.aws/knowledge-center/source-latency-requests-api-gateway)指南。
**意图：**此警报可以检测阶段中的 API Gateway 请求何时具有高延迟。如果您已启用详细的 CloudWatch 指标，并且每个方法和资源的延迟性能要求不同，我们建议您创建备用警报，以便对每个资源和方法的延迟进行更精细的监控。
**统计数据：**p90
**建议阈值：**2500.0
**阈值理由：**建议阈值并不适用于所有 API 工作负载。但是，您可以将其用作阈值的起点。然后，您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟，则可以设置更高的阈值以降低告警的敏感度。但是，如果预计 API 能够提供近乎实时的响应，请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟，然后相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**延迟**
**维度：**ApiName、Stage、Resource、Method
**警报描述：**此警报会检测阶段中资源和方法的高延迟。确定 `IntegrationLatency` 指标值以检查 API 后端延迟。如果这两个指标基本一致，则 API 后端是导致延迟更高的来源，您应该调查其中是否存在性能问题。另外，请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致高延迟的错误。如果适用，您也可以参阅[如何排查与 Lambda 集成的 API Gateway 请求中的高延迟问题？](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda)或[如何在 API Gateway 中解决边缘优化的 API 端点中的延迟问题？](https://repost.aws/knowledge-center/source-latency-requests-api-gateway)指南。
**意图：**此警报可以检测阶段中资源和方法的 API Gateway 请求何时具有高延迟。
**统计数据：**p90
**建议阈值：**2500.0
**阈值理由：**建议阈值并不适用于所有 API 工作负载。但是，您可以将其用作阈值的起点。然后，您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟，则可以设置更高的阈值以降低告警的敏感度。但是，如果预计 API 能够提供近乎实时的响应，请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟，然后相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**延迟**
**尺寸：**ApilD、Stage
**警报描述：**此警报会检测阶段中的高延迟。确定 `IntegrationLatency` 指标值以检查 API 后端延迟。如果这两个指标基本一致，则 API 后端是导致延迟更高的来源，您应该调查其中是否存在性能问题。另外，请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致高延迟的错误。此外，可以考虑启用详细的 CloudWatch 指标，以便按路由查看此指标，并缩小延迟来源的范围。如果适用，您也可以参阅[如何排查与 Lambda 集成的 API Gateway 请求中的高延迟问题？](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda)指南。
**意图：**此警报可以检测阶段中的 API Gateway 请求何时具有高延迟。如果您已启用详细的 CloudWatch 指标，并且每个路由的延迟性能要求不同，我们建议您创建备用警报，以便对每个路由的延迟进行更精细的监控。
**统计数据：**p90
**建议阈值：**2500.0
**阈值理由：**建议阈值并不适用于所有 API 工作负载。但是，您可以将其用作阈值的起点。然后，您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟，则可以设置更高的阈值以降低其敏感度。但是，如果 API 预期会提供近乎实时的响应，请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟，然后相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**延迟**
**维度：**ApiId、Stage、Resource、Method
**警报描述：**此警报会检测阶段中路由的高延迟。确定 `IntegrationLatency` 指标值以检查 API 后端延迟。如果这两个指标基本一致，则 API 后端是导致延迟更高的来源，您应该调查其中是否存在性能问题。另外，请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致高延迟的错误。如果适用，您也可以参阅[如何排查与 Lambda 集成的 API Gateway 请求中的高延迟问题？](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda)指南。
**意图：**此警报用于检测阶段中路由的 API Gateway 请求何时具有高延迟。
**统计数据：**p90
**建议阈值：**2500.0
**阈值理由：**建议阈值并不适用于所有 API 工作负载。但是，您可以将其用作阈值的起点。然后，您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟，则可以设置更高的阈值以降低告警的敏感度。但是，如果预计 API 能够提供近乎实时的响应，请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟，然后相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**4xx**
**尺寸：**ApilD、Stage
**警报描述：**此警报会检测高客户端错误率。这可能表明授权或客户端请求参数存在问题。这也可能意味着路由已被删除，或者客户端正在请求一个 API 中不存在的资源。请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致 4xx 错误的错误。此外，可以考虑启用详细的 CloudWatch 指标，以便按路由查看此指标，帮助您缩小错误来源的范围。超出配置的节流限制也可能导致错误。如果响应和日志报告的 429 错误率很高且出人意料，请按照[本指南](https://repost.aws/knowledge-center/api-gateway-429-limit)排查此问题。
**意图：**此警报可以检测 API Gateway 请求的高客户端错误率。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**建议阈值会检测何时总请求数中超过 5% 的请求会收到 4xx 错误。但是，您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。需要对经常发生的 4xx 错误发出警报。但是，将阈值设置得非常低可能会导致警报过于敏感。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**5xx**
**尺寸：**ApilD、Stage
**警报描述：**此警报有助于检测高客户端错误率。这可能表明 API 后端、网络或 API 网关与后端 API 之间的集成存在问题。本[文档](https://repost.aws/knowledge-center/api-gateway-5xx-error)可以帮助您排查 5xx 错误的原因。
**意图：**此警报可以检测 API Gateway 请求的高服务器端错误率。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**建议阈值会检测何时总请求数中超过 5% 的请求会收到 5xx 错误。但是，您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。需要对经常发生的 5xx 错误发出警报。但是，将阈值设置得非常低可能会导致警报过于敏感。
**时间段：**60
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**MessageCount**
**尺寸：**ApilD、Stage
**警报描述：**此警报有助于检测 WebSocket API 阶段的低流量。这可能表示客户端调用 API 时存在问题（例如使用不正确的端点），或者后端向客户端发送消息时存在问题。这也可能表明 API 的配置或权限存在问题，导致客户端无法访问它。
**意图：**此警报可检测 WebSocket API 阶段的意外低流量。如果您的 API 在正常条件下收到并发送数量可预测且一致的消息，我们建议您创建此警报。如果您已启用详细的 CloudWatch 指标，并且可以预测每个路由的正常流量，最好为此创建备用警报，以便对每个路由的流量下降进行更精细的监控。对于预计流量不稳定的 API，不建议使用此警报。
**统计数据：**SampleCount
**建议阈值：**取决于您的情况
**阈值理由：**根据历史数据分析设置阈值，以确定您的 API 的预期基准消息计数是多少。将阈值设置为非常高的值，可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反，将其设置为非常低的值可能会导致警报错过流量异常小的下降。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**MessageCount**
**维度：**Apild、Stage、Route
**警报描述：**此警报有助于检测阶段中 WebSocket API 路由的低流量。这可能表示客户端调用 API 时存在问题（例如使用不正确的端点），或者后端向客户端发送消息时存在问题。这也可能表明 API 的配置或权限存在问题，导致客户端无法访问它。
**意图：**此警报可检测阶段中 WebSocket API 路由的意外低流量。如果您的 API 在正常条件下收到并发送数量可预测且一致的消息，我们建议您创建此警报。对于预计流量不稳定的 API，不建议使用此警报。
**统计数据：**SampleCount
**建议阈值：**取决于您的情况
**阈值理由：**根据历史数据分析设置阈值，以确定您的 API 的预期基准消息计数是多少。将阈值设置为非常高的值，可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反，将其设置为非常低的值可能会导致警报错过流量异常小的下降。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**ClientError**
**尺寸：**ApilD、Stage
**警报描述：**此警报会检测高客户端错误率。这可能表示授权或消息参数存在问题。这也可能意味着路由已被删除，或者客户端正在请求一个 API 中不存在的资源。请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致 4xx 错误的错误。此外，可以考虑启用详细的 CloudWatch 指标，以便按路由查看此指标，帮助您缩小错误来源的范围。超出配置的节流限制也可能导致错误。如果响应和日志报告的 429 错误率很高且出人意料，请按照[本指南](https://repost.aws/knowledge-center/api-gateway-429-limit)排查此问题。
**意图：**此警报可以检测 WebSocket API Gateway 消息的高客户端错误率。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**建议阈值会检测何时总请求数中超过 5% 的请求会收到 4xx 错误。您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。需要对经常发生的 4xx 错误发出警报。但是，将阈值设置得非常低可能会导致警报过于敏感。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ExecutionError**
**尺寸：**ApilD、Stage
**警报描述：**此警报有助于检测高执行错误率。这可能是由于您的集成出现 5xx 错误、权限问题或其他阻碍成功调用集成的因素（例如集成受限制或遭删除）所致。请考虑为您的 API 启用 CloudWatch Logs，并检查日志以了解错误的类型和原因。此外，可以考虑启用详细的 CloudWatch 指标，以便按路由查看此指标，帮助您缩小错误来源的范围。本[文档](https://repost.aws/knowledge-center/api-gateway-websocket-error)可以帮助您排查任何连接错误的原因。
**意图：**此警报可以检测 WebSocket API Gateway 消息的高执行错误率。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**建议阈值会检测何时总请求数中超过 5% 的请求会收到执行错误。您可以调整阈值以适应请求的流量以及可接受的错误率。您可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。需要对经常发生的执行错误发出警报。但是，将阈值设置得非常低可能会导致警报过于敏感。
**时间段：**60
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon EC2 Auto Scaling
**GroupInServiceCapacity**
**维度：**AutoScalingGroupName
**警报描述：**此警报有助于检测组中的容量何时低于工作负载所需的容量。要排查问题，请检查您的扩展活动是否存在启动失败，并确认所需的容量配置是否正确。
**意图：**此警报可以检测由于启动失败或暂停而导致的自动扩缩组中的低可用性。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**阈值应为运行工作负载所需的最低容量。在大多数情况下，您可以将其设置为与 GroupDesiredCapicity 指标相匹配。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**LESS\$1THAN\$1THRESHOLD
## AWS Certificate Manager (ACM)
**DaysToExpiry**
**维度：**CerticateArn
**警报描述：**此警报有助于您检测由 ACM 管理或导入 ACM 的证书何时即将到期。它有助于防止证书意外到期从而导致服务中断的情况。当警报进入 ALARM 状态时，应立即采取措施续订或重新导入证书。对于 ACM 管理的证书，请参阅[证书续订流程](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html)中的说明。对于导入 ACM 的证书，请参阅[重新导入流程](https://docs.aws.amazon.com/acm/latest/userguide/import-reimport.html)中的说明。
**用途：**此警报可以主动提醒您哪些证书即将到期。它提供了足够提前的通知，以便进行人工干预，您能够在证书到期之前续订或更换证书。这有助于您维护启用了 TLS 的服务的安全性和可用性。它进入 ALARM 状态后，请立即调查证书状态并在必要时启动续订流程。
**统计数据：**Minimum
**建议阈值：**44.0
**阈值理由：**44 天的阈值在过早预警和避免误报之间取得了平衡。如果自动续订失败，它留出了足够时间进行人工干预。根据证书续订流程和操作响应时间调整此值。
**时间段：**86400
**要发出警报的数据点数**：1
**评估期：**1
**比较运算符：**LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon CloudFront
**5xxErrorRate**
**维度：**DistributionId、Region=Global
**警报描述：**此警报会监控来自您的原始服务器的 5xx 错误响应百分比，帮助您检测 CloudFront 服务是否存在问题。有关帮助您了解服务器问题的信息，请参阅[对来自源的错误响应进行故障排除](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-response-errors.html)。此外，[开启其他指标](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html#monitoring-console.distributions-additional)可获取详细的错误指标。
**意图：**此警报用于检测处理来自原始服务器的请求时出现的问题，或者 CloudFront 与原始服务器之间的通信问题。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于对 5xx 响应的容忍度。您可以分析历史数据和趋势，然后相应地设置阈值。由于 5xx 错误可能由暂时性问题引起，我们建议您将阈值设置为大于 0 的值，这样警报就不会过于敏感。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**OriginLatency**
**维度：**DistributionId、Region=Global
**警报描述：**此警报有助于监控原始服务器的响应时间是否过长。如果服务器响应时间过长，则可能会导致超时。如果您持续遇到高 `OriginLatency` 值的问题，请参阅[查找并修复原始服务器上来自应用程序的延迟响应](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-504-gateway-timeout.html#http-504-gateway-timeout-slow-application)。
**意图：**此警报用于检测原始服务器响应时间过长的问题。
**统计数据：**p90
**建议阈值：**取决于您的情况
**阈值理由：**您应计算原始响应超时大约 80% 的值，并将结果用作阈值。如果此指标持续接近源响应超时值，则您可能会开始遇到 504 错误。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**FunctionValidationErrors**
**维度：**DistributionId、FunctionName、Region=Global
**警报描述：**此警报可帮助您监控 CloudFront Functions 中的验证错误，以便您可以采取措施解决它们。分析 CloudWatch 函数日志并查看函数代码，找出问题的根本原因并予以解决。要了解 CloudFront Functions 的常见配置错误，请参阅[边缘函数的限制](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions-restrictions.html)。
**意图：**此警报用于检测 CloudFront Functions 中的验证错误。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**值大于 0 表示验证错误。我们建议将阈值设置为 0，因为验证错误意味着 CloudFront Functions 交回给 CloudFront 时出现问题。例如，CloudFront 需要 HTTP 主机标头才能处理请求。没有什么可以阻止用户删除其 CloudFront Functions 代码中的主机标头。但是，当 CloudFront 返回响应并且主机标头丢失时，CloudFront 会引发验证错误。
**时间段：**60
**要发出警报的数据点数**：2
**评估期：**2
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**FunctionExecutionErrors**
**维度：**DistributionId、FunctionName、Region=Global
**警报描述：**此警报可帮助您监控 CloudFront Functions 中的执行错误，以便您可以采取措施解决它们。分析 CloudWatch 函数日志并查看函数代码，找出问题的根本原因并予以解决。
**意图：**此警报用于检测 CloudFront Functions 中的执行错误。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**我们建议将阈值设置为 0，因为执行错误表示运行时系统代码有问题。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**FunctionThrottles**
**维度：**DistributionId、FunctionName、Region=Global
**警报描述：**此警报可帮助您监控您的 CloudFront 函数是否受到限制。如果您的函数受到限制，则意味着其执行时间太长。为避免函数限制，请考虑优化函数代码。
**意图：**此警报可以检测您的 CloudFront 函数何时会受到限制，以便您可以作出反应并解决问题，从而提供流畅的客户体验。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**我们建议将阈值设置为 0，以便更快地解决函数限制。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon Cognito
**SignUpThrottles**
**维度：**UserPool、UserPoolClient
**警报描述：**此警报会监控受限请求的数量。如果用户持续受到限制，则应通过请求增加服务限额来提高限制。要了解如何请求增加限额，请参阅 [Amazon Cognito 中的限额](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html)。要主动执行操作，请考虑跟踪[使用限额](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#track-quota-usage)。
**意图：**此警报有助于监控受限注册请求的发生情况。这可以帮助您了解何时该执行操作来缓解注册体验的恶化。持续的限制请求会带来较差的用户注册体验。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**预置良好的用户群体不应遇到跨越多个数据点的任何限制。因此，预期工作负载的典型阈值应为 0。对于具有频繁突发的不规则工作负载，您可以分析历史数据以确定应用程序工作负载的可接受限制，然后可以相应地调整阈值。应重试受限请求，最大限度地减少对应用程序的影响。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**SignInThrottles**
**维度：**UserPool、UserPoolClient
**警报描述：**此警报会监控受限用户身份验证请求的计数。如果用户持续受到限制，您可能需要通过请求增加服务限额来提高限制。要了解如何请求增加限额，请参阅 [Amazon Cognito 中的限额](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html)。要主动执行操作，请考虑跟踪[使用限额](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#track-quota-usage)。
**意图：**此警报有助于监控受限登录请求的发生情况。这可以帮助您了解何时该执行操作来缓解登录体验的恶化。持续的限制请求会带来糟糕的用户身份验证体验。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**预置良好的用户群体不应遇到跨越多个数据点的任何限制。因此，预期工作负载的典型阈值应为 0。对于具有频繁突发的不规则工作负载，您可以分析历史数据以确定应用程序工作负载的可接受限制，然后可以相应地调整阈值。应重试受限请求，最大限度地减少对应用程序的影响。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**TokenRefreshTrott**
**维度：**UserPool、UserPoolClient
**警报描述：**您可以设置阈值以适应请求的流量，并为令牌刷新请求匹配可接受限制。限制用于保护您的系统不会收到过多请求。但是，请务必监控您的正常流量是否也预置不足。您可以分析历史数据以确定应用程序工作负载的可接受限制，然后可以将警报阈值调整为高于可接受限制级别。受限请求应由应用程序/服务重试，因为它们是暂时性的。因此，非常低的阈值可能会导致警报过于敏感。
**意图：**此警报有助于监控受限令牌刷新请求的发生情况。这可以帮助您了解何时该执行操作来缓解任何潜在问题，从而确保流畅的用户体验以及身份验证系统的正常运行和可靠性。持续的限制请求会带来糟糕的用户身份验证体验。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**也可以设置/调整阈值，以适应请求的流量以及令牌刷新请求的可接受限制。限制是为了保护您的系统不会收到过多请求，不过，请务必监控您的正常流量是否也预置不足，并查看是否此情况是否造成了影响。还可以分析历史数据以了解应用程序工作负载的可接受限制，然后可以将阈值调整为高于一般可接受限制级别。受限请求应由应用程序/服务重试，因为它们是暂时性的。因此，非常低的阈值可能会导致警报过于敏感。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**FederationThrottles**
**维度：**UserPool、UserPoolClient、IdentityProvider
**警报描述：**此警报会监控受限身份联合验证请求的计数。如果您持续受到限制，则表示您需要通过请求增加服务限额来提高限制。要了解如何请求增加限额，请参阅 [Amazon Cognito 中的限额](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html)。
**意图：**此警报有助于监控受限身份联合验证请求的发生情况。这可以帮助您主动应对性能瓶颈或配置错误，并确保您的用户获得流畅的身份验证体验。持续的限制请求会带来糟糕的用户身份验证体验。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**您可以设置阈值以适应请求的流量，并为身份联合验证请求匹配可接受限制。限制用于保护您的系统不会收到过多请求。但是，请务必监控您的正常流量是否也预置不足。您可以分析历史数据以确定应用程序工作负载的可接受限制，然后将阈值调整为高于可接受限制级别的值。受限请求应由应用程序/服务重试，因为它们是暂时性的。因此，非常低的阈值可能会导致警报过于敏感。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon DynamoDB
**AccountProvisionedReadCapacityUtilization**
**维度：**None
**警报描述：**此警报会检测账户的读取容量是否将达到其预置限制。如果发生这种情况，您可以提高读取容量利用率的账户限额。您可以使用[服务限额](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)查看读取容量单位的当前限额，并请求增加限额。
**意图：**此警报可以检测账户的读取容量利用率是否接近其预置读取容量利用率。如果利用率达到最大限制，DynamoDB 会开始限制读取请求。
**统计数据：**Maximum
**建议阈值：**80.0
**阈值理由：**将阈值设置为 80%，这样就可以在阈值达到最大容量之前执行操作（例如提高账户限制），以避免限制。
**时间段：**300
**要发出警报的数据点数**：2
**评估期：**2
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**AccountProvisionedWriteCapacityUtilization**
**维度：**None
**警报描述：**此警报会检测账户的写入容量是否将达到其预置限制。如果发生这种情况，您可以提高写入容量利用率的账户限额。您可以使用[服务限额](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)查看写入容量单位的当前限额，并请求增加限额。
**意图：**此警报可以检测账户的写入容量利用率是否接近其预置写入容量利用率。如果利用率达到最大限制，DynamoDB 会开始限制写入请求。
**统计数据：**Maximum
**建议阈值：**80.0
**阈值理由：**将阈值设置为 80%，这样就可以在阈值达到最大容量之前执行操作（例如提高账户限制），以避免限制。
**时间段：**300
**要发出警报的数据点数**：2
**评估期：**2
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**AgeOfOldestUnreplicatedRecord**
**维度：**TableName、DelegatedOperation
**警报描述：**此警报会检测复制到 Kinesis 数据流过程中的延迟。在正常运行情况下，`AgeOfOldestUnreplicatedRecord` 应该只有几毫秒。根据由客户控制的配置选项造成的失败复制尝试次数，此数量会增加。例如，可能导致复制尝试失败的客户控制配置包括：预置不足的 Kinesis 数据流容量导致过度限制，或者手动更新 Kinesis 数据流的访问策略会阻止 DynamoDB 向数据流添加数据。为将此指标保持在尽可能低的水平，您需要确保预置合适的 Kinesis 数据流容量，并确保未更改 DynamoDB 的权限。
**意图：**此警报可以监控失败复制尝试次数，以及由此导致的复制到 Kinesis 数据流过程中的延迟。
**统计数据：**Maximum
**建议阈值：**取决于您的情况
**阈值理由：**根据以毫秒为单位的所需复制延迟设置阈值。此值取决于您的工作负载要求和预期性能。
**时间段：**300
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**FailedToReplicateRecordCount**
**维度：**TableName、DelegatedOperation
**警报描述：**此警报会检测 DynamoDB 无法复制到 Kinesis 数据流的记录数。某些大于 34KB 的项目可能会扩增，以更改大于 Kinesis Data Streams 1MB 项目大小限制的数据记录。当大于 34KB 的项目包含大量布尔值或空属性值时，就会出现此扩增现象。布尔值和空属性值在 DynamoDB 中存储为 1 个字节，但在使用标准 JSON 进行 Kinesis Data Streams 复制时，最多可扩展到 5 个字节。DynamoDB 无法将此类更改记录复制到 Kinesis 数据流中。DynamoDB 跳过这些更改数据记录，并自动继续复制后续记录。
**意图：**此警报可以监控由于 Kinesis 数据流的项目大小限制，DynamoDB 无法复制到 Kinesis 数据流的记录数。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**将阈值设置为 0，可检测 DynamoDB 未能复制的任何记录。
**时间段：**60
**要发出警报的数据点数**：1
**评估期：**1
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ReadThrottleEvents**
**维度：**TableName
**警报描述：**此警报可检测 DynamoDB 表是否有大量读取请求受到限制。要解决此问题，请参阅[解决 Amazon DynamoDB 中的限制问题](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html)。
**意图：**此警报可以检测对 DynamoDB 表的读取请求的持续限制。持续限制读取请求会对您的工作负载读取操作产生负面影响，并降低系统的整体效率。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**根据 DynamoDB 表的预期读取流量设置阈值，同时考虑可接受的限制级别。请务必监控您的预置是否不足并且不会导致持续的限制。您还可以分析历史数据以确定应用程序工作负载的可接受限制级别，然后将警报阈值调整为高于一般限制级别。受限请求应由应用程序/服务重试，因为它们是暂时性的。因此，阈值过低可能会导致警报过于敏感，从而导致不必要的状态转换。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ReadThrottleEvents**
**维度**：TableName、GlobalSecondaryIndexName
**警报描述：**此警报可检测 DynamoDB 表的全局二级索引是否有大量读取请求受到限制。要解决此问题，请参阅[解决 Amazon DynamoDB 中的限制问题](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html)。
**意图：**此警报可以检测对 DynamoDB 表的全局二级索引读取请求的持续限制。持续限制读取请求会对您的工作负载读取操作产生负面影响，并降低系统的整体效率。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**根据 DynamoDB 表的预期读取流量设置阈值，同时考虑可接受的限制级别。请务必监控您的预置是否不足并且不会导致持续的限制。您还可以分析历史数据以确定应用程序工作负载的可接受限制级别，然后将阈值调整为高于一般可接受限制级别。受限请求应由应用程序/服务重试，因为它们是暂时性的。因此，阈值过低可能会导致警报过于敏感，从而导致不必要的状态转换。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ReplicationLatency**
**维度：**TableName、ReceivingRegion
**警报描述：**此警报会检测全局表某个区域中的副本是否滞后于源区域。如果 AWS 区域降级，并且您在该区域有一个副本表，则延迟可能会增加。在这种情况下，可以临时将应用程序的读取和写入活动重定向到不同的 AWS 区域。如果您使用的是 2017.11.29（旧版）的全局表，则应验证每个副本表的写入容量单位（WCU）是否相同。您也可以确保遵循 [Best practices and requirements for managing capacity](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables_reqs_bestpractices.html#globaltables_reqs_bestpractices.tables) 中的建议。
**意图：**此警报可以检测一个区域中的副本表是否落后于从另一个区域复制更改。这可能会导致您的副本与其他副本不同。了解每个 AWS 区域的复制延迟，并在该复制延迟持续增加时发出提醒会很有帮助。表的复制仅适用于全局表。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于您的用例。超过 3 分钟的复制延迟通常都需要调查。查看复制延迟的临界程度和要求并分析历史趋势，然后相应地选择阈值。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**SuccessfulRequestLatency**
**维度：**TableName、Operation
**警报描述：**此警报会检测 DynamoDB 表操作的高延迟（由警报中 `Operation` 的维度值表示）。请参阅[此问题排查文档](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingLatency.html)，了解如何排查 Amazon DynamoDB 中的延迟问题。
**意图：**此警报可以检测 DynamoDB 表操作的高延迟。操作的较高延迟会对系统的整体效率产生负面影响。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**DynamoDB 会为单例操作（例如 getItem、PutiTem 等）提供平均个位数毫秒延迟。但是，您可以根据工作负载中涉及的操作类型和表的可接受延迟容差来设置阈值。您可以分析此指标的历史数据以确定表操作的一般延迟，然后将阈值设置为代表操作的临界延迟的数字。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**SystemErrors**
**维度：**TableName
**警报描述：**此警报会检测 DynamoDB 表请求的持续大量系统错误。如果您持续收到 5xx 错误，请打开 [AWS 服务运行状况控制面板](https://status.aws.amazon.com/)，以检查服务是否存在操作问题。如果 DynamoDB 持续存在内部服务问题，您可以使用此警报来获取通知，它可以帮助您弄清楚您的客户端应用程序面临的问题。有关更多信息，请参阅 [DynamoDB 错误处理](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.MessagesAndCodes.http5xx)。
**意图：**此警报可以检测 DynamoDB 表请求的持续系统错误。系统错误表示 DynamoDB 中的内部服务错误，有助于您弄清楚客户端遇到的问题。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**根据预期流量设置阈值，同时考虑系统错误的可接受级别。您还可以分析历史数据以确定应用程序工作负载的可接受错误计数，然后相应地调整阈值。系统错误应由应用程序/服务重试，因为它们是暂时性的。因此，阈值过低可能会导致警报过于敏感，从而导致不必要的状态转换。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ThrottledPutRecordCount**
**维度：**TableName、DelegatedOperation
**警报描述：**此警报会检测在将更改数据捕获复制到 Kinesis 的过程中，您的 Kinesis 数据流限制的记录。出现此限制的原因是 Kinesis 数据流容量不足。如果遇到过多和定期的限制，则可能需要按照观察到的表写入吞吐量成比例增加 Kinesis 流分片数量。要了解有关如何确定 Kinesis 数据流的大小的详细信息，请参阅[确定 Kinesis Data Streams 的初始大小](https://docs.aws.amazon.com/streams/latest/dev/amazon-kinesis-streams.html#how-do-i-size-a-stream)。
**意图：**此警报可以监控由于 Kinesis 数据流容量不足而受到 Kinesis 数据流限制的记录数量。
**统计数据：**Maximum
**建议阈值：**取决于您的情况
**阈值理由：**异常使用高峰期间可能会遇到一些限制，但受限记录应保持在尽可能低的水平，以避免较高的复制延迟（DynamoDB 重试将受限记录发送到 Kinesis 数据流）。将阈值设置为一个数字，这样可以帮助您发现常规过度限制。您还可以分析此指标的历史数据，以确定应用程序工作负载的可接受限制速率。根据您的用例将阈值调整为应用程序可以容忍的值。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**UserErrors**
**维度：**None
**警报描述：**此警报会检测 DynamoDB 表请求的持续大量用户错误。您可以在问题时间范围内查看客户端应用程序日志，了解请求无效的原因。您可以检查 [HTTP 状态码 400](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.MessagesAndCodes.http400)，查看您收到的错误类型并执行相应操作。您可能必须修复应用程序逻辑才能创建有效的请求。
**意图：**此警报可以检测 DynamoDB 表请求的持续用户错误。所请求操作的用户错误表示客户端在生成无效请求并且正在失败。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**将阈值设置为 0 可检测任何客户端错误。或者，如果要避免因错误数量非常少而触发警报，可以将其设置为更高的值。基于您的用例和请求的流量来决定。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**WriteThrottleEvents**
**维度：**TableName
**警报描述：**此警报可检测 DynamoDB 表是否有大量写入请求受到限制。要解决此问题，请参阅[解决 Amazon DynamoDB 中的限制问题](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html)。
**意图：**此警报可以检测 DynamoDB 表的写入请求的持续限制。持续限制写入请求会对您的工作负载写入操作产生负面影响，并降低系统的整体效率。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**根据 DynamoDB 表的预期写入流量设置阈值，同时考虑可接受的限制级别。请务必监控您的预置是否不足并且不会导致持续的限制。您还可以分析历史数据以确定应用程序工作负载的可接受限制级别，然后将阈值调整为高于一般可接受限制级别的值。受限请求应由应用程序/服务重试，因为它们是暂时性的。因此，阈值过低可能会导致警报过于敏感，从而导致不必要的状态转换。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**WriteThrottleEvents**
**维度**：TableName、GlobalSecondaryIndexName
**警报描述：**此警报可检测 DynamoDB 表的全局二级索引是否有大量写入请求受到限制。要解决此问题，请参阅[解决 Amazon DynamoDB 中的限制问题](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html)。
**意图：**此警报可以检测对 DynamoDB 表全局二级索引的写入请求的持续限制。持续限制写入请求会对您的工作负载写入操作产生负面影响，并降低系统的整体效率。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**根据 DynamoDB 表的预期写入流量设置阈值，同时考虑可接受的限制级别。请务必监控您的预置是否不足并且不会导致持续的限制。您还可以分析历史数据以确定应用程序工作负载的可接受限制级别，然后将阈值调整为高于一般可接受限制级别的值。受限请求应由应用程序/服务重试，因为它们是暂时性的。因此，值过低可能会导致警报过于敏感，从而导致不必要的状态转换。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon EBS
**VolumeStalledIOCheck**
**维度：**VolumeId, InstanceId
**警报描述：**此警报有助于监控 Amazon EBS 卷的 IO 性能。此检查可检测 Amazon EBS 基础设施的潜在问题，例如 Amazon EBS 卷所基于的存储子系统硬件或软件问题、影响从 Amazon EC2 实例访问 Amazon EBS 卷的物理主机硬件问题，还可以检测实例与 Amazon EBS 卷之间的连接问题。如果“停滞 IO 检查”失败，您可以等待 AWS 解决问题，也可以自行采取措施，例如替换受影响的卷或停止并重启挂载了该卷的实例。在大多数情况下，当该指标失败时，Amazon EBS 将在几分钟内自动诊断并恢复您的卷。
**意图：**此警报可以检测 Amazon EBS 卷的状态，以确定这些卷何时受损且无法完成 I/O 操作。
**统计数据：**Maximum
**建议阈值：**1.0
**阈值理由：**当状态检查失败时，此指标的值为 1。设置阈值后，每当状态检查失败时，警报都将处于“ALARM”状态。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon EC2
**CPU 利用率**
**维度：**InstanceId
**警报描述：**此警报有助于监控 EC2 实例的 CPU 利用率。根据应用程序的不同，持续的高利用率级别可能是正常的。但是，如果性能下降，并且应用程序不受磁盘 I/O、内存或网络资源的限制，则达到极限的 CPU 可能表示存在资源瓶颈或应用程序性能问题。高 CPU 利用率可能表示需要升级到 CPU 密集型实例。如果启用了详细监控，则可以将时间段更改为 60 秒而不是 300 秒。有关更多信息，请参阅[对实例启用或禁用详细监控](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)。
**意图：**此警报用于检测高 CPU 利用率。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**通常，您可以将 CPU 利用率的阈值设置为 70-80%。但是，您可以根据可接受性能级别和工作负载特征来调整此值。对于某些系统，持续的高 CPU 利用率可能是正常现象，并不表示存在问题，而对于某些系统，此情况应引起注意。分析历史 CPU 利用率数据以确定使用情况，弄清您系统的可接受 CPU 利用率，并相应地设置阈值。
**时间段：**300
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**StatusCheckFailed**
**维度：**InstanceId
**警报描述：**此警报有助于监控系统状态检查和实例状态检查。如果任一类型的状态检查失败，则此警报应处于“ALARM”状态。
**意图：**此警报用于检测实例的根本问题，包括系统状态检查失败和实例状态检查失败。
**统计数据：**Maximum
**建议阈值：**1.0
**阈值理由：**当状态检查失败时，此指标的值为 1。设置阈值后，每当状态检查失败时，警报都将处于“ALARM”状态。
**时间段：**300
**要发出警报的数据点数**：2
**评估期：**2
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**StatusCheckFailed\$1AttachedEBS**
**维度：**InstanceId
**警报描述：**此警报可帮助您监控附加到实例的 Amazon EBS 卷是否可以访问并能够完成 I/O 操作。此状态检查可检测计算或 Amazon EBS 基础设施存在的底层问题，如下所示：
+ Amazon EBS 卷底层的存储子系统的硬件或软件问题
+ 物理主机上的硬件问题，该问题会影响 Amazon EBS 卷的可访问性
+ 实例和 Amazon EBS 卷之间的连接问题
当附加的 EBS 状态检查失败时，您可以等待 Amazon 解决问题，也可以自行采取措施，例如更换受影响的卷或停止并重启实例。
**意图：**此警报用于检测附加到实例的哪些 Amazon EBS 卷无法访问。这些会导致 I/O 操作失败。
**统计数据：**Maximum
**建议阈值：**1.0
**阈值理由：**当状态检查失败时，此指标的值为 1。设置阈值后，每当状态检查失败时，警报都将处于“ALARM”状态。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon ElastiCache
**CPU 利用率**
**维度：**CacheClusterId、CacheNodeId
**警报描述：**此警报有助于监控整个 ElastiCache 实例的 CPU 利用率，包括数据库引擎进程和实例上运行的其他进程。AWSElasticache 支持两种引擎类型：Memcached 和 Redis OSS。当您在 Memcached 节点上达到高 CPU 利用率时，应考虑纵向扩展实例类型或添加新的缓存节点。对于 Redis OSS，如果您的主要工作负载来自读取请求，则应考虑向缓存集群添加更多只读副本。如果您的主要工作负载来自写入请求，则要在集群模式下运行时，应考虑添加更多分片以将工作负载分配到更多主节点；而要非集群模式下运行 Redis OSS 时，应考虑纵向扩展实例类型。
**意图：**此警报用于检测 ElastiCache 主机的高 CPU 利用率。这对全面了解整个实例（包括非引擎进程）的 CPU 使用情况很有用。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**将阈值设置为反映应用程序的临界 CPU 利用率级别的百分比。对于 Memcached，引擎最多可以使用 num\$1threads 个核心。对于 Redis OSS，引擎主要是单线程的，但如果有额外的核心，也可以使用它们来加速 I/O。在大多数情况下，您可以将阈值设置为可用 CPU 的 90% 左右。因为 Redis OSS 是单线程的，实际阈值应计算为节点总容量的一小部分。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**CurrConnections**
**维度：**CacheClusterId、CacheNodeId
**警报描述：**此警报可检测高连接计数，这可能表示负载过重或存在性能问题。`CurrConnections` 的持续增加可能会导致 65000 个可用连接耗尽。这可能表明应用程序端的连接关闭不当，并且在服务器端未断开。您应该考虑使用连接池或空闲连接超时来限制与集群建立的连接数量，或者对于 Redis OSS，可以考虑在集群上调整 [tcp-keepalive](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html)，以检测和终止潜在失效对端。
**意图：**此警报有助于您识别可能影响 ElastiCache 集群性能和稳定性的高连接计数。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于集群的可接受连接范围。查看 ElastiCache 集群的容量和预期工作负载，分析常规使用期间的历史连接计数以建立基准，然后相应地选择阈值。请记住，每个节点最多可以支持 65000 个并发连接。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**DatabaseMemoryUsagePercentage**
**维度：**CacheClusterId
**警报描述：**此警报有助于监控集群的内存利用率。当 `DatabaseMemoryUsagePercentage` 达到 100% 时，将触发 Redis OSS maxmemory 策略，并且可能会根据所选策略进行驱逐。如果缓存中没有符合驱逐策略的对象，则写入操作将失败。有些工作负载期望或依赖驱逐，如果不是这样，您需要增加集群的内存容量。您可以通过添加更多主节点来横向扩展集群，也可以使用更大的节点类型对其纵向扩展。有关详细信息，请参阅 [Scaling ElastiCache for Redis OSS clusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html)。
**意图：**此警报用于检测集群的高内存利用率，以便在写入集群时避免失败。如果您的应用程序预计不会遭遇驱逐，则了解何时需要纵向扩展集群会很有用。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**根据应用程序的内存要求和 ElastiCache 集群的内存容量，您应将阈值设置为反映集群内存使用量临界水平的百分比。您可以使用历史内存使用数据，作为可接受内存使用量阈值的参考。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**EngineCPUUtilization**
**维度：**CacheClusterId
**警报描述：**此警报有助于监控 ElastiCache 实例中 Redis OSS 引擎线程的 CPU 利用率。引擎 CPU 占用率高的常见原因包括：消耗高 CPU 的长时间运行的命令、大量请求、短时间内新的客户端连接请求增加，以及缓存没有足够的内存来容纳新数据时的高驱逐率。您应该考虑通过添加更多节点或纵向扩展实例类型来实现 [ElastiCache for Redis OSS 集群的扩缩](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html)。
**意图：**此警报用于检测 Redis OSS 引擎线程的高 CPU 利用率。它在要监控数据库引擎本身的 CPU 利用率时很有用。
**统计数据：**平均值
**建议阈值：**90.0
**阈值理由：**将阈值设置为反映应用程序的临界引擎 CPU 利用率级别的百分比。您可以使用应用程序和预期工作负载对集群进行基准测试，关联 EngineCPUUtilization 和性能作为参考，然后相应地设置阈值。在大多数情况下，您可以将阈值设置为可用 CPU 的 90% 左右。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ReplicationLag**
**维度：**CacheClusterId
**警报描述：**此警报有助于监控您的 ElastiCache 集群的复制运行状况。高复制滞后意味着主节点或副本无法跟上复制的步伐。如果您的写入活动过高，可以考虑通过添加更多主节点来横向扩展集群，或者使用更大的节点类型纵向扩展集群。有关详细信息，请参阅 [Scaling ElastiCache for Redis OSS clusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html)。如果您的只读副本因读取请求的数量而过载，可以考虑添加更多只读副本。
**意图：**此警报用于检测主节点上的数据更新与其同步到副本节点之间的延迟。它有助于确保只读副本集群节点的数据一致性。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**根据应用程序的要求和复制滞后的潜在影响来设置阈值。您应该考虑应用程序的预期写入速率和网络条件，以确定可接受的复制滞后。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon ECS
以下是针对 Amazon ECS 的推荐警报。
**CPUReservation**
**维度：**ClusterName
**警报描述：**此警报有助于您检测 ECS 集群的高 CPU 预留。高 CPU 预留可能表示集群将耗尽为任务注册的 CPU。要排查问题，您可以添加更多容量、扩展集群，也可以设置自动扩缩。
**意图：**该警报用于检测集群上任务预留的 CPU 单元总数是否达到为集群注册的 CPU 单位总数。这有助于您了解何时纵向扩展集群。达到集群的 CPU 单位总数可能会导致任务的 CPU 耗尽。如果您开启了 EC2 容量提供商托管式扩展，或者您已将 Fargate 关联到容量提供商，则不建议设置此警报。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将 CPU 预留阈值设置为 80%。或者，您可以基于集群特征选择较小的值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**CPU 利用率**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测 ECS 服务的高 CPU 利用率。如果没有正在进行的 ECS 部署，则达到极限的 CPU 利用率可能表示存在资源瓶颈或应用程序性能问题。要排查问题，可以提高 CPU 限制。
**意图：**此警报用于检测 Amazon ECS 服务的高 CPU 利用率。持续的高 CPU 利用率可能表示存在资源瓶颈或应用程序性能问题。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**CPU 利用率的服务指标可能超过 100% 的利用率。但是，我们建议您监控高 CPU 利用率的指标，避免影响其他服务。将阈值设置为大约 80-85% 左右。我们建议您更新任务定义以反映实际使用量，以防其他服务将来出现问题。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**EBSFilesystemUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测挂载到 Amazon ECS 任务的 Amazon EBS 卷的存储利用率是否较高。如果 Amazon EBS 卷的利用率持续较高，则可以检查使用情况并针对新任务增加卷大小。
**用途：**此警报用于检测挂载到 Amazon ECS 任务的 Amazon EBS 卷的存储利用率是否较高。存储利用率持续较高可能表明 Amazon EBS 卷已满，这可能导致容器出现故障。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**可以将 Amazon EBS 文件系统的利用率阈值设置为 80% 左右。您可以根据可接受的存储利用率调整此值。对于只读快照卷，利用率较高可能表明该卷的大小合适。对于活动数据卷，存储利用率较高可能表示应用程序正在写入大量数据，此时容量不足可能会导致容器出现故障。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**MemoryReservation**
**维度：**ClusterName
**警报描述：**此警报有助于检测 Amazon ECS 集群的高内存预留。高内存预留可能表示集群存在资源瓶颈。要排查问题，请分析服务任务的性能，查看是否可以优化任务的内存利用率。此外，您可以注册更多内存或设置自动扩缩。
**意图：**该警报用于检测集群上任务预留的存储单元总数是否达到为集群注册的存储单元总数。这有助于您了解何时纵向扩展集群。达到集群的存储单元总数可能会导致集群无法启动新任务。如果您开启了 EC2 容量提供商托管式扩展，或者您已将 Fargate 关联到容量提供商，则不建议设置此警报。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将内存预留阈值设置为 80%。您可以基于集群特征将其调整为较小的值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**MemoryUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测 Amazon ECS 服务内存利用率较高的情况。如果没有正在进行的 Amazon ECS 部署，则达到极限的内存利用率可能表示存在资源瓶颈或应用程序性能问题。要排查问题，您可以提高内存限制。
**意图：**此警报用于检测 Amazon ECS 服务内存利用率较高的情况。持续的高内存利用率可能表明存在资源瓶颈或应用程序性能问题。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**内存利用率的服务指标可能超过 100% 的利用率。但是，我们建议您监控高内存利用率的指标，避免影响其他服务。将阈值设置为大约 80%。我们建议您更新任务定义以反映实际使用量，以防其他服务将来出现问题。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**HTTPCode\$1Target\$15XX\$1Count**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测 ECS 服务的服务器端高错误计数。这可能表示存在导致服务器无法处理请求的错误。要排查问题，请检查您的应用程序日志。
**意图：**此警报用于检测 ECS 服务的服务器端高错误计数。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**计算约占平均流量的 5％ 的值，并使用该值作为阈值的起点。您可以使用 `RequestCount` 指标确定平均流量。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。需要对经常发生的 5XX 错误发出警报。但是，将阈值设置得非常低可能会导致警报过于敏感。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**TargetResponseTime**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测 ECS 服务请求的长目标响应时间。这可能表示存在导致服务无法及时处理请求的错误。要排查问题，请检查 CPUUtilization 指标以查看服务是否耗尽了 CPU，或者检查您的服务所依赖的其他下游服务的 CPU 利用率。
**意图：**此警报用于检测 ECS 服务请求的长目标响应时间。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于您的用例。查看服务的目标响应时间的临界程度和要求，并分析此指标的历史行为以确定合理的阈值级别。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## 具有 Container Insights 的 Amazon ECS
以下是针对使用 Container Insights 的 Amazon ECS 推荐警报。
**EphemeralStorageUtilized**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测 Fargate 集群的临时存储空间利用率较高的情况。如果临时存储空间利用率持续较高，则可以检查临时存储空间使用情况并增加临时存储空间。
**意图：**此警报用于检测 Fargate 集群的临时存储空间利用率较高的情况。如果临时存储空间利用率持续较高，则可能表明磁盘已满，并可能导致容器出现故障。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值调整：**将阈值设置为临时存储空间大小的 90% 左右。您可以根据您的 Fargate 集群可接受的临时存储空间利用率调整此值。对于某些系统，临时存储空间利用率持续较高可能是正常的，而对于另一些系统，则可能会导致容器出现故障。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**RunningTaskCount**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测 Amazon ECS 服务运行任务数不足的情况。如果正在运行的任务数太少，则可能表明应用程序无法处理服务负载，并可能导致性能问题。如果没有正在运行的任务，Amazon ECS 服务可能不可用或者可能存在部署问题。
**意图：**此警报用于检测正在运行的任务数是否过少。持续较少的运行任务数可能表明 Amazon ECS 服务部署或性能存在问题。
**统计数据：**平均值
**建议阈值：**0.0
**阈值调整：**您可以根据 Amazon ECS 服务的最小运行任务数来调整阈值。如果正在运行的任务数为 0，则 Amazon ECS 服务将不可用。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**TaskCpuUtilization**
**维度：**ClusterName
**警报描述：**此警报有助于您检测 Amazon ECS 集群中任务 CPU 利用率较高的情况。如果任务 CPU 利用率持续较高，则可能需要优化任务或增加其 CPU 预留。
**意图：**此警报用于检测 Amazon ECS 集群中任务 CPU 利用率较高的情况。持续的高 CPU 利用率可能表明任务承受压力，可能需要更多的 CPU 资源或优化才能维持性能。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为任务 CPU 预留的 80% 左右。您可以根据可接受的任务 CPU 利用率来调整此值。对于某些工作负载，CPU 利用率持续较高可能是正常的，而对于另一些工作负载，则可能表明存在性能问题或需要更多资源。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**TaskCpuUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测属于 Amazon ECS 服务的任务 CPU 利用率较高的情况。如果任务 CPU 利用率持续较高，则可能需要优化任务或增加其 CPU 预留。
**意图：**此警报用于检测属于 Amazon ECS 服务的任务 CPU 利用率较高的情况。持续的高 CPU 利用率可能表明任务承受压力，可能需要更多的 CPU 资源或优化才能维持性能。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为任务 CPU 预留的 80% 左右。您可以根据可接受的任务 CPU 利用率来调整此值。对于某些工作负载，CPU 利用率持续较高可能是正常的，而对于另一些工作负载，则可能表明存在性能问题或需要更多资源。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ContainerCpuUtilization**
**维度：**ClusterName
**警报描述：**此警报可监控 Amazon ECS 集群中容器使用的 CPU 单元占其预留 CPU 的百分比。此警报有助于根据 ContainerCpuUtilized/ContainerCpuReserved 比率检测容器何时接近其 CPU 限制。
**意图：**此警报可检测 Amazon ECS 集群中的容器何时占用其预留 CPU 容量的百分比较高，其计算方法为 `ContainerCpuUtilized/ContainerCpuReserved`。持续的高值表示容器运行接近其 CPU 限制，可能需要调整容量。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为容器 CPU 利用率的 80% 左右。这样做可以在容器接近其 CPU 容量限制时提供预警，同时允许 CPU 利用率出现正常波动。可以根据您的工作负载特征和性能要求来调整阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ContainerCpuUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报可监控属于 Amazon ECS 服务的容器使用的 CPU 单元占其预留 CPU 的百分比。此警报有助于根据 ContainerCpuUtilized/ContainerCpuReserved 比率检测容器何时接近其 CPU 限制。
**意图：**此警报可检测属于 Amazon ECS 服务的容器何时占用其预留 CPU 容量的百分比较高，其计算方法为 ContainerCpuUtilized/ContainerCpuReserved。持续的高值表示容器运行接近其 CPU 限制，可能需要调整容量。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为容器 CPU 利用率的 80% 左右。这样做可以在容器接近其 CPU 容量限制时提供预警，同时允许 CPU 利用率出现正常波动。可以根据您的工作负载特征和性能要求来调整阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**维度：**ClusterName
**警报描述：**此警报有助于您检测 Amazon ECS 集群中任务的临时存储利用率较高的情况。如果存储利用率持续较高，则可能需要优化存储使用量或增加存储预留。
**意图：**此警报用于检测 Amazon ECS 集群中任务的临时存储利用率较高的情况。持续的高存储利用率可能表明任务的磁盘空间不足，可能需要更多的存储资源或优化才能维持正常运行。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为任务临时存储预留的 80% 左右。您可以根据可接受的任务临时存储利用率来调整此值。对于某些工作负载，存储利用率持续较高可能是正常的，而对于另一些工作负载，则可能表明磁盘空间存在潜在问题或需要更多存储空间。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测属于 Amazon ECS 服务的任务临时存储利用率较高的情况。如果存储利用率持续较高，则可能需要优化存储使用量或增加存储预留。
**意图：**此警报用于检测属于 Amazon ECS 服务的任务临时存储利用率较高的情况。持续的高存储利用率可能表明任务的磁盘空间不足，可能需要更多的存储资源或优化才能维持正常运行。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为任务临时存储预留的 80% 左右。您可以根据可接受的任务临时存储利用率来调整此值。对于某些工作负载，存储利用率持续较高可能是正常的，而对于另一些工作负载，则可能表明磁盘空间存在潜在问题或需要更多存储空间。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**维度：**ClusterName
**警报描述：**此警报有助于您检测 Amazon ECS 集群中任务内存利用率较高的情况。如果内存利用率持续较高，则可能需要优化任务或增加内存预留。
**意图：**此警报用于检测 Amazon ECS 集群中任务内存利用率较高的情况。持续的高内存利用率可能表明任务承受内存压力，可能需要更多的内存资源或优化才能维持稳定性。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为任务内存预留的 80% 左右。您可以根据可接受的任务内存利用率来调整此值。对于某些工作负载，内存利用率持续较高可能是正常的，而对于另一些工作负载，则可能表明存在内存压力或需要更多资源。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测属于 Amazon ECS 服务的任务内存利用率较高的情况。如果内存利用率持续较高，则可能需要优化任务或增加内存预留。
**意图：**此警报用于检测属于 Amazon ECS 服务的任务内存利用率较高的情况。持续的高内存利用率可能表明任务承受内存压力，可能需要更多的内存资源或优化才能维持稳定性。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为任务内存预留的 80% 左右。您可以根据可接受的任务内存利用率来调整此值。对于某些工作负载，内存利用率持续较高可能是正常的，而对于另一些工作负载，则可能表明存在内存压力或需要更多资源。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**维度：**ClusterName
**警报描述：**此警报有助于您检测 Amazon ECS 集群中容器内存利用率较高的情况。如果内存利用率持续较高，则可能需要优化容器或增加内存预留。
**意图：**此警报用于检测 Amazon ECS 集群中容器内存利用率较高的情况。持续的高内存利用率可能表明容器承受内存压力，可能需要更多的内存资源或优化才能维持稳定性。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为容器内存预留的 80% 左右。您可以根据可接受的容器内存利用率来调整此值。对于某些工作负载，内存利用率持续较高可能是正常的，而对于另一些工作负载，则可能表明存在内存压力或需要更多资源。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于您检测属于 Amazon ECS 服务的容器内存利用率较高的情况。如果内存利用率持续较高，则可能需要优化容器或增加内存预留。
**意图：**此警报用于检测属于 Amazon ECS 服务的容器内存利用率较高的情况。持续的高内存利用率可能表明容器承受内存压力，可能需要更多的内存资源或优化才能维持稳定性。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将阈值设置为容器内存预留的 80% 左右。您可以根据可接受的容器内存利用率来调整此值。对于某些工作负载，内存利用率持续较高可能是正常的，而对于另一些工作负载，则可能表明存在内存压力或需要更多资源。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**instance\$1filesystem\$1utilization**
**维度：**InstanceId、ContainerInstanceId、ClusterName
**警报描述：**此警报有助于您检测 Amazon ECS 集群的文件系统利用率较高的情况。如果文件系统利用率持续较高，请检查磁盘利用率。
**意图：**此警报用于检测 Amazon ECS 集群的文件系统利用率较高的情况。文件系统利用率持续较高可能表示存在资源瓶颈或应用程序性能问题，并且可能会阻碍新任务的运行。
**统计数据：**平均值
**建议阈值：**90.0
**阈值调整：**您可以将文件系统利用率的阈值设置为 90-95%。您可以根据 Amazon ECS 集群可接受的文件系统容量级别调整此值。对于某些系统，文件系统利用率持续较高可能是正常现象，并不表示存在问题；而对于另一些系统，这可能令人担忧，并可能导致性能问题并阻碍新任务的运行。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## 使用增强了可观测性的 Container Insights 的 Amazon ECS
以下是针对使用增强了可观测性的 Container Insights 的 Amazon ECS 推荐警报。
**TaskCpuUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于检测任务正在使用的 CPU 单位的总百分比。
**意图：**此警报用于检测高任务 CPU 利用率。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**通常，可以将 CPU 利用率的阈值设置为 80%。但是，您可以根据可接受性能级别和工作负载特征来调整此值。对于某些任务而言，持续的高 CPU 利用率可能是正常现象，并不表示存在问题，而对于其他任务而言，此情况应引起注意。分析历史 CPU 利用率数据来确定使用情况，弄清任务的可接受 CPU 利用率，并相应地设置阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于检测任务正在使用的内存的总百分比。
**意图：**此警报用于检测高内存利用率。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**通常，可以将内存利用率的阈值设置为 80%。但是，您可以根据可接受性能级别和工作负载特征来调整此值。对于某些任务而言，持续的高内存利用率可能是正常现象，并不表示存在问题，而对于其他任务而言，此情况应引起注意。分析历史内存利用率数据来确定使用情况，弄清任务的可接受内存利用率，并相应地设置阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ContainerCPUUtilization**
**维度：**ContainerName、ClusterName、ServiceName
**警报描述：**此警报有助于检测容器正在使用的 CPU 单位的总百分比。
**意图：**此警报用于检测高任务 CPU 利用率。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**通常，可以将 CPU 利用率的阈值设置为 80%。但是，您可以根据可接受性能级别和工作负载特征来调整此值。对于某些容器而言，持续的高 CPU 利用率可能是正常现象，并不表示存在问题，而对于其他容器而言，此情况应引起注意。分析历史 CPU 利用率数据来确定使用情况，弄清容器的可接受 CPU 利用率，并相应地设置阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**维度：**ContainerName、ClusterName、ServiceName
**警报描述：**此警报有助于检测容器正在使用的内存单位的总百分比。
**意图：**此警报用于检测高任务内存利用率。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**通常，可以将内存利用率的阈值设置为 80%。但是，您可以根据可接受性能级别和工作负载特征来调整此值。对于某些容器而言，持续的高内存利用率可能是正常现象，并不表示存在问题，而对于其他容器而言，此情况应引起注意。分析历史内存利用率数据来确定使用情况，弄清任务的可接受内存利用率，并相应地设置阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**TaskEBSfilesystemUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于检测任务正在使用的临时存储的总百分比。
**意图：**此警报用于检测任务的高 Amazon EBS 文件系统使用率。
**统计数据：**平均值
**建议阈值：**80.0
**阈值理由：**将 Amazon EBS 文件系统的大小阈值设置为 80% 左右。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**维度：**ClusterName、ServiceName
**警报描述：**此警报有助于检测任务正在使用的临时存储的总百分比。
**意图：**此警报用于检测任务的高临时存储使用率。如果临时存储空间利用率持续较高，则可能表明磁盘已满，并可能导致任务失败。
**统计数据：**平均值
**建议阈值：**80.0
**阈值调整：**将临时存储空间大小的阈值设置为 80% 左右。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon EFS
**PercentIOLimit**
**维度：**FileSystemId
**警报描述：**此警报有助于确保工作负载保持在文件系统可用的 I/O 限制范围内。如果指标持续达到其 I/O 限制，可以考虑将应用程序移至使用最大 I/O 性能作为模式的文件系统。要排查问题，请检查连接到文件系统的客户端和限制文件系统之客户端的应用程序。
**意图：**此警报用于检测文件系统接近通用性能模式的 I/O 限制的情况。持续的高 I/O 百分比可能表明文件系统无法在 I/O 请求方面进行足够的扩展，并且文件系统可能成为使用该文件系统之应用程序的资源瓶颈。
**统计数据：**平均值
**建议阈值：**100.0
**阈值理由：**当文件系统达到其 I/O 限制时，它对读取和写入请求的响应速度可能会变慢。因此，建议监控该指标，以免影响使用文件系统的应用程序。阈值可以设置为 100% 左右。但是，可根据文件系统特征将此值调整为较低的值。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**BurstCreditBalance**
**维度：**FileSystemId
**警报描述：**此警报有助于确保文件系统使用量有可用的突增积分余额。当没有可用的突增积分时，由于吞吐量低，应用程序对文件系统的访问将受到限制。如果指标持续降至 0，可以考虑将吞吐量模式更改为 [Elastic 或预置吞吐量模式](https://docs.aws.amazon.com/efs/latest/ug/performance.html#throughput-modes)。
**意图：**此警报用于检测文件系统的低突增积分余额。持续的低突增积分余额可能表明吞吐量降低和 I/O 延迟增加。
**统计数据：**平均值
**建议阈值：**0.0
**阈值理由：**当文件系统耗尽突增积分时，即使基准吞吐率较低，EFS 仍会继续向所有文件系统提供 1MiBps 的计量吞吐量。但是，建议监控指标是否存在低突增积分余额，避免文件系统成为应用程序的资源瓶颈。阈值可以设置为 0 字节左右。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## 具有 Container Insights 的 Amazon EKS
**node\$1cpu\$1utilization**
**维度：**ClusterName
**警报描述：**此警报有助于检测 EKS 集群的 Worker 节点中的高 CPU 利用率。如果利用率一直很高，则可能表明需要将 Worker 节点替换为具有更高 CPU 的实例，或者需要横向扩展系统。
**意图：**此警报有助于监控 EKS 集群中 Worker 节点的 CPU 利用率，这样系统性能就不会降低。
**统计数据：**Maximum
**建议阈值：**80.0
**阈值理由：**建议将阈值设置为小于或等于 80%，以便有足够的时间在系统开始受到影响之前调试问题。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**node\$1filesystem\$1utilization**
**维度：**ClusterName
**警报描述：**此警报有助于检测 EKS 集群的 Worker 节点中的高文件系统利用率。如果利用率一直很高，则可能需要更新 Worker 节点以拥有更大的磁盘卷，或者可能需要横向扩展。
**意图：**此警报有助于监控 EKS 集群中 Worker 节点的文件系统利用率。如果利用率达到 100%，则可能导致应用程序故障、磁盘 I/O 瓶颈、容器组（pod）驱逐或节点完全无响应。
**统计数据：**Maximum
**建议阈值：**取决于您的情况
**阈值理由：**如果有足够的磁盘压力（这意味着磁盘将满），则节点将被标记为运行状况不佳，容器组（pod）将被驱逐出节点。当可用文件系统低于 kubelet 上设置的驱逐阈值时，有磁盘压力的节点上的容器组（pod）将被驱逐。设置警报阈值，以便您在节点被驱逐出集群之前有足够的时间作出反应。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**node\$1memory\$1utilization**
**维度：**ClusterName
**警报描述：**此警报有助于检测 EKS 集群的 Worker 节点中的高内存利用率。如果利用率一直很高，则可能表明需要扩展容器组（pod）副本的数量或优化您的应用程序。
**意图：**此警报有助于监控 EKS 集群中 Worker 节点的内存利用率，这样系统性能就不会降低。
**统计数据：**Maximum
**建议阈值：**80.0
**阈值理由：**建议将阈值设置为小于或等于 80%，以便有足够的时间在系统开始受到影响之前调试问题。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**pod\$1cpu\$1utilization\$1over\$1pod\$1limit**
**维度：**ClusterName、Namespace、Service
**警报描述：**此警报有助于检测 EKS 集群的容器组（pod）中的高 CPU 利用率。如果利用率一直很高，则可能表明需要增加受影响容器组（pod）的 CPU 限制。
**意图：**此警报有助于监控 EKS 集群中属于 Kubernetes 服务的容器组（pod）的 CPU 利用率，以便您可以快速识别服务的容器组（pod）占用的 CPU 是否高于预期。
**统计数据：**Maximum
**建议阈值：**80.0
**阈值理由：**建议将阈值设置为小于或等于 80%，以便有足够的时间在系统开始受到影响之前调试问题。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**pod\$1memory\$1utilization\$1over\$1pod\$1limit**
**维度：**ClusterName、Namespace、Service
**警报描述：**此警报有助于检测 EKS 集群的容器组（pod）中的高内存利用率。如果利用率一直很高，则可能表明需要增加受影响容器组（pod）的内存限制。
**意图：**此警报有助于监控 EKS 集群中容器组（pod）的内存利用率，这样系统性能就不会降低。
**统计数据：**Maximum
**建议阈值：**80.0
**阈值理由：**建议将阈值设置为小于或等于 80%，以便有足够的时间在系统开始受到影响之前调试问题。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon EventBridge 调度器
**TargetErrorThrottledCount**
**维度：**None
**警报描述：**此警报有助于您识别目标节流的情况。为避免目标节流错误，请考虑[配置灵活的时间窗口](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule-flexible-time-windows.html)，以分散调用负载或提高目标服务的限制。
**用途：**此警报用于检测可能导致计划延迟的目标节流错误。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**如果目标节流错误的数量持续大于 0，则计划交付会延迟。对于某些系统，短时间内存在目标节流错误可能是正常，而对于另一些系统，这可能是问题隐患。相应地设置此警报的阈值、`datapointsToAlarm` 和 `evaluationPeriods`。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**InvocationThrottleCount**
**维度：**None
**警报描述：**此警报有助于您识别 Amazon EventBridge 调度器 的调用节流的情况。为避免调用节流错误，请考虑[配置灵活的时间窗口](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule-flexible-time-windows.html)，以分散调用负载或[提高调用节流限制](https://docs.aws.amazon.com/scheduler/latest/UserGuide/scheduler-quotas.html)。
**用途：**此警报用于检测可能导致计划延迟的 Amazon EventBridge 调度器 调用节流错误。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**如果调用节流的数量持续大于 0，则计划交付会延迟。对于某些系统，短时间内存在调用节流错误可能是正常，而对于另一些系统，这可能是问题隐患。相应地设置此警报的阈值、`datapointsToAlarm` 和 `evaluationPeriods`。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**InvocationDroppedCount**
**维度：**None
**警报描述：**此警报有助于您识别 Amazon EventBridge 调度器 丢弃的调用。考虑通过为计划[配置 DLQ](https://docs.aws.amazon.com/scheduler/latest/UserGuide/configuring-schedule-dlq.html) 来进行调查。
**用途：**此警报用于检测 Amazon EventBridge 调度器 丢弃的调用。如果您已在所有计划中正确配置了 DLQ，则丢弃的调用将出现在 DLQ 中，您可以跳过此警报的设置。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**将阈值设置为 0，以检测丢弃的调用。
**时间段：**60
**要发出警报的数据点数**：1
**评估期：**1
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**InvocationsFailedToBeSentToDeadLetterCount**
**维度：**None
**警报描述：**此警报有助于您识别 Amazon EventBridge 调度器 未能发送到配置后的 DLQ 的调用。如果该指标持续大于 0，请修改 DLQ 配置以解决问题。使用 `InvocationsFailedToBeSentToDeadLetterCount`\$1metrics 来确定问题。
**用途：**此警报用于检测 Amazon EventBridge 调度器 未能发送到配置后的 DLQ 的调用。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**将阈值设置为 0，以检测任何未能发送到配置后的 DLQ 的调用。此指标中还会显示可重试错误，因此此警报的 `datapointsToAlarm` 已设置为 15。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon Kinesis Data Streams
**GetRecords.IteratorAgeMilliseconds**
**维度**：StreamName
**警报描述：**此警报可以检测迭代器的最大寿命是否过高。对于实时数据处理应用程序，可以根据延迟容差配置数据留存。这通常只需几分钟就能完成。对于处理历史数据的应用程序，可以使用此指标来监控追赶速度。阻止数据丢失的快速解决方案是在排查问题时延长保留期。您还可以增加在消费端应用程序中处理记录的工作程序数量。逐渐增长迭代器寿命最常见的原因是没有足够的物理资源，或者记录处理逻辑没有随着流吞吐量的增大而相应扩展。有关更多详细信息，请参阅[链接](https://repost.aws/knowledge-center/kinesis-data-streams-iteratorage-metric)。
**意图：**此警报用于检测流中的数据是否会因为保存时间过长或记录处理速度太慢而过期。它可以帮助您在达到 100% 的流保留时间后避免数据丢失。
**统计数据：**Maximum
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于流的保留期以及记录的处理延迟容差。查看您的需求并分析历史趋势，然后将阈值设置为表示临界处理延迟的毫秒数。如果迭代器的寿命超过了保留期的 50%（默认值为 24 小时，可配置为最高 365 天），则存在由于记录过期造成数据丢失的风险。您可以监控该指标，确保您的任何分片都不会达到此限制。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**GetRecords.Success**
**维度**：StreamName
**警报描述：**每当您的消费端成功从您的流中读取数据时，此指标就会增加。当它引发异常时，`GetRecords` 不会返回任何数据。最常见的例外情况是 `ProvisionedThroughputExceededException`，由于流的请求速率太高，或者因为给定秒钟的可用吞吐量已经得到满足。降低请求的频率或大小。有关更多信息，请参阅《Amazon Kinesis Data Streams 开发人员指南》中的 [Streams Limits](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) 和 [Error Retries and Exponential Backoff in AWS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)。
**意图：**此警报可以检测消费端从流中检索记录是否失败。通过为此指标设置警报，您可以主动检测数据消耗方面的任何问题，例如错误率增加或检索成功率下降。这让您可以及时执行操作来解决潜在问题，并保持数据处理管道的顺畅运行。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**根据从流中检索记录的重要性，基于应用程序对失败记录的容忍度来设置阈值。阈值应为成功操作的相应百分比。您可以使用历史 GetRecords 指标数据作为可接受失败率的参考。设置阈值时还应考虑重试，因为可以重试失败记录。这有助于防止暂时性峰值触发不必要的提醒。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**PutRecord.Success**
**维度**：StreamName
**警报描述：**此警报会检测失败的 `PutRecord` 操作的数量何时超过阈值。调查数据生成器日志，弄清楚失败的根本原因。最常见的原因是导致 `ProvisionedThroughputExceededException` 的分片的预置吞吐量不足。之所以发生这种情况，是因为流的请求速率太高，或者尝试摄取到分片中的吞吐量太高。降低请求的频率或大小。有关更多信息，请参阅 [Streams Limits](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) 和 [Error Retries and Exponential Backoff in AWS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)。
**意图：**此警报可以检测向流中摄取记录是否失败。它有助于您识别向流写入数据时存在的问题。通过为此指标设置警报，您可以主动检测生成器在向流发布数据时存在的任何问题，例如错误率增加或成功发布的记录减少。这让您可以及时执行操作来解决潜在问题，并保持数据摄取过程的可靠运行。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**根据对服务进行数据摄取和处理的重要性，基于应用程序对失败记录的容忍度来设置阈值。阈值应为成功操作的相应百分比。您可以使用历史 PutRecord 指标数据作为可接受失败率的参考。设置阈值时还应考虑重试，因为可以重试失败记录。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**PutRecords.FailedRecords**
**维度**：StreamName
**警报描述：**此警报会检测失败的 `PutRecords` 的数量何时超过阈值。Kinesis Data Streams 会尝试处理每个 `PutRecords` 请求中的所有记录，但是单个记录失败并不会停止对后续记录的处理。这些失败的主要原因是超过了流或单个分片的吞吐量。常见的原因是流量激增和网络延迟，这会导致记录不均匀地到达流。您必须检测处理不成功的记录并在后续调用中重试它们。有关更多详细信息，请参阅 [Handling Failures When Using PutRecords](https://docs.aws.amazon.com/streams/latest/dev/developing-producers-with-sdk.html)。
**意图：**当使用批处理操作将记录放入流时，此警报可以检测持续失败。通过为此指标设置警报，您可以主动检测失败记录的增加，从而能够及时执行操作来解决潜在问题，并确保数据摄取过程顺畅可靠。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**将阈值设置为失败记录数，以反映应用程序对失败记录的容忍度。您可以使用历史数据作为可接受失败值的参考。设置阈值时还应考虑重试，因为可以在后续 PutRecords 调用中重试失败记录。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ReadProvisionedThroughputExceeded**
**维度**：StreamName
**警报描述：**此警报会跟踪导致读取吞吐能力限制的记录数。如果您发现自己持续受到限制，则应考虑向流中添加更多分片以增加预置读取吞吐量。如果有多个消费端应用程序在流中运行，并且它们共享 `GetRecords` 限制，我们建议您通过增强型扇出功能注册新的消费端应用程序。如果添加更多分片不会降低限制的数量，则可能有一个“热”分片被读取的次数超过了其他分片。启用增强监控，确定“热”分片，然后将其拆分。
**意图：**此警报可以检测消费端在超过预置的读取吞吐量（由您拥有的分片数量决定）时是否受到限制。在这种情况下，您将无法从流中读取内容，并且流可以开始备份。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**通常可以重试受限请求，因此将阈值设置为 0 会使警报过于敏感。但是，持续的限制可能会影响从流中进行读取，因此应该会触发警报。根据应用程序的限制请求和重试配置，将阈值设置为百分比。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**SubscribeToShardEvent.MillisBehindLatest**
**维度：**StreamName、ConsumerName
**警报描述：**此警报会检测应用程序中的记录处理延迟何时超过阈值。诸如对下游应用程序的 API 操作失败之类的暂时性问题可能会导致指标突然增加。您应该调查它们是否持续发生。一个常见的原因是，由于物理资源不足，或者记录处理逻辑没有随着流吞吐量的增加而扩展，导致消费端处理记录的速度不够快。在关键路径中阻止调用通常是导致记录处理速度减慢的原因。您可以通过增加分片的数量来提高并行度。您还应确认底层处理节点在需求高峰期间有足够的物理资源。
**意图：**此警报可以检测流分片事件订阅的延迟。这表明存在处理延迟，可以帮助识别消费端应用程序性能或流的整体运行状况的潜在问题。当处理延迟变得严重时，您应该调查并解决任何瓶颈或消费端应用程序效率低下的问题，以确保实时数据处理并最大限度地减少数据积压。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于您的应用程序可以容忍的延迟。查看应用程序的要求并分析历史趋势，然后相应地选择阈值。当 SubscribeToShard 调用成功后，您的消费端将开始通过持续连接接收 SubscribeToShardEvent 事件，最长可持续 5 分钟，之后如果您想继续接收记录，需要再次调用 SubscribetoShard 来续订订阅。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**WriteProvisionedThroughputExceeded**
**维度**：StreamName
**警报描述：**此警报会检测导致写入吞吐能力限制的记录数何时达到阈值。当您的生成器超过预置写入吞吐量（由您拥有的分片数量决定）时，它们就会受到限制，您将无法将记录放入流中。为了解决持续限制的问题，您应该考虑向流中添加分片。这会提高您的预置写入吞吐量并防止未来发生限制。在摄取记录时，还应考虑分区键的选择。首选随机分区键，因为它会尽可能将记录均匀地分布在流的分片上。
**意图：**此警报可以检测您的生成器是否因为流或分片的限制而在写入记录时被拒。如果您的数据流处于预置模式，则设置此警报有助于您在数据流达到限制时主动执行操作，让您可以优化预置容量或执行相应扩展操作，以免数据丢失并保持数据处理的顺畅运行。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**通常可以重试受限请求，因此将阈值设置为 0 会使警报过于敏感。但是，持续的限制可能会影响写入流的操作，因此您应该设置警报阈值来检测此类限制。根据应用程序的限制请求和重试配置，将阈值设置为百分比。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Lambda
**ClaimedAccountConcurrency**
**维度：**None
**警报描述：**此警报有助于监控 Lambda 函数的并发是否接近账户的区域级并发限制。如果函数达到并发限制，它就会开始受到限制。您可以执行下列操作来避免限制。
1. 在此区域[请求增加并发](https://repost.aws/knowledge-center/lambda-concurrency-limit-increase)。
1. 识别并减少任何未使用的预留并发或预配置的并发。
1. 确定函数中的性能问题，以提高处理速度，从而提高吞吐量。
1. 增加函数的批处理大小，以便每次函数调用都能处理更多消息。
**意图：**此警报可以主动检测 Lambda 函数的并发是否接近账户的区域级并发限额，以便您可以视情况采取行动。如果 `ClaimedAccountConcurrency` 达到账户的区域级并发限额，则该函数将受到节流。如果您使用的是预留并发（RC）或预调配并发 （PC），则与 `ConcurrentExecutions` 上的警报相比，此警报可让您更清楚地了解并发利用率。
**统计数据：**Maximum
**建议阈值：**取决于您的情况
**阈值理由：**您应该计算账户在该地区设置的并发配额大约 90% 的值，并将结果用作阈值。默认情况下，您的账户针对区域内所有函数的并发限额为 1000。但是，您应该从“服务配额”控制面板中查看账户的配额。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**错误**
**维度：**FunctionName
**警报描述：**此警报会检测高错误计数。错误包括代码引发的异常和 Lambda 运行时系统引发的异常。您可以检查与函数相关的日志来诊断问题。
**意图：**此警报有助于检测函数调用中的高错误计数。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**将阈值设置为大于 0 的数字。确切的值可取决于对您应用程序中的错误的容忍度。了解函数正在处理之调用的临界程度。对于某些应用程序，任何错误都可能是不可接受的，而某些应用程序可能允许一定的错误幅度。
**时间段：**60
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**限制**
**维度：**FunctionName
**警报描述：**此警报会检测大量受限调用请求。限制在无并发可用于纵向扩展时发生。有多种方法可解决此问题。1) 向此区域的 AWS Support 请求增加并发。2) 确定函数中的性能问题，以提高处理速度，从而提高吞吐量。3) 增加函数的批处理大小，以便每次函数调用都能处理更多消息。
**意图：**此警报有助于检测针对 Lambda 函数的大量受限调用请求。请务必了解请求是否由于限制而持续被拒，以及您是否需要提高 Lambda 函数性能或并发能力以避免持续的限制。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**将阈值设置为大于 0 的数字。阈值的确切值可取决于应用程序的容忍度。根据函数的使用和扩展要求设置阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Duration**
**维度：**FunctionName
**警报描述：**此警报会检测 Lambda 函数处理事件的长持续时间。持续时间长可能是因为函数代码的变化使函数的执行时间更长，或者函数的依赖项需要更长的时间。
**意图：**此警报可以检测 Lambda 函数的长运行持续时间。运行时系统持续时间长表示函数的调用时间较长，如果 Lambda 处理的事件数量更多，还会影响调用的并发能力。请务必了解 Lambda 函数的执行时间是否持续比预期的要长。
**统计数据：**p90
**建议阈值：**取决于您的情况
**阈值理由：**持续时间阈值取决于您的应用程序和工作负载以及您的性能要求。对于高性能要求，可以将阈值设置为更短的时间，以查看函数是否符合预期。您还可以分析持续时间指标的历史数据，查看所花费的时间是否与函数的预期性能相符，然后将阈值设置为比历史平均值更长的时间。确保将阈值设置为低于配置的函数超时。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ConcurrentExecutions**
**维度：**FunctionName
**警报描述：**此警报有助于监控函数的并发是否接近账户的区域级并发限制。如果函数达到并发限制，它就会开始受到限制。您可以执行下列操作来避免限制。
1. 在此区域请求增加并发。
1. 确定函数中的性能问题，以提高处理速度，从而提高吞吐量。
1. 增加函数的批处理大小，以便每次函数调用都能处理更多消息。
为了更好地了解预留并发和预调配的并发利用率，请改为对新指标 `ClaimedAccountConcurrency` 设置警报。
**意图：**此警报可以主动检测函数的并发是否接近账户的区域级并发限额，以便您可以视情况采取行动。如果函数达到账户的区域级并发限额，则该函数将受到限制。
**统计数据：**Maximum
**建议阈值：**取决于您的情况
**阈值理由：**将阈值设置成为区域中账户设置的并发限额的 90% 左右。默认情况下，您的账户针对区域内所有函数的并发限额为 1000。不过，您可以查看账户的限额，因为可以联系 AWS Support 来增加限额。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Lambda Insights
我们建议为以下 Lambda Insights 指标设置最佳实践警报。
**memory\$1utilization**
**维度：**function\$1name
**警报描述：**此警报用于检测 Lambda 函数的内存利用率是否接近配置的限制。要排查问题，您可以尝试 1) 优化您的代码。2) 通过准确估算内存需求来正确调整内存分配的大小。您可以参考 [Lambda Power Tuning](https://docs.aws.amazon.com/lambda/latest/operatorguide/profile-functions.html) 了解相同内容。3) 使用连接池。有关 RDS 数据库的连接池的信息，请参阅 [Using Amazon RDS Proxy with Lambda](https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/)。4) 您也可以考虑设计函数，以免两次调用之间在内存中存储大量数据。
**意图：**此警报用于检测 Lambda 函数的内存利用率是否接近配置的限制。
**统计数据：**平均值
**阈值建议：**90.0
**阈值理由：**将阈值设置为 90%，以便在内存利用率超过分配内存的 90% 时收到提醒。如果您担心工作负载的内存利用率，则可以将此阈值调整为较低的值。您也可以查看此指标的历史数据并相应地设置阈值。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon VPC (`AWS/NATGateway`)
**ErrorPortAllocation**
**维度：**NatGatewayId
**警报描述：**此警报有助于检测 NAT 网关何时无法为新连接分配端口。要解决此问题，请参阅[解决 NAT 网关上的端口分配错误](https://repost.aws/knowledge-center/vpc-resolve-port-allocation-errors)。
**意图：**此警报用于检测 NAT 网关是否无法分配源端口。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**如果 ErrorPortAllocation 的值大于 0，则意味着通过 NatGateway 打开了太多与单个热门目标的并发连接。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**PacketsDropCount**
**维度：**NatGatewayId
**警报描述：**此警报有助于检测 NAT 网关何时丢弃数据包。这可能是因为 NAT 网关存在问题，因此请检查 [AWS 服务运行状况控制面板](https://health.aws.amazon.com/health/status)，了解区域中的 AWS NAT 网关的状态。这可以帮助您弄清楚与使用 NAT 网关的流量相关的网络问题。
**意图：**此警报用于检测 NAT 网关是否正丢弃数据包。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**您应计算 NAT 网关上总流量 0.01% 的值，并将该结果用作阈值。使用 NAT 网关上流量的历史数据来确定阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## AWS 私有链接 (`AWS/PrivateLinkEndpoints`)
**PacketsDropped**
**维度：**VPC Id、VPC Endpoint Id、Endpoint Type、Subnet Id、Service Name
**警报描述：**此警报通过监控端点丢弃的数据包数量，帮助检测端点或端点服务是否运行状况不佳。请注意，到达 VPC 端点的大小超过 8500 字节的数据包将被丢弃。要进行问题排查，请参阅[接口 VPC 端点和端点服务之间的连接问题](https://repost.aws/knowledge-center/connect-endpoint-service-vpc)。
**意图：**此警报用于检测端点或端点服务是否运行状况不佳。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**根据用例设置阈值。如果您想了解端点或端点服务的运行状况不佳状态，应将阈值设置得较低，以便有机会在出现大量数据丢失之前修复问题。您可以使用历史数据来了解对丢弃数据包的容忍度，并相应地设置阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## AWS 私有链接 (`AWS/PrivateLinkServices`)
**RstPacketsSent**
**维度：**Service Id、Load Balancer Arn、Az
**警报描述：**此警报有助于您根据发送到端点之重置数据包的数量来检测端点服务的运行状况不佳目标。当您使用服务的消费端调试连接错误时，可以验证服务是否正在使用 rstPacketsSent 指标重置连接，或者网络路径上是否有其他操作会失败。
**意图：**此警报用于检测端点服务运行状况不佳的目标。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**该阈值取决于用例。如果您的用例可以容忍运行状况不佳目标，则可以将阈值设置得较高。如果用例无法容忍运行状况不佳目标，则可以将阈值设置得非常低。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## `Amazon RDS`
**CPU 利用率**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控 CPU 利用率持续较高的情况。CPU 利用率衡量非空闲时间。考虑使用[增强监控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.Enabling.html)或 [Performance Insights](https://aws.amazon.com/rds/performance-insights/) 来查看对于 MariaDB、MySQL、Oracle 和 PostgreSQL，哪些[等待时间](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring-Available-OS-Metrics.html)消耗的 CPU 时间最多（`guest`、`irq`、`wait`、`nice` 等）。然后评估哪些查询消耗的 CPU 量最高。如果您无法调整工作负载，可以考虑改用更大的数据库实例类。
**意图：**此警报用于检测 CPU 利用率持续较高的情况，以防响应时间过长和超时。如果要检查 CPU 利用率的微爆，可以设置较短的警报评估时间。
**统计数据：**平均值
**建议阈值：**90.0
**阈值调整：**CPU 消耗的随机峰值可能不会影响数据库性能，但是 CPU 利用率持续较高可能会阻碍即将到来的数据库请求。根据数据库的总体工作负载，您的 RDS/Aurora 实例的 CPU 利用率较高可能会降低整体性能。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**DatabaseConnections**
**维度：**DBInstanceIdentifier
**警报描述：**此警报可以检测大量连接。检查现有连接并终止任何处于“休眠”状态或未正确关闭的连接。考虑使用连接池来限制新连接的数量。或者，增加数据库实例大小以使用具有更多内存的类，由此增加“max\$1connections”的默认值，或者如果当前类可以支持您的工作负载，则增加 [RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html)、Aurora [MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Performance.html) 和 [PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Managing.html) 中的“max\$1connections”值。
**意图：**当达到最大数据库连接数时，此警报用于帮助防止连接被拒绝。如果您经常更改数据库实例类，则不建议使用此警报，因为这样做会更改内存和默认的最大连接数。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值调整：**允许的连接数取决于数据库实例类的大小以及与进程/连接相关的数据库引擎特定参数。您应计算一个介于数据库最大连接数的 90-95% 之间的值，并将该结果用作阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**EBSByteBalance%**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控剩余吞吐量积分的低百分比。要进行问题排查，请查看 [RDS 中的延迟问题](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck)。
**意图：**此警报用于检测突增存储桶中剩余的低百分比吞吐量积分。低字节余额百分比可能会导致吞吐量瓶颈问题。不建议对 Aurora PostgreSQL 实例使用此警报。
**统计数据：**平均值
**建议阈值：**10.0
**阈值调整：**吞吐量积分余额低于 10% 被视为较差，您应相应地设置阈值。如果您的应用程序可以容忍较低的工作负载吞吐量，也可以设置较低的阈值。
**时间段：**60
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**EBSIOBalance%**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控剩余的 IOPS 积分的低百分比。要进行问题排查，请参阅 [RDS 中的延迟问题](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck)。
**意图：**此警报用于检测突增存储桶中剩余的低百分比 I/O 积分。低 IOPS 余额百分比可能会导致 IOPS 瓶颈问题。建议不要对 Aurora 实例使用此警报。
**统计数据：**平均值
**建议阈值：**10.0
**阈值调整：**IOPS 积分余额低于 10% 被视为较差，您可以相应地设置阈值。如果您的应用程序可以容忍较低的工作负载 IOPS，也可以设置较低的阈值。
**时间段：**60
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**FreeableMemory**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控可用内存不足的情况，这可能意味着数据库连接出现峰值或您的实例可能承受较高的内存压力。除了 `FreeableMemory` 之外，还可以通过监控 `SwapUsage` 的 CloudWatch 指标来检查内存压力。如果实例内存消耗频繁过高，这表示您应检查您的工作负载或升级您的实例类。对于 Aurora 读取器数据库实例，请考虑向集群添加额外的读取器数据库实例。有关 Aurora 问题排查的更多信息，请参阅[可用内存问题](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#Troubleshooting.FreeableMemory)。
**意图：**此警报有利于防止内存不足的问题，此问题会导致连接被拒绝。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值调整：**根据工作负载和实例类，可能适合使用不同的阈值。理想情况下，可用内存不应长时间低于总内存的 25%。对于 Aurora，您可以将阈值设置为接近 5%，因为指标接近 0 意味着数据库实例已经尽可能地扩展。您可以分析该指标的历史行为以确定合理的阈值级别。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**FreeLocalStorage**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控本地可用存储空间不足的问题。Aurora PostgreSQL 兼容版使用本地存储空间来存储错误日志和临时文件。Aurora MySQL 使用本地存储来存储错误日志、一般日志、慢速查询日志、审核日志和非 InnoDB 临时表。这些本地存储卷由 Amazon EBS Store 提供支持，并可以通过使用更大的数据库实例类来进行扩展。要进行问题排查，请查看 Aurora [PostgreSQL 兼容版](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue)和 [MySQL 兼容版](https://repost.aws/knowledge-center/aurora-mysql-local-storage)。
**意图：**此警报用于检测如果您未使用 Aurora Serverless v2 或更高版本，Aurora 数据库实例与本地存储空间限制之间的差距。当您在本地存储空间中存储非永久性数据（例如临时表和日志文件）时，本地存储空间可能会达到容量上限。此警报可以防止在数据库实例用尽本地存储空间时，发生空间不足的错误。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值调整：**您应根据卷的使用速度和趋势计算可用存储量的约 10%-20%，然后使用该结果作为阈值，在卷达到限制之前主动采取行动。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**FreeStorageSpace**
**维度：**DBInstanceIdentifier
**警报描述：**此警报可以监控可用存储空间不足的问题。如果您经常接近存储空间容量限制，请考虑纵向扩展数据库存储。包含一些缓冲区，以适应不可预见的应用程序需求增加。或者，可以考虑启用 RDS 存储空间自动扩缩。此外，可以考虑通过删除未使用或过时的数据和日志来释放更多空间。有关更多信息，请查看 [RDS 用尽存储空间文档](https://repost.aws/knowledge-center/rds-out-of-storage)和 [PostgreSQL 存储空间问题文档](https://repost.aws/knowledge-center/diskfull-error-rds-postgresql)。
**意图：**此警报有助于防止存储空间已满的问题。这可以防止数据库实例用尽存储空间时出现停机。如果您启用了存储空间自动扩缩，或者您经常更改数据库实例的存储容量，我们不建议使用此警报。
**统计数据：**Minimum
**建议阈值：**取决于您的情况
**阈值调整：**阈值将取决于当前分配的存储空间。通常，您应计算已分配存储空间的 10% 的值，并将该结果用作阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**MaximumUsedTransactionIDs**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于防止 PostgreSQL 的事务 ID 重叠。请参阅[此博客](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/)中的问题排查步骤来调查和解决问题。您也可以参考[此博客](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/)，进一步熟悉 autovacuum 的概念、常见问题和最佳实践。
**意图：**此警报用于帮助防止 PostgreSQL 的事务 ID 重叠。
**统计数据：**平均值
**建议阈值：**1.0E9
**阈值调整：**将此阈值设置为 10 亿应该可以让您有时间调查问题。默认的 autovacuum\$1freeze\$1max\$1age 值为 2 亿。如果最早的事务的期限为 10 亿，则 autovacuum 很难将该阈值保持在 2 亿个事务 ID 的目标以下。
**时间段：**60
**要发出警报的数据点数**：1
**评估期：**1
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ReadLatency**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控高读取延迟的情况。如果存储延迟很高，那是因为工作负载超过了资源限制。您可以查看相对于实例和分配的存储配置的 I/O 利用率。请参阅[排查由 IOPS 瓶颈导致的 Amazon EBS 卷延迟问题](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck)。对于 Aurora，您可以切换到具有 [I/O 优化存储配置](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html)的实例类。有关指导，请参阅 [Planning I/O in Aurora](https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/)。
**意图：**此警报用于检测高读取延迟。数据库磁盘的读取/写入延迟通常较低，但可能存在导致高延迟操作的问题。
**统计数据：**p90
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于您的用例。读取延迟高于 20 毫秒时通常都需要调查。如果您的应用程序可能具有更高的读取操作延迟，则也可以设置更高的阈值。查看读取延迟的严重性和要求，并分析此指标的历史行为以确定合理的阈值级别。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**ReplicaLag**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于您了解副本落后于主实例的秒数。如果源数据库实例上未发生任何用户事务，则 PostgreSQL 只读副本将在最迟 5 分钟后报告复制滞后。当 ReplicaLag 指标达到 0 时，即表示副本已赶上主数据库实例进度。如果 ReplicaLag 指标返回 –1，则当前未激活复制。有关与 RDS PostgreSQL 相关的指导，请参阅[复制最佳实践](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/)；有关 `ReplicaLag` 和相关错误的问题排查，请参阅 [ReplicaLag 问题排查](https://repost.aws/knowledge-center/rds-postgresql-replication-lag)。
**意图：**此警报可以检测副本延迟，这反映了主实例出现故障时可能发生的数据丢失。如果副本落后于主实例太远而主实例出现故障，则副本将丢失主实例中的数据。
**统计数据：**Maximum
**建议阈值：**60.0
**阈值调整：**通常，可接受的延迟取决于应用程序。我们建议不要超过 60 秒。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**WriteLatency**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控高写入延迟。如果存储延迟很高，那是因为工作负载超过了资源限制。您可以查看相对于实例和分配的存储配置的 I/O 利用率。请参阅[排查由 IOPS 瓶颈导致的 Amazon EBS 卷延迟问题](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck)。对于 Aurora，您可以切换到具有 [I/O 优化存储配置](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html)的实例类。有关指导，请参阅 [Planning I/O in Aurora](https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/)。
**意图：**此警报用于检测高写入延迟。尽管数据库磁盘通常具有较低的读取/写入延迟，但可能会遇到导致高延迟操作的问题。对此进行监控可以确保磁盘延迟与预期一样低。
**统计数据：**p90
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于您的用例。写入延迟高于 20 毫秒时通常都需要调查。如果您的应用程序可能具有更高的写入操作延迟，则也可以设置更高的阈值。查看写入延迟的严重性和要求，并分析此指标的历史行为以确定合理的阈值级别。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**DBLoad**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控高数据库负载。如果进程数超过 vCPU 的数量，则进程开始排队。当队列增加时，性能会受到影响。如果数据库负载经常高于最大 vCPU 并且主要等待状态为 CPU，则表示 CPU 过载。在这种情况下，您可以在“Performance Insights/增强监控”中监控 `CPUUtilization`、`DBLoadCPU` 和排队的任务。您可能需要限制与实例的连接数，优化具有高 CPU 负载的任何 SQL 查询，或考虑使用更大的实例类。如果始终有大量实例处于任何等待状态，则表示可能存在要解决的瓶颈或资源争用问题。
**意图：**此警报用于检测高数据库负载的情况。高数据库负载可能会导致数据库实例出现性能问题。此警报不适用于无服务器数据库实例。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值调整：**最大 vCPU 值由数据库实例的 vCPU（虚拟 CPU）内核数决定。根据最大 vCPU 的不同，可能适合使用不同的阈值。理想情况下，数据库负载不应超过 vCPU 线。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**AuroraVolumeBytesLeftTotal**
**维度：**DBClusterIdentifier
**警报描述：**此警报有助于监控卷剩余总量过低的情况。当卷剩余总量达到大小限制时，集群会报告空间不足错误。Aurora 存储空间会根据集群卷中的数据自动扩展，并根据[数据库引擎版本](https://repost.aws/knowledge-center/aurora-version-number)扩展至 128 TiB 或 64 TiB。考虑通过删除不再需要的表和数据库来减少存储空间。有关更多信息，请参阅[存储空间扩展](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html)。
**意图：**此警报用于检测 Aurora 集群与卷大小限制的差距。此警报可以防止在集群用尽空间时，发生空间不足的错误。此警报仅推荐用于 Aurora MySQL。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值调整：**您应根据卷使用量增加的速度和趋势计算实际大小限制的 10%-20%，然后使用该结果作为阈值，在卷达到限制之前主动采取行动。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**AuroraBinlogReplicaLag**
**维度：**DBClusterIdentifier、Role=WRITER
**警报描述：**此警报有助于监控 Aurora 写入器实例复制的错误状态。有关更多信息，请参阅[跨AWS区域复制 Aurora MySQL 数据库集群](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html)。有关问题排查，请参阅 [Aurora MySQL 复制问题](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.MySQL)。
**意图：**此警报用于检测写入器实例是否处于错误状态并且无法复制源。此警报仅推荐用于 Aurora MySQL。
**统计数据：**平均值
**建议阈值：**–1.0
**阈值调整：**我们建议您使用 -1 作为阈值，因为如果副本处于错误状态，Aurora MySQL 会发布此值。
**时间段：**60
**要发出警报的数据点数**：2
**评估期：**2
**比较运算符：**LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**BlockedTransactions**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控 Aurora 数据库实例中被阻止事务数量高的情况。被阻止的事务最后可以回滚或提交。高并发度、事务空闲或事务长时间运行都可能导致事务被阻止。有关问题排查，请参阅 [Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/ams-waits.row-lock-wait.html) 文档。
**意图：**此警报用于检测 Aurora 数据库实例中被阻止事务数量高的情况，以防止事务回滚和性能下降。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值调整：**您应使用 `ActiveTransactions` 指标计算实例所有事务的 5%，并将该结果用作阈值。您还可以查看被阻止事务的严重性和要求，并分析此指标的历史行为以确定合理的阈值级别。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**BufferCacheHitRatio**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于您监控 Aurora 集群缓存命中率持续较低的情况。低命中率表示您对这个数据库实例的查询经常转向磁盘。有关问题排查，请调查您的工作负载以查看哪些查询导致了此行为，并参阅[数据库实例 RAM 建议](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.BestPractices.html#Aurora.BestPractices.Performance.Sizing)文档。
**意图：**此警报用于检测缓存命中率持续较低的情况，以防 Aurora 实例的性能持续下降。
**统计数据：**平均值
**建议阈值：**80.0
**阈值调整：**您可以将缓冲区缓存命中率的阈值设置为 80%。但是，您可以根据可接受性能级别和工作负载特征来调整此值。
**时间段：**60
**要发出警报的数据点数**：10
**评估期：**10
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**EngineUptime**
**维度：**DBClusterIdentifier、Role=WRITER
**警报描述：**此警报有助于监控写入器数据库实例停机时间较少的情况。由于重启、维护、升级或失效转移，写入器数据库实例可能会停机。当正常运行时间因集群中的失效转移而达到 0，并且集群具有一个或多个 Aurora 副本时，Aurora 副本会在故障事件期间提升至主写入器实例。要提高数据库集群的可用性，请考虑在两个或更多不同可用区中创建一个或多个 Aurora 副本。有关更多信息，请查看[影响 Aurora 停机时间的因素](https://repost.aws/knowledge-center/aurora-mysql-downtime-factors)。
**意图：**此警报用于检测 Aurora 写入器数据库实例是否处于停机状态。这可以防止由于崩溃或失效转移而导致在写入器实例中出现长时间运行的故障。
**统计数据：**平均值
**建议阈值：**0.0
**阈值调整：**故障事件将导致短暂中断，其间的读取和写入操作将失败并引发异常。不过，服务通常会在 60 秒内（经常在 30 秒内）还原。
**时间段：**60
**要发出警报的数据点数**：2
**评估期：**2
**比较运算符：**LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**RollbackSegmentHistoryListLength**
**维度：**DBInstanceIdentifier
**警报描述：**此警报有助于监控 Aurora 实例回滚分段历史记录长度持续较长。InnoDB 历史记录列表长度较长则表明大量的旧行版本、查询和数据库关闭已经变慢。有关更多信息和问题排查，请参阅 [InnoDB 历史记录列表长度显著增加](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/proactive-insights.history-list.html)文档。
**意图：**此警报用于检测回滚段历史记录长度持续较长。这有助于您防止 Aurora 实例的持续性能下降和 CPU 利用率过高。此警报仅推荐用于 Aurora MySQL。
**统计数据：**平均值
**建议阈值：**1000000.0
**阈值调整：**将此阈值设置为 100 万可让您有充足的时间调查问题。但是，您可以根据可接受性能级别和工作负载特征来调整此值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**StorageNetworkThroughput**
**维度：**DBClusterIdentifier、Role=WRITER
**警报描述：**此警报有助于监控存储网络吞吐量较高的情况。如果存储网络吞吐量超过 [EC2 实例](https://aws.amazon.com/ec2/instance-types/)的总网络带宽，则可能导致读取和写入延迟较高，从而导致性能下降。您可以从 AWS 控制台查看您的 EC2 实例类型。有关问题排查，请检查写入/读取延迟的任何变化，并评估您是否也针对此指标发出了警报。如果是这样的话，请评估警报触发期间的工作负载模式。这有助于您确定是否可以优化工作负载以减少总网络流量。如果无法优化，您可能需要考虑扩展实例。
**意图：**此警报用于检测存储网络吞吐量较高的情况。检测高吞吐量可以防止网络数据包丢失和性能下降。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值调整：**您应计算出 EC2 实例类型总网络带宽的约 80%-90%，然后使用该结果作为阈值，以便在网络数据包受到影响之前主动采取行动。您还可以查看存储网络吞吐量的严重性和要求，并分析此指标的历史行为以确定合理的阈值级别。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## `Amazon Route 53 Public Data Plane`
**HealthCheckStatus**
**维度：**HealthCheckId
**警报描述：**此警报有助于根据运行状况检查程序检测运行状况不佳的端点。要了解导致运行状况不佳状态的失败的原因，请使用 Route 53 运行状况检查控制台中的“运行状况检查程序”选项卡，查看每个区域的状态以及上次运行状况检查的失败情况。“状态”选项卡还显示端点被报告为运行状况不佳的原因。请参阅[问题排查步骤](https://repost.aws/knowledge-center/route-53-fix-unhealthy-health-checks)。
**意图：**此警报使用 Route53 运行状况检查程序来检测运状况不佳的端点。
**统计数据：**平均值
**建议阈值：**1.0
**阈值理由：**当端点运行正常时，其状态报告为 1。所有小于 1 的情况都表示运行状况不佳。
**时间段：**60
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**LESS\$1THAN\$1THRESHOLD
## `Amazon S3`
**4xxErrors**
**维度：**BucketName、FilterId
**警报描述：**此警报可帮助我们报告为响应客户端请求而发出的 4xx 错误状态代码的总数。例如，403 错误代码可能表示 IAM 策略不正确，404 错误代码可能表示客户端应用程序操作不当。临时[启用 S3 服务器访问日志记录](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html)将帮助您使用 HTTP 状态和错误代码字段查明问题的根源。要了解有关错误代码的更多信息，请参阅 [Error Responses](https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html)。
**意图：**此告警可用于为典型的 4xx 错误率创建基准，以便您可以调查可能表明存在设置问题的任何异常。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**建议阈值旨在检测是否总请求数中超过 5% 的请求会收到 4XX 错误。应针对频繁发生的 4XX 错误设置告警。但是，将阈值设置得非常低可能会导致告警过于敏感。您还可以调整阈值以适应请求的负载，同时考虑可接受的 4XX 错误级别。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**5xxErrors**
**维度：**BucketName、FilterId
**警报描述：**此警报有助于您检测高客户端错误数。此类错误表明客户端发出了服务器无法完成的请求。这可以帮助您弄清楚您的应用程序因为 S3 而面临的问题。有关帮助您高效处理或减少错误的更多信息，请参阅[优化性能设计模式](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html#optimizing-performance-timeouts-retries)。错误也可能是由 S3 的问题所致，请查看 [AWS 服务运行状况控制面板](https://health.aws.amazon.com/health/status)，了解区域中的 Amazon S3 的状态。
**意图：**此警报有助于检测应用程序是否因 5xx 错误而遇到问题。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**我们建议设置阈值，以检测是否总请求数中超过 5% 的请求会收到 5XX 错误。但是，您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**OperationsFailedReplication**
**维度：**SourceBucket、DestinationBucket、RuleId
**警报描述：**此警报有助于了解复制失败。此指标会跟踪使用 S3 CRR 或 S3 SRR 复制的新对象的状态，还会跟踪使用 S3 批量复制复制的现有对象。有关更多详细信息，请参阅[对复制进行问题排查](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-troubleshoot.html)。
**意图：**此警报用于检测是否存在失败的复制操作。
**统计数据：**Maximum
**建议阈值：**0.0
**阈值理由：**对于成功的操作，此指标会发出值 0；当一分钟内没有执行任何复制操作时，此指标不发出任何值。当指标发出的值大于 0 时，复制操作将失败。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## `S3ObjectLambda`
**4xxErrors**
**维度：**AccessPointName、DataSourceARN
**警报描述：**此警报可帮助我们报告为响应客户端请求而发出的 4xx 错误状态代码的总数。临时[启用 S3 服务器访问日志记录](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html)将帮助您使用 HTTP 状态和错误代码字段查明问题的根源。
**意图：**此告警可用于为典型的 4xx 错误率创建基准，以便您可以调查可能表明存在设置问题的任何异常。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**我们建议设置阈值，以检测是否总请求数中超过 5% 的请求会收到 4xx 错误。应针对频繁发生的 4XX 错误设置告警。但是，将阈值设置得非常低可能会导致告警过于敏感。您还可以调整阈值以适应请求的负载，同时考虑可接受的 4XX 错误级别。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**5xxErrors**
**维度：**AccessPointName、DataSourceARN
**警报描述：**此警报有助于检测高客户端错误数。此类错误表明客户端发出了服务器无法完成的请求。此类错误也可能是由 S3 的问题所致，请查看 [AWS 服务运行状况控制面板](https://health.aws.amazon.com/health/status)，了解区域中的 Amazon S3 的状态。这可以帮助您弄清楚您的应用程序因为 S3 而面临的问题。有关帮助您高效处理或减少此类错误的信息，请参阅[优化性能设计模式](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html#optimizing-performance-timeouts-retries)。
**意图：**此警报有助于检测应用程序是否因 5xx 错误而遇到问题。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**我们建议设置阈值，以检测是否总请求数中超过 5% 的请求会收到 5XX 错误。但是，您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**LambdaResponse4xx**
**维度：**AccessPointName、DataSourceARN
**警报描述：**此警报有助于您检测和诊断 S3 对象 Lambda 调用中的失败（500 秒）。此类错误可能是由负责响应您请求的 Lambda 函数中的错误或配置错误所致。调查与对象 Lambda 接入点关联的 Lambda 函数的 CloudWatch 日志流，可以帮助您根据 S3 对象 Lambda 的响应查明问题的根源。
**意图：**此警报用于检测 WriteGetObjectResponse 调用的 4xx 客户端错误。
**统计数据：**平均值
**建议阈值：**0.05
**阈值理由：**我们建议设置阈值，以检测是否总请求数中超过 5% 的请求会收到 4xx 错误。应针对频繁发生的 4XX 错误设置告警。但是，将阈值设置得非常低可能会导致告警过于敏感。您还可以调整阈值以适应请求的负载，同时考虑可接受的 4XX 错误级别。您还可以分析历史数据以确定应用程序工作负载的可接受错误率，然后相应地调整阈值。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon SNS
**NumberOfMessagesPublished**
**维度：**TopicName
**警报描述：**此警报可以检测何时发布的 SNS 消息数量过低。要排查问题，请检查发布者发送的流量减少的原因。
**意图：**此警报有助于您主动监控和检测通知发布的显著下降。这可以帮助您识别应用程序或业务流程的潜在问题，以便您可以执行适当的操作来维护预期的通知流。如果您希望系统处理的流量最低，则应创建此警报。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**发布的消息数量应与应用程序的预期已发布消息数量一致。您还可以分析历史数据、趋势和流量，以确定合适的阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**NumberOfNotificationsDelivered**
**维度：**TopicName
**警报描述：**此警报可以检测何时传送的 SNS 消息数量过低。这可能是由于端点意外取消订阅或导致消息出现延迟的 SNS 事件所致。
**意图：**此警报有助于您检测传送的消息量的下降。如果您希望系统处理的流量最低，则应创建此警报。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**传送的消息数量应与预期生成的消息数量和消费端数量相符。您还可以分析历史数据、趋势和流量，以确定合适的阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**NumberOfNotificationsFailed**
**维度：**TopicName
**警报描述：**此警报可以检测何时传送失败的 SNS 消息数量过高。要排查失败通知的问题，请启用日志记录功能，并将日志记录到 CloudWatch Logs 中。检查日志可以帮助您确定面向哪些订阅用户的通知失败了，以及这些通知返回的状态码。
**意图：**此警报有助于您主动发现通知传送方面的问题，并执行适当的操作来解决这些问题。
**统计数据：**Sum
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于失败通知的影响。查看提供给最终用户的 SLA、通知的容错能力和临界程度，并分析历史数据，然后相应地选择阈值。对于只有 SQS、Lambda 或 Firehose 订阅的主题，失败的通知数量应为 0。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFilteredOut-InvalidAttributes**
**维度：**TopicName
**警报描述：**此警报有助于监控和解决发布者或订阅用户遇到的潜在问题。检查发布者是否在发布具有无效属性的消息，或者是否对订阅用户应用了不当筛选条件。您还可以分析 CloudWatch Logs，以帮助确定问题的根本原因。
**意图：**此警报用于检测已发布的消息是否无效，或者是否对订阅用户应用了不当筛选条件。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**无效属性几乎总是发布者出错导致的。我们建议将阈值设置为 0，因为在运行正常的系统中，预计不会出现无效属性。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFilteredOut-InvalidMessageBody**
**维度：**TopicName
**警报描述：**此警报有助于监控和解决发布者或订阅用户遇到的潜在问题。检查发布者是否在发布具有无效消息正文的消息，或者是否对订阅用户应用了不当筛选条件。您还可以分析 CloudWatch Logs，以帮助确定问题的根本原因。
**意图：**此警报用于检测已发布的消息是否无效，或者是否对订阅用户应用了不当筛选条件。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**无效消息正文几乎总是发布者出错导致的。我们建议将阈值设置为 0，因为在运行正常的系统中，预计不会出现无效消息正文。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsRedrivenToDlq**
**维度：**TopicName
**警报描述：**此警报有助于监控要移至死信队列的消息数量。
**意图：**此警报用于检测要移至死信队列的消息。我们建议您在将 SNS 与 SQS、Lambda 或 Firehose 结合使用时创建此警报。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**在任何订阅用户类型的运行正常的系统中，不应将消息移至死信队列。如果有任何消息进入该队列，我们建议向您发送通知，以便您可以识别根本原因并解决问题，并有可能重新驱动死信队列中的消息以防止数据丢失。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFailedToRedriveToDlq**
**维度：**TopicName
**警报描述：**此警报有助于监控无法移至死信队列的消息。检查您的死信队列是否存在，并检查其配置是否正确。此外，请验证 SNS 是否有权访问死信队列。要了解更多信息，请参阅[死信队列文档](https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html)。
**意图：**此警报用于检测无法移至死信队列的消息。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**如果无法将消息移至死信队列，则几乎总会出错。建议阈值为 0，这意味着在配置队列后，所有处理失败的消息都必须能够到达死信队列。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**SMSMonthToDateSpentUSD**
**维度：**TopicName
**警报描述：**此警报有助于监控您的账户中是否有足够的限额让 SNS 能够传送消息。如果达到了限额，SNS 将无法传送 SMS 消息。有关设置您的每月 SMS 支出限额的信息，或有关向 AWS 请求提高支出限额的信息，请参阅[设置发送 SMS 消息的首选项](https://docs.aws.amazon.com/sns/latest/dg/sms_preferences.html)。
**意图：**此警报用于检测您的账户中是否有足够的限额来成功传送 SMS 消息。
**统计数据：**Maximum
**建议阈值：**取决于您的情况
**阈值理由：**根据账户的限额（账户支出限额）设置阈值。选择一个阈值，该阈值会尽早告知您已达到限额，以便您有时间请求增加限额。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
**SMSSuccessRate**
**维度：**TopicName
**警报描述：**此警报有助于监控 SMS 消息传送的失败率。您可以设置 [Cloudwatch Logs](https://docs.aws.amazon.com/sns/latest/dg/sms_stats_cloudwatch.html) 以了解失败的性质并据此执行操作。
**意图：**此警报用于检测 SMS 消息传送失败。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**根据您对 SMS 消息传送失败的容忍度设置警报阈值。
**时间段：**60
**要发出警报的数据点数**：5
**评估期：**5
**比较运算符：**GREATER\$1THAN\$1THRESHOLD
## Amazon SQS
**ApproximateAgeOfOldestMessage**
**维度：**QueueName
**警报描述：**此警报会监控队列中最早消息的期限。您可以使用此警报来监控您的消费端是否以所需速度处理 SQS 消息。考虑增加消费端数量或消费端吞吐量以缩短消息期限。此指标可以与 `ApproximateNumberOfMessagesVisible` 结合使用，以确定队列积压的大小以及消息的处理速度。为防止消息在处理之前被删除，请考虑将死信队列配置为放弃潜在的毒丸消息。
**意图：**此警报用于检测 queueName 队列中最早消息的期限是否过长。长期限可能表示消息处理速度不够快，或者有一些毒丸消息卡在队列中无法处理。
**统计数据：**Maximum
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于预期的消息处理时间。您可以使用历史数据计算平均消息处理时间，然后将阈值设置为比队列消费端的预期最大 SQS 消息处理时间多 50%。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ApproximateNumberOfMessagesNotVisible**
**维度：**QueueName
**警报描述：**此警报有助于检测与 `QueueName` 有关的大量传输中消息。要排查问题，请检查[消息积压减少](https://repost.aws/knowledge-center/sqs-message-backlog)。
**意图：**此警报用于检测队列中大量的传输中消息。如果消费端没有在可见性超时期限内删除消息，则在轮询队列时，消息会重新出现在队列中。对于 FIFO 队列，最多可以有 20000 条传输中消息。如果您达到此限额，SQS 将不会返回任何错误消息。FIFO 队列会浏览前 2 万条消息以确定可用的消息组。这意味着，如果您在单个消息组中积压了消息，则在成功使用积压的消息之前，您无法使用其他消息组中稍后发送到该队列的消息。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**此警报的建议阈值在很大程度上取决于预期的传输中消息数量。您可以使用历史数据来计算传输中消息的预期最大数量，并将阈值设置为超过该值的 50%。如果队列的消费端正在处理消息但没有从队列中删除消息，则此数量将突然增加。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ApproximateNumberOfMessagesVisible**
**维度：**QueueName
**警报描述：**此警报会监控消息队列的积压是否大于预期，这表明消费端的速度太慢或消费端数量不足。如果此警报进入“ALARM”状态，可以考虑增加消费端数量或加快消费端的速度。
**意图：**此警报用于检测活动队列的消息计数是否过高，消费端是否处理消息缓慢，或者是否没有足够的消费端来处理消息。
**统计数据：**平均值
**建议阈值：**取决于您的情况
**阈值理由：**可见消息的数量异常高，表明消费端处理消息的速度未达到预期。设置此阈值时，应考虑历史数据。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**NumberOfMessagesSent**
**维度：**QueueName
**警报描述：**此警报有助于检测生成器是否没有就 `QueueName` 发送任何消息。要排查问题，请检查生成器未发送消息的原因。
**意图：**此警报用于检测生成器何时停止发送消息。
**统计数据：**Sum
**建议阈值：**0.0
**阈值理由：**如果发送的消息数量为 0，则生成器不会发送任何消息。如果此队列的 TPS 较低，请相应地增加 EvaluationPeriods 的数量。
**时间段：**60
**要发出警报的数据点数**：15
**评估期：**15
**比较运算符：**LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Site-to-Site VPN
**TunnelState**
**维度：**VpnId
**警报描述：**此警报有助于您了解一条或多条隧道的状态是否为“DOWN”。有关问题排查，请参阅[如何排查与 Amazon VPC 的 VPN 隧道连接故障？](https://repost.aws/knowledge-center/vpn-tunnel-troubleshooting)。
**意图：**此警报用于检测此 VPN 的至少一条隧道是否处于“DOWN”状态，以便您可以排查受影响 VPN 的问题。对于仅配置了单条隧道的网络，此警报将始终处于“ALARM”状态。
**统计数据：**Minimum
**建议阈值：**1.0
**阈值理由：**值小于 1 表示至少有一条隧道处于“DOWN”状态。
**时间段：**300
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**LESS\$1THAN\$1THRESHOLD
**TunnelState**
**维度：**TunnelIpAddress
**警报描述：**此警报有助于您了解此隧道的状态是否为“DOWN”。有关问题排查，请参阅[如何排查与 Amazon VPC 的 VPN 隧道连接故障？](https://repost.aws/knowledge-center/vpn-tunnel-troubleshooting)。
**意图：**此警报用于检测隧道是否处于“DOWN”状态，以便您可以排查受影响 VPN 的问题。对于仅配置了单条隧道的网络，此警报将始终处于“ALARM”状态。
**统计数据：**Minimum
**建议阈值：**1.0
**阈值理由：**值小于 1 表示隧道处于“DOWN”状态。
**时间段：**300
**要发出警报的数据点数**：3
**评估期：**3
**比较运算符：**LESS\$1THAN\$1THRESHOLD
# 警报使用场景和示例
以下部分提供了常见使用场景的警报示例和教程。
**Topics**
+ [创建账单告警以监控预估的 AWS 费用](monitor_estimated_charges_with_cloudwatch.md)
+ [创建 CPU 使用率告警](US_AlarmAtThresholdEC2.md)
+ [创建发送电子邮件的负载均衡器延迟告警](US_AlarmAtThresholdELB.md)
+ [创建发送电子邮件的存储吞吐量告警](US_AlarmAtThresholdEBS.md)
+ [针对 AWS 数据库中的性能详情计数器指标创建警报](CloudWatch_alarm_database_performance_insights.md)
# 创建账单告警以监控预估的 AWS 费用
您可以使用 Amazon CloudWatch 监控 AWS 估算费用。在为您的 AWS 账户启用估算费用监控时，将每天计算几次估算费用并作为指标数据发送到 CloudWatch。
账单指标数据存储在美国东部（弗吉尼亚北部）区域中，并表示全球费用。该数据包括您在 AWS 中使用的每个服务的估算费用，以及您的 AWS 估算费用总和。
当您的账户账单超过阈值时，将触发告警。它仅在当前账单超出阈值时触发。它不会根据您本月迄今为止的使用情况进行预测。
如果您每当费用超出阈值时创建一个账单告警，则告警将立即变为 `ALARM`（告警）状态。
**注意**
有关分析已计费的 CloudWatch 费用的信息，请参阅 [分析、优化和降低 CloudWatch 成本](cloudwatch_billing.md)。
**Topics**
+ [启用账单提醒](#turning_on_billing_metrics)
+ [创建账单警报](#creating_billing_alarm_with_wizard)
+ [删除账单告警](#deleting_billing_alarm)
## 启用账单提醒
在为估算费用创建告警之前，您必须启用账单提醒，以便监控 AWS 估算费用并使用账单指标数据创建告警。在启用账单提醒后，您无法禁用数据收集，但可以删除创建的任何账单告警。
首次启用账单提醒后，大约需要 15 分钟时间，您就可以查看账单数据和设置账单告警。
**要求**
+ 您必须使用账户根用户凭证或作为被授予权限的 IAM 用户登录，才能查看账单信息。
+ 对于整合账单账户，每个关联账户的账单数据可以在付款账户登录后找到。您可以查看每个关联账户以及整合账户的估计费用总和，和各项服务的估计费用。
+ 在整合账单账户中，仅当付款人账户启用 **Receive Billing Alerts（接收账单提醒）**首选项时，才会捕获成员关联账户的指标。如果您更改了您的管理账户/付款人账户，则必须在新的管理账户/付款人账户中启用账单提醒。
+ 该账户不能属于 Amazon 合作伙伴网络 (APN)，因为对于 APN 账户，账单指标不会发布到 CloudWatch。有关更多信息，请参阅 [AWS 合作伙伴网络](https://aws.amazon.com/partners/)。
**要启用预估收费监控**
1. 打开 AWS 账单与成本管理 控制台，网址为 [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/)。
1. 在导航窗格中，选择 **Billing Preferences（账单首选项）**。
1. 通过**提醒首选项**选择**编辑**。
1. 选择**接收 CloudWatch 账单提醒**。
1. 选择**保存首选项**。
## 创建账单警报
**重要**
创建账单告警之前，您必须将区域设置为美国东部（弗吉尼亚州北部）。账单指标数据存储在该区域中，并表示全球费用。您还必须为您的账户启用账单提醒；或者，如果您使用的是整合账单，则必须在管理账户/付款人账户中启用账单提醒。有关更多信息，请参阅 [启用账单提醒](#turning_on_billing_metrics)。
在该过程中，您可以创建一个告警，以便在 AWS 的估算费用超出定义的阈值时发送通知。
**使用 CloudWatch 控制台创建告警**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择 **Alarms**（告警），然后选择 **All alarms**（所有告警）。
1. 选择**创建警报**。
1. 选择**选择指标**。在 **AWS 命名空间**中，选择**账单**，然后选择**总估算费用**。
**注意**
如果您没看到**账单**/**总估算费用**指标，则启用账单提醒，并将您的区域更改为美国东部（弗吉尼亚州北部）。有关更多信息，请参阅 [启用账单提醒](#turning_on_billing_metrics)。
1. 选中 **EstimatedCharges**（估算费用）指标的复选框，然后选择 **Select metric**（选择指标）。
1. 对于 **Statistic（统计数据）**，选择 **Maximum（最大）**。
1. 对于 **Period**（周期），选择 **6 hours**（6 小时）。
1. 对于**阈值类型**，选择**静态**。
1. 对于 **Whenever EstimatedCharges is . . .**（当估算费用. .），选择 **Greater**（大）。
1. 对于 **than . . .**，请定义要触发告警的值。例如，**200** USD。
**EstimatedCharges** 指标值仅以美元（USD）为单位，货币转换由 Amazon Services LLC 提供。有关更多信息，请参阅[什么是 AWS Billing？](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html)。
**注意**
定义阈值后，预览图显示您当月的预估费用。
1. 在**其他配置**中，执行以下操作：
+ 对于 **Datapoints to alarm**（触发告警的数据点数），指定 **1 out of 1**（1 选 1）。
+ 对于 **Missing data treatment**（缺失数据处理），选择 **Treat missing data as missing**（将缺失的数据视为缺失）。
1. 选择**下一步**。
1. 在**通知**下，确保选择**告警中**。选择当您的告警处于 `ALARM` 状态时要通知的 Amazon SNS 主题。Amazon SNS 主题可以包含您的电子邮件地址，这样当账单金额超过您指定的阈值时，您就会收到电子邮件。
您可以选择现有的 Amazon SNS 主题、创建一个新 Amazon SNS 主题或使用主题 ARN 通知其他账户。如果您希望您的告警为相同告警状态或不同告警状态发送多个通知，请选择 **Add notification**（添加通知）。
1. 选择**下一步**。
1. 在 **Name and description**（名称和描述）下，为您的告警输入名称。名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。
1. （可选）输入告警的描述。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
1. 选择**下一步**。
1. 在 **Preview and create**（预览和创建）下，确保您的配置正确，然后选择 **Create alarm**（创建告警）。
## 删除账单告警
当您不再需要账单告警时，可将其删除。
**删除账单告警**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 如果需要，可将区域更改为美国东部（弗吉尼亚北部）。账单指标数据存储在此区域中，并且反映全球费用。
1. 在导航窗格中，依次选择 **Alarms**（警报）和 **All alarms**（所有警报）。
1. 选中告警旁的复选框，然后依次选择 **Actions（操作）** 和 **Delete（删除）**。
1. 当系统提示进行确认时，选择 **Yes, Delete（是，删除）**。
# 创建 CPU 使用率告警
您可以创建在告警状态从 `OK`（正常）变为 `ALARM`（告警）时使用 Amazon SNS 发送通知的 CloudWatch 告警。
在 EC2 实例的平均 CPU 使用率在指定的连续评估期内超出指定的阈值时，告警将变为 `ALARM`（告警）状态。
## 使用 AWS 管理控制台 设置 CPU 使用率告警
可以执行以下步骤以使用 AWS 管理控制台创建 CPU 使用率警报。
**根据 CPU 利用率创建警报**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms**（告警）和 **All alarms**（所有告警）。
1. 选择**创建警报**。
1. 选择**选择指标**。
1. 在 **All metrics（所有指标）**选项卡中，选择 **EC2 metrics（EC2 指标）**。
1. 选择一个指标类别（例如，**Per-Instance Metrics（每个实例的指标）**）。
1. 找到您希望在 **InstanceId（实例 ID）**列和 **Metric Name（指标名称）**中的 **CPUUtilization（CPU 使用率）**中列出的实例所在的行。选中此行旁边的复选框，然后选择 **Select metric（选择指标）**。
1. 在 **Specify metric and conditions（指定指标和条件）**下，对于 **Statistic（统计数据）**，选择 **Average（平均值）**，然后选择一个预定义百分位数，或指定自定义百分位数（例如 **p95.45**）。
1. 选择时间段（例如 **5 minutes**）。
1. 在**条件**下面，指定以下内容：
1. 对于 **Threshold type（阈值类型）**，选择 **Static（静态）**。
1. 对于 **Whenever CPUUtilization is（每当 CPU 利用率）**，指定 **Greater（大）**。在 **than...（于...）**下，指定在 CPU 使用率超过此百分比时触发告警进入“ALARM（告警）”状态的阈值。例如，70。
1. 选择**其他配置**。对于**触发警报的数据点数**，指定必须有多少个评估期（数据点）处于 `ALARM` 状态才能触发警报。如果此处的两个值匹配，则会创建一个告警；如果多个连续评估期违例，该告警将变为 `ALARM`（告警）状态。
要创建“M（最大为 N）”告警，为第一个值指定的数字应小于为第二个值指定的数字。有关更多信息，请参阅 [告警评估](alarm-evaluation.md)。
1. 对于**缺失数据处理**，选择在缺失某些数据点时的警报行为。有关更多信息，请参阅 [配置 CloudWatch 告警处理缺失数据的方式](alarms-and-missing-data.md)。
1. 如果警报将百分比值作为监控的统计数据，将显示**样本数少的百分比**框。使用它来选择是评估还是忽略采样率低的案例。如果选择**忽略 (保持警报状态)**，在样本大小太小时，将始终保持当前警报状态。有关更多信息，请参阅 [基于百分位数的告警和小数据样本](percentiles-with-low-samples.md)。
1. 选择**下一步**。
1. 在 **Notification（通知）**下，选择 **In alarm（处于告警中）**，并选择当告警处于 `ALARM` 状态时要通知的 SNS 主题
要使告警为相同告警状态或不同告警状态发送多个通知，请选择**添加通知**。
要让警报不发送通知，请选择**删除**。
1. 在完成后，选择**下一步**。
1. 输入警报的名称和说明。然后选择**下一步**。
名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
1. 在 **Preview and create** 下面，确认具有所需的信息和条件，然后选择 **Create alarm**。
## 使用 AWS CLI 设置 CPU 使用率告警
可以执行以下步骤以使用 AWS CLI创建 CPU 使用率警报。
**根据 CPU 利用率创建警报**
1. 设置 SNS 主题。有关更多信息，请参阅 [设置 Amazon SNS 通知](Notify_Users_Alarm_Changes.md#US_SetupSNS)。
1. 使用 [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) 命令创建告警，如下所示。
```
aws cloudwatch put-metric-alarm --alarm-name cpu-mon --alarm-description "Alarm when CPU exceeds 70%" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 70 --comparison-operator GreaterThanThreshold --dimensions Name=InstanceId,Value=i-12345678 --evaluation-periods 2 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-topic --unit Percent
```
1. 通过使用 [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html) 命令强制更改警报状态来测试警报。
1. 将告警状态从 `INSUFFICIENT_DATA`（数据不足）更改为 `OK`（正常）。
```
aws cloudwatch set-alarm-state --alarm-name cpu-mon --state-reason "initializing" --state-value OK
```
1. 将告警状态从 `OK`（正常）更改为 `ALARM`（告警）。
```
aws cloudwatch set-alarm-state --alarm-name cpu-mon --state-reason "initializing" --state-value ALARM
```
1. 检查您是否收到有关告警的电子邮件通知。
# 创建发送电子邮件的负载均衡器延迟告警
您可以设置 Amazon SNS 通知并配置告警，此告警监控经典负载均衡器超过 100 毫秒的延迟。
## 使用 AWS 管理控制台 设置延迟告警
可以执行以下步骤以使用 AWS 管理控制台创建负载均衡器延迟警报。
**创建负载均衡器延迟告警**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms**（告警）和 **All alarms**（所有告警）。
1. 选择**Create alarm（创建警报）**。
1. 在 **CloudWatch Metrics by Category（按类别显示的 CloudWatch 指标）**下，选择 **ELB Metrics（ELB 指标）**类别。
1. 选择包含经典负载均衡器和 **Latency（延迟）**指标的行。
1. 对于统计数据，选择 **Average（平均值）**，然后选择其中的一个预定义百分比值，或者指定一个自定义百分比值（例如 **p95.45**）。
1. 对于时间段，选择 **1 Minute（1 分钟）**。
1. 选择**下一步**。
1. 在**警报阈值**下面，输入警报的唯一名称（例如，**myHighCpuAlarm**）和警报描述（例如，**Alarm when Latency exceeds 100s**）。告警名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符
名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
1. 在 **Whenever（每当）**下，对于 **is（是）**，选择 **>** 并输入 **0.1**。对于 **for（持续时间）**，输入 **3**。
1. 在 **Additional settings（附加设置）**下，对于 **Treat missing data as（将缺失的数据作为以下内容处理）**选择 **ignore (maintain alarm)（忽略（保持告警状态））**，以使缺失数据点不会触发告警状态更改。
对于 **Percentiles with low samples（样本数少的百分比）**，选择 **ignore (maintain the alarm state)（忽略（保持告警状态））**，使告警只评估具有充足数量的数据样本的情况。
1. 在 **Actions（操作）**下，为 **Whenever this alarm（每当此告警）**选择 **State is ALARM（状态为“告警”）**。对于 **Send notification to（发送通知到）**，选择一个现有 SNS 主题或创建一个新 SNS 主题。
要创建 SNS 主题，请选择 **New list（新列表）**。对于 **Send notification to（发送通知到）**输入 SNS 主题的名称（例如 **myHighCpuAlarm**），对于 **Email list（电子邮件列表）**输入在告警状态变为 `ALARM`（告警）时通知的电子邮件地址列表（以逗号分隔）。将向每个电子邮件地址发送一封主题订阅确认电子邮件。您必须先确认订阅，然后才会发送通知。
1. 选择**创建警报**。
## 使用 AWS CLI 设置延迟告警
可以执行以下步骤以使用 AWS CLI创建负载均衡器延迟警报。
**创建负载均衡器延迟告警**
1. 设置 SNS 主题。有关更多信息，请参阅 [设置 Amazon SNS 通知](Notify_Users_Alarm_Changes.md#US_SetupSNS)。
1. 使用 [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) 命令创建告警，如下所示：
```
1. aws cloudwatch put-metric-alarm --alarm-name lb-mon --alarm-description "Alarm when Latency exceeds 100s" --metric-name Latency --namespace AWS/ELB --statistic Average --period 60 --threshold 100 --comparison-operator GreaterThanThreshold --dimensions Name=LoadBalancerName,Value=my-server --evaluation-periods 3 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-topic --unit Seconds
```
1. 通过使用 [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html) 命令强制更改警报状态来测试警报。
1. 将告警状态从 `INSUFFICIENT_DATA`（数据不足）更改为 `OK`（正常）。
```
1. aws cloudwatch set-alarm-state --alarm-name lb-mon --state-reason "initializing" --state-value OK
```
1. 将告警状态从 `OK`（正常）更改为 `ALARM`（告警）。
```
1. aws cloudwatch set-alarm-state --alarm-name lb-mon --state-reason "initializing" --state-value ALARM
```
1. 检查您是否收到有关告警的电子邮件通知。
# 创建发送电子邮件的存储吞吐量告警
您可以设置 SNS 通知并配置告警，该告警在 Amazon EBS 超过 100MB 吞吐量时触发。
## 使用 AWS 管理控制台 设置存储吞吐量告警
可以执行以下步骤，使用 AWS 管理控制台 创建基于 Amazon EBS 吞吐量的告警。
**创建存储吞吐量告警**
1. 访问 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)，打开 CloudWatch 控制台。
1. 在导航窗格中，依次选择 **Alarms**（告警）和 **All alarms**（所有告警）。
1. 选择**Create alarm（创建警报）**。
1. 在 **EBS Metrics（EBS 指标）**下，选择一个指标类别。
1. 选择包含卷和 **VolumeWriteBytes** 指标的行。
1. 对于统计数据，选择 **Average（平均值）**。对于时间段，选择 **5 Minutes（5 分钟）**。选择**下一步**。
1. 在**警报阈值**下面，输入警报的唯一名称（例如，**myHighWriteAlarm**）和警报描述（例如，**VolumeWriteBytes exceeds 100,000 KiB/s**）。名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
1. 在 **Whenever（每当）**下，对于 **is（是）**，选择 **>** 并输入 **100000**。对于 **for（持续时间）**，输入 **15** 个连续评估期。
**Alarm Preview（告警预览）**下会显示阈值的图形表示。
1. 在 **Additional settings（附加设置）**下，对于 **Treat missing data as（将缺失的数据作为以下内容处理）**选择 **ignore (maintain alarm)（忽略（保持告警状态））**，以使缺失数据点不会触发告警状态更改。
1. 在 **Actions（操作）**下，为 **Whenever this alarm（每当此告警）**选择 **State is ALARM（状态为“告警”）**。对于 **Send notification to（发送通知到）**，选择现有的 SNS 主题或创建一个主题。
要创建 SNS 主题，请选择 **New list（新列表）**。对于 **Send notification to（发送通知到）**输入 SNS 主题的名称（例如 **myHighCpuAlarm**），对于 **Email list（电子邮件列表）**输入在告警状态变为 `ALARM`（告警）时通知的电子邮件地址列表（以逗号分隔）。将向每个电子邮件地址发送一封主题订阅确认电子邮件。您必须先确认订阅，然后才能将通知发送到电子邮件地址。
1. 选择 **Create Alarm（创建告警）**。
## 使用 AWS CLI 设置存储吞吐量告警
可以执行以下步骤，使用 AWS CLI 创建基于 Amazon EBS 吞吐量的告警。
**创建存储吞吐量告警**
1. 创建一个 SNS 主题。有关更多信息，请参阅 [设置 Amazon SNS 通知](Notify_Users_Alarm_Changes.md#US_SetupSNS)。
1. 创建告警。
```
1. aws cloudwatch put-metric-alarm --alarm-name ebs-mon --alarm-description "Alarm when EBS volume exceeds 100MB throughput" --metric-name VolumeReadBytes --namespace AWS/EBS --statistic Average --period 300 --threshold 100000000 --comparison-operator GreaterThanThreshold --dimensions Name=VolumeId,Value=my-volume-id --evaluation-periods 3 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-alarm-topic --insufficient-data-actions arn:aws:sns:us-east-1:111122223333:my-insufficient-data-topic
```
1. 通过使用 [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html) 命令强制更改警报状态来测试警报。
1. 将告警状态从 `INSUFFICIENT_DATA`（数据不足）更改为 `OK`（正常）。
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value OK
```
1. 将告警状态从 `OK`（数据不足）更改为 `ALARM`（正常）。
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value ALARM
```
1. 将告警状态从 `ALARM`（正常）更改为 `INSUFFICIENT_DATA`（告警）。
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value INSUFFICIENT_DATA
```
1. 检查您是否收到有关告警的电子邮件通知。
# 针对 AWS 数据库中的性能详情计数器指标创建警报
CloudWatch 包含 **DB\$1PERF\$1INSIGHTS** 指标数学函数，您可以使用该函数将 Amazon Relational Database Service 和 Amazon DocumentDB（与 MongoDB 兼容）中的性能详情计数器指标引入 CloudWatch。**DB\$1PERF\$1INSIGHTS** 还以亚分钟为间隔引入 `DBLoad` 指标。您可以根据这些指标设置 CloudWatch 警报。
有关 Amazon RDS 性能详情的更多信息，请参阅[在 Amazon RDS 上使用性能详情监控数据库负载](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)。
有关 Amazon DocumentDB 性能详情的更多信息，请参阅[使用性能详情进行监控](https://docs.aws.amazon.com/documentdb/latest/developerguide/performance-insights.html.html)。
基于 **DB\$1PERF\$1INSIGHTS** 函数的警报不支持异常检测。
**注意**
**DB\$1PERF\$1INSIGHTS** 检索的精度为亚分钟的高分辨率指标仅适用于 **DBLoad** 指标，或者如果您启用了更高分辨率的增强监控，则适用于操作系统指标。有关 Amazon RDS 增强监控的更多信息，请参阅[使用增强监控监控操作系统指标](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)。
您可以使用 **DB\$1PERF\$1INSIGHTS** 函数创建高分辨率警报。高分辨率警报的最长评估范围为三小时。您可以使用 CloudWatch 控制台绘制任何时间范围内通过 **DB\$1PERF\$1INSIGHTS** 函数检索到的指标的图表。
**创建基于性能详情指标的警报**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
1. 在导航窗格中，选择 **Alarms**（告警），然后选择 **All alarms**（所有告警）。
1. 选择**创建警报**。
1. 选择 **Select Metric（选择指标）**。
1. 选择**添加数学**下拉列表，然后从列表中选择**所有函数**、**DB\$1PERF\$1INSIGHTS**。
选择 **DB\$1PERF\$1INSIGHTST** 后，系统将显示一个数学表达式框，您可以在其中应用或编辑数学表达式。
1. 在数学表达式框中，输入 **DB\$1PERF\$1INSIGHTS** 数学表达式，然后选择**应用**。
例如，**DB\$1PERF\$1INSIGHTS(‘RDS’, ‘db-ABCDEFGHIJKLMNOPQRSTUVWXY1’, ‘os.cpuUtilization.user.avg’)**
**重要**
使用 **DB\$1PERF\$1INSIGHTS** 数学表达式时，必须指定数据库的唯一数据库资源 ID。这与数据库标识符不同。要在 Amazon RDS 控制台中查找数据库资源 ID，请选择数据库实例以查看其详细信息。然后，选择**配置**选项卡。**资源 ID** 将显示在**配置**部分中。
有关 **DB\$1PERF\$1INSIGHTS** 函数和可用于指标数学的其他函数的信息，请参阅 [指标数学语法和函数](using-metric-math.md#metric-math-syntax)。
1. 选择**选择指标**。
将显示 **Specify metric and conditions（指定指标和条件）**页面，其中显示一个图表以及有关您选择的数学表达式的其他信息。
1. 对于 **Whenever *expression* is（每当表达式）**，指定表达式是必须大于、小于还是等于阈值。在**于...** 下面，指定阈值。
1. 选择**其他配置**。对于**触发警报的数据点数**，指定必须有多少个评估期（数据点）处于 `ALARM` 状态才能触发警报。如果此处的两个值匹配，则会创建一个告警；如果多个连续评估期违例，该告警将变为 `ALARM`（告警）状态。
要创建“M（最大为 N）”告警，为第一个值指定的数字应小于为第二个值指定的数字。有关更多信息，请参阅 [告警评估](alarm-evaluation.md)。
1. 对于**缺失数据处理**，选择在缺失某些数据点时的警报行为。有关更多信息，请参阅 [配置 CloudWatch 告警处理缺失数据的方式](alarms-and-missing-data.md)。
1. 选择**下一步**。
1. 在**通知**下面，选择一个在警报处于 `ALARM`、`OK` 或 `INSUFFICIENT_DATA` 状态时通知的 SNS 主题。
要使告警为相同告警状态或不同告警状态发送多个通知，请选择**添加通知**。
要让警报不发送通知，请选择**删除**。
1. 要让警报执行 Auto Scaling、EC2、Lambda 或 Systems Manager 操作，请选择相应的按钮，然后选择警报状态和要执行的操作。如果您选择 Lambda 函数作为警报操作，则需要指定函数名称或 ARN，并且可以选择该函数的特定版本。
告警只有在进入“ALARM（告警）”状态时才能执行 Systems Manager 操作。有关 Systems Manager 操作的更多信息，请参阅[将 CloudWatch 配置为通过告警创建 OpsItems ](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)和[事件创建](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
**注意**
要创建执行 SSM Incident Manager 操作的告警，您必须具有特定的权限。有关更多信息，请参阅 [AWS Systems Manager Incident Manager 的基于身份的策略示例](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html)。
1. 在完成后，选择**下一步**。
1. 输入警报的名称和说明。然后选择**下一步**。
名称必须仅包含 UTF-8 字符，并且不能包含 ASCII 控制字符。描述可以包含 Markdown 格式，该格式仅在 CloudWatch 控制台的警报**详细信息**选项卡中显示。Markdown 非常适合用于向运行手册或其他内部资源添加链接。
1. 在 **Preview and create** 下面，确认具有所需的信息和条件，然后选择 **Create alarm**。