Allarmi CloudWatch e allarmi compositi

Un allarme CloudWatch monitora una singola metrica o il risultato di un'espressione di matematica delle metriche per un intervallo di tempo specificato. Quando la metrica supera una soglia definita, l'allarme cambia stato e può automaticamente attivare un'azione, ad esempio inviare una notifica SNS, dimensionare un gruppo Auto Scaling, arrestare un'istanza EC2 o eseguire un OpsItem di Systems Manager. Gli allarmi sono il principale meccanismo per la risposta operativa automatizzata in AWS.

Un allarme CloudWatch si trova sempre in uno dei tre stati seguenti: OK — la metrica rientra nella soglia definita; ALARM — la metrica ha superato la soglia per il numero di periodi di valutazione richiesto; INSUFFICIENT_DATA — l'allarme è stato appena creato, la metrica non è disponibile oppure non sono ancora stati raccolti dati sufficienti. Le transizioni tra gli stati attivano le azioni configurate per quel cambiamento di stato — è possibile avere argomenti SNS diversi per gli stati OK, ALARM e INSUFFICIENT_DATA.

Quando crea un allarme, specifica: la metrica e lo spazio dei nomi, la statistica (Average, Sum, Maximum e così via), il periodo (la frequenza di valutazione della metrica, in secondi), i periodi di valutazione (il numero di periodi consecutivi che devono superare la soglia), il valore di soglia e l'operatore di confronto. L'allarme si attiva quando la metrica supera la soglia per il numero specificato di periodi di valutazione consecutivi.

Le azioni degli allarmi possono indirizzare diverse destinazioni: argomenti Amazon SNS (per inviare e-mail o SMS oppure attivare Lambda), policy Auto Scaling (per aumentare o ridurre le dimensioni di un ASG) e azioni EC2 (per arrestare, terminare, riavviare o ripristinare un'istanza EC2). Per ogni stato (OK, ALARM, INSUFFICIENT_DATA) è possibile specificare un insieme diverso di azioni — ad esempio, notificare il team in caso di ALARM, inviare una notifica al ripristino con OK e generare un avviso in caso di INSUFFICIENT_DATA per rilevare lacune nel monitoraggio.

Quando CloudWatch valuta un allarme e mancano alcuni punti dati, è necessario decidere come gestirli. Le opzioni sono: notBreaching (considerare i dati mancanti entro la soglia — l'allarme resta su OK se gli altri dati sono OK), breaching (considerare i dati mancanti oltre la soglia — l'allarme passa ad ALARM), ignore (lo stato dell'allarme non cambia) e missing (l'allarme passa a INSUFFICIENT_DATA). Scegliere l'opzione sbagliata può causare falsi positivi o errori silenziosi — una sottigliezza importante dell'esame SAA-C03.

La risoluzione dell'allarme è il prodotto di periodo × periodi di valutazione. Ad esempio, un periodo di 60 secondi con 5 periodi di valutazione significa che l'allarme considera 5 punti dati consecutivi di 1 minuto. Per impostazione predefinita, l'allarme passa ad ALARM solo quando tutti e cinque i periodi superano la soglia. È possibile configurare datapoints-to-alarm per richiedere che superino la soglia solo M periodi su N — ad esempio, 3 su 5 — riducendo così i falsi positivi dovuti a picchi transitori.

Un allarme composito valuta lo stato di diversi altri allarmi usando la logica booleana (AND, OR, NOT). Entra nello stato ALARM solo quando l'espressione della regola restituisce true. Gli allarmi compositi vengono usati per ridurre il rumore degli avvisi — ad esempio, per generare un avviso solo se gli allarmi di CPU elevata E latenza elevata sono attivi contemporaneamente, poiché una CPU elevata da sola può essere accettabile durante l'elaborazione batch. È inoltre possibile usare gli allarmi compositi per sopprimere gli allarmi figlio durante le finestre di manutenzione.

Gli allarmi compositi supportano le azioni di soppressione degli allarmi — è possibile configurare un allarme composito per sopprimere gli allarmi figlio durante la manutenzione pianificata. Ad esempio, durante una finestra di distribuzione, si potrebbe impostare un allarme composito che combina un allarme 'MaintenanceMode' con la logica OR, sopprimendo tutte le notifiche degli allarmi figlio mentre la manutenzione è attiva. In questo modo si evita una valanga di avvisi quando i servizi vengono intenzionalmente messi offline per gli aggiornamenti.

I gruppi Auto Scaling usano gli allarmi CloudWatch come trigger per le policy di step scaling e simple scaling. Quando l'allarme entra nello stato ALARM, la policy di dimensionamento viene eseguita. Per lo step scaling, si definiscono più modifiche delle dimensioni per diversi intervalli di soglia — ad esempio, aggiungere 1 istanza se la CPU è al 70-80%, aggiungerne 3 se è all'80-90% e aggiungerne 5 se supera il 90%. L'allarme attiva il primo passaggio applicabile in base al livello di superamento rilevato al momento della valutazione.

È possibile creare allarmi di fatturazione in CloudWatch per ricevere una notifica quando i costi AWS stimati superano una soglia. Le metriche di fatturazione vengono pubblicate solo nella Regione us-east-1 (indipendentemente dalla posizione delle risorse) e vengono aggiornate circa ogni 6 ore. Per abilitare gli allarmi di fatturazione, è necessario prima attivare Billing Alerts nella console AWS Billing. Lo strumento più preciso è AWS Budgets, ma gli allarmi di fatturazione CloudWatch restano un'opzione valida e inclusa nell'esame.

È possibile impostare manualmente lo stato di un allarme usando il comando set-alarm-state per testare le azioni dell'allarme senza attendere il reale superamento di una soglia. Questa funzionalità è utile per verificare che gli argomenti SNS, le policy Auto Scaling e le funzioni Lambda rispondano correttamente. Esegua sempre i test delle azioni degli allarmi in un ambiente non di produzione e verifichi che le sottoscrizioni e-mail dell'argomento SNS siano state confermate correttamente prima di affidarsi agli allarmi per gli avvisi in produzione.

Verifichi la propria comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: gli allarmi hanno tre stati (OK, ALARM, INSUFFICIENT_DATA) e possono attivare azioni SNS, Auto Scaling ed EC2; datapoints-to-alarm consente una valutazione M-su-N per ridurre i falsi positivi; gli allarmi compositi usano la logica booleana per combinare più allarmi e ridurre il rumore degli avvisi. Nella prossima lezione esamineremo CloudWatch Logs e Log Insights per la gestione centralizzata dei log.