REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità
Le notifiche vengono inviate al rilevamento del superamento delle soglie, anche se l'evento causato dal problema è stato risolto automaticamente.
Il ripristino automatizzato consente al carico di lavoro di risultare affidabile. Tuttavia, potrebbe anche nascondere problemi sottostanti che devono essere risolti. Implementa il monitoraggio e gli eventi appropriati in modo da poter rilevare i modelli di problemi, inclusi quelli risolti dalla diagnostica automatica e risolvere così i problemi della causa principale.
I sistemi resilienti sono progettati in modo che gli eventi di degrado vengano immediatamente comunicati ai team appropriati. Queste notifiche devono essere inviate tramite uno o più canali di comunicazione.
Risultato desiderato: Gli avvisi vengono inviati immediatamente ai team operativi quando vengono superate soglie come i tassi di errore, la latenza o altri parametri critici degli indicatori chiave di prestazione (KPI), in modo che questi problemi vengano risolti il prima possibile e l'impatto sugli utenti sia evitato o ridotto al minimo.
Anti-pattern comuni:
-
Invio di un numero eccessivo di avvisi.
-
Invio di avvisi non utilizzabili.
-
Impostazione di soglie di allarme troppo alte (troppo sensibili) o troppo basse (troppo poco sensibili).
-
Mancato invio di avvisi per dipendenze esterne.
-
Non considerando guasti nell'area grigia nella progettazione di sistemi di monitoraggio e allarmi.
-
Eseguire l'automazione del risanamento, ma senza avvisare il team competente che era necessario un intervento di ripristino.
Vantaggi dell'adozione di questa best practice: Le notifiche di ripristino rendono i team operativi e aziendali consapevoli dei peggioramenti del servizio in modo che possano reagire immediatamente per ridurre al minimo sia il tempo medio di rilevamento (MTTD) che il tempo medio di riparazione (MTTR). Le notifiche degli eventi di ripristino consentono anche di non ignorare i problemi che si verificano di rado.
Livello di rischio associato se questa best practice non fosse adottata: medio. La mancata implementazione di meccanismi di monitoraggio e notifica degli eventi appropriati può comportare l'impossibilità di rilevare i modelli di problemi, compresi quelli risolti mediante la correzione automatica. Un team verrà informato del degrado del sistema solo nel momento in cui gli utenti contattano il servizio clienti o per caso.
Guida all'implementazione
Quando si definisce una strategia di monitoraggio, un allarme attivato è un evento comune. Questo evento dovrebbe contenere un identificatore dell'allarme, lo stato dell'allarme (ad esempio IN ALLARME o OK) e dettagli su cosa l'ha innescato. In molti casi, è necessario rilevare un evento di allarme e inviare una notifica tramite e-mail. Questo è un esempio di azione su un allarme. La notifica degli allarmi è fondamentale per l'osservabilità, in quanto informa le persone giuste della presenza di un problema. Tuttavia, quando le operazioni eseguite sulla base degli eventi raggiungono un certo grado di maturità nella soluzione di osservabilità, è possibile risolvere automaticamente il problema senza la necessità dell'intervento umano.
Una volta stabiliti gli allarmi di monitoraggio dei KPI, è necessario inviare avvisi ai team appropriati quando vengono superate le soglie. Tali avvisi possono essere utilizzati anche per attivare processi automatizzati che tenteranno di porre rimedio al danno o alla compromissione.
Per un monitoraggio delle soglie più complesso, è necessario prendere in considerazione gli allarmi compositi. Gli allarmi compositi utilizzano una serie di allarmi di monitoraggio dei KPI per creare un avviso basato sulla logica di business operativa. Gli allarmi CloudWatch possono essere configurati per l'invio di e-mail o per la registrazione di file di log nei sistemi di monitoraggio di terze parti tramite l'integrazione con Amazon SNS o Amazon EventBridge.
Passaggi dell'implementazione
Crea vari tipi di allarmi in base al modo in cui vengono monitorati i carichi di lavoro, ad esempio:
-
Gli allarmi applicativi vengono utilizzati per rilevare quando una parte del carico di lavoro non funziona correttamente.
-
Allarmi infrastrutturali indicano quando dimensionare le risorse. Gli allarmi possono essere visualizzati visivamente sui pannelli di controllo, essere inviati tramite Amazon SNS o tramite e-mail e utilizzati con Auto Scaling per aumentare o diminuire le risorse del carico di lavoro.
-
Semplice allarmi statici per monitorare quando una metrica supera una soglia statica per un numero specificato di periodi di valutazione.
-
Gli allarmi compositi possono tenere conto di allarmi complessi provenienti da più fonti.
-
Una volta creato l'allarme è possibile generare eventi di notifica appropriati. Puoi richiamare direttamente una API Amazon SNS per inviare notifiche e collegare qualsiasi automazione per la correzione o la comunicazione.
-
integra Amazon Health Aware
per consentire il monitoraggio della visibilità sulle risorse AWS che potrebbero presentare un deterioramento. Per i carichi di lavoro aziendali essenziali, questa soluzione fornisce l'accesso ad avvisi proattivi e in tempo reale per i servizi AWS.
Risorse
Best practice Well-Architected correlate:
Documenti correlati:
Strumenti correlati:
