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à.
Come funziona il monitoraggio
Guarda la seguente grafica sull'architettura di monitoraggio in AWS Managed Services (AMS).
Il diagramma seguente fornisce una panoramica di alto livello del flusso di lavoro di monitoraggio della landing zone con più account AMS e del flusso di lavoro di monitoraggio della landing zone con account singolo AMS.
Generazione: al momento dell'onboarding dell'account, AMS configura il monitoraggio di base (una combinazione di allarmi CloudWatch (CW) e regole degli eventi CW) per tutte le risorse create in un account gestito. La configurazione di monitoraggio di base genera un avviso quando viene attivato un allarme CW o viene generato un evento CW.
Aggregazione:
Multi-Account Landing Zone: gli avvisi vengono generati dalle vostre risorse all'interno degli account Application e Core Organizational Unit e inviati al sistema di monitoraggio AMS indirizzandoli tramite l'account Security.
Zona di destinazione per account singolo: tutti gli avvisi generati dalle tue risorse vengono inviati al sistema di monitoraggio AMS indirizzandoli a un argomento SNS dell'account.
Puoi anche configurare il modo in cui AMS raggruppa gli avvisi. EC2 AMS raggruppa tutti gli avvisi relativi alla stessa EC2 istanza in un unico incidente o crea un incidente per avviso, a seconda delle preferenze. Puoi modificare questa configurazione in qualsiasi momento collaborando con il tuo Cloud Service Delivery Manager o Cloud Architect. Funziona allo stesso modo indipendentemente dal fatto che utilizzi Multi-Account Landing Zone o Single-Account Landing Zone.
Elaborazione: AMS analizza gli avvisi e li elabora in base al loro potenziale impatto. Gli avvisi vengono elaborati come descritto di seguito.
Avvisi con un impatto noto sui clienti: portano alla creazione di un nuovo rapporto sugli incidenti e AMS segue il processo di gestione degli incidenti; per informazioni sulla gestione degli incidenti, vedere. Risposta agli incidenti AMS
Esempio di avviso: un' EC2 istanza Amazon non supera un controllo dello stato del sistema, AMS tenta di ripristinare l'istanza interrompendola e riavviandola.
Avvisi con un impatto incerto sui clienti: per questi tipi di avvisi, AMS invia un rapporto sugli incidenti, in molti casi chiedendo di verificare l'impatto prima che AMS intervenga. Tuttavia, se i controlli relativi all'infrastruttura vengono superati, AMS non ti invia una segnalazione sull'incidente.
Ad esempio: un avviso per un utilizzo della CPU superiore all'85% per più di 10 minuti su un' EC2istanza Amazon non può essere immediatamente classificato come incidente poiché questo comportamento potrebbe essere previsto in base all'utilizzo. In questo esempio, AMS Automation esegue controlli relativi all'infrastruttura sulla risorsa. Se tali controlli vengono superati, AMS non invia una notifica di avviso, anche se l'utilizzo della CPU supera il 99%. Se Automation rileva che i controlli relativi all'infrastruttura non riescono sulla risorsa, AMS invia una notifica di avviso e verifica se è necessaria una mitigazione. Le notifiche di avviso sono illustrate in dettaglio in questa sezione. AMS offre opzioni di mitigazione nella notifica. Quando rispondi alla notifica confermando che l'avviso è un incidente, AMS crea un nuovo rapporto sull'incidente e inizia il processo di gestione degli incidenti AMS. Le notifiche di servizio che ricevono una risposta di «nessun impatto sul cliente» o nessuna risposta per tre giorni, vengono contrassegnate come risolte e l'avviso corrispondente viene contrassegnato come risolto.
Avvisi senza impatto sul cliente: se, dopo la valutazione, AMS determina che l'avviso non ha alcun impatto sul cliente, l'avviso viene chiuso.
Ad esempio, AWS Health notifica la presenza di un' EC2 istanza che richiede la sostituzione, ma da allora tale istanza è stata interrotta.
EC2 notifiche raggruppate di istanze
È possibile configurare il monitoraggio AMS per raggruppare gli avvisi della stessa EC2 istanza in un unico incidente. Il tuo Cloud Service Delivery Manager o Cloud Architect può configurarlo per te. È possibile configurare quattro parametri per ogni account gestito da AMS.
Ambito: scegli a livello di account o basato su tag.
Per specificare una configurazione applicabile a ogni EC2 istanza di quell'account, scegli scope = a livello di account.
Per specificare una configurazione che si applica solo alle EC2 istanze di quell'account con un tag specifico, scegli scope = tag-based.
Regola di raggruppamento: scegli classica o istanza.
Per configurare il raggruppamento a livello di istanza per ogni risorsa del tuo account, scegli ambito = a livello di account e regola di raggruppamento = istanza.
Per configurare risorse specifiche nel tuo account per utilizzare il raggruppamento a livello di istanza, tagga tali istanze e quindi scegli scope = basato su tag e regola di raggruppamento = livello di istanza.
Per non utilizzare il raggruppamento di istanze per gli avvisi nel tuo account, scegli la regola di raggruppamento = classica.
Opzione di coinvolgimento: scegli nessuna opzione, solo report o predefinita.
Affinché AMS non crei incidenti o non esegua automazioni per gli allarmi utilizzando tali risorse mentre la configurazione è attiva, scegli nessuna.
Affinché AMS non crei incidenti o esegua automazioni per gli allarmi da tali risorse mentre la configurazione è attiva e non esegua documenti di correzione automatica di Systems Manager, ma per includere i record di questi eventi nei report, scegli solo report. Ciò può essere utile se desiderate ridurre il volume dei casi di assistenza in caso di incidenti con cui interagite e se alcuni incidenti causati da alcune risorse non richiedono un'attenzione immediata, ad esempio quelli relativi a un account non di produzione.
Affinché AMS elabori gli avvisi, esegua automazioni e crei casi di incidenti quando necessario, scegli Default.
Risolvi dopo: scegli tra 24 ore, 48 ore o 72 ore. Infine, configura quando i casi di incidente vengono chiusi automaticamente. Se l'ora dell'ultima corrispondenza tra i casi raggiunge il valore Resolve after configurato, l'incidente viene chiuso.
Notifica di avviso
Come parte dell'elaborazione degli avvisi, basata sull'analisi dell'impatto, AWS Managed Services (AMS) crea un incidente e avvia il processo di gestione degli incidenti per la correzione, quando è possibile determinare l'impatto. Se non è possibile determinare l'impatto, AMS invia una notifica di avviso all'indirizzo e-mail associato al tuo account tramite una notifica di servizio. In alcuni scenari, questa notifica di avviso non viene inviata. Ad esempio, se i controlli relativi all'infrastruttura vengono superati per un avviso di utilizzo elevato della CPU, all'utente non viene inviata una notifica di avviso. Per ulteriori informazioni, consulta il diagramma sull'architettura di monitoraggio AMS per il processo di gestione degli avvisi in. Come funziona il monitoraggio
Notifica di avviso basata su tag
Utilizza i tag per inviare notifiche di avviso relative alle tue risorse a diversi indirizzi e-mail. È consigliabile utilizzare notifiche di avviso basate su tag, poiché le notifiche inviate a un singolo indirizzo e-mail potrebbero creare confusione quando più team di sviluppatori utilizzano lo stesso account. Le notifiche di avviso basate su tag non sono influenzate dalle EC2 notifiche raggruppate di istanze impostazioni scelte.
Con le notifiche di avviso basate su tag puoi:
Inviare avvisi a un indirizzo e-mail specifico: contrassegna le risorse che dispongono di avvisi che devono essere inviati a un indirizzo e-mail specifico con,.
key = OwnerTeamEmailvalue =EMAIL_ADDRESSInvia avvisi a più indirizzi e-mail: per utilizzare più indirizzi e-mail, specifica un elenco di valori separati da virgole. Ad esempio,
key =,OwnerTeamEmailvalue =. Il numero totale di caratteri per il campo del valore non può superare 260.EMAIL_ADDRESS_1,EMAIL_ADDRESS_2,EMAIL_ADDRESS_3, ...Usa una chiave di tag personalizzata: per utilizzare una chiave di tag personalizzata, fornisci il nome della chiave tag personalizzata al tuo CSDM in un'e-mail che dia esplicitamente il consenso all'attivazione di notifiche automatiche per la comunicazione basata su tag. È consigliabile utilizzare la stessa strategia di tagging per i tag di contatto in tutte le istanze e le risorse.
Nota
Il valore chiave OwnerTeamEmail non deve necessariamente essere nel caso di camel. Tuttavia, i tag fanno distinzione tra maiuscole e minuscole ed è consigliabile utilizzare il formato consigliato.
L'indirizzo e-mail deve essere specificato per intero, con il segno «at» (@) per separare la parte locale dal dominio. Esempi di indirizzi e-mail non validi: Team.AppATabc.xyz ojohn.doe. Per indicazioni generali sulla tua strategia di tagging, consulta AWS Tagging resources. Non aggiungere informazioni di identificazione personale (PII) nei tag. Usa liste di distribuzione o alias laddove possibile.
La notifica di avviso basata su tag è supportata per le risorse dei seguenti Amazon Services: Elastic Block Store (EBS) EC2, Elastic Load Balancing (ELB), Application Load Balancer (ALB), Network Load Balancer, Relational Database Service (RDS), Elastic File System (EFS) e VPN. OpenSearch FSx Site-to-Site
