Come si utilizza HealthyHostCount di ELB per il monitoraggio in CloudWatch?

Question

Abbiamo tre istanze EC2, una in ciascuna zona di disponibilità (AZ) nella regione eu-west-1. Sono bilanciati dal carico usando ELB. Vorremmo monitorare quante istanze sono registrate al loadbalancer, usando CloudWatch. Il problema è: non capisco davvero la metrica HealthyHostCount.

Per una distribuzione, vorremmo essere in grado di annullare la registrazione di una singola istanza (estrarla dall'LB) senza essere notificata. Quindi l'allarme sarebbe: Notifica se c'è solo 1 istanza sana lasciata dietro il loadbalancer per 5 minuti.

Per quanto ho capito, HealthyHostCount (HHC) è il numero di istanze sane registrate con un dato ELB, mediato su tutte le AZ. Se tutto è a posto, l'HHC dovrebbe essere 1 (indipendentemente da quale periodo di tempo) perché c'è 1 istanza in ogni AZ.

Un paio di giorni fa, qualcuno si era schierato senza ripetere la registrazione delle istanze, quindi c'era solo 1 istanza in bilico. Quando l'abbiamo notato, abbiamo creato un allarme che doveva notificarci quando l'HHC medio è diminuito sotto 0,6 dopo 5 minuti. (Se in ELB è registrata solo 1 istanza, l'HHC dovrebbe avere una media di 0,33 per qualsiasi periodo di tempo.) Tuttavia, l'allarme non è mai cambiato in "ALLARME".

Quando ho controllato l'HHC in CloudWatch, l'HHC erano numeri che non avevano senso (somma di 10.0 per un intervallo di 5 minuti è tutto ciò che ricordo ora).

È tutto un gran casino per me. Ogni volta che penso di capire la metrica, i grafici di Cloud Watch sono per me senza senso.

Qualcuno potrebbe spiegare come utilizzare HHC per ottenere un allarme quando è registrata solo 1 istanza? L'HHC medio è la strada da percorrere o dovrei usare un'altra metrica?

Answer 1

Questa è un'area in cui la console Web CloudWatch non espone tutto ciò che può fare il cloud watch. Come spiega docs, HealthyHostCount è una metrica per area di disponibilità. La console consente di disporre di HealthHostCount in base alla zona di disponibilità (ma su tutti i bilanciatori di carico) o al bilanciamento del carico (ma su tutte le zone) ma non affetta in entrambe le direzioni.

Se si dispone di un solo bilanciatore del carico, la cosa più semplice sarebbe impostare un allarme su ciascuna delle metriche per zona. Se si dispone di più zone di disponibilità, si dovrebbe essere in grado di utilizzare l'API per creare un allarme che affetta attraverso la zona di disponibilità e il bilanciamento del carico (di nuovo, un allarme per bilanciamento del carico) ma non è possibile farlo dall'interfaccia Web per quanto riguarda I conoscere.

Answer 2

La metrica HealthyHostCount registra un valore di dati con il numero di host disponibili per ciascuna zona di disponibilità, ogni volta che viene eseguito un controllo dello stato. Il controllo dello stato ELB ha un parametro Interval che definisce quanti controlli di stato vengono eseguiti al minuto.

Se si sta guardando una metrica Per-AZ, con un controllo sanitario Interval di 10 secondi, con 2 padroni di casa sani che AZ, si vedrà 6 punti dati al minuto (60/10) con un valore pari a 2. La media , max e min saranno 2, ma la somma sarà 6*2=12.

Se si dispone di 3 AZ con 2 host ciascuna, sempre con uno Interval = 10, ma si sta osservando la metrica Per-LB, vedrete i punti di dati 3*6=18 al minuto, ciascuno con un valore di 2. Il media, max e min saranno 2, ma la somma sarà 18*2=36

Ti consiglio di impostare un valore di intervallo che può dividere 60 secondi (5, 6, 10, 15, 20, 30 o 60 secondi).

Nel tuo caso, se l'intervallo è di 30 secondi e hai 3 AZ e 1 server per AZ: dovresti aspettarti 2 punti dati per AZ al minuto, quindi impostare un allarme Per-LB, con un Period di 1 minuto, per Sum of HealthyHostCount che si attiva quando il valore è LowerOrEqual di 2 (2 data values * 1 Healthy AZ * 1 healthy server = 2, gli altri 4 valori di dati delle AZ dannose devono essere 0 in modo che non influiscano sulla somma).

UPDATE:

E turns out che il numero di controllo sanitario eseguito anche dipende dal numero di istanze interne che modella l'ELB (ussually uno per AZ), quindi se si è affetti un picco di traffico, o il carico abbastanza per saturare una singola istanza interna elb, la quantità di server interni all'interno dell'ELB crescerà e si avranno inaspettatamente più punti dati. Ciò potrebbe influire sul valore sum, solo se si ha molto traffico. Non ho visto questo problema con un picco di carico di 6k RPM distribuito in 3 AZ. Se questo è il tuo scenario, allora usare average è una scommessa più sicura, ma ti consiglio di usare LowerThan 0.65 come soglia.

I link mi fa anche chiedo come fa la funzione Cross-Zone Load Balancing influisce sulla quantità di punti dati ...