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à.
# Definisci e configura gli allarmi in Incident Detection and Response
AWS collabora con te per definire metriche e allarmi per fornire visibilità sulle prestazioni delle tue applicazioni e della loro infrastruttura sottostante AWS . Chiediamo che gli allarmi rispettino i seguenti criteri durante la definizione e la configurazione delle soglie:
+ Gli allarmi entrano nello stato «Allarme» solo quando si verifica un impatto critico sul carico di lavoro monitorato (perdita di ricavi o peggioramento dell'esperienza del cliente che riduce significativamente le prestazioni) che richiede l'attenzione immediata dell'operatore.
+ Gli allarmi devono inoltre coinvolgere i risolutori specificati per il carico di lavoro contemporaneamente o prima di coinvolgere il team di gestione degli incidenti. I tecnici addetti alla gestione degli incidenti devono collaborare con i risolutori specificati nel processo di mitigazione, non fungere da soccorritori di prima linea e poi rivolgersi a voi.
+ Le soglie di allarme devono essere impostate su una soglia e una durata appropriate in modo che ogni volta che scatta un allarme, sia necessaria un'indagine. Se un allarme oscilla tra lo stato «Allarme» e «OK», si verifica un impatto sufficiente a giustificare la risposta e l'attenzione dell'operatore.
**Tipi di allarmi:**
+ Allarmi che illustrano il livello di impatto aziendale e trasmettono informazioni pertinenti per una semplice rilevazione dei guasti.
+ CloudWatch Canarini Amazon. [Per ulteriori informazioni, vedere [Canaries and X-Ray tracing e X-Ray](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html).](https://aws.amazon.com/xray/)
+ Allarme aggregato (monitoraggio delle dipendenze)
La tabella seguente fornisce esempi di allarmi, tutti basati sul sistema di monitoraggio. CloudWatch
****
| Nome della metrica/Soglia di allarme | ARN di allarme o ID della risorsa | Se questo allarme si attiva | Se richiesto, chiudi un Premium Support Case per questi servizi |
| --- | --- | --- | --- |
| Errori API/ Numero di errori >= 10 per 10 punti dati | arn:aws:cloudwatch:us-west- 2:000000000000:alarm:E2 Lambda-Errors MPmim | Ticket inviato al team di amministratori del database (DBA) | Lambda, API Gateway |
| ServiceUnavailable (Codice di stato Http 503) Numero di errori >=3 per 10 punti dati (client diversi) in una finestra di 5 minuti | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode503 | Ticket consegnato al team di assistenza | Lambda, API Gateway |
| ThrottlingException (Codice di stato Http 400) Numero di errori >=3 per 10 punti dati (client diversi) in una finestra di 5 minuti | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode400 | Ticket consegnato al team di assistenza | EC2, Amazon Aurora |
Per ulteriori dettagli, consultare [Monitoraggio e osservabilità di AWS Incident Detection and Response](observe-idr.md).
Se preferisci utilizzare strumenti di automazione per integrare gli allarmi, l'interfaccia CLI (Incident Detection and Response Command Line Interface) ti aiuta a implementare e integrare gli allarmi. Per ulteriori dettagli, consultare [CLI AWS per il rilevamento e la risposta agli incidenti](idr-cli.md).
**Risultati chiave:**
+ Definizione e configurazione degli allarmi sui carichi di lavoro.
+ Completamento dei dettagli degli allarmi nel questionario di onboarding.
**Topics**
+ [Crea allarmi CloudWatch](idr-alarms-fit-purpose.md)
+ [Crea CloudWatch allarmi con modelli CloudFormation](idr-create-alarms-with-cfn.md)
+ [Esempi di casi d'uso per gli allarmi CloudWatch](idr-ex-alarm-use-cases.md)
# Crea CloudWatch allarmi adatti alle tue esigenze aziendali in Incident Detection and Response
Quando crei CloudWatch allarmi Amazon, puoi eseguire diversi passaggi per assicurarti che gli allarmi soddisfino al meglio le tue esigenze aziendali.
**Nota**
Per alcuni esempi di CloudWatch allarmi consigliati Servizi AWS da integrare in Incident Detection and Response, consulta le Best Practices per il rilevamento e la risposta agli [allarmi di risposta agli incidenti](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr) su. AWS re:Post
## Esamina gli allarmi proposti CloudWatch
Esamina gli allarmi proposti per assicurarti che entrino nello stato «Allarme» solo quando c'è un impatto critico sul carico di lavoro monitorato (perdita di ricavi o peggioramento dell'esperienza del cliente che riduce significativamente le prestazioni). Ad esempio, ritenete che questo allarme sia sufficientemente importante da dover reagire immediatamente se entra nello stato «Allarme»?
Di seguito sono riportate le metriche suggerite che potrebbero rappresentare un impatto aziendale critico, ad esempio influire sull'esperienza degli utenti finali con un'applicazione:
+ **CloudFront:** Per ulteriori informazioni, consulta [Visualizzazione CloudFront e metriche delle funzioni edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html).
+ **Application Load Balancer:** è consigliabile creare i seguenti allarmi per Application Load Balancers, se possibile:
+ HTTPCode\$1ELB\$15xx\$1Count
+ HTTPCode\$1Target\$15xx\$1Count
Gli allarmi precedenti consentono di monitorare le risposte dei target che si trovano dietro l'Application Load Balancer o ad altre risorse. Ciò semplifica l'identificazione della fonte degli errori 5XX. Per ulteriori informazioni, consulta le [CloudWatch metriche per il tuo Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).
+ **Amazon API Gateway:** se utilizzi l' WebSocket API in Elastic Beanstalk, prendi in considerazione l'utilizzo delle seguenti metriche:
+ Tassi di errore di integrazione (filtrati fino a 5XX errori)
+ Latenza di integrazione
+ Errori di esecuzione
Per ulteriori informazioni, consulta [Monitoraggio dell'esecuzione delle WebSocket API con CloudWatch metriche](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html).
+ **Amazon Route 53:** monitora la **EndPointUnhealthyENICount**metrica. **Questa metrica indica il numero di interfacce di rete elastiche nello stato di ripristino automatico.** Questo stato indica i tentativi del resolver di ripristinare una o più interfacce di rete Amazon Virtual Private Cloud associate all'endpoint (specificato da). **EndpointId** Nel processo di ripristino, l'endpoint funziona con una capacità limitata. L'endpoint non può elaborare le query DNS finché non viene completamente ripristinato. Per ulteriori informazioni, consulta [Monitoraggio degli endpoint Amazon Route 53 Resolver con](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html) Amazon. CloudWatch
## Convalida le configurazioni degli allarmi
Dopo aver verificato che gli allarmi proposti soddisfino le esigenze aziendali, convalida la configurazione e la cronologia degli allarmi:
+ Convalida la **soglia** per la metrica per accedere allo stato «Allarme» rispetto all'andamento del grafico della metrica.
+ Convalida il **periodo utilizzato per i punti dati di** polling. I dati di sondaggio a 60 secondi aiutano a rilevare precocemente gli incidenti.
+ Convalida la configurazione. **DatapointToAlarm** Nella maggior parte dei casi, è consigliabile impostarlo su 3 su 3 o 5 su 5. In caso di incidente, l'allarme si attiva dopo 3 minuti se impostato come [metriche di 60 secondi con 3 su 3 DatapointToAlarm] o 5 minuti se impostato come [metriche di 60 secondi con 5 su 5]. DatapointToAlarm Utilizzate questa combinazione per eliminare gli allarmi rumorosi.
**Nota**
I consigli precedenti potrebbero variare a seconda di come si utilizza un servizio. Ogni AWS servizio funziona in modo diverso all'interno di un carico di lavoro. Inoltre, lo stesso servizio potrebbe funzionare in modo diverso se utilizzato in più luoghi. È necessario assicurarsi di comprendere in che modo il carico di lavoro utilizza le risorse che alimentano l'allarme, nonché gli effetti a monte e a valle.
## Verifica il modo in cui i tuoi allarmi gestiscono i dati mancanti
Alcune fonti metriche non inviano dati a CloudWatch intervalli regolari. **Per queste metriche, è consigliabile considerare i dati mancanti come NotBreach.** Per ulteriori informazioni, consulta [Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) e [Evitare transizioni premature](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition) allo stato di allarme.
Ad esempio, se una metrica monitora un tasso di errore e non vi sono errori, la metrica non riporta alcun dato (zero). Se configuri l'allarme in modo che i dati mancanti vengano considerati **mancanti**, un singolo punto dati di violazione seguito da due punti dati privi di dati (nulli) fa sì che la metrica passi allo stato «Allarme» (per 3 punti dati su 3). Questo perché la configurazione dei dati mancanti valuta l'ultimo punto dati noto nel periodo di valutazione.
Nei casi in cui le metriche monitorano un tasso di errore, in assenza di un peggioramento del servizio si può presumere che l'assenza di dati sia una buona cosa. È consigliabile considerare i dati mancanti come **NotBreach** in modo che i dati mancanti vengano trattati come «OK» e la metrica non entri nello stato «Alarm» su un singolo punto dati.
## Rivedi la cronologia di ogni allarme
Se la cronologia di un allarme mostra che spesso entra nello stato «Allarme» e poi si ripristina rapidamente, l'allarme potrebbe diventare un problema per te. Assicurati di regolare l'allarme per evitare rumori o falsi allarmi.
## Convalida le metriche per le risorse sottostanti
Assicurati che le tue metriche prendano in considerazione risorse sottostanti valide e utilizzino le statistiche corrette. Se un allarme è configurato per esaminare i nomi delle risorse non validi, l'allarme potrebbe non essere in grado di tenere traccia dei dati sottostanti. Ciò potrebbe far sì che l'allarme entri nello stato «Allarme».
## Crea allarmi compositi
Se offri alle operazioni di rilevamento e risposta agli incidenti un gran numero di allarmi per l'onboarding, ti potrebbe essere chiesto di creare allarmi compositi. Gli allarmi compositi riducono il numero totale di allarmi che devono essere integrati.
# Crea CloudWatch allarmi in Incident Detection and Response con modelli CloudFormation
AWS Fornisce modelli per accelerare l'onboarding verso AWS Incident Detection and Response e ridurre lo sforzo necessario per creare allarmi. CloudFormation Questi modelli includono impostazioni di allarme ottimizzate per i servizi di bordo più comuni, come Application Load Balancer, Network Load Balancer e Amazon. CloudFront
**Crea allarmi con modelli CloudWatch CloudFormation**
1. Scarica un modello utilizzando i link forniti:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IDR/latest/userguide/idr-create-alarms-with-cfn.html)
1. Controlla il file JSON scaricato per assicurarti che soddisfi i processi operativi e di sicurezza della tua organizzazione.
1. Crea uno CloudFormation stack:
**Nota**
I passaggi seguenti utilizzano il processo di creazione dello CloudFormation stack standard. Per i passaggi dettagliati, vedi [Creazione di uno stack sulla CloudFormation console](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html).
1. Apri la AWS CloudFormation console in [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Seleziona **Crea stack**.
1. Scegli **Template is ready**, quindi carica il file del modello dalla cartella locale.
Di seguito è riportato un esempio della schermata **Create stack**.
![\[Crea un esempio di file modello di caricamento dello stack\]](http://docs.aws.amazon.com/it_it/IDR/latest/userguide/images/create-cfn-stack1.png)
1. Scegli **Next (Successivo)**.
1. Immetti le seguenti informazioni necessarie:
+ **AlarmNameConfig**e **AlarmDescriptionConfig**: inserisci un nome e una descrizione per la sveglia.
+ **ThresholdConfig**: Modifica il valore della soglia per soddisfare i requisiti dell'applicazione.
+ **Distribuzione IDConfig**: assicurati che l'ID di distribuzione indichi le risorse corrette nell'account in cui stai creando lo CloudFormation stack.
1. Scegli **Next (Successivo)**.
1. Controlla i valori predefiniti nei **DatapointsToAlarmConfig**campi **PeriodConfig**EvalutionPeriodConfig****, e. È consigliabile utilizzare i valori predefiniti per questi campi. È possibile apportare modifiche, se necessario, per soddisfare i requisiti dell'applicazione.
1. Se necessario, inserisci i tag e le informazioni di notifica SNS. È consigliabile attivare la **protezione dalla terminazione** per evitare la cancellazione accidentale dell'allarme. Per attivare la protezione dalla terminazione, seleziona il pulsante di opzione **Attivato**, come mostrato nell'esempio seguente:
![\[Crea un esempio di protezione dalla terminazione di attivazione dello stack\]](http://docs.aws.amazon.com/it_it/IDR/latest/userguide/images/create-cfn-stack2.png)
1. Scegli **Next (Successivo)**.
1. **Controlla le impostazioni dello stack, quindi scegli Crea stack.**
1. Dopo aver creato lo stack, l'allarme viene visualizzato nell'elenco Amazon CloudWatch **Alarm**, come mostrato nell'esempio seguente:
![\[Elenco di CloudWatch allarmi di esempio\]](http://docs.aws.amazon.com/it_it/IDR/latest/userguide/images/create-cfn-stack3.png)
1. Dopo aver creato tutti gli allarmi nell'account e nella AWS regione corretti, invia una notifica al Technical Account Manager (TAM). Il team di AWS Incident Detection and Response esamina lo stato dei nuovi allarmi, quindi continua l'onboarding.
# Esempi di casi d'uso degli CloudWatch allarmi in Incident Detection and Response
I seguenti casi d'uso forniscono esempi di come utilizzare gli CloudWatch allarmi Amazon in Incident Detection and Response. Questi esempi dimostrano come è possibile configurare gli CloudWatch allarmi per monitorare le metriche e le soglie chiave di vari AWS servizi, consentendoti di identificare e rispondere a potenziali problemi che potrebbero influire sulla disponibilità e sulle prestazioni delle applicazioni e dei carichi di lavoro.
## Esempio di utilizzo A: Application Load Balancer
È possibile creare il seguente CloudWatch allarme che segnala il potenziale impatto sul carico di lavoro. Per fare ciò, si crea una metrica matematica che avvisa quando le connessioni riuscite scendono al di sotto di una certa soglia. Per le metriche disponibili, consulta CloudWatch le [CloudWatch metriche per il tuo Application](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) Load Balancer
**Metrica:** `HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`
**NameSpace: AWS/ApplicationELB**
**ComparisonOperator(Soglia):** Meno di x (x = soglia del cliente).
**Periodo:** 60 secondi
**DatapointsToAlarm:** 3 su 3
**Trattamento dei dati mancanti:** considera i dati mancanti come una [violazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Statistica: **Sum
Il diagramma seguente mostra il flusso per lo Use Case A:
![\[Esempio di utilizzo per Application Load Balancer\]](http://docs.aws.amazon.com/it_it/IDR/latest/userguide/images/UseCaseAALB.png)
## Esempio di utilizzo B: Amazon API Gateway
È possibile creare il seguente CloudWatch allarme che segnala il potenziale impatto sul carico di lavoro. Per fare ciò, crei una metrica composita che avvisa quando c'è un'elevata lantenza o un numero medio elevato di errori 4XX nell'API Gateway. Per i parametri disponibili, consulta [Dimensioni e metriche di Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)
**Metrica:** `compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`
**NameSpace:** AWS/API Gateway
**ComparisonOperator(Soglia):** maggiore di (soglie x o y del cliente)
**Periodo: 60 secondi**
**DatapointsToAlarm:** 1 su 1
**Trattamento dei dati mancanti:** considera i dati mancanti come [non una violazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Statistica:**
Il diagramma seguente mostra il flusso per lo Use Case B:
![\[Esempio di utilizzo per API Gateway\]](http://docs.aws.amazon.com/it_it/IDR/latest/userguide/images/UseCaseBAPIGW.png)
## Esempio di utilizzo C: Amazon Route 53
Puoi monitorare le tue risorse creando controlli sullo stato di Route 53 che raccolgono ed elaborano dati grezzi in metriche leggibili quasi in tempo reale. CloudWatch È possibile creare il seguente CloudWatch allarme che segnala il potenziale impatto sul carico di lavoro. Puoi utilizzare le CloudWatch metriche per creare un allarme che si attiva quando supera la soglia stabilita. Per le metriche disponibili, consulta CloudWatch le metriche per i controlli sanitari di [CloudWatch Route](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics) 53
**Metrica:** `R53-HC-Success`
**NameSpace: AWS/Itinerario** 53
**Soglia HealthCheckStatus:** HealthCheckStatus < x per 3 punti dati entro 3 minuti (corrispondente alla soglia x del cliente)
**Periodo**: 1 minuto
**DatapointsToAlarm:** 3 su 3
**Trattamento dei dati mancanti:** considera i dati mancanti come una [violazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Statistica: **Minimum
Il diagramma seguente mostra il flusso per lo Use Case C:
![\[Esempio di utilizzo per Route 53\]](http://docs.aws.amazon.com/it_it/IDR/latest/userguide/images/UseCaseCR53.png)
## Esempio di utilizzo D: monitora un carico di lavoro con un'app personalizzata
È fondamentale dedicare del tempo alla definizione di un controllo sanitario appropriato in questo scenario. Se verifichi solo che la porta di un'applicazione sia aperta, significa che non hai verificato che l'applicazione funzioni. Inoltre, effettuare una chiamata alla home page di un'applicazione non è necessariamente il modo corretto per determinare se l'app funziona. Ad esempio, se un'applicazione dipende sia da un database che da Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3), il controllo dello stato deve convalidare tutti gli elementi. **Un modo per farlo è creare una pagina Web di monitoraggio, ad esempio /monitor.** La pagina web di monitoraggio effettua una chiamata al database per assicurarsi che possa connettersi e ottenere dati. Inoltre, la pagina Web di monitoraggio effettua una chiamata ad Amazon S3. **Quindi, indirizza il controllo dello stato del sistema di bilanciamento del carico alla pagina /monitor.**
Il diagramma seguente mostra il flusso per lo Use Case D:
![\[Esempio di utilizzo per il monitoraggio con un'app personalizzata\]](http://docs.aws.amazon.com/it_it/IDR/latest/userguide/images/CustomAlarm.png)