Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Supervisión de las implementaciones para su restauración automática
Durante una implementación, puede mitigar las situaciones en las que los datos de configuración incorrectos o con formato incorrecto provocan errores en la aplicación usando una combinación de estrategias de implementación y restauraciones automáticas de AWS AppConfig basadas en las alarmas de Amazon CloudWatch. Una vez configurada, si una o más alarmas de CloudWatch pasan al estado ALARM o INSUFFICIENT_DATA durante una implementación, AWS AppConfig revierte automáticamente los datos de configuración a la versión anterior, evitando así interrupciones de la aplicación o errores.
nota
Una implementación no se revierte automáticamente si las acciones se han deshabilitado en una alarma de CloudWatch asociada.
Puede desactivar y habilitar las alarmas mediante las acciones de la API DisableAlarmActions y EnableAlarmActions o los comandos disable-alarm-actions y enable-alarm-actions en la AWS CLI.
También puede restaurar una configuración llamando a la operación de la API StopDeployment mientras la implementación aún está en curso.
importante
Para las implementaciones que se completan correctamente, AWS AppConfig también admite la reversión de los datos de configuración a una versión anterior mediante el uso del parámetro AllowRevert con la operación de la API StopDeployment. Para algunos clientes, volver a una configuración anterior después de una implementación exitosa garantiza que los datos serán los mismos que antes de la implementación. La reversión también ignora la supervisión de la alarma, lo que puede impedir que se produzca una puesta al día durante una emergencia con la aplicación. Para obtener más información, consulte Cómo revertir una configuración.
Para configurar restauraciones automáticas, debe especificar el nombre de recurso de Amazon (ARN) de una o más métricas de CloudWatch en el campo Alarmas de CloudWatch al crear (o editar) un entorno de AWS AppConfig. Para obtener más información, consulte Creación de entornos para su aplicación en AWS AppConfig.
nota
Si utiliza una solución de supervisión de terceros (por ejemplo, Datadog), puede crear una extensión de AWS AppConfig que compruebe si hay alarmas en el punto de acción AT_DEPLOYMENT_TICK y, como barrera de protección, revierta la implementación si se activa una alarma. Para obtener más información acerca de las extensiones de AWS AppConfig, consulte Ampliación de AWS AppConfig los flujos de trabajo mediante extensiones. Para obtener más información acerca de las extensiones personalizadas, consulte Tutorial: Creación de extensiones personalizadas AWS AppConfig. Para ver un ejemplo de código de una extensión de AWS AppConfig que usa el punto de acción AT_DEPLOYMENT_TICK para integrarse con Datadog, consulte aws-samples/aws-appconfig-tick-extn-for-datadog
Métricas recomendadas para supervisar la restauración automática
Las métricas que elija supervisar dependerán del hardware y el software que utilicen sus aplicaciones. Los clientes de AWS AppConfig a menudo supervisan las siguientes métricas. Para obtener una lista completa de las métricas recomendadas agrupadas por Servicio de AWS, consulte Alarmas recomendadas en la Guía del usuario de Amazon CloudWatch.
Tras determinar las métricas que desea supervisar, utilice CloudWatch para configurar las alarmas. Para obtener más información, consulte Uso de las alarmas de Amazon CloudWatch.
| Servicio | Métrica | Detalles |
|---|---|---|
|
4XXError |
Esta alarma detecta una tasa elevada de errores del lado del cliente. Esto puede indicar un problema en los parámetros de autorización o de la solicitud del cliente. También, puede significar que se ha eliminado un recurso o que un cliente solicita uno que no existe. Considere la posibilidad de habilitar los Registros de Amazon CloudWatch y comprobar si hay algún error que pueda causar los errores 4XX. Además, considere la posibilidad de habilitar las métricas detalladas de CloudWatch para ver esta métrica por recurso y método y, así, reducir la búsqueda del origen de los errores. Los errores también pueden deberse a que se supera la limitación configurada. |
|
|
5XXError |
Esta alarma ayuda a detectar una alta tasa de errores del lado del servidor. Esto puede indicar que hay algún problema en el backend de la API, en la red o en la integración entre la puerta de enlace de la API y la API del backend. |
|
|
Latencia |
Esta alarma detecta una latencia elevada en una etapa. Encuentre el valor de la métrica |
|
|
GroupInServiceCapacity |
Esta alarma ayuda a detectar cuando la capacidad del grupo está por debajo de la capacidad deseada requerida para la carga de trabajo. Para solucionar el problema, compruebe si sus actividades de escalado fallaron en el lanzamiento y confirme que la configuración de capacidad deseada es la correcta. |
|
|
CPUUtilization |
Esta alarma ayuda a supervisar el uso de la CPU de una instancia de EC2. En función de la aplicación, puede que los niveles de utilización siempre altos sean normales. Pero, si se degrada el rendimiento y la aplicación no está limitada por la E/S del disco, la memoria o los recursos de red, una CPU al máximo podría indicar un cuello de botella en los recursos o problemas de rendimiento de la aplicación. |
|
|
CPUReservation |
Esta alarma le ayuda a detectar una reserva de CPU elevada en el clúster ECS. Una reserva de CPU elevada puede indicar que el clúster se está quedando sin CPU registradas para la tarea. |
|
|
HTTPCode_Target_5XX_Count |
Esta alarma ayuda a detectar un recuento elevado de errores del lado del servidor en el servicio de ECS. Esto puede indicar que hay errores que hacen que el servidor no pueda atender las solicitudes. |
|
|
node_cpu_utilization |
Esta alarma ayuda a detectar un uso elevado de la CPU en los nodos de trabajo del clúster de Amazon EKS. Si la utilización es elevada de forma constante, podría indicar la necesidad de reemplazar los nodos de trabajo por instancias que tengan mayor CPU o la necesidad de escalar horizontalmente el sistema. |
|
|
node_memory_utilization |
Esta alarma ayuda a detectar un uso elevado de la memoria en los nodos de trabajo del clúster de Amazon EKS. Si la utilización es elevada de forma constante, podría indicar la necesidad de aumentar el número de réplicas de los pods u optimizar la aplicación. |
|
|
pod_cpu_utilization_over_pod_limit |
Esta alarma ayuda a detectar un uso elevado de la CPU en los pods del clúster de Amazon EKS. Si la utilización es siempre alta, podría indicar la necesidad de aumentar el límite de la CPU del pod afectado. |
|
|
pod_memory_utilization_over_pod_limit |
Esta alarma ayuda a detectar un uso elevado de la CPU en los pods del clúster de Amazon EKS. Si la utilización es siempre alta, podría indicar la necesidad de aumentar el límite de la CPU del pod afectado. |
|
|
Errores |
Esta alarma detecta un alto número de errores. Los errores incluyen las excepciones lanzadas por el código y las excepciones lanzadas por el tiempo de ejecución de Lambda. |
|
|
Limitaciones |
Esta alarma detecta un número elevado de solicitudes de invocación limitadas. La limitación ocurre cuando no hay ninguna simultaneidad disponible para escalar verticalmente. |
|
|
memory_utilization |
Esta alarma se utiliza para detectar si la utilización de la memoria de una función de lambda se acerca al límite configurado. |
|
|
4xxErrors |
Esta alarma nos ayuda a informar del número total de códigos de estado de error 4XX que se crean en respuesta a las solicitudes de los clientes. Por ejemplo, los códigos de error 403 pueden indicar una política de IAM incorrecta y los códigos de error 404 pueden indicar un mal comportamiento de la aplicación cliente. |
|
|
5xxErrors |
Esta alarma ayuda a detectar una gran cantidad de errores por parte del servidor. Estos errores indican que un cliente realizó una solicitud que el servidor no pudo completar. Esto puede ayudarlo a correlacionar el problema al que se enfrenta su aplicación debido a S3. |
