Detección de errores en la implementación de Amazon ECS por las alarmas de CloudWatch

Puede configurar Amazon ECS para que defina la implementación como fallida cuando detecte que una alarma de CloudWatch específica ha pasado al estado ALARM.

Si lo desea, puede establecer la configuración para restaurar una implementación con errores a la última implementación completada.

En los siguientes ejemplos de la AWS CLI de create-service, se muestra cómo crear un servicio de Linux cuando se utilizan las alarmas de implementación con la opción de restauración.

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}"

Tenga en cuenta lo siguiente al utilizar el método de alarmas de Amazon CloudWatch en un servicio.

• El tiempo de incorporación es un periodo que transcurre después de que la nueva versión del servicio se escala horizontalmente y la versión anterior se reduce horizontalmente, durante el cual Amazon ECS sigue monitoreando la alarma asociada a la implementación. Amazon ECS calcula este periodo en función de la configuración de alarma asociada a la implementación.

• El parámetro de solicitud deploymentConfiguration ahora contiene el tipo de datos alarms. Puede especificar los nombres de las alarmas, si desea utilizar el método y si desea iniciar una restauración cuando las alarmas indiquen un error de implementación. Para obtener más información, consulte CreateService en la Referencia de la API de Amazon Elastic Container Service.

• La respuesta de DescribeServices proporciona información sobre el estado de una implementación, el rolloutState y el rolloutStateReason. Cuando se inicia una nueva implementación, el estado de implementación comienza en el estado IN_PROGRESS. Cuando el servicio alcanza un estado estable y se completa el tiempo de incorporación, el estado de implementación pasa a COMPLETED. Si el servicio no alcanza un estado estable y la alarma pasa al estado ALARM, la implementación pasará al estado FAILED. Si el estado de una implementación es FAILED, no lanzará ninguna tarea nueva.

• Además de los eventos de cambio de estado de implementación del servicio que Amazon ECS envía para implementaciones que se han iniciado y completado, Amazon ECS también envía un evento cuando se produce un error con una implementación que usa alarmas. Estos eventos proporcionan detalles acerca de por qué falló una implementación o si se inició debido a una restauración. Para obtener más información, consulte Eventos de cambio de estado de implementación de servicios de Amazon ECS.

• Si se inicia una nueva implementación porque se produjo un error en una implementación anterior y se activó la restauración, el campo reason del evento de cambio de estado de implementación de servicio indicará que la implementación se inició debido a una restauración.

• Si utiliza el interruptor de implementación y las alarmas de Amazon CloudWatch para detectar errores, los dos pueden iniciar un error de implementación tan pronto como se cumplan los criterios de cualquiera de los métodos. Se produce una restauración cuando se utiliza esta opción en el método que inició el error de implementación.

• Las alarmas de Amazon CloudWatch solo son compatibles con los servicios de Amazon ECS que utilizan el controlador de implementación de actualización continua (ECS).

• Puede configurar esta opción mediante la consola de Amazon ECS o la AWS CLI. Para obtener más información, consulte Creación de un servicio a partir de los parámetros definidos y create-service en la Referencia de la AWS Command Line Interface.

• Notará que el estado de implementación permanece IN_PROGRESS durante un periodo prolongado. La razón de esto es que Amazon ECS no cambia el estado hasta que no haya eliminado la implementación activa y esto no ocurre hasta después del tiempo de incorporación. En función de la configuración de alarmas, puede parecer que la implementación tarda varios minutos más que si no se utilizan alarmas (aunque el nuevo conjunto de tareas principal escale verticalmente y la implementación anterior se reduzca verticalmente). Si usa los tiempos de espera de CloudFormation, considere aumentarlos. Para obtener más información, consulte Creación de condiciones de espera en una plantilla en la Guía del usuario de AWS CloudFormation.

• Amazon ECS llama a DescribeAlarms para sondear las alarmas. Las llamadas a DescribeAlarms contabilizarán para las cuotas de servicio de CloudWatch asociadas a su cuenta. Si tiene otros servicios de AWS que llamen a DescribeAlarms, Amazon ECS podría tener un impacto en el sondeo de las alarmas. Por ejemplo, si otro servicio hace suficientes llamadas a DescribeAlarms para alcanzar la cuota, ese servicio recibe una limitación y el de Amazon ECS también, y no puede sondear las alarmas. Si se genera una alarma durante el periodo de limitación, es posible que Amazon ECS no la detecte y que no se produzca la restauración. No hay ningún otro impacto en la implementación. Para obtener más información sobre las cuotas de servicio de CloudWatch, consulte Service Quotas de CloudWatch en la Guía del usuario de CloudWatch.

• Si hay una alarma en el estado ALARM al principio de una implementación, Amazon ECS no supervisará las alarmas mientras dure esa implementación (Amazon ECS ignora la configuración de la alarma). Este comportamiento aborda el caso en el que desee iniciar una nueva implementación para corregir un error de implementación inicial.

Alarmas recomendadas

Le recomendamos que utilice las siguientes métricas de alarma:

• Si usa un equilibrador de carga de aplicación, use las métricas de equilibrador de carga de aplicación HTTPCode_ELB_5XX_Count y HTTPCode_ELB_4XX_Count. Estas métricas comprueban si hay picos de HTTP. Para obtener más información acerca de las métricas del equilibrador de carga de aplicación, consulte Métricas de CloudWatch para su equilibrador de carga de aplicación en la Guía del usuario para equilibradores de carga de aplicaciones.

• Si ya tiene una aplicación, utilice las métricas CPUUtilization y MemoryUtilization. Estas métricas comprueban el porcentaje de CPU y memoria que utiliza el clúster o el servicio. Para obtener más información, consulte Consideraciones.

• Si usa colas de Amazon Simple Queue Service en sus tareas, utilice la métrica ApproximateNumberOfMessagesNotVisible de Amazon SQS. Esta métrica comprueba el número de mensajes de la cola que van con retraso y no están disponibles para su lectura inmediata. Para obtener más información sobre las métricas de Amazon SQS, consulte Métricas de CloudWatch disponibles para Amazon SQS en la Guía para desarrolladores de Amazon Simple Queue Service.