# CloudWatch 警报如何检测 Amazon ECS 部署故障
<a name="deployment-alarm-failure"></a>

您可以配置 Amazon ECS 以在检测到指定的 CloudWatch 警报已进入 `ALARM` 状态时，将部署设置为失败。

您可以选择设置配置，将失败的部署回滚到上一个完成的部署。

以下 `create-service` AWS CLI 示例显示如何在将部署警报和回滚选项结合使用时创建 Linux 服务。

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

对服务使用 Amazon CloudWatch 警报方法时，请注意以下事项。
+ 生产流量转移后，蓝色服务修订版和绿色服务修订版同时运行的持续时间。Amazon ECS 根据与部署关联的警报配置计算此时间段。您不能设置该值。
+ `deploymentConfiguration` 请求参数现在包含 `alarms` 数据类型。您可以指定警报名称、是否使用该方法以及在警报显示部署故障时是否启动回滚。有关更多信息，请参阅**《Amazon Elastic Container Service API 参考》中的 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)。
+ `DescribeServices` 响应提供了对部署状态、`rolloutState` 和 `rolloutStateReason` 的深入了解。启动新部署时，回滚状态将在 `IN_PROGRESS` 状态开始。当服务达到稳定状态时，烘焙时间完成，回滚状态将转换为 `COMPLETED`。如果服务未能达到稳定状态并且警报已进入 `ALARM` 状态，则部署将转换为 `FAILED` 状态。`FAILED` 状态中的部署不会启动任何新任务。
+ 除了 Amazon ECS 为已启动和已完成的部署发送的服务部署状态更改事件外，Amazon ECS 还将在使用警报的部署失败时发送事件。这些事件提供了有关部署失败的原因或部署是否由于回滚而启动的详细信息。有关更多信息，请参阅 [Amazon ECS 服务部署状态更改事件](ecs_service_deployment_events.md)。
+ 如果由于以前的部署失败并打开了回滚而启动了新部署，则服务部署状态更改事件的 `reason` 字段将指示部署是由于回滚而启动的。
+ 如果您使用部署断路器和 Amazon CloudWatch 警报来检测故障，则两种方法中的任意一个都可以在满足任一方法的条件后立即启动部署失败。当您对启动部署故障的方法使用回滚选项时，会发生回滚。
+ Amazon CloudWatch 警报仅支持使用滚动更新（`ECS`）部署控制器的 Amazon ECS 服务。
+ 您可以使用新 Amazon ECS 控制台或 AWS CLI 来配置此选项。这种方法的示例是，如果有关更多信息，请参阅**《AWS Command Line Interface 参考》中的 [使用定义的参数创建服务](create-service-console-v2.md#create-custom-service) 和 [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)。
+ 您可能会注意到，部署状态会长时间处于 `IN_PROGRESS`。其原因是，只有在删除活动部署后 Amazon ECS 才会更改状态，而这种情况要等到烘焙时间之后才会发生。根据您的警报配置，部署所需的时间可能比在不使用警报时长几分钟（即使新的主要任务集已纵向扩展而旧的部署已缩减）。如果您使用 CloudFormation 超时，请考虑延长超时。有关更多信息，请参阅**《AWS CloudFormation 用户指南》中的[在模板中创建等待条件](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html)。
+ Amazon ECS 调用 `DescribeAlarms` 轮询警报。对 `DescribeAlarms` 调用计入与您的账户相关的 CloudWatch 服务配额。如果您有调用 `DescribeAlarms` 的其他 AWS 服务，则对 Amazon ECS 的轮询警报可能有影响。例如，如果其他服务进行足够 `DescribeAlarms` 调用以达到配额，则该服务会受到限制，Amazon ECS 也会受到限制，无法轮询警报。如果在节流期内生成警报，Amazon ECS 可能会错过警报，也可能不会发生回滚。对部署没有其他影响。有关更多信息，请参阅**《CloudWatch 用户指南》中的 [CloudWatch 服务配额](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm)。
+ 如果警报在部署开始时处于 `ALARM` 状态，则 Amazon ECS 在该部署期间不会监控警报（Amazon ECS 将忽略警报配置）。此行为解决了您想要启动新部署来修复初始部署失败的问题。

## 建议的警报
<a name="ecs-deployment-alarms"></a>

我们建议您使用以下警报指标：
+ 如果您使用应用程序负载均衡器，请使用 `HTTPCode_ELB_5XX_Count` 和 `HTTPCode_ELB_4XX_Count` 应用程序负载均衡器指标。这些指标检查 HTTP 峰值。有关更多信息，请参阅**《应用程序负载均衡器用户指南》中的[应用程序负载均衡器的 CloudWatch 指标](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)。
+ 如果您有现有的应用程序，请使用 `CPUUtilization` 和 `MemoryUtilization` 指标。这些指标检查集群或服务使用的 CPU 和内存百分比。有关更多信息，请参阅 [注意事项](cloudwatch-metrics.md#enable_cloudwatch)。
+ 如果您在任务中使用 Amazon Simple Queue Service 队列，请使用 `ApproximateNumberOfMessagesNotVisible` Amazon SQS 指标。该指标检查队列中延迟且无法立即读取的消息数量。有关更多信息，请参阅**《Amazon Simple Queue Service 开发人员指南》中的 [Amazon SQS 的可用 CloudWatch 指标](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)。

## 烘焙时间
<a name="deployment-bake-time"></a>

当您对服务部署使用回滚选项时，Amazon ECS 会在目标服务修订部署完成后额外等待一段时间，然后再发送 CloudWatch 警报。这称为烘焙时间。此时间开始于：
+ 目标服务修订的所有任务都在运行且状态良好
+ 源服务修订缩减至 0%

默认烘焙时间少于 5 分钟。烘焙时间到期后，服务部署标记为已完成。

您可以配置滚动部署的烘焙时间。当您使用 CloudWatch 警报检测故障时，如果您更改了烘焙时间，然后决定使用 Amazon ECS 默认设置，则必须手动设置烘焙时间。