# 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 durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente después de que se haya transferido el tráfico de producción. Amazon ECS calcula este periodo en función de la configuración de alarma asociada a la implementación. No puede establecer este valor. + 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](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) 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](ecs_service_deployment_events.md). + 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](create-service-console-v2.md#create-custom-service) y [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) 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](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) 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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm) 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](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) 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](cloudwatch-metrics.md#enable_cloudwatch). + 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](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) en la *Guía para desarrolladores de Amazon Simple Queue Service*. ## Tiempo procesamiento Cuando utiliza la opción de reversión para las implementaciones de servicios, Amazon ECS espera un periodo adicional después de implementar la revisión del servicio de destino antes de enviar una alarma de CloudWatch. Esto se conoce como tiempo de incorporación. Este tiempo comienza después de lo siguiente: + Todas las tareas de una revisión de servicio de destino están en marcha y en buen estado + Las revisiones del servicio de origen se han reducido al 0 % El tiempo de incorporación predeterminado es inferior a 5 minutos. La implementación del servicio se marca como completada una vez transcurrido el tiempo de incorporación. Puede configurar el tiempo de incorporación de una implementación continua. Al usar las alarmas de CloudWatch para detectar un error, si cambia el tiempo de incorporación y, a continuación, decide que prefiere el valor predeterminado de Amazon ECS, debe configurar el tiempo de incorporación manualmente.