Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
REL11-BP06 Invia 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 le soglie, ad esempio i tassi di errore, la latenza o altri 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 allarmi.
-
Invio di allarmi non utilizzabili.
-
Impostazione di soglie di allarme troppo alte (troppo sensibili) o troppo basse (troppo poco sensibili).
-
Mancato invio di allarmi per dipendenze esterne.
-
Mancata presa in considerazione dei 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 derivanti dall'adozione di questa best practice: le notifiche di ripristino informano i team operativi e aziendali 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 ALARM o OK) e i dettagli di ciò che lo ha attivato. In molti casi, è necessario rilevare un evento di allarme e inviare una notifica tramite e-mail. Questo è un esempio di operazione 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 KPI monitoraggio, è 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 KPI monitoraggio per creare un avviso basato sulla logica aziendale operativa. CloudWatchGli allarmi possono essere configurati per inviare e-mail o per registrare gli incidenti in sistemi di tracciamento degli incidenti di terze parti utilizzando SNS l'integrazione di Amazon 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.
-
Gli allarmi infrastrutturali indicano quando scalare le risorse. Gli allarmi possono essere visualizzati visivamente sulle dashboard, inviare avvisi tramite Amazon SNS o e-mail e utilizzare Auto Scaling per aumentare o ridurre le risorse del carico di lavoro.
-
È possibile creare semplici allarmi statistici 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 un Amazon SNS API per inviare notifiche e collegare qualsiasi automazione per la riparazione o la comunicazione.
-
Integra il monitoraggio di Amazon Health Aware
per consentire il monitoraggio della visibilità AWS delle risorse 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:
