本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# CloudWatch 警报
<a name="cloudwatch-alarms"></a>

该解决方案部署了两个 CloudWatch 警报，用于监控需要注意的操作条件。默认情况下，这些警报没有配置任何通知操作。我们建议为每个警报订阅 Amazon SNS 主题，以便操作员在出现问题时立即收到通知。

## 订阅警报通知
<a name="subscribe-to-alarms"></a>

要在警报触发时接收通知，请执行以下操作：

1. 打开[CloudWatch 警报控制台](https://console.aws.amazon.com/cloudwatch/home#alarmsV2:)。

1. 搜索以堆栈名称为前缀的警报（例如`my-stack-OrphanCleanupFailure`）。

1. 选择闹钟并选择**编辑**。

1. 在 “**通知**” 下，选择 “**添加通知**”。

1. 使用您的首选通知终端节点（电子邮件、短信或 Lambda）选择或创建 SNS 主题。

1. 选择**更新警报**。

对每个闹钟重复此操作。

## OrphanCleanupFailure
<a name="orphan-cleanup-failure-alarm"></a>


| 属性 | 值 | 
| --- | --- | 
| 告警名称 |  `{StackName}-OrphanCleanupFailure`  | 
| 指标 |  `OrphanCleanupFailures`在`distributed-load-testing`命名空间中 | 
| Threshold | >= 5 分钟内有 1 次失败 | 
| 处理缺失的数据 | 突破 | 

 **此警报监控的内容：**该解决方案使用三层防御来防止 ECS 服务失控：
+  **第 1 层：自动错误处理** — 测试编排工作流程包括每一步的错误处理。如果在配置、稳定或执行过程中出现任何故障，工作流程会自动触发清理以耗尽和删除 ECS 服务。
+  **第 2 层：执行失败检测** — 如果编排工作流程本身意外退出（例如，由于超时或内部错误绕过了正常的错误处理）， EventBridge 则规则会检测失败并独立触发测试中涉及的每个区域的清理。
+  **第 3 层：每小时清理孤儿** — 每小时运行一次定时进程，扫描与任何活动测试无关的 ECS 服务，然后强制删除它们。这是万不得已的安全网——如果第 1 层和第 2 层都出现故障，泄露的服务仍将在一小时内删除。如果孤儿清理过程本身失败，则会触发此警报。

 **为何重要：**孤立 ECS Fargate 服务继续运行并产生费用，但在 DLT 控制台中看不见。如果没有通知订阅，运营商只有在账单上出现意外费用时才会发现问题。

 **推荐响应：**当此警报触发时，导航到 [Amazon ECS 控制台](https://console.aws.amazon.com/ecs/)，找出 DLT 集群中与正在运行的测试不对应的服务，然后手动将其删除。

## MetricFilterCount
<a name="metric-filter-count-alarm"></a>


| 属性 | 值 | 
| --- | --- | 
| 告警名称 |  `{StackName}-MetricFilterCount-Alarm`  | 
| 指标 |  `MetricFilterCount`在`distributed-load-testing`命名空间中 | 
| Threshold | >= 90 | 
| 处理缺失的数据 | 未突破 | 

 **此警报监控的内容：**该解决方案在 ECS 日志组上动态创建 CloudWatch 指标筛选器，以支持测试执行期间的实时指标。AWS 将每个日志组限制为 100 个指标筛选条件。当使用量达到该限制的 90% 时，将触发此警报。

 **为何重要：**如果达到限制，新的负载测试运行将失败。

 **推荐回应：**删除不再需要的测试场景。删除测试场景后，该解决方案会删除关联的指标筛选条件并释放容量以进行新的测试。