CloudWatch 警报如何检测 Amazon ECS 部署故障 - Amazon Elastic Container Service
建议的警报

CloudWatch 警报如何检测 Amazon ECS 部署故障

您可以配置 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 继续监控与部署关联的警报。Amazon ECS 根据与部署关联的警报配置计算此时间段。

  • deploymentConfiguration 请求参数现在包含 alarms 数据类型。您可以指定警报名称、是否使用该方法以及在警报显示部署故障时是否启动回滚。有关更多信息，请参阅《Amazon Elastic Container Service API 参考》中的 CreateService。

  • DescribeServices 响应提供了对部署状态、rolloutState 和 rolloutStateReason 的深入了解。启动新部署时，回滚状态将在 IN_PROGRESS 状态开始。当服务达到稳定状态时，烘焙时间完成，回滚状态将转换为 COMPLETED。如果服务未能达到稳定状态并且警报已进入 ALARM 状态，则部署将转换为 FAILED 状态。FAILED 状态中的部署不会启动任何新任务。

  • 除了 Amazon ECS 为已启动和已完成的部署发送的服务部署状态更改事件外，Amazon ECS 还将在使用警报的部署失败时发送事件。这些事件提供了有关部署失败的原因或部署是否由于回滚而启动的详细信息。有关更多信息，请参阅 Amazon ECS 服务部署状态更改事件。

  • 如果由于以前的部署失败并打开了回滚而启动了新部署，则服务部署状态更改事件的 reason 字段将指示部署是由于回滚而启动的。

  • 如果您使用部署断路器和 Amazon CloudWatch 警报来检测故障，则两种方法中的任意一个都可以在满足任一方法的条件后立即启动部署失败。当您对启动部署故障的方法使用回滚选项时，会发生回滚。

  • Amazon CloudWatch 警报仅支持使用滚动更新 (ECS) 部署控制器的 Amazon ECS 服务。

  • 您可以使用新 Amazon ECS 控制台或 AWS CLI 来配置此选项。这种方法的示例是，如果有关更多信息，请参阅《AWS Command Line Interface 参考》中的 使用定义的参数创建服务 和 create-service。

  • 您可能会注意到，部署状态会长时间处于 IN_PROGRESS。其原因是，只有在删除活动部署后 Amazon ECS 才会更改状态，而这种情况要等到烘焙时间之后才会发生。根据您的警报配置，部署所需的时间可能比在不使用警报时长几分钟（即使新的主要任务集已纵向扩展而旧的部署已缩减）。如果您使用 CloudFormation 超时，请考虑延长超时。有关更多信息，请参阅《AWS CloudFormation 用户指南》中的在模板中创建等待条件。

  • Amazon ECS 调用 DescribeAlarms 轮询警报。对 DescribeAlarms 调用计入与您的账户相关的 CloudWatch 服务限额。如果您有调用 DescribeAlarms 的其他 AWS 服务，则对 Amazon ECS 的轮询警报可能有影响。例如，如果其他服务进行足够 DescribeAlarms 调用以达到配额，则该服务会受到限制，Amazon ECS 也会受到限制，无法轮询警报。如果在节流期内生成警报，Amazon ECS 可能会错过警报，也可能不会发生回滚。对部署没有其他影响。有关更多信息，请参阅《CloudWatch 用户指南》中的 CloudWatch 服务限额。

  • 如果警报在部署开始时处于 ALARM 状态，则 Amazon ECS 在该部署期间不会监控警报（Amazon ECS 将忽略警报配置）。此行为解决了您想要启动新部署来修复初始部署失败的问题。

建议的警报

我们建议您使用以下警报指标：

  • 如果您使用应用程序负载均衡器，请使用 HTTPCode_ELB_5XX_Count 和 HTTPCode_ELB_4XX_Count 应用程序负载均衡器指标。这些指标检查 HTTP 峰值。有关更多信息，请参阅《应用程序负载均衡器用户指南》中的应用程序负载均衡器的 CloudWatch 指标。

  • 如果您有现有的应用程序，请使用 CPUUtilization 和 MemoryUtilization 指标。这些指标检查集群或服务使用的 CPU 和内存百分比。有关更多信息，请参阅 注意事项。

  • 如果您在任务中使用 Amazon Simple Queue Service 队列，请使用 ApproximateNumberOfMessagesNotVisible Amazon SQS 指标。该指标检查队列中延迟且无法立即读取的消息数量。有关更多信息，请参阅《Amazon Simple Queue Service 开发人员指南》中的 Amazon SQS 的可用 CloudWatch 指标。