¿Cómo uso el HealthyHostCount de ELB para monitorear en CloudWatch?

Question

Tenemos tres instancias EC2, una en cada zona de disponibilidad (AZ) en la región eu-west-1. Se equilibran según el uso de ELB. Nos gustaría controlar cuántas instancias están registradas en loadbalancer, usando CloudWatch. El problema es: realmente no entiendo la métrica HealthyHostCount.

Para una implementación, nos gustaría poder anular el registro de una sola instancia (sacarla del LB) sin que se nos notifique. Entonces, la alarma sería: Notificar si solo queda 1 instancia saludable detrás del loadbalancer durante 5 minutos.

Por lo que tengo entendido, HealthyHostCount (HHC) es la cantidad de instancias sanas que se registran con un ELB determinado, promediado en todos los AZ. Si todo está bien, el HHC debe ser 1 (sin importar en qué período de tiempo) porque hay 1 instancia en cada AZ.

Hace un par de días, alguien implementó sin volver a registrar las instancias, por lo que solo se equilibró 1 instancia. Cuando lo notamos, creamos una alarma que nos avisaba cuando el HHC promedio se hundía por debajo de 0.6 después de 5 minutos. (Si solo se registra 1 instancia en ELB, el HHC debe promediar 0.33 para cualquier período de tiempo). Sin embargo, la alarma nunca cambió para indicar "ALARMA".

Cuando revisé el HHC en CloudWatch, el HHC eran números que no tenían sentido (la suma de 10.0 para un intervalo de 5 minutos es todo lo que recuerdo ahora).

Todo es un gran desastre para mí. Cada vez que creo que entiendo la métrica, los gráficos de CloudWatch son todo un galimatías para mí.

¿Podría alguien explicar cómo usar HHC para obtener una alarma cuando solo se registra 1 instancia? ¿Es HHC promedio el camino a seguir o debería usar otra métrica?

Answer 1

Este es un área donde la consola web de CloudWatch no expone todo lo que el reloj en la nube puede hacer. Como se explica en docs, HealthyHostCount es una métrica de zona de disponibilidad. La consola le permite tener HealthHostCount por zona de disponibilidad (pero en todos los equilibradores de carga) o por balanceador de carga (pero en todas las zonas), pero no cortado en ambos sentidos.

Si solo tiene un equilibrador de carga, lo más simple sería configurar una alarma en cada una de las métricas por zona. Si tiene múltiples zonas de disponibilidad, debería poder usar la API para crear una alarma cortando la zona de disponibilidad y el equilibrador de carga (una vez más, una alarma por equilibrador de carga) pero no puede hacerlo desde la interfaz de usuario web hasta donde yo saber.

Answer 2

La métrica HealthyHostCount registra un valor de datos con el recuento de hosts disponibles para cada zona de disponibilidad, cada vez que se ejecuta una comprobación de estado. Su control de salud ELB tiene un parámetro Interval que define cuántas comprobaciones de estado se realizan por minuto.

Si está viendo una métrica Per-AZ, con un chequeo de salud Interval de 10 segundos, con 2 hosts sanos en esa AZ, verá 6 puntos de datos por minuto (60/10) con un valor de 2. La media , max y min serán 2, pero la suma será 6*2=12.

Si tiene 3 AZ con 2 hosts cada uno, de nuevo con Interval = 10, pero está viendo la métrica Per-LB, verá 3*6=18 puntos de datos por minuto, cada uno con un valor de 2. promedio, max y min será de 2, pero la suma serán 18*2=36

te recomiendo de configurar un valor de intervalo que puede dividir 60 segundos (o bien 5, 6, 10, 15, 20, 30 o 60 segundos)

En su caso, si su intervalo es de 30 segundos, y tiene 3 AZs y 1 servidor por AZ: debe esperar 2 puntos de datos por AZ por minuto, configure una alarma Per-LB con Period de 1 minuto, para Sum of HealthyHostCount que se activa cuando el valor es inferior a 2 (2 data values * 1 Healthy AZ * 1 healthy server = 2), los otros 4 valores de datos de los AZ insalubres deben ser 0 para que no afecten a la suma).

ACTUALIZACIÓN:

Se turns out que el número de comprobación de estado ejecutado también depende del número de instancias internas que da forma a la ELB (suele exhibir una por AZ), por lo que si usted está sufriendo un aumento de tráfico, o la carga suficiente para saturar una única instancia de elb-internal, la cantidad de servidores internos dentro del ELB crecerá y tendrá más puntos de datos de forma inesperada. Esto puede afectar el valor sum, solo si tiene mucho tráfico. No vi este problema con una carga máxima de 6k RPM distribuida en 3 AZ. Si este es su caso, entonces usar average es una apuesta más segura, pero le recomendaría que use LowerThan 0.65 como su umbral.

Los link también hace que me pregunte cómo funciona la prestación de Cross-Zone Load Balancing afecta a la cantidad de puntos de datos ...