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.
# Observabilidad de Multi-AZ
Para poder evacuar una zona de disponibilidad durante un evento que está aislado en una sola zona de disponibilidad, primero debe poder detectar que el error está, de hecho, aislada en una sola zona de disponibilidad. Esto requiere una visibilidad de alta fidelidad del comportamiento del sistema en cada zona de disponibilidad. Muchos AWS servicios proporcionan out-of-the-box métricas que proporcionan información operativa sobre sus recursos. Por ejemplo, Amazon EC2 proporciona numerosas métricas, como la CPU utilización, las lecturas y escrituras del disco y el tráfico de entrada y salida de la red.
Sin embargo, a medida que crea cargas de trabajo que utilizan estos servicios, necesita más visibilidad que solo esas métricas estándar. Desea tener visibilidad de la experiencia del cliente que proporciona su carga de trabajo. Además, necesita que sus métricas estén alineadas con las zonas de disponibilidad en las que se producen. Esta es la información que necesita para detectar los errores grises que se pueden observar de forma diferencial. Este nivel de visibilidad requiere una instrumentación.
La instrumentación requiere escribir código explícito. Este código debería realizar acciones como registrar la duración de las tareas, contar cuántos elementos se han ejecutado correctamente o no, recopilar metadatos sobre las solicitudes, etc. También es necesario definir los umbrales con antelación para definir qué se considera normal y qué no. Debe describir los objetivos y los diferentes umbrales de gravedad para la latencia, la disponibilidad y el recuento de errores de la carga de trabajo. El artículo de Amazon Builders’ Library sobre la [Instrumentación de sistemas distribuidos para la visibilidad operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) proporciona una serie de prácticas recomendadas.
Las métricas deben generarse tanto en el lado del servidor como en el lado del cliente. Una práctica recomendada para generar métricas del lado del cliente y comprender su experiencia es utilizar [valores controlados](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), un software que analiza periódicamente la carga de trabajo y registra las métricas.
Además de generar estas métricas, también es necesario comprender su contexto. Una forma de hacerlo consiste en utilizar [dimensiones](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension). Las dimensiones dan a las métricas una identidad única y ayudan a explicar lo que indican las métricas. En el caso de las métricas que se utilizan para identificar errores en la carga de trabajo (por ejemplo, la latencia, la disponibilidad o el recuento de errores), debe utilizar dimensiones que se ajusten a los [límites de aislamiento de errores](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html).
Por ejemplo, si ejecuta un servicio web en una región, en varias zonas de disponibilidad y utiliza un marco web [M odel-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC), debe utilizar, `Region` [https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)`Controller``Action`, y `InstanceId` como dimensiones para sus conjuntos de dimensiones (si utilizara microservicios, podría utilizar el nombre y el HTTP método del servicio en lugar de los nombres del controlador y de la acción). Esto es así porque se espera que estos límites aíslen los distintos tipos de errores. No se espera que un error en el código del servicio web que afecta a su capacidad de enumerar productos también afecte a la página de inicio. Del mismo modo, no esperaría que un EBS volumen completo en una sola EC2 instancia afectara a otras EC2 instancias a la hora de publicar su contenido web. La dimensión del ID de zona de disponibilidad es lo que le permite identificar los impactos relacionados con la zona de disponibilidad de forma coherente en todas las Cuentas de AWS. Puede encontrar el ID de zona de disponibilidad en sus cargas de trabajo de varias maneras. Consulte [Apéndice A: Obtener el ID de la zona de disponibilidad](appendix-a-getting-the-availability-zone-id.md) para ver algunos ejemplos.
Si bien este documento utiliza principalmente Amazon EC2 como recurso informático en los ejemplos, `InstanceId` podría sustituirse por un ID de contenedor para los recursos informáticos de [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AmazonECS) y [Amazon Elastic Kubernetes](https://aws.amazon.com/eks/) Service (EKSAmazon) como componentes de sus dimensiones.
Sus valores controlados también pueden usar `Controller`, `Action`, `AZ-ID` y `Region` como dimensiones en sus métricas si tiene puntos de conexión zonales para su carga de trabajo. En este caso, alinee sus valores controlados para que se ejecuten en la zona de disponibilidad que estén probando. Esto garantiza que si un evento aislado de la zona de disponibilidad afecta a la zona de disponibilidad donde se ejecuta su valor controlado, no registra las métricas que hacen que una zona de disponibilidad diferente que esté probando parezca tener un estado incorrecto. [Por ejemplo, Canary puede probar cada punto final zonal para detectar un servicio detrás de un Network Load Balancer NLB () o Application Load ALB Balancer () utilizando sus nombres zonales. DNS](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#dns-name)
![\[Diagrama que muestra un canario corriendo con CloudWatch Synthetics o una AWS Lambda función que prueba cada punto final zonal de un NLB\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/canary-testing-for-zonal-impact.png)
Al generar métricas con estas dimensiones, puede establecer [ CloudWatch alarmas de Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) que le notifiquen cuando se produzcan cambios en la disponibilidad o la latencia dentro de esos límites. También puede analizar rápidamente esos datos mediante [paneles](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). Para utilizar las métricas y los registros de forma eficiente, Amazon CloudWatch ofrece el [formato de métrica integrado](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) (EMF) que te permite integrar métricas personalizadas en los datos de registro. CloudWatchextrae automáticamente las métricas personalizadas para que puedas visualizarlas y alarmarlas. AWS proporciona varias [bibliotecas de clientes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) para diferentes lenguajes de programación que facilitan su inicioEMF. Se pueden usar con AmazonEC2, Amazon ECS EKS [AWS Lambda](https://aws.amazon.com/lambda/), Amazon y entornos locales. Con las métricas integradas en sus registros, también puede usar [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) para crear gráficos de series temporales que muestren los datos de los colaboradores. En este escenario, podemos mostrar los datos agrupados por dimensiones como `AZ-ID`, `InstanceId` o `Controller`, así como cualquier otro campo del registro, como `SuccessLatency` o `HttpResponseCode`.
```
{
"_aws": {
"Timestamp": 1634319245221,
"CloudWatchMetrics": [
{
"Namespace": "workloadname/frontend",
"Metrics": [
{ "Name": "2xx", "Unit": "Count" },
{ "Name": "3xx", "Unit": "Count" },
{ "Name": "4xx", "Unit": "Count" },
{ "Name": "5xx", "Unit": "Count" },
{ "Name": "SuccessLatency", "Unit": "Milliseconds" }
],
"Dimensions": [
[ "Controller", "Action", "Region", "AZ-ID", "InstanceId"],
[ "Controller", "Action", "Region", "AZ-ID"],
[ "Controller", "Action", "Region"]
]
}
],
"LogGroupName": "/loggroupname"
},
"CacheRefresh": false,
"Host": "use1-az2-name.example.com",
"SourceIp": "34.230.82.196",
"TraceId": "|e3628548-42e164ee4d1379bf.",
"Path": "/home",
"OneBox": false,
"Controller": "Home",
"Action": "Index",
"Region": "us-east-1",
"AZ-ID": "use1-az2",
"InstanceId": "i-01ab0b7241214d494",
"LogGroupName": "/loggroupname",
"HttpResponseCode": 200,
"2xx": 1,
"3xx": 0,
"4xx": 0,
"5xx": 0,
"SuccessLatency": 20
}
```
Este registro tiene tres conjuntos de dimensiones. Progresan en orden de granularidad, desde la Instancia a la Zona de disponibilidad y a la Región (`Controller` y `Action` siempre se incluyen en este ejemplo). Permiten crear alarmas en toda la carga de trabajo que indican cuándo hay un impacto en una determinada acción del controlador en una instancia individual, en una zona de disponibilidad individual o en toda la Región de AWS. Estas dimensiones se utilizan para el recuento de las métricas de HTTP respuesta de 2xx, 3xx, 4xx y 5xx, así como para la latencia de las métricas de solicitudes correctas (si la solicitud fallara, también registraría una métrica para la latencia de las solicitudes fallidas). El registro también registra otra información, como la HTTP ruta, la IP de origen del solicitante y si esta solicitud requirió la actualización de la caché local. Luego, estos puntos de datos se pueden usar para calcular la disponibilidad y la latencia de cada una de las cargas de trabajo proporcionadasAPI.
**Nota sobre el uso de códigos de HTTP respuesta para las métricas de disponibilidad**
Por lo general, puede considerar que las respuestas 2xx y 3xx son correctas y las respuestas 5xx son fallidas. Los códigos de respuesta 4xx se encuentran en un punto intermedio. Por lo general, se producen debido a un error del cliente. Puede que un parámetro esté fuera del rango y provoque una [respuesta 400](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes), o que estén solicitando algo que no existe, lo que provoca una respuesta 404. Estas respuestas no deben contar para la disponibilidad de su carga de trabajo. Sin embargo, esto también puede deberse a un error en el software.
Por ejemplo, si ha introducido una validación de entradas más estricta que rechaza una solicitud que anteriormente hubiera sido correcta, la respuesta 400 puede considerarse una disminución de la disponibilidad. O tal vez está limitando el número de peticiones del cliente, lo que devuelve una respuesta 429. Si bien limitar un cliente protege el servicio para mantener la disponibilidad, desde la perspectiva del cliente, el servicio no está disponible para procesar su solicitud. Deberá decidir si los códigos de respuesta 4xx forman parte o no de su cálculo de disponibilidad.
Si bien en esta sección se describe su uso CloudWatch como una forma de recopilar y analizar métricas, no es la única solución que puede utilizar. También puede enviar las métricas a Amazon Managed Service para Prometheus y Amazon Managed Grafana, a una tabla de Amazon DynamoDB, o utilizar una solución de supervisión de terceros. La clave es que las métricas que genere su carga de trabajo deben contener un contexto sobre los límites de aislamiento de errores de la carga de trabajo.
Con cargas de trabajo que generan métricas con dimensiones alineadas con los límites del aislamiento de errores, puede crear una observabilidad que detecte los errores aislados de las zonas de disponibilidad. En las siguientes secciones, se describen tres enfoques complementarios para detectar los errores que se derivan del deterioro de una única zona de disponibilidad.
**Topics**
+ [Detección de fallos con alarmas CloudWatch compuestas](failure-detection-with-cloudwatch-composite-alarms.md)
+ [Detección de errores utilizando la detección de valores atípicos](failure-detection-using-outlier-detection.md)
+ [Detección de errores de recursos zonales de una sola instancia](failure-detection-of-single-instance-zonal-resources.md)
+ [Resumen](summary.md)
# Detección de fallos con alarmas CloudWatch compuestas
En CloudWatch las métricas, cada conjunto de dimensiones es una métrica única y puede crear una CloudWatch alarma en cada una de ellas. A continuación, puede crear [alarmas CloudWatch compuestas de Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) para agregar estas métricas.
Para detectar con precisión el impacto, los ejemplos de este documento utilizarán dos estructuras de CloudWatch alarma diferentes para cada dimensión activada en la que se active la alarma. Cada alarma utilizará un **período** de un minuto, lo que significa que la métrica se evalúa una vez por minuto. El primer enfoque consiste en utilizar tres puntos de datos de infracción consecutivos estableciendo los **Períodos de evaluación** y los **Puntos de datos para la alarma** en tres, lo que supone un impacto de tres minutos en total. El segundo enfoque consiste en utilizar “M de N” cuando se produzca una infracción de tres puntos de datos en un intervalo de cinco minutos, estableciendo los **Períodos de evaluación** en cinco y los **Puntos de datos para la alarma** en tres. Esto permite detectar una señal constante, así como una que fluctúe en un breve período de tiempo. Las duraciones de tiempo y los números de puntos de datos que se incluyen aquí son una sugerencia. Utilice valores que se adapten a sus cargas de trabajo.
## Detectar el impacto en una sola zona de disponibilidad
Con este constructo, supongamos una carga de trabajo que utiliza `Controller`, `Action`, `InstanceId`, `AZ-ID` y `Region` como dimensiones. La carga de trabajo tiene dos controladores, Products y Home, y una acción por controlador, List e Index, respectivamente. Opera en tres zonas de disponibilidad de la región `us-east-1`. Deberá crear dos alarmas de disponibilidad para cada combinación de `Controller` y `Action` en cada zona de disponibilidad, así como dos alarmas de latencia para cada una. A continuación, si lo desea, puede crear una alarma compuesta de disponibilidad para cada combinación de `Controller` y `Action`. Por último, debe crear una alarma compuesta que agrupe todas las alarmas de disponibilidad de la zona de disponibilidad. Esto se muestra en la siguiente figura para una sola zona de disponibilidad, `use1-az1`, utilizando la alarma compuesta opcional para cada combinación de `Controller` y `Action` (también hay alarmas similares para las zonas de disponibilidad `use1-az2` y `use1-az3`, pero no se muestran por motivos de simplicidad).
![\[Diagrama que muestra una estructura de alarma compuesta de disponibilidad en use1-az1\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-availability.png)
También debe crear una estructura de alarma similar para la latencia, como se muestra en la siguiente figura.
![\[Diagrama que muestra una estructura de alarma compuesta de latencia en use1-az1\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-latency.png)
Para el resto de las figuras de esta sección, solo se mostrarán las alarmas compuestas `az1-availability` y `az1-latency` en el nivel superior. Estas alarmas compuestas `az1-availability` y `az1-latency` indicarán si la disponibilidad cae por debajo de los umbrales definidos o si la latencia supera los umbrales definidos en una determinada zona de disponibilidad para cualquier parte de su carga de trabajo. También puede considerar la posibilidad de medir el rendimiento para detectar un impacto que impida que su carga de trabajo en una sola zona de disponibilidad reciba trabajo. También puede integrar las alarmas generadas a partir de las métricas emitidas por los valores controlados en estas alarmas compuestas. De esta forma, si el lado del servidor o el lado del cliente ve un impacto en la disponibilidad o la latencia, la alarma generará una alerta.
## Asegurarse de que el impacto no sea regional
Se puede usar otro conjunto de alarmas compuestas para garantizar que solo un evento aislado de la zona de disponibilidad provoque la activación de la alarma. Para ello, debe asegurarse de que la alarma compuesta de la zona de disponibilidad tenga un estado `ALARM`, mientras que las alarmas compuestas de las demás zonas de disponibilidad tienen el estado `OK`. Esto generará una alarma compuesta por cada zona de disponibilidad que utilice. En la siguiente figura, se muestra un ejemplo (recuerde que hay alarmas de latencia y disponibilidad en `use1-az2` y `use1-az3`, `az2-latency`, `az2-availability`, `az3-latency` y `az3-availability`, que no se muestran por motivos de simplicidad).
![\[Un diagrama que muestra una estructura de alarma compuesta para detectar un impacto aislado en una única zona de disponibilidad\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-impact.png)
## Asegurarse de que el impacto no se deba a una sola instancia
Una sola instancia (o un pequeño porcentaje de su flota total) puede tener un impacto desproporcionado en las métricas de disponibilidad y latencia, lo que puede hacer que toda la zona de disponibilidad parezca estar afectada, cuando en realidad no es así. Eliminar una sola instancia problemática es más rápido e igual de eficaz que evacuar una zona de disponibilidad.
Por lo general, las instancias y los contenedores se tratan como recursos efímeros y, con frecuencia, se sustituyen por servicios como [AWS Auto Scaling](https://aws.amazon.com/autoscaling/). Es difícil crear una nueva CloudWatch alarma cada vez que se crea una nueva instancia (pero sin duda es posible con los [ganchos de ciclo de vida de [Amazon EventBridge](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)). En su lugar, puedes usar [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) para identificar la cantidad de contribuyentes a las métricas de disponibilidad y latencia.
Por ejemplo, en el caso de una aplicación HTTP web, puede crear una regla para identificar a los principales contribuyentes de cinco veces HTTP las respuestas en cada zona de disponibilidad. Esto identificará qué instancias están contribuyendo a una disminución de la disponibilidad (nuestra métrica de disponibilidad definida anteriormente se basa en la presencia de errores 5xx). Con el ejemplo del EMF registro, cree una regla con una clave de`InstanceId`. A continuación, filtre el registro por el campo `HttpResponseCode`. Este ejemplo es una regla para la zona de disponibilidad de `use1-az1`.
```
{
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.InstanceId",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"GreaterThan": 499
},
{
"Match": "$.HttpStatusCode",
"LessThan": 600
},
{
"Match": "$.AZ-ID",
"In": ["use1-az1"]
},
],
"Keys": [
"$.InstanceId"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
"/loggroupname"
],
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
}
}
```
CloudWatch También se pueden crear alarmas en función de estas reglas. Puede crear alarmas en función de las reglas de Contributor Insights utilizando la [matemática de métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) y la función `INSIGHT_RULE_METRIC` con la métrica `UniqueContributors`. También puedes crear reglas adicionales de Contributor Insights con CloudWatch alarmas para métricas como la latencia o el recuento de errores, además de otras relacionadas con la disponibilidad. Estas alarmas se pueden usar con las alarmas compuestas de impacto en la zona de disponibilidad aislada para garantizar que las instancias individuales no activen la alarma. La métrica de la regla de Insights para `use1-az1` será parecida a la siguiente:
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
Puede definir una alarma cuando esta métrica supere un umbral; en este ejemplo, dos. Se activa cuando los colaboradores únicos a las respuestas 5xx superan ese umbral, lo que indica que el impacto se origina en más de dos instancias. La razón por la que esta alarma utiliza una comparación “mayor que” en lugar de “menor que” es garantizar que un valor cero para los colaboradores únicos no active la alarma. Esto indica que el impacto *no* proviene de una sola instancia. Ajuste este umbral para su carga de trabajo individual. Una regla general es que este número sea un 5 % o más del total de recursos de la zona de disponibilidad. Si el tamaño de la muestra es suficiente, más del 5 % de los recursos afectados tiene relevancia estadística.
## Resumen global
La siguiente figura muestra la estructura de alarma compuesta completa para una única zona de disponibilidad:
![\[Un diagrama que muestra una estructura de alarma compuesta completa para determinar el impacto en una zona de disponibilidad única\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-complete.png)
La última alarma compuesta, `use1-az1-isolated-impact`, se activa cuando la alarma compuesta que indica un impacto aislado en la zona de disponibilidad debido a la latencia o la disponibilidad, `use1-az1-aggregate-alarm`, tiene un estado `ALARM`, y cuando la alarma basada en la regla de Contributor Insights para la misma zona de disponibilidad, `not-single-instance-use1-az1`, también tiene un estado `ALARM` (lo que significa que el impacto se produce en más de una sola instancia). Debe crear esta pila de alarmas para cada zona de disponibilidad que utilice la carga de trabajo.
Puedes adjuntar una alerta de [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (AmazonSNS) a esta última alarma. Todas las alarmas anteriores se configuran sin necesidad de realizar ninguna acción. La alerta puede notificar a un operador por correo electrónico que inicie una investigación manual. También puede iniciar la automatización para evacuar la zona de disponibilidad. No obstante, hay que tener cuidado al crear la automatización para responder a estas alertas. Tras la evacuación de una zona de disponibilidad, el resultado debería ser que se mitigue el aumento de las tasas de error y que la alarma vuelva a su estado `OK`. Si el impacto se produce en otra zona de disponibilidad, es posible que la automatización pueda evacuar una segunda o tercera zona de disponibilidad, lo que podría eliminar toda la capacidad disponible de la carga de trabajo. La automatización debe comprobar si ya se ha realizado una evacuación antes de tomar ninguna medida. Es posible que también deba escalar los recursos en otras zonas de disponibilidad para que la evacuación se lleve a cabo correctamente.
Cuando agrega nuevos controladores o acciones a su aplicación MVC web, o un nuevo microservicio o, en general, cualquier funcionalidad adicional que desee monitorear por separado, solo necesita modificar algunas alarmas en esta configuración. Deberá crear nuevas alarmas de disponibilidad y latencia para la nueva funcionalidad y, a continuación, las añadirá a las alarmas compuestas de disponibilidad y latencia alineadas con la zona de disponibilidad correspondiente, `az1-latency` y `az1-availability` en el ejemplo que hemos estado usando aquí. Las alarmas compuestas restantes permanecen estáticas una vez configuradas. Esto permite que la incorporación de nuevas funcionalidades con este enfoque sea un proceso muy sencillo.
# Detección de errores utilizando la detección de valores atípicos
Con el enfoque anterior, puede surgir una brecha si se observan tasas de errores elevadas en varias zonas de disponibilidad por un motivo *no correlacionado*. Imagine un escenario en el que tiene EC2 instancias implementadas en tres zonas de disponibilidad y su umbral de alarma de disponibilidad es del 99%. En él, se produce un deterioro en una sola zona de disponibilidad, lo que aísla muchas instancias y hace que la disponibilidad en esa zona disminuya al 55 %. Al mismo tiempo, pero en una zona de disponibilidad diferente, una sola EC2 instancia agota todo el almacenamiento de su EBS volumen y ya no puede escribir archivos de registro. Esto hace que comience a generar errores, pero aun así supera las comprobaciones de estado del equilibrador de carga, ya que estas no activan la escritura de un archivo de registro. Esto hace que la disponibilidad disminuya al 98 % en esa zona de disponibilidad. En este caso, la alarma de impacto en una única zona de disponibilidad no se activará, porque está viendo un impacto en la disponibilidad en varias zonas de disponibilidad. Sin embargo, aún podría mitigar casi todo el impacto evacuando la zona de disponibilidad deteriorada.
En algunos tipos de cargas de trabajo, es posible que se produzcan errores de forma uniforme en todas las zonas de disponibilidad, donde la métrica de disponibilidad anterior podría no ser útil. Tomemos, AWS Lambda por ejemplo. AWS permite a los clientes crear su propio código para ejecutarlo en la función Lambda. Para utilizar el servicio, debe cargar el código en un ZIP archivo, incluidas las dependencias, y definir el punto de entrada a la función. Sin embargo, a veces los clientes se equivocan en esta parte; por ejemplo, pueden olvidar una dependencia crítica en el ZIP archivo o escribir mal el nombre del método en la definición de la función Lambda. Esto provoca que no se pueda invocar la función y se produce un error. AWS Lambda ve este tipo de errores todo el tiempo, pero no son indicativos de que algo esté necesariamente en mal estado. Sin embargo, un deterioro de la zona de disponibilidad también puede provocar la aparición de estos errores.
Para detectar señales en este tipo de ruido, puede utilizar la detección de valores atípicos para determinar si existe un sesgo estadísticamente relevante en el número de errores entre las zonas de disponibilidad. Aunque veamos errores en varias zonas de disponibilidad, si realmente se hubiera producido un error en una de ellas, esperaríamos ver una tasa de errores mucho mayor en esa zona de disponibilidad en comparación con las demás, o posiblemente mucho más baja. Pero, ¿cuánto mayor o cuánto menor?
Una forma de realizar este análisis consiste en utilizar una prueba de [chi cuadrado](https://en.wikipedia.org/wiki/Chi-squared_test) (*χ*2) para detectar diferencias estadísticamente relevantes en las tasas de errores entre las distintas zonas de disponibilidad (hay [muchos algoritmos diferentes para detectar valores atípicos](https://dataprocessing.aixcape.org/DataPreprocessing/DataCleaning/OutlierDetection/index.html)). Veamos cómo funciona la prueba de chi cuadrado.
La prueba de chi cuadrado evalúa la probabilidad de que se produzca alguna distribución de los resultados. En este caso, nos interesa la distribución de los errores en un conjunto definido deAZs. En este ejemplo, para facilitar las matemáticas, supongamos cuatro zonas de disponibilidad.
En primer lugar, establezca la *hipótesis nula*, que define cuál cree que es el resultado predeterminado. En esta prueba, la hipótesis nula es que se espera que los errores estén distribuidos uniformemente en cada zona de disponibilidad. A continuación, genere la *hipótesis alternativa*, según la cual los errores no se distribuyen uniformemente, lo que indica que la zona de disponibilidad se ha deteriorado. Ahora puede probar estas hipótesis con los datos de sus métricas. Para ello, muestreará sus métricas en un período de cinco minutos. Supongamos que obtiene 1000 puntos de datos publicados en esa ventana, en la que ve un total de 100 errores. Es de esperar que, con una distribución uniforme, los errores se produzcan el 25 % del tiempo en cada una de las cuatro zonas de disponibilidad. Supongamos que la siguiente tabla muestra lo que esperaba comparado con lo que observa realmente.
*Tabla 1: Los errores esperados comparados con los errores reales observados*
| AZ | Expected | Real |
| --- | --- | --- |
| use1-az1 | 25 | 20 |
| use1-az2 | 25 | 20 |
| use1-az3 | 25 | 25 |
| use1-az4 | 25 | 35 |
Como puede ver, la distribución en realidad no es uniforme. Sin embargo, puede pensar que esto ha ocurrido debido a un cierto nivel de aleatoriedad en los puntos de datos que ha muestreado. Hay un cierto nivel de probabilidad de que este tipo de distribución se produzca en el conjunto de la muestra y aun así suponer que la hipótesis nula es cierta. Esto nos lleva a la siguiente pregunta: ¿cuál es la probabilidad de obtener un resultado tan extremo como mínimo? Si esa probabilidad está por debajo de un umbral definido, debe rechazar la hipótesis nula. Para que sea [https://en.wikipedia.org/wiki/Statistical_significance](https://en.wikipedia.org/wiki/Statistical_significance), esta probabilidad debe ser del 5 % o menos1.
1 Craparo, Robert M. (2007). “Significance level”. En Salkind, Neil J. Encyclopedia of Measurement and Statistics 3. Thousand Oaks, CA: SAGE Publicaciones. págs. 889—891. ISBN1-412-91611-9.
¿Cómo se calcula la probabilidad de este resultado? Utilice la estadística *χ2*, que proporciona distribuciones muy estudiadas y permite determinar la probabilidad de obtener un resultado así de extremo o más con esta fórmula.
![\[Fórmulas para Ei, Oi y X2\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas1.png)
En nuestro ejemplo, esto da como resultado:
![\[Fórmulas para Ei, Oi y X2 usando nuestro ejemplo, que dan como resultado una respuesta de 6.\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas2.png)
Entonces, ¿qué significa `6` en términos de nuestra probabilidad? Es necesario observar una distribución de chi cuadrado con el grado de libertad adecuado. En la siguiente figura, se muestran varias distribuciones de chi cuadrado para distintos grados de libertad.
![\[Gráfica que muestra las distribuciones de chi cuadrado para diferentes grados de libertad\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/chi-squared-distributions.png)
El grado de libertad se calcula como un valor menos que el número de opciones de la prueba. En este caso, dado que hay cuatro zonas de disponibilidad, el grado de libertad es tres. A continuación, querrá saber el área bajo la curva (la integral) de *x ≥ 6* en el gráfico *k = 3*. También puede usar una tabla precalculada con valores de uso común para aproximar ese valor.
*Tabla 2: Valores críticos de chi cuadrado*
| Grados de libertad | Probabilidad inferior al valor crítico | | **0.75** | **0.90** | **0,95** | **0,99** | **0,999** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 1.323 | 2.706 | 3.841 | 6.635 | 10,828 |
| 2 | 2.773 | 4,605 | 5.991 | 9.210 | 13,816 |
| 3 | 4.108 | 6.251 | 7,815 | 11,345 | 16.266 |
| 4 | 5.385 | 7,779 | 9,488 | 13.277 | 18.467 |
Para tres grados de libertad, el valor de chi cuadrado de seis se encuentra entre las columnas de probabilidad de 0,75 y 0,9. Esto significa que hay una probabilidad superior al 10 % de que se produzca esta distribución, lo que no es inferior al umbral del 5 %. Por lo tanto, acepta la *hipótesis nula* y determina que *no* hay una diferencia estadísticamente relevante en las tasas de errores entre las zonas de disponibilidad.
Las matemáticas CloudWatch métricas no admiten de forma nativa la realización de una prueba estadística con chi-cuadrado, por lo que tendrá que recopilar las métricas de error aplicables CloudWatch y ejecutar la prueba en un entorno informático como Lambda. Puedes decidir realizar esta prueba a nivel de MVC controlador/acción o microservicio individual, o bien a nivel de zona de disponibilidad. Deberá tener en cuenta si un deterioro de la zona de disponibilidad afectaría a cada controlador/acción o microservicio por igual, o si algo como un DNS fallo podría afectar a un servicio de bajo rendimiento y no a uno de alto rendimiento, lo que podría enmascarar el impacto al agregarse. En cualquier caso, seleccione las dimensiones adecuadas para crear la consulta. El nivel de granularidad también afectará a las alarmas resultantes que cree. CloudWatch
Recopile la métrica de recuento de errores para cada zona de disponibilidad y controlador/acción en un período de tiempo específico. Primero, calcule el resultado de la prueba de chi cuadrado como true (ha habido un sesgo estadísticamente relevante) o false (no lo ha habido, es decir, la hipótesis nula es válida). Si el resultado es false, publique un punto de datos 0 en su flujo de métricas para obtener resultados de chi cuadrado para cada zona de disponibilidad. Si el resultado es true, publique un punto de datos 1 para la zona de disponibilidad con los errores más alejados del valor esperado y 0 para los demás (consulte [Apéndice B: Ejemplo de cálculo con chi cuadrado](appendix-b-example-chi-squared-calculation.md) para ver el código de ejemplo que se puede utilizar en una función de Lambda). Puede seguir el mismo enfoque que las alarmas de disponibilidad anteriores mediante la creación de una alarma CloudWatch métrica de 3 filas y una alarma métrica de 3 de cada 5 CloudWatch en función de los puntos de datos que produce la función Lambda. Como en los ejemplos anteriores, este enfoque se puede modificar para utilizar más o menos puntos de datos en un intervalo más corto o más largo.
A continuación, añada estas alarmas a la alarma de disponibilidad de la zona de disponibilidad existente para la combinación de controlador y acción, como se muestra en la siguiente figura.
![\[Diagrama que muestra la integración de la prueba estadística de chi cuadrado con alarmas compuestas\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/statistics-test-with-composite-alarms.png)
Como se mencionó anteriormente, al incorporar una nueva funcionalidad a su carga de trabajo, solo necesita crear las alarmas CloudWatch métricas adecuadas que sean específicas de esa nueva funcionalidad y actualizar el siguiente nivel de la jerarquía compuesta de alarmas para incluir esas alarmas. El resto de la estructura de alarmas permanece estático.
# Detección de errores de recursos zonales de una sola instancia
En algunos casos, es posible que tenga una única instancia activa de un recurso zonal, generalmente sistemas que requieren un componente de escritura única, como una base de datos relacional (como AmazonRDS) o una caché distribuida (como [Amazon ElastiCache (OSSRedis](https://aws.amazon.com/elasticache/redis/))). Si el deterioro de una sola zona de disponibilidad afecta a la zona de disponibilidad en la que se encuentra el recurso principal, puede afectar a todas las zonas de disponibilidad que acceden al recurso. Esto podría hacer que se superaran los umbrales de disponibilidad en todas las zonas de disponibilidad, lo que implicará que el primer enfoque no identifica correctamente la única fuente de impacto de la zona de disponibilidad. Además, es probable que vea tasas de errores similares en cada zona de disponibilidad, lo que significa que el análisis de valores atípicos tampoco detecta el problema. Esto significa que necesita implementar una observabilidad adicional para detectar específicamente este escenario.
Es probable que el recurso que le preocupa genere sus propias métricas sobre su estado, pero si se produce un deterioro de la zona de disponibilidad, es posible que ese recurso no pueda ofrecer dichas métricas. En este caso, debe crear o actualizar alarmas para saber si está *yendo a ciegas*. Si hay métricas importantes que ya supervisa y para las que ha activado la alarma, puede configurar la alarma para que considere los [datos que faltan](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) como una infracción. Esto le permitirá saber si el recurso deja de notificar datos, y se puede incluir en las mismas alarmas *seguidas* y *m de n* utilizadas anteriormente.
También es posible que en algunas de las métricas que indican el estado del recurso se publique un dato con un valor cero cuando no haya ninguna actividad. Si el deterioro impide las interacciones con el recurso, no puede utilizar el enfoque de los datos que faltan para este tipo de métricas. Probablemente tampoco desee crear una alarma cuando el valor sea cero, ya que podría haber escenarios legítimos en los que esto entre dentro de los umbrales normales. El mejor enfoque para detectar este tipo de problema consiste en generar métricas a partir de los recursos que utilizan esta dependencia. En este caso, queremos detectar el impacto en *varias* zonas de disponibilidad utilizando alarmas compuestas. Estas alarmas deben utilizar varias categorías de métricas críticas relacionadas con el recurso. A continuación, se muestran algunos ejemplos:
+ **Rendimiento**: la tasa de unidades de trabajo entrantes. Pueden ser transacciones, lecturas, escrituras, etc.
+ **Disponibilidad**: mide la cantidad de unidades de trabajo con éxito y erróneas.
+ **Latencia**: mide varios percentiles de latencia para ver que el trabajo realizado con éxito en las operaciones críticas.
Una vez más, puede crear alarmas de métricas *seguidas* y *m de n* para cada métrica de cada categoría de métrica que desee medir. Como antes, se pueden combinar en una alarma compuesta para determinar si este recurso compartido es la fuente del impacto en varias zonas de disponibilidad. Desea poder identificar el impacto en más de una zona de disponibilidad con las alarmas compuestas, pero no un requisito que el impacto se produzca necesariamente en *todas* las zonas de disponibilidad. La estructura de alarma compuesta de alto nivel para este tipo de enfoque se muestra en la siguiente figura.
![\[Diagrama que muestra un ejemplo de creación de alarmas para detectar el impacto en varias zonas de disponibilidad debido a un solo recurso\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)
Observará que este diagrama es menos prescriptivo sobre el tipo de alarmas de métricas que se deben utilizar y la jerarquía de las alarmas compuestas. Esto se debe a que descubrir este tipo de problema puede resultar difícil y requerirá una especial atención a las señales correctas del recurso compartido. Es posible que esas señales también deban evaluarse de manera específica.
Además, debe tener en cuenta que la alarma `primary-database-impact` no está asociada a una zona de disponibilidad específica. Esto se debe a que la instancia de base de datos principal puede estar ubicada en cualquier zona de disponibilidad que esté configurada para usar y no hay una CloudWatch métrica que especifique dónde se encuentra. Cuando vea que se activa esta alarma, debe utilizarla como una señal de que puede haber un problema con el recurso e iniciar una conmutación por error a otra zona de disponibilidad, si no se ha realizado automáticamente. Después de mover el recurso a otra zona de disponibilidad, puede esperar y comprobar si la alarma de zona de disponibilidad aislada está activada, o bien optar por invocar de forma preventiva su plan de evacuación de la zona de disponibilidad.
# Resumen
En esta sección, se describen tres enfoques para identificar los deterioros en una sola zona de disponibilidad. Cada enfoque debe usarse en conjunto para proporcionar una visión holística del estado de su carga de trabajo.
El enfoque de alarma CloudWatch compuesta permite detectar problemas en los que el sesgo en la disponibilidad no es significativo desde el punto de vista estadístico, por ejemplo, con una disponibilidad del 98% (la zona de disponibilidad afectada), del 100% y del 99,99%, que no se debe a un único recurso compartido.
La detección de valores atípicos permitirá detectar los deterioros de una sola zona de disponibilidad donde se produzcan errores no correlacionados en varias zonas de disponibilidad que superen el umbral de alarma.
Por último, identificar la degradación de un recurso zonal de una sola instancia permite descubrir cuándo un deterioro de la zona de disponibilidad afecta a un recurso que se comparte entre varias zonas de disponibilidad.
Las alarmas resultantes de cada uno de estos patrones se pueden combinar en una jerarquía de alarmas CloudWatch compuesta para detectar cuándo se producen deficiencias en una sola zona de disponibilidad que afectan a la disponibilidad o la latencia de la carga de trabajo.