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à.
# Utilizzo degli CloudWatch allarmi Amazon
Puoi creare allarmi con parametri di controllo e inviare notifiche o apportare automaticamente modifiche alle risorse che stai monitorando quando viene superata una soglia. Ad esempio, puoi monitorare l’utilizzo della CPU, le letture e le scritture sul disco delle istanze Amazon EC2 e, quindi, utilizzare tali dati per determinare se debbano essere avviate ulteriori istanze per gestire il carico incrementato. Puoi inoltre utilizzare questi dati per fermare le istanze poco utilizzate per risparmiare denaro.
Puoi creare allarmi *metrici* e *compositi* in Amazon. CloudWatch
Puoi creare allarmi sulle query di Metrics Insights che utilizzano i tag delle AWS risorse per filtrare e raggruppare le metriche. **Per utilizzare i tag con gli allarmi, su, scegli Impostazioni. [https://console.aws.amazon.com/connect/](https://console.aws.amazon.com/connect/)** **Nella pagina **CloudWatch Impostazioni**, in **Abilita i tag delle risorse sulla telemetria**, scegli Abilita.** Per un monitoraggio sensibile al contesto che si adatti automaticamente alla tua strategia di tagging, crea allarmi sulle query di Metrics Insights utilizzando i tag delle risorse. AWS Ciò consente di monitorare tutte le risorse taggate con applicazioni o ambienti specifici.
+ Un *allarme metrico* controlla una singola metrica o il risultato di un' CloudWatch espressione matematica basata sulle metriche. CloudWatch L'allarme esegue una o più operazioni basate sul valore del parametro o espressione relativa a una soglia su un certo numero di periodi. L'azione può consistere nell'invio di una notifica a un argomento di Amazon SNS, nell'esecuzione di un'azione Amazon EC2 o Amazon EC2 Auto Scaling, nell'avvio di un' CloudWatch indagine in indagini, indagini operative o nella creazione di un incidente o in Systems Manager. OpsItem
+ Un *allarme PromQL* monitora le metriche utilizzando una query istantanea Prometheus Query Language (PromQL) sulle metriche inserite tramite l'endpoint OTLP. CloudWatch L'allarme tiene traccia delle singole serie temporali di violazione in qualità di contributori e utilizza periodi di attesa e ripristino basati sulla durata per controllare le transizioni di stato. Per ulteriori informazioni, consulta [Allarmi ProMQL](alarm-promql.md).
+ Un *allarme composito* include un'espressione di regola che tiene conto degli stati di avviso di altri avvisi creati. L'allarme composito entra in stato ALARM solo se tutte le condizioni della regola sono soddisfatte. Gli allarmi specificati nell'espressione di regola di un allarme composito possono includere allarmi di parametri e altri allarmi compositi.
L'utilizzo di allarmi compositi consente di ridurre il rumore dell'allarme. È possibile creare più allarmi di parametri e anche creare un allarme composito e impostare gli avvisi solo per l'allarme composito. Ad esempio, un composito potrebbe entrare in stato ALARM solo quando tutti gli allarmi dei parametri sottostanti sono in stato ALARM.
Gli allarmi compositi possono inviare notifiche Amazon SNS quando cambiano stato e possono creare indagini, Systems OpsItems Manager o incidenti quando entrano nello stato ALARM, ma non possono eseguire azioni EC2 o azioni di Auto Scaling.
**Nota**
Puoi creare tutti gli allarmi che desideri nel tuo account. AWS
Inoltre, puoi aggiungere allarmi ai pannelli di controllo, in modo da poter monitorare e ricevere avvisi relativi alle risorse e alle applicazioni AWS in più regioni. Dopo avere aggiunto un allarme a un pannello di controllo, l'allarme diventa grigio quando è nello stato `INSUFFICIENT_DATA` e rosso quando è nello stato `ALARM`. L'allarme non ha alcun colore quando è nello stato `OK`.
Puoi anche aggiungere ai preferiti gli avvisi visitati di recente dall'opzione *Preferiti e recenti* nel pannello di navigazione della CloudWatch console. L'opzione *Favorites and recents* (Preferiti e recenti) contiene colonne per gli allarmi contrassegnati come preferiti e quelli consultati di recente.
Un allarme richiama le operazioni solo quando lo stato dell'allarme cambia. L'eccezione è per gli allarmi con operazioni Auto Scaling. Per operazioni Auto Scaling, l'allarme continua a richiamare l'operazione una volta per ogni minuto durante il quale rimane nel nuovo stato.
Un allarme può osservare una metrica nello stesso account. Se hai abilitato la funzionalità tra account nella tua CloudWatch console, puoi anche creare allarmi che controllano le metriche di altri account. AWS La creazione di allarmi compositi tra più account non è supportata. È supportata la creazione di allarmi tra più account che utilizzano espressioni matematiche, ad eccezione del fatto che le funzioni `ANOMALY_DETECTION_BAND`, `INSIGHT_RULE` e `SERVICE_QUOTA` non sono supportate per gli allarmi tra più account.
**Nota**
CloudWatch non verifica o convalida le azioni specificate, né rileva errori di Amazon EC2 Auto Scaling o Amazon SNS derivanti da un tentativo di richiamare azioni inesistenti. Assicurati che le tue operazioni relative agli allarmi esistano.
# Concetti
CloudWatch gli allarmi monitorano le metriche e attivano azioni quando vengono superate le soglie. Comprendere come gli allarmi valutano i dati e rispondono alle condizioni è essenziale per un monitoraggio efficace.
**Topics**
+ [Richieste di dati di allarme](alarm-data-queries.md)
+ [Valutazione degli allarmi](alarm-evaluation.md)
+ [Allarmi ProMQL](alarm-promql.md)
+ [Allarmi compositi](alarm-combining.md)
+ [Operazione per gli allarmi](alarm-actions.md)
+ [Regole di silenziamento degli allarmi](alarm-mute-rules.md)
+ [Limits](alarm-limits.md)
# Richieste di dati di allarme
CloudWatch gli allarmi possono monitorare varie fonti di dati. Scegli il tipo di query appropriato in base alle tue esigenze di monitoraggio.
## Metriche
Monitora una singola CloudWatch metrica. Questo è il tipo di allarme più comune per il monitoraggio delle prestazioni delle risorse. Per ulteriori informazioni sulle metriche, consulta Concetti relativi alle [CloudWatch metriche](cloudwatch_concepts.md).
Per ulteriori informazioni, consulta [Crea un CloudWatch allarme basato su una soglia statica](ConsoleAlarms.md).
## Matematica dei parametri
Puoi impostare un allarme in base al risultato di un'espressione matematica che è basata su uno o più parametri CloudWatch. Un'espressione matematica utilizzata per un allarme può includere fino a 10 parametri. Ogni parametro deve utilizzare lo stesso periodo.
Per un allarme basato su un'espressione matematica, puoi specificare come desideri CloudWatch trattare i punti dati mancanti. In questo caso, il punto dati viene considerato mancante se l'espressione matematica non restituisce un valore per quel punto dati.
Allarmi basati su espressioni matematiche non possono eseguire operazioni Amazon EC2.
Per ulteriori informazioni sulle espressioni matematiche e la sintassi dei parametri, consulta [Utilizzo di espressioni matematiche con metriche CloudWatch](using-metric-math.md).
Per ulteriori informazioni, consulta [Crea un CloudWatch allarme basato su un'espressione matematica metrica](Create-alarm-on-metric-math-expression.md).
## Approfondimenti sulle metriche
Una query CloudWatch Metrics Insights consente di interrogare le metriche su larga scala utilizzando una sintassi simile a SQL. È possibile creare un allarme su qualsiasi query di Approfondimenti sulle metriche, incluse le query che restituiscono molteplici serie temporali. Questa funzionalità amplia notevolmente le opzioni di monitoraggio. Quando si crea un allarme in base a una query di Approfondimenti sulle metriche, l'allarme si regola automaticamente man mano che le risorse vengono aggiunte o rimosse dal gruppo monitorato. È sufficiente creare l'allarme una sola volta affinché qualsiasi risorsa che corrisponde alla definizione della query e ai filtri entri a far parte dell'ambito di monitoraggio degli allarmi non appena la metrica corrispondente diventa disponibile. Per le query su più serie temporali, ogni serie temporale restituita contribuisce all'allarme, consentendo un monitoraggio più granulare e dinamico.
Ecco due casi d'uso principali per gli allarmi di Metrics Insights: CloudWatch
+ Rilevamento delle anomalie e monitoraggio aggregato
Crea un allarme su qualsiasi query di Approfondimenti sulle metriche che restituisce una singola serie temporale aggregata. Questo approccio è ideale per gli allarmi dinamici che monitorano le metriche aggregate nell'infrastruttura o nelle applicazioni. Ad esempio, è possibile monitorare l'utilizzo massimo della CPU in tutte le istanze e l'allarme scala automaticamente man mano che si amplia il parco.
Per creare un allarme di monitoraggio aggregato, utilizza questa struttura di query:
```
SELECT FUNCTION(metricName)
FROM SCHEMA(...)
WHERE condition;
```
+ Monitoraggio del parco per risorsa
Crea un allarme che monitori più serie temporali, in cui ogni serie temporale funge da collaboratore con il proprio stato. L'allarme si attiva quando un collaboratore entra nello stato ALARM, attivando operazioni specifiche della risorsa. Ad esempio, monitora le connessioni al database su più istanze RDS per evitare il rifiuto delle connessioni.
Per monitorare più serie temporali, utilizza questa struttura di query:
```
SELECT AVG(DatabaseConnections)
FROM AWS/RDS
WHERE condition
GROUP BY DBInstanceIdentifier
ORDER BY AVG() DESC;
```
Quando si creano allarmi con serie temporali multiple, è necessario includere due clausole chiave nella query:
+ una clausola `GROUP BY`, che definisce come strutturare le serie temporali e determina quante serie temporali produrrà la query;
+ una clausola `ORDER BY`, che stabilisce un ordinamento deterministico delle metriche, permettendo all'allarme di valutare prima i segnali più importanti.
Queste clausole sono essenziali per una corretta valutazione degli allarmi. La clausola `GROUP BY` suddivide i dati in serie temporali separate (ad esempio, per ID di istanza), mentre la clausola `ORDER BY` garantisce un'elaborazione coerente e prioritaria di queste serie temporali durante la valutazione degli allarmi.
Per ulteriori informazioni su come creare un allarme basato su più serie temporali, vedere. [Crea un allarme basato su una query di Multi Time Series Metrics Insights](multi-time-series-alarm.md)
## Filtri metrici di gruppo di log
È possibile creare un allarme basato su un filtro metrico del gruppo di log. Con i filtri metrici, puoi cercare termini e modelli nei dati di registro man mano che i dati vengono inviati. CloudWatch Per ulteriori informazioni, consulta [Creare metriche dagli eventi di log utilizzando i filtri](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) nella *Amazon CloudWatch Logs User* Guide.
Per ulteriori informazioni su come creare un allarme basato sul filtro loggroup-metric, consulta. [Creazione di allarmi sui log](Alarm-On-Logs.md)
## ProMQL
Puoi creare un allarme che utilizza una query istantanea Prometheus Query Language (PromQL) per monitorare le metriche inserite tramite l'endpoint OTLP. CloudWatch
Per ulteriori informazioni sul funzionamento degli allarmi PromQL, vedere. [Allarmi ProMQL](alarm-promql.md)
Per ulteriori informazioni su come creare un allarme ProMQL, vedere. [Creare un allarme utilizzando una query PromQL](Create_PromQL_Alarm.md)
## Fonte di dati esterna
Puoi creare allarmi che controllano le metriche provenienti da fonti di dati che non sono presenti. CloudWatch Per ulteriori informazioni sulla creazione di connessioni a queste altre origini dati, consulta [Recupero dei parametri da altre origini dati](MultiDataSourceQuerying.md).
Per ulteriori informazioni su come creare un allarme basato su una fonte di dati connessa, consulta. [Creazione di un allarme basato su un'origine dati connessa](Create_MultiSource_Alarm.md)
# Valutazione degli allarmi
## Stati degli allarmi di parametri
Un allarme di parametri può trovarsi nei possibili stati elencati di seguito:
+ `OK` - Il parametro o espressione rientra nella soglia definita.
+ `ALARM` - Il parametro o espressione non rientra nella soglia definita.
+ `INSUFFICIENT_DATA` - L'allarme è stato appena attivato, il parametro non è disponibile o la quantità di dati non è sufficiente affinché il parametro determini lo stato dell'allarme.
## Stato di valutazione degli allarmi
Oltre allo stato di allarme, ogni allarme ha uno stato di valutazione che fornisce informazioni sul processo di valutazione dell'allarme. Possono verificarsi i seguenti stati:
+ `PARTIAL_DATA`— Indica che non è stato possibile recuperare tutti i dati disponibili a causa delle limitazioni delle quote. Per ulteriori informazioni, consulta [Come vengono gestiti i dati parziali](cloudwatch-metrics-insights-alarms-partial-data.md).
+ `EVALUATION_ERROR`— Indica errori di configurazione nella configurazione degli allarmi che richiedono revisione e correzione. Per maggiori dettagli, fare riferimento al StateReason campo dell'allarme.
+ `EVALUATION_FAILURE`— Indica CloudWatch problemi temporanei. Si consiglia il monitoraggio manuale fino alla risoluzione del problema
È possibile visualizzare lo stato di valutazione nei dettagli dell'allarme nella console o utilizzando il comando `describe-alarms` CLI o `DescribeAlarms` l'API.
## Impostazioni di valutazione degli allarmi
Quando si crea un allarme, si specificano tre impostazioni CloudWatch per consentire di valutare quando modificare lo stato dell'allarme:
+ **Periodo** è l'intervallo di tempo su cui valutare il parametro o l'espressione e creare ogni singolo punto di dati per un allarme. Viene espresso in secondi.
+ **Evaluation Periods** (Periodi di valutazione) è il numero di periodi più recenti, o punti di dati, per valutare quando stabilire lo stato di allarme.
+ **Datapoints to Alarm** (Punti di dati all'allarme) è il numero punti di dati all'interno dei periodi di valutazione che devono essere violati per fare in modo che l'allarme sia nello stato `ALARM`. I punti dati oggetto della violazione non devono essere consecutivi, ma devono solo essere tutti all'interno dell'ultimo numero di punti dati pari all'**Evaluation Period** (Periodo di valutazione).
Per un periodo di almeno un minuto, un allarme viene valutato ogni minuto e la valutazione si basa sulla finestra temporale definita da **Periodo** e **Periodi di valutazione**. Ad esempio, se **Periodo** è di 5 minuti (300 secondi) e **Periodi di valutazione** è 1, alla fine del minuto 5 l'allarme viene valutato in base ai dati compresi tra 1 e 5 minuti. Quindi, alla fine del minuto 6, l'allarme viene valutato in base ai dati dal secondo al sesto minuto.
Se il periodo di allarme è di 10 secondi, 20 secondi o 30 secondi, l'allarme viene valutato ogni 10 secondi. Per ulteriori informazioni, consulta [Allarmi ad alta risoluzione](#high-resolution-alarms).
Se il numero di periodi di valutazione per un allarme moltiplicato per la durata di ciascun periodo di valutazione supera un giorno, l'allarme viene valutato una volta all'ora. Per ulteriori dettagli su come vengono valutati questi allarmi giornalieri, consulta. [Esempio di valutazione di un allarme di più giorni](#evaluate-multiday-alarm)
Nella figura seguente, la soglia di allarme per un allarme dei parametri è impostata su tre unità. Sia l'**Evaluation Period** (Periodo di valutazione) che **Datapoints to Alarm** (Punti di dati all'allarme) sono 3. Quando tutti i punti dati esistenti nei tre periodi consecutivi più recenti sono sopra la soglia, l'allarme passa allo stato `ALARM`. Nella figura, questo accade dal terzo al quinto periodo di tempo. Al periodo sei, il valore scende sotto la soglia, perciò uno dei periodi valutati non effettua una violazione e lo stato dell'allarme cambia in `OK`. Durante il nono periodo di tempo, la soglia viene nuovamente superata, ma per un solo periodo. Di conseguenza, lo stato dell'allarme rimane `OK`.
![\[Soglia dell'allarme del trigger\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/alarm_graph.png)
Quando si configura **Evaluation Periods** (Periodi di valutazione) e **Datapoints to Alarm** (Punti dati all'allarme) come valori diversi, si imposta un allarme "M su N". **Datapoints to Alarm** è («M») e **Evaluation Periods è («N»). L'intervallo di valutazione è il numero di periodi** di valutazione moltiplicato per la durata del periodo. Ad esempio, se configuri 4 punti dati su 5 con un periodo di 1 minuto, l'intervallo di valutazione è di 5 minuti. Se configuri 3 punti dati su 3 con un periodo di 10 minuti, l'intervallo di valutazione è di 30 minuti.
**Nota**
Se i punti dati mancano subito dopo la creazione di un allarme e la metrica veniva riportata CloudWatch prima della creazione dell'allarme, CloudWatch recupera i punti dati più recenti precedenti alla creazione dell'allarme durante la valutazione dell'allarme.
## Allarmi ad alta risoluzione
Se imposti un allarme su una metrica ad alta risoluzione, puoi specificare un allarme ad alta risoluzione con un periodo di 10 secondi, 20 secondi o 30 secondi. Per gli allarmi ad alta risoluzione il costo è più elevato. Per ulteriori informazioni sui parametri ad alta risoluzione, consulta [Publish custom metrics](publishingMetrics.md).
## Esempio di valutazione di un allarme di più giorni
Un allarme è considerato un allarme di più giorni se il numero di periodi di valutazione moltiplicato per la durata di ciascun periodo di valutazione supera un giorno. Gli allarmi di più giorni vengono valutati una volta all'ora. Quando vengono valutati gli allarmi di più giorni, durante la valutazione CloudWatch tiene conto solo delle metriche fino all'ora corrente al minuto 00.
Ad esempio, consideriamo un allarme che monitora un processo che viene eseguito ogni 3 giorni alle 10:00.
1. Alle 10:02, il processo fallisce.
1. Alle 10:03, l'allarme viene valutato e rimane nello stato `OK`, poiché la valutazione considera i dati solo fino alle 10:00.
1. Alle 11:03, l'allarme considera i dati fino alle 11:00 e passa allo stato `ALARM`.
1. Alle 11:43, l'errore viene corretto e il processo ora viene eseguito correttamente.
1. Alle 12:03, l'allarme viene nuovamente valutato, rileva che il processo è riuscito e torna allo stato `OK`.
# Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti
A volte, non tutti i dati previsti per una metrica vengono segnalati. CloudWatch Questo può accadere, ad esempio, quando una connessione viene persa, un server è inattivo oppure quando un parametro comunica dati solo a intermittenza per progetto.
CloudWatch consente di specificare come trattare i punti dati mancanti durante la valutazione di un allarme. Questo può aiutare a configurare l'allarme in modo che entri nello stato `ALARM` solo quando richiesto per il tipo di dati monitorati. È possibile evitare falsi positivi quando i dati mancanti non indicano un problema.
Analogamente a come ogni allarme si trova sempre in uno dei tre stati, ogni punto dati specifico a cui viene segnalato CloudWatch rientra in una delle tre categorie seguenti:
+ Non superato (entro la soglia)
+ Superato (fuori dalla soglia)
+ Mancante
Per ogni allarme, puoi specificare CloudWatch di trattare i punti dati mancanti come segue:
+ `notBreaching` - I punti dati mancanti vengono trattati come se fossero “corretti” e all'interno della soglia
+ `breaching` - I punti dati mancanti vengono trattati come se fossero “errati” e violassero la soglia
+ `ignore` - Lo stato dell'allarme attuale viene mantenuto
+ `missing` - Se mancano tutti i punti di dati nell'intervallo di valutazione degli allarmi, l'allarme passa a INSUFFICIENT\$1DATA.
La scelta migliore dipende dal tipo di metrica e dallo scopo dell'allarme. Ad esempio, se si sta creando un allarme di rollback dell'applicazione utilizzando una metrica che segnala continuamente i dati mancanti, potrebbe essere consigliabile trattare i punti di dati mancanti come se violassero la regola, in quanto ciò potrebbe indicare un problema. Tuttavia, per un parametro che genera punti dati solo quando si verifica un errore, ad esempio `ThrottledRequests` in Amazon DynamoDB, i dati mancanti potrebbero venire trattati come `notBreaching`. Il comportamento predefinito è `missing`.
**Importante**
Gli allarmi configurati sulle metriche Amazon EC2 possono assumere temporaneamente lo stato INSUFFICIENT\$1DATA se mancano dei punti dati delle metriche. Si tratta di una circostanza rara, ma può verificarsi nel caso di un'interruzione della segnalazione delle metriche, anche quando l'istanza Amazon EC2 è integra. Per gli allarmi sulle metriche di Amazon EC2 configurati per eseguire operazioni di arresto, terminazione, riavvio o ripristino, consigliamo di configurare tali allarmi in modo che trattino i dati mancanti come `missing` e che questi allarmi si attivino solo nello stato ALARM.
La scelta dell'opzione migliore per il tuo allarme previene modifiche della condizione dell'allarme non necessarie e fuorvianti e indica anche in maniera più accurata la verifica del sistema.
**Importante**
Gli allarmi che valutano le metriche nel `AWS/DynamoDB` namespace ignorano per impostazione predefinita i dati mancanti. Puoi ignorarlo se scegli un'opzione diversa per il modo in cui l'allarme deve trattare i dati mancanti. Quando un`AWS/DynamoDB`parametro ha dati mancanti, gli allarmi che valutano quel parametro rimangono nello stato attuale.
## Come viene valutato lo stato dell'allarme quando mancano i dati
**Ogni volta che un allarme valuta se cambiare stato, CloudWatch tenta di recuperare un numero maggiore di punti dati rispetto al numero specificato come Periodi di valutazione.** L'esatto numero di punti di dati che tenta di recuperare dipende dalla durata del periodo di allarme e se si basa su un parametro con risoluzione standard o ad alta risoluzione. L'intervallo di tempo dei punti dati che tenta di recuperare è *l'intervallo di valutazione*.
Una volta CloudWatch recuperati questi punti dati, accade quanto segue:
+ Se non mancano punti dati nell'intervallo di valutazione, CloudWatch valuta l'allarme in base ai punti dati più recenti raccolti. Il numero di punti dati valutato è uguale agli **Evaluation Periods** (Periodi di valutazione) per l'allarme. I punti dati aggiuntivi provenienti da un punto più indietro nel tempo nell'intervallo di valutazione non sono necessari e vengono ignorati.
+ Se mancano alcuni punti dati nell'intervallo di valutazione, ma il numero totale di punti dati esistenti che sono stati recuperati con successo dall'intervallo di valutazione è uguale o superiore ai **Periodi di valutazione** dell'allarme, CloudWatch valuta lo stato dell'allarme in base ai punti dati reali più recenti che sono stati recuperati con successo, inclusi i punti dati aggiuntivi necessari da più lontano nell'intervallo di valutazione. In questo caso, il valore impostato per la modalità di gestione dei dati mancanti non è necessario e verrà ignorato.
+ Se mancano alcuni punti dati nell'intervallo di valutazione e il numero di punti dati effettivi recuperati è inferiore al numero di **periodi di valutazione** dell'avviso, CloudWatch inserisce i punti dati mancanti con il risultato specificato per il trattamento dei dati mancanti, quindi valuta l'allarme. Tuttavia, tutti i punti dati reali nell'intervallo di valutazione sono inclusi nella valutazione. CloudWatch utilizza i punti dati mancanti solo il minor numero di volte possibile.
**Nota**
Un caso particolare di questo comportamento è che gli CloudWatch allarmi potrebbero rivalutare ripetutamente l'ultimo set di punti dati per un periodo di tempo dopo che la metrica ha smesso di scorrere. Questa rivalutazione può comportare la modifica dello stato dell'allarme e una nuova esecuzione delle operazioni, se lo stato fosse stato modificato immediatamente prima dell'arresto del flusso del parametro. Per mitigare questo comportamento, utilizzare periodi più brevi.
Le seguenti tabelle illustrano esempi del comportamento di valutazione dell'allarme. **Nella prima tabella, **Datapoints to Alarm e Evaluation Periods sono entrambi** 3.** CloudWatch recupera i 5 punti dati più recenti durante la valutazione dell'allarme, nel caso in cui manchino alcuni dei 3 punti dati più recenti. 5 è l'intervallo di valutazione dell'allarme.
Nella colonna 1 vengono visualizzati i 5 punti dati più recenti, poiché l'intervallo di valutazione è 5. Questi punti dati vengono visualizzati con il punto di dati più recente a destra. 0 è un punto di dati che non supera la soglia, X è un punto di dati che viola la soglia e - è un punto di dati mancante.
Nella colonna 2 sono mostrati quanti dei 3 punti di dati necessari risultano mancanti. Anche se vengono valutati gli ultimi 5 punti di dati, ne sono necessari solo 3 (l'impostazione di **Evaluation Periods** (Periodi di valutazione)) per valutare lo stato dell'allarme. Il numero di punti di dati nella colonna 2 rappresenta il numero di dati che devono essere "riempiti", utilizzando l'impostazione relativa al trattamento dei dati mancanti.
Nelle colonne 3-6, le intestazioni di colonna sono i valori possibili per come trattare i dati mancanti. Le righe di queste colonne mostrano lo stato di allarme impostato per ciascuno di questi modi possibili per trattare i dati mancanti.
| Punti di dati | N di punti di dati che devono essere riempiti | MANCANTE | IGNORA | VIOLAZIONE | NON VIOLAZIONE |
| --- | --- | --- | --- | --- | --- |
| 0 - X - X | 0 | `OK` | `OK` | `OK` | `OK` |
| - - - - 0 | 2 | `OK` | `OK` | `OK` | `OK` |
| - - - - - | 3 | `INSUFFICIENT_DATA` | Mantieni lo stato attuale | `ALARM` | `OK` |
| 0 X X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| - - X - - | 2 | `ALARM` | Mantieni lo stato attuale | `ALARM` | `OK` |
Nella seconda riga della tabella precedente, l'allarme rimane `OK` anche se i dati mancanti vengono trattati come violazione, perché il singolo punto dati esistente non sta effettuando una violazione e questo aspetto viene valutato insieme a due punti dati mancanti trattati come violazione. La prossima volta in cui questo allarme viene valutato, se i dati sono ancora mancanti si visualizzerà `ALARM` e il punto dati di non-violazione non rientrerà più nell'intervallo di valutazione.
La terza riga, in cui mancano tutti e cinque i punti di dati più recenti, illustra come le varie impostazioni per il trattamento dei dati mancanti influiscano sullo stato dell'allarme. Se i punti di dati mancanti sono considerati una violazione, l'allarme entra in stato ALARM, mentre se non sono considerati una violazione, l'allarme entra in stato OK. Se i punti di dati mancanti vengono ignorati, l'allarme mantiene lo stato corrente che aveva prima dei punti di dati mancanti. E se i punti di dati mancanti sono solo considerati mancanti, allora l'allarme non ha abbastanza dati reali recenti per effettuare una valutazione ed entra nello stato INSUFFICIENT\$1DATA.
Nella quarta riga, l'allarme entra nello stato `ALARM` in tutti i casi perché i tre punti di dati più recenti costituiscono una violazione, e gli **Evaluation Periods** (Periodi di valutazione) e i **Datapoints to Alarm** (Punti di dati all'allarme) sono entrambi impostati su 3. In questo caso, il punto di dati mancante viene ignorato e l'impostazione della modalità di valutazione dei dati mancanti non è necessaria, poiché sono disponibili 3 punti di dati reali da valutare.
La riga 5 rappresenta un caso speciale di valutazione dell'allarme chiamato *stato di allarme prematuro*. Per ulteriori informazioni, consulta la pagina [Evitare transizioni premature allo stato di allarme](#CloudWatch-alarms-avoiding-premature-transition).
Nella tabella seguente, il **Period** (Periodo) è di nuovo impostato su 5 minuti e **Datapoints to Alarm** (Punti dati all'allarme) è solo 2 mentre i **Evaluation Periods** (Periodi di valutazione) è 3. Questo è un 2 su 3, allarme M di N.
L'intervallo di valutazione è 5. Questo è il numero massimo di punti dati recenti che vengono recuperati e che è possibile utilizzare nel caso in cui alcuni punti dati risultino mancanti.
| Punti di dati | Numero di punti di dati mancanti | MANCANTE | IGNORA | VIOLAZIONE | NON VIOLAZIONE |
| --- | --- | --- | --- | --- | --- |
| 0 - X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| 0 0 X 0 X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| 0 - X - - | 1 | `OK` | `OK` | `ALARM` | `OK` |
| - - - - 0 | 2 | `OK` | `OK` | `ALARM` | `OK` |
| - - - - X | 2 | `ALARM` | Mantieni lo stato attuale | `ALARM` | `OK` |
Nelle righe 1 e 2, l'allarme passa sempre allo stato ALARM perché 2 dei 3 punti di dati più recenti stanno costituendo una violazione. Nella riga 2, i due punti di dati più vecchi nell'intervallo di valutazione non sono necessari perché non manca nessuno dei tre punti di dati più recenti, quindi questi due punti di dati meno recenti vengono ignorati.
Nelle righe 3 e 4, l'allarme passa allo stato ALARM solo se i dati mancanti vengono trattati come violazione, nel qual caso i due punti di dati mancanti più recenti vengono entrambi trattati come violazione. Nella riga 4, questi due punti di dati mancanti trattati come una violazione forniscono i due punti di dati oggetto violazione necessari per attivare lo stato ALARM.
La riga 5 rappresenta un caso speciale di valutazione dell'allarme chiamato *stato di allarme prematuro*. Per ulteriori informazioni, consulta la sezione seguente.
### Evitare transizioni premature allo stato di allarme
CloudWatch la valutazione degli allarmi include una logica per cercare di evitare falsi allarmi, in cui l'allarme passa prematuramente allo stato ALARM quando i dati sono intermittenti. L'esempio mostrato nella riga 5 delle tabelle della sezione precedente illustra questa logica. In queste righe e negli esempi seguenti, gli **Evaluation Periods** (Periodi di valutazione) sono 3 e l'intervallo di valutazione è di 5 punti di dati. **Datapoints to Alarm** (Punti di dati all'allarme) è 3, ad eccezione dell'esempio M di N, dove **Datapoints to alarm** (Punti di dati all'allarme) è 2.
Supponiamo che i dati più recenti di un allarme siano `- - - - X`, con quattro punti di dati mancanti e quindi un punto di dati oggetto di violazione come punto di dati più recente. Poiché il punto di dati successivo potrebbe non costituire una violazione, l'allarme non entra immediatamente in stato ALARM quando i dati sono `- - - - X` o `- - - X -` e **Datapoints to Alarm** (Punti di dati all'allarme) è 3. In questo modo, i falsi positivi vengono evitati quando il punto di dati successivo non costituisce una violazione e fa sì che i dati siano `- - - X O` o `- - X - O`.
Tuttavia, se gli ultimi punti di dati sono `- - X - -`, l'allarme entra in stato ALARM anche se i punti di dati mancanti vengono trattati come mancanti. Questo perché gli allarmi sono progettati per entrare sempre nello stato ALARM quando il punto di dati oggetto di violazione meno recente disponibile durante il numero di **Periodi di valutazione** di punti di dati è vecchio almeno quanto il valore di **Punti di dati all'allarme** e tutti gli altri punti di dati più recenti costituiscono una violazione o sono mancanti. In questo caso, l'allarme entra in stato ALARM anche se il numero totale di punti di dati disponibili è inferiore a M (**Datapoints to Alarm** (Punti di dati all'allarme)).
Questa logica di allarme si applica anche a M allarmi su N. Se il punto di dati oggetto di violazione meno recente durante l'intervallo di valutazione è vecchio almeno quanto il valore di **Datapoints to Alarm** (Punti di dati all'allarme) e tutti i punti di dati più recenti costituiscono una violazione o sono mancanti, l'allarme entra in stato ALARM indipendentemente dal valore di M (**Datapoints to Alarm** (Punti di dati all'allarme)).
## Dati mancanti negli allarmi di Metrics Insights CloudWatch
**Allarmi basati su query di Metrics Insights che si aggregano in un'unica serie temporale**
Gli scenari di dati mancanti e i loro effetti sulla valutazione degli allarmi sono gli stessi di un allarme metrico standard in termini di trattamento configurato dei dati mancanti. Per informazioni, consultare [Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](#alarms-and-missing-data).
**Allarmi basati su interrogazioni di Metrics Insights che producono più serie temporali**
Gli scenari relativi ai dati mancanti per gli allarmi di Metrics Insights si verificano quando:
+ I singoli punti dati all'interno di una serie temporale non sono presenti.
+ Una o più serie temporali scompaiono quando si valuta su più serie temporali.
+ L'interrogazione non recupera alcuna serie temporale.
Gli scenari di dati mancanti influiscono sulla valutazione degli allarmi nel modo seguente:
+ Per la valutazione di una serie temporale, il trattamento dei dati mancanti viene applicato ai singoli punti dati all'interno della serie temporale. Ad esempio, se vengono interrogati 3 punti dati per le serie temporali ma ne viene ricevuto solo 1, 2 punti dati seguirebbero la configurazione dei dati mancanti configurata.
+ Se una serie temporale non viene più recuperata dalla query, passerà al trattamento dei dati mancanti indipendentemente dal trattamento. `OK` Le azioni di allarme associate alla `OK` transizione a livello di contributore vengono eseguite e viene `StateReason` specificato che il suddetto collaboratore non è stato trovato con il messaggio «Nessun dato è stato restituito per questo collaboratore». Lo stato dell'allarme dipenderà dallo stato degli altri contributori che sono stati recuperati dalla query.
+ A livello di allarme, se la query restituisce un risultato vuoto (nessuna serie temporale), l'allarme passerà a `INSUFFICIENT_DATA` qualsiasi trattamento dei dati mancanti impostato.
# Come vengono gestiti i dati parziali
## Come vengono valutati i dati parziali di una query di Approfondimenti sulle metriche
Se la query di Approfondimenti sulle metriche utilizzata per l'allarme corrisponde a più di 10.000 parametri, l'allarme viene valutato in base ai primi 10.000 parametri trovati dalla query. Ciò significa che l'allarme viene valutato sulla base di dati parziali.
Per sapere se un allarme di Approfondimenti sulle metriche sta valutando il suo stato di allarme sulla base di dati parziali, puoi utilizzare i seguenti metodi:
+ Nella console, quando selezioni un allarme per visualizzare la pagina **Details** (Dettagli), viene mostrato il messaggio **Evaluation warning: Not evaluating all data** (Avviso di valutazione: impossibile valutare tutti i dati).
+ Il valore `PARTIAL_DATA` nel `EvaluationState` campo viene visualizzato quando si utilizza il comando [describe-alarms o l'API](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/describe-alarms.html?highlight=describe%20alarms) AWS CLI . [ DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html)
Gli allarmi pubblicano anche eventi su Amazon EventBridge quando passa allo stato parziale dei dati, quindi puoi creare una EventBridge regola per controllare questi eventi. In questi eventi, il campo `evaluationState` presenta il valore `PARTIAL_DATA`. Di seguito è riportato un esempio di :
```
{
"version": "0",
"id": "12345678-3bf9-6a09-dc46-12345EXAMPLE",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-11-08T11:26:05Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:my-alarm-name"
],
"detail": {
"alarmName": "my-alarm-name",
"state": {
"value": "ALARM",
"reason": "Threshold Crossed: 3 out of the last 3 datapoints [20000.0 (08/11/22 11:25:00), 20000.0 (08/11/22 11:24:00), 20000.0 (08/11/22 11:23:00)] were greater than the threshold (0.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2022-11-08T11:26:05.399+0000\",\"startDate\":\"2022-11-08T11:23:00.000+0000\",\"period\":60,\"recentDatapoints\":[20000.0,20000.0,20000.0],\"threshold\":0.0,\"evaluatedDatapoints\":[{\"timestamp\":\"2022-11-08T11:25:00.000+0000\",\"value\":20000.0}]}",
"timestamp": "2022-11-08T11:26:05.401+0000",
"evaluationState": "PARTIAL_DATA"
},
"previousState": {
"value": "INSUFFICIENT_DATA",
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2022-11-08T11:25:51.227+0000"
},
"configuration": {
"metrics": [
{
"id": "m2",
"expression": "SELECT SUM(PartialDataTestMetric) FROM partial_data_test",
"returnData": true,
"period": 60
}
]
}
}
}
```
Se la query per l'allarme include un'istruzione GROUP BY che inizialmente restituisce più di 500 serie temporali, l'allarme viene valutato in base alle prime 500 serie temporali rilevate dalla query. Tuttavia, se utilizzi una clausola ORDER BY, tutte le serie temporali rilevate dalla query vengono ordinate e le 500 serie temporali con valori più alti o più bassi in base alla clausola ORDER BY vengono utilizzate per valutare l'allarme.
## Come vengono valutati i dati parziali provenienti da un allarme proveniente da più fonti di dati
Se la funzione Lambda restituisce dati parziali:
+ L'allarme continua a essere valutato sui punti dati restituiti.
+ Per sapere se un allarme su una funzione Lambda sta valutando il suo stato di allarme sulla base di dati parziali, puoi utilizzare i seguenti metodi:
+ Nella console, seleziona un allarme e scegli la pagina **Dettagli**. Se in quella pagina viene visualizzato il messaggio **Avviso di valutazione: impossibile valutare tutti i dati**, la valutazione è basata su dati parziali.
+ Se vedi il valore `PARTIAL_DATA` nel `EvaluationState` campo quando usi il `describe-alarms` AWS CLI comando o l' DescribeAlarms API, significa che si tratta di una valutazione in base a dati parziali.
+ Un allarme pubblica anche gli eventi su Amazon EventBridge quando passa allo stato parziale dei dati.
# Allarmi basati su percentile ed esempi di dati ridotti
Quando si imposta un percentile come la statistica per un allarme, puoi specificare come gestire i dati che non sono sufficienti per una buona valutazione statistica. Puoi scegliere di impostare l'allarme in modo che valuti in ogni caso le statistiche e, possibilmente, modifichi lo stato dell'allarme. In alternativa, puoi impostare l'allarme in modo che ignori il parametro quando le dimensioni dell'esempio sono ridotte e in modo che attenda per valutarli finché non sono presenti abbastanza dati per essere significativi a livello statistico.
Per percentili tra 0,5 (incluso) e 1,00 (escluso), questa impostazione viene utilizzata quando sono presenti meno punti di dati di 10/(1-percentile) durante il periodo di valutazione. Ad esempio, questa impostazione potrebbe essere utilizzata se fossero presenti meno di 1.000 esempi per un allarme su un percentile di p99. Per percentili tra 0 e 0,5 (escluso), l'impostazione viene utilizzata quando sono presenti meno punti di dati di 10/percentile.
# Allarmi ProMQL
Un allarme PromQL monitora le metriche utilizzando una query istantanea Prometheus Query Language (PromQL). La query seleziona le metriche inserite tramite l'endpoint CloudWatch OTLP e tutte le serie temporali corrispondenti restituite dalla query vengono considerate violazioni. *L'allarme valuta la query a intervalli regolari e tiene traccia di ogni serie temporale di violazione in modo indipendente come collaboratore.*
Per informazioni sull'utilizzo delle metriche di acquisizione, consulta. OpenTelemetry [OpenTelemetry](CloudWatch-OpenTelemetry-Sections.md)
## Come funzionano gli allarmi ProMQL
Un allarme PromQL valuta una query istantanea PromQL su una pianificazione ricorrente definita da. `EvaluationInterval` La query restituisce solo le serie temporali che soddisfano la condizione. Ogni serie temporale restituita è un *contributore*, identificato dal relativo set di attributi univoco.
L'allarme utilizza transizioni di stato basate sulla durata:
+ *Quando un collaboratore viene restituito dalla query, viene considerata una violazione.* Se il contributore continua a violare per la durata specificata da`PendingPeriod`, passa allo stato. `ALARM`
+ *Quando un collaboratore smette di essere restituito dalla query, viene considerato un ripristino.* Se il collaboratore rimane assente per la durata specificata da`RecoveryPeriod`, torna allo stato. `OK`
L'allarme viene attivato quando almeno un collaboratore ha violato la legge per un periodo superiore al periodo in sospeso. `ALARM` L'allarme torna `OK` allo stato quando tutti i contributori si sono ripresi.
## Configurazione degli allarmi ProMQL
Un allarme PromQL è configurato con i seguenti parametri:
+ **PendingPeriod**è la durata in secondi che un contributore deve continuamente violare prima che passi allo stato. `ALARM` Equivale alla durata della regola di avviso Prometheus. `for`
+ **RecoveryPeriod**è la durata in secondi che un contributore deve interrompere prima che torni allo stato. `OK` Equivale alla durata della regola di avviso Prometheus. `keep_firing_for`
+ **EvaluationInterval**è la frequenza, in secondi, con cui l'allarme valuta la query PromQL.
Per creare un allarme ProMQL, vedere. [Creare un allarme utilizzando una query PromQL](Create_PromQL_Alarm.md)
# Allarmi compositi
Con CloudWatch, puoi combinare più allarmi in un unico *allarme composito* per creare un indicatore di stato riepilogato e aggregato su un'intera applicazione o gruppo di risorse. Gli allarmi compositi sono allarmi che determinano il loro stato monitorando gli stati di altri allarmi. Definisci le regole per combinare lo stato degli allarmi monitorati utilizzando la logica booleana.
È possibile utilizzare allarmi compositi per ridurre il rumore dell'allarme intraprendendo operazioni solo a livello aggregato. Ad esempio, puoi creare un allarme composito affinché il team del tuo server web riceva una notifica se si attiva un qualsiasi allarme relativo al server web. Quando uno di questi allarmi entra nello stato ALARM, l'allarme composito entra automaticamente nello stato ALARM e invia una notifica al team. Se anche altri allarmi relativi al server web entrano nello stato ALARM, il team non viene sovraccaricato di nuove notifiche poiché l'allarme composito li ha già informati della situazione.
Puoi anche utilizzare gli allarmi compositi per creare condizioni di allarme complesse e agire solo quando vengono soddisfatte molte condizioni diverse. Ad esempio, è possibile creare un allarme composito che combini un allarme CPU e un allarme di memoria e invii una notifica al team solo se si sono attivati sia gli allarmi relativi alla CPU sia quelli relativi alla memoria.
**Utilizzo degli allarmi compositi**
Quando utilizzi gli allarmi compositi, hai due possibilità:
+ Configurare le operazioni che desideri intraprendere solo a livello di allarme composito e creare gli allarmi monitorati sottostanti senza operazioni
+ Configurare un diverso insieme di operazioni a livello di allarme composito. Ad esempio, le operazioni di allarme composito potrebbero coinvolgere un team diverso in caso di un problema diffuso.
Gli allarmi compositi possono effettuare soltanto le operazioni seguenti:
+ Notifica di argomenti Amazon SNS
+ Richiamo delle funzioni Lambda
+ Crea OpsItems in Systems Manager Ops Center
+ Creazione di incidenti in Systems Manager Incident Manager
**Nota**
Tutti gli allarmi sottostanti dell'allarme composito devono trovarsi nello stesso account e nella stessa regione dell'allarme composito. Tuttavia, se imposti un allarme composito in un account di monitoraggio CloudWatch dell'osservabilità tra più account, gli allarmi sottostanti possono controllare le metriche in diversi account di origine e nell'account di monitoraggio stesso. Per ulteriori informazioni, consulta [CloudWatch osservabilità tra più account](CloudWatch-Unified-Cross-Account.md).
Un singolo allarme composito può monitorare 100 allarmi sottostanti e 150 allarmi compositi possono monitorare un singolo allarme sottostante.
**Espressioni di regola**
Tutti gli allarmi composti contengono espressioni di regole. Le espressioni delle regole indicano agli allarmi compositi quali altri allarmi monitorare e determinare i loro stati. Espressioni di regola può riferirsi ad allarmi dei parametri e ad altri allarmi compositi. Quando si fa riferimento a un allarme in un'espressione di regola, si designa una funzione all'allarme che determina in quale dei tre stati seguenti si troverà l'allarme:
+ ALLARME
ALARM ("alarm-name or alarm-ARN") è TRUE se l'allarme è in stato ALARM.
+ OK
OK ("alarm-name or alarm-ARN") è TRUE se l'allarme è in stato OK.
+ INSUFFICIENT\$1DATA
INSUFFICIENT\$1DATA ("alarm-name or alarm-ARN") è TRUE se l'allarme denominato è in stato INSUFFICIENT\$1DATA.
**Nota**
TRUE restituisce sempre TRUE e FALSE restituisce sempre FALSE
**Riferimenti agli allarmi**
Quando si fa riferimento a un allarme, utilizzando il nome dell'allarme o l'ARN, la sintassi della regola può supportare il riferimento all'allarme con o senza virgolette («) attorno al nome dell'allarme o all'ARN.
+ Se specificato senza virgolette, i nomi degli allarmi non ARNs devono contenere spazi, parentesi tonde o virgole.
+ Se specificati tra virgolette, i nomi degli allarmi o *quelli ARNs che includono* virgolette doppie («) devono racchiudere i caratteri" utilizzando la barra inversa di escape (\$1) per una corretta interpretazione del riferimento.
**Sintassi**
La sintassi dell'espressione utilizzata per combinare più allarmi in un unico allarme composito utilizza la logica e le funzioni booleane. La tabella seguente descrive gli operatori e le funzioni disponibili nelle espressioni delle regole:
| Operatore/funzione | Description |
| --- | --- |
| AND | Operatore AND logico. Restituisce TRUE quando tutte le condizioni specificate sono VERE. |
| OR | Operatore OR logico. Restituisce TRUE quando almeno una delle condizioni specificate è VERA. |
| NOT | Operatore NOT logico. Restituisce TRUE quando la condizione specificata è FALSA. |
| AT\$1LEAST | Funzione che restituisce TRUE quando un numero o una percentuale minima di allarmi specificati si trova nello stato richiesto. Formato: AT\$1LEAST(M, STATE\$1CONDITION, (alarm1, alarm2, ...alarmN)) dove M può essere un numero o una percentuale assoluti (ad esempio, 50%) e STATE\$1CONDITION può essere ALARM, OK, INSUFFICIENT\$1DATA, NOT ALARM, NOT OK o NOT INSUFFICIENT\$1DATA. |
È possibile utilizzare le parentesi per raggruppare le condizioni e controllare l'ordine di valutazione nelle espressioni complesse.
**Espressioni di esempio**
Il parametro request `AlarmRule` supporta l'uso degli operatori logici e `AND` `OR``NOT`, oltre alla `AT_LEAST` funzione, consente di combinare più funzioni in un'unica espressione. Le seguenti espressioni di esempio mostrano come configurare gli allarmi sottostanti nell'allarme composito:
+ `ALARM(CPUUtilizationTooHigh) AND ALARM(DiskReadOpsTooHigh)`
L'espressione specifica che l'allarme composito entra in stato `ALARM` solo se `CPUUtilizationTooHigh` e `DiskReadOpsTooHigh` sono in stato `ALARM`.
+ `AT_LEAST(2, ALARM, (WebServer1CPU, WebServer2CPU, WebServer3CPU, WebServer4CPU))`
L'espressione specifica che l'allarme composito si attiva `ALARM` quando almeno 2 dei 4 allarmi CPU del server Web sono attivi. `ALARM` Ciò consente di attivare avvisi in base a una soglia di risorse interessate anziché richiedere che tutte o solo una si trovi in stato di allarme.
+ `AT_LEAST(50%, OK, (DatabaseConnection1, DatabaseConnection2, DatabaseConnection3, DatabaseConnection4))`
L'espressione specifica che l'allarme composito si attiva `ALARM` quando almeno il 50% degli allarmi di connessione al database è attivo. `OK` L'utilizzo delle percentuali consente alla regola di adattarsi dinamicamente man mano che si aggiungono o rimuovono allarmi monitorati.
+ `ALARM(CPUUtilizationTooHigh) AND NOT ALARM(DeploymentInProgress)`
L'espressione specifica che l'allarme composito entra in stato `ALARM` se `CPUUtilizationTooHigh` è in stato `ALARM` e `DeploymentInProgress` non è in stato `ALARM`. Questo è un esempio di allarme composito che riduce il rumore di allarme durante una finestra di implementazione.
+ `AT_LEAST(2, ALARM, (AZ1Health, AZ2Health, AZ3Health)) AND NOT ALARM(MaintenanceWindow)`
L'espressione specifica che l'allarme composito si attiva `ALARM` quando almeno 2 allarmi `ALARM` sullo stato di salute delle zone di disponibilità su 3 sono attivi e l'allarme relativo alla finestra di manutenzione non è attivo. `ALARM` Ciò combina la funzione AT\$1LEAST con altri operatori logici per scenari di monitoraggio più complessi.
# Soppressione degli allarmi
La soppressione composita delle azioni di allarme consente di disabilitare temporaneamente le azioni di allarme senza eliminare o modificare la configurazione dell'allarme. Ciò è utile durante la manutenzione pianificata, le implementazioni o quando si esaminano problemi noti.
Con la soppressione dell'operazione di allarme composita, si definiscono allarmi come allarmi soppressori. Gli allarmi soppressori impediscono agli allarmi compositi di agire. Ad esempio, è possibile specificare un allarme soppressore che rappresenta lo stato di una risorsa di supporto. Se la risorsa di supporto è inattiva, l'allarme soppressore impedisce all'allarme composito di inviare notifiche.
## Quando utilizzare la soppressione degli allarmi
Situazioni comuni in cui la soppressione degli allarmi è utile:
+ Finestre di manutenzione dell'applicazione
+ Implementazioni delle applicazioni
+ Indagine sugli incidenti in corso
+ Attività di test e sviluppo
## Come funzionano gli allarmi soppressori
Gli allarmi soppressori vengono specificati quando si configurano gli allarmi compositi. Qualsiasi allarme può funzionare come un allarme soppressore. Quando un allarme soppressore cambia stato da `OK` a `ALARM`, il suo allarme composito smette di agire. Quando un allarme soppressore cambia stato da `ALARM` a `OK`, il suo allarme composito riprende ad agire.
Poiché gli allarmi compositi consentono di ottenere una visione aggregata dello stato di integrità attraverso più allarmi, esistono alcune situazioni comuni in cui è previsto che tali allarmi si attivino, ad esempio, durante una finestra di manutenzione dell'applicazione o quando si indaga su un incidente in corso. In tali situazioni, potresti voler sopprimere le operazioni degli allarmi compositi, per evitare notifiche indesiderate o la creazione di nuove segnalazioni di incidenti.
Con la soppressione dell'operazione di allarme composita, si definiscono allarmi come allarmi soppressori. Gli allarmi soppressori impediscono agli allarmi compositi di agire. Ad esempio, è possibile specificare un allarme soppressore che rappresenta lo stato di una risorsa di supporto. Se la risorsa di supporto è inattiva, l'allarme soppressore impedisce all'allarme composito di inviare notifiche. La soppressione delle operazioni di allarmi compositi aiuta a ridurre il rumore degli allarmi, in modo da dedicare meno tempo alla gestione degli allarmi e più tempo a concentrarsi sulle operazioni.
Gli allarmi soppressori vengono specificati quando si configurano gli allarmi compositi. Qualsiasi allarme può funzionare come un allarme soppressore. Quando un allarme soppressore cambia stato da `OK` a `ALARM`, il suo allarme composito smette di agire. Quando un allarme soppressore cambia stato da `ALARM` a `OK`, il suo allarme composito riprende ad agire.
### `WaitPeriod` e `ExtensionPeriod`
Quando si specifica un allarme soppressore, si impostano i parametri `WaitPeriod` e `ExtensionPeriod`. Questi parametri impediscono agli allarmi compositi di agire in modo imprevisto mentre gli allarmi soppressori cambiano stato. Utilizza `WaitPeriod` per compensare eventuali ritardi che possono verificarsi quando un allarme soppressore cambia da `OK` a `ALARM`. Ad esempio, se un allarme soppressore cambia da `OK` a `ALARM` entro 60 secondi, imposta `WaitPeriod` a 60 secondi.
![\[Soppressione delle azioni interne WaitPeriod\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/example1border.png)
Nell'immagine, l'allarme composito cambia da `OK` a `ALARM` a t2. Un `WaitPeriod` inizia a t2 e termina a t8. Questo dà all'allarme soppressore il tempo di cambiare stato da `OK` a `ALARM` a t4 prima di sopprimere le operazioni dell'allarme composito quando il `WaitPeriod` scade al t8.
Utilizza `ExtensionPeriod` per compensare eventuali ritardi che possono verificarsi quando un allarme composito cambia `OK` a seguito di un allarme soppressore che cambia in `OK`. Ad esempio, se un allarme composito cambia in `OK` entro 60 secondi dal passaggio di un allarme soppressore a `OK`, imposta `ExtensionPeriod` a 60 secondi.
![\[Soppressione delle azioni all'interno ExtensionPeriod\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/example2border.png)
Nell'immagine, l'allarme soppressore cambia da `ALARM` a `OK` a t2. Un `ExtensionPeriod` inizia a t2 e termina a t8. Questo dà all'allarme composito il tempo di passare da `ALARM` a `OK` prima della scadenza di `ExtensionPeriod` a t8.
Gli allarmi compositi non intervengono quando `WaitPeriod` e `ExtensionPeriod` diventano attivi. Gli allarmi compositi eseguono operazioni basate sui loro stati correnti quando `ExtensionPeriod` e `WaitPeriod` diventano inattivi. Ti consigliamo di impostare il valore per ogni parametro su 60 secondi, poiché valuta gli allarmi metrici ogni minuto. È possibile impostare i parametri su qualsiasi numero intero in secondi.
Gli esempi seguenti descrivono in modo più dettagliato come `WaitPeriod` e `ExtensionPeriod` impediscono che gli allarmi compositi intraprendano operazioni impreviste.
**Nota**
Negli esempi seguenti, `WaitPeriod` è configurato come 2 unità di tempo e `ExtensionPeriod` è configurato come 3 unità di tempo.
#### Esempi
** Esempio 1: le operazioni non vengono soppresse dopo `WaitPeriod` **
![\[primo esempio di soppressione dell'operazione\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/example3border.png)
Nell'immagine, l'allarme composito cambia stato da `OK` a `ALARM` a t2. Un `WaitPeriod` inizia a t2 e termina a t4, in modo che possa impedire all'allarme composito di agire. Dopo la scadenza del `WaitPeriod`a t4, l'allarme composito compie le sue operazioni perché l'allarme soppressore è ancora attivo `OK`.
** Esempio 2: le operazioni vengono soppresse dall'allarme prima della scadenza di `WaitPeriod` **
![\[secondo esempio di soppressione dell'operazione\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/example4border.png)
Nell'immagine, l'allarme composito cambia stato da `OK` a `ALARM` a t2. Un `WaitPeriod` inizia a t2 e termina a t4. Questo dà all'allarme soppressore il tempo di cambiare stato da `OK` a `ALARM` a t3. Perché l'allarme soppressore cambia stato `OK` a `ALARM` a t3, il `WaitPeriod` che è iniziato a t2 viene scartato e l'allarme soppressore ora impedisce all'allarme composito di agire.
** Esempio 3: transizione di stato quando le operazioni vengono soppresse da `WaitPeriod` **
![\[terzo esempio di soppressione dell'operazione\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/example5border.png)
Nell'immagine, l'allarme composito cambia stato da `OK` a `ALARM` a t2. Un `WaitPeriod` inizia a t2 e termina a t4. Questo dà all'allarme soppressore il tempo di cambiare stato. L'allarme composito torna a `OK` a t3, quindi il `WaitPeriod` che è iniziato a t2 viene scartato. Un nuovo `WaitPeriod` inizia a t3 e termina a t5. Dopo la scadenza del nuovo `WaitPeriod` a t5, l'allarme composito compie le sue operazioni.
** Esempio 4: transizione di stato quando le operazioni vengono soppresse da un allarme **
![\[quarto esempio di soppressione dell'operazione\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/cwasexamplefourborder.png)
Nell'immagine, l'allarme composito cambia stato da `OK` a `ALARM` a t2. L'allarme soppressore è già in stato `ALARM`. L'allarme soppressore impedisce all'allarme composito di agire.
** Esempio 5: le operazioni non vengono soppresse dopo `ExtensionPeriod` **
![\[quinto esempio di soppressione dell'operazione\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/example7border.png)
Nell'immagine, l'allarme composito cambia stato da `OK` a `ALARM` a t2. Un `WaitPeriod` inizia a t2 e termina a t4. Questo dà all'allarme soppressore il tempo di cambiare stato da `OK` a `ALARM` a t3 prima che sopprime le operazioni dell'allarme composito fino a t6. Perché l'allarme soppressore cambia stato `OK` a `ALARM` a t3, il `WaitPeriod` che è iniziato a t2 viene scartato. A t6, l'allarme soppressore cambia in `OK`. Un `ExtensionPeriod` inizia a t6 e termina a t9. Dopo la scadenza di `ExtensionPeriod`, l'allarme composito esegue le sue operazioni.
** Esempio 6: transizione di stato quando le operazioni vengono soppresse da `ExtensionPeriod` **
![\[sesto esempio di soppressione dell'operazione\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/cwasexamplesixrborder.png)
Nell'immagine, l'allarme composito cambia stato da `OK` a `ALARM` a t2. Un `WaitPeriod` inizia a t2 e termina a t4. Questo dà all'allarme soppressore il tempo di cambiare stato da `OK` a `ALARM` a t3 prima che sopprime le operazioni dell'allarme composito fino a t6. Perché l'allarme soppressore cambia stato `OK` a `ALARM` a t3, il `WaitPeriod` che è iniziato a t2 viene scartato. A t6, l'allarme soppressore torna a `OK`. Un `ExtensionPeriod` inizia a t6 e termina a t9. Quando l'allarme composito torna a `OK` a t7, il `ExtensionPeriod` viene scartato e un nuovo `WaitPeriod` inizia a t7 e termina a t9.
**Suggerimento**
Se si sostituisce l'operazione di allarme soppressore, qualsiasi `WaitPeriod` o `ExtensionPeriod` viene scartato.
## Regole di soppressione e silenziamento delle azioni
Quando per un allarme composito sono attive sia le regole di soppressione delle azioni che quelle di silenziamento degli allarmi, queste ultime hanno la precedenza e sopprimono tutte le azioni di allarme. Al termine della finestra di silenziamento, la configurazione di soppressione delle azioni dell'allarme composito determina se le azioni vengono eseguite in base allo stato dell'allarme di soppressione e ai periodi di attesa o di estensione configurati. Per ulteriori informazioni sulle regole di silenziamento degli allarmi, vedere. [Regole di silenziamento degli allarmi](alarm-mute-rules.md)
# Operazione per gli allarmi
È possibile specificare le operazioni intraprese da un allarme quando cambia stato tra gli stati OK, ALARM e INSUFFICIENT\$1DATA.
È possibile impostare la maggior parte delle operazioni per la transizione in ciascuno dei tre stati. Ad eccezione delle operazioni di dimensionamento automatico, le operazioni si verificano solo nelle transizioni di stato e non vengono più eseguite se la condizione persiste per ore o giorni.
Le seguenti azioni sono supportate come azioni di allarme:
+ Inviare una notifica a uno o più abbonati tramite un argomento Amazon Simple Notification Service. Gli abbonati possono essere sia applicazioni che persone.
+ Richiamare una funzione Lambda. Questo è il modo più semplice per automatizzare le azioni personalizzate relative alle dello stato degli allarmi.
+ Gli allarmi basati su parametri EC2 possono eseguire operazioni EC2, ad esempio l'arresto, l'interruzione, il riavvio o il ripristino di un'istanza EC2.
+ Gli allarmi possono anche eseguire operazioni per dimensionare un gruppo Auto Scaling.
+ Gli allarmi possono essere creati OpsItems in Systems Manager Ops Center o creare incidenti in AWS Systems Manager Incident Manager. Queste operazioni vengono eseguite solo quando l'allarme entra in stato ALARM.
+ Un allarme può avviare un'indagine quando entra in stato ALARM.
Gli allarmi emettono anche eventi Amazon EventBridge quando cambiano stato e possono essere configurati in modo Amazon EventBridge da attivare altre azioni per questi cambiamenti di stato.
## Operazioni degli allarmi e notifiche
La tabella seguente mostra le azioni eseguite per gli allarmi insieme al loro comportamento per gli allarmi con più serie temporali (o contributori):
| Tipo di operazione | Supporto per più allarmi con serie temporali di Metrics Insights | Supporto per PromQL Alarm | Ulteriori informazioni |
| --- | --- | --- | --- |
| Notifiche SNS | Livello di collaboratore | Livello di collaboratore | [Destinazioni per eventi Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html) |
| Operazioni EC2 (arresto, terminazione, riavvio, ripristino) | Non supportata | Non supportata | [Arresta, termina, riavvia o ripristina un'istanza EC2](UsingAlarmActions.md) |
| Operazioni Auto Scaling | Non supportata | Non supportata | [Semplici policy di dimensionamento per fasi per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html) |
| OpsItem Creazione di Systems Manager | Livello di allarme | Non supportata | [Configura CloudWatch gli allarmi da creare OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) |
| Strumento di gestione degli incidenti Systems Manager | Livello di allarme | Non supportata | [Creazione automatica di incidenti con allarmi CloudWatch ](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html#incident-tracking-auto-alarms) |
| Invocazione della funzione Lambda | Livello di collaboratore | Livello di collaboratore | [Invocazione di una funzione Lambda da un allarme](alarms-and-actions-Lambda.md) |
| CloudWatch indagini, indagini | Livello di allarme | Non supportata | [Avvia un' CloudWatch indagine da un allarme](Start-Investigation-Alarm.md) |
Il contenuto delle notifiche di allarme varia a seconda del tipo di allarme:
+ Gli allarmi a metrica singola includono sia un motivo dello stato che dati dettagliati sul motivo dello stato, mostrando i punti dati specifici che hanno causato il cambiamento di stato.
+ Gli allarmi Metrics Insights a più serie temporali forniscono un motivo di stato semplificato per ogni collaboratore, senza il blocco dati dettagliato del motivo dello stato.
+ Gli allarmi PromQL non includono un motivo dello stato o i dati del motivo dello stato nelle loro notifiche.
**Example Esempi di contenuto delle notifiche**
La notifica di allarme a metrica singola include dati dettagliati:
```
{
"stateReason": "Threshold Crossed: 3 out of the last 3 datapoints [32.6 (03/07/25 08:29:00), 33.8 (03/07/25 08:24:00), 41.0 (03/07/25 08:19:00)] were greater than the threshold (31.0)...",
"stateReasonData": {
"version": "1.0",
"queryDate": "2025-07-03T08:34:06.300+0000",
"startDate": "2025-07-03T08:19:00.000+0000",
"statistic": "Average",
"period": 300,
"recentDatapoints": [41, 33.8, 32.6],
"threshold": 31,
"evaluatedDatapoints": [
{
"timestamp": "2025-07-03T08:29:00.000+0000",
"sampleCount": 5,
"value": 32.6
}
// Additional datapoints...
]
}
}
```
Notifica SNS di più serie temporali Metrics Insights Alarm per Contributor, ad esempio:
```
{
"AlarmName": "DynamoDBInsightsAlarm",
"NewStateValue": "ALARM",
"NewStateReason": "Threshold Crossed: 1 datapoint was less than the threshold (1.0). The most recent datapoint which crossed the threshold: [0.0 (01/12/25 13:34:00)].",
"StateChangeTime": "2025-12-01T13:42:04.919+0000",
"OldStateValue": "OK",
"AlarmContributorId": "6d442278dba546f6",
"AlarmContributorAttributes": {
"TableName": "example-dynamodb-table-name"
}
// Additional information...
}
```
Esempio di notifica SNS PromQL Alarm per Contributor:
```
{
"AlarmName": "HighCPUUsageAlarm",
"NewStateValue": "ALARM",
"StateChangeTime": "2025-12-01T13:42:04.919+0000",
"OldStateValue": "OK",
"AlarmContributorId": "1d502278dcd546a1",
"AlarmContributorAttributes": {
"team": "example-team-name"
}
// Additional information...
}
```
## Disattivazione delle azioni di allarme
Le regole di silenziamento degli allarmi consentono di disattivare automaticamente le azioni di allarme durante finestre temporali predefinite, come periodi di manutenzione o eventi operativi. CloudWatch continua a monitorare gli stati degli allarmi prevenendo al contempo le notifiche indesiderate. Per ulteriori informazioni, consulta [Regole di silenziamento degli allarmi](alarm-mute-rules.md).
**Disattiva le regole e disabilita le azioni di allarme**
Le regole di silenziamento degli allarmi disattivano temporaneamente le azioni durante le finestre temporali pianificate e riattivano automaticamente l'audio al termine della finestra. Al contrario, l'`DisableAlarmActions`API disabilita permanentemente le azioni di allarme fino a quando non si effettua una chiamata manuale. `EnableAlarmActions` L'`EnableAlarmActions`API non riattiva gli allarmi disattivati in base a regole di silenziamento attive.
**Nota**
La disattivazione di un allarme non CloudWatch impedisce l'invio di eventi di allarme per la creazione, l'aggiornamento, l'eliminazione e le modifiche allo stato di un allarme su Amazon EventBridge.
# Regole di silenziamento degli allarmi
Alarm Mute Rules è una CloudWatch funzionalità che fornisce un meccanismo per disattivare automaticamente le azioni di allarme durante finestre temporali predefinite. Quando si crea una regola di silenziamento, si definiscono periodi di tempo specifici e si scelgono come target gli allarmi le cui azioni verranno disattivate. CloudWatch continuerà a monitorare e valutare gli stati degli allarmi evitando al contempo notifiche indesiderate o azioni di allarme automatizzate durante gli eventi operativi previsti.
Alarm Mute Rules ti aiuta a gestire scenari operativi critici in cui le azioni di allarme sarebbero inutili o dirompenti. Ad esempio, durante le finestre di manutenzione pianificata, è possibile impedire azioni di allarme automatizzate mentre i sistemi sono intenzionalmente offline o presentano problemi previsti, consentendovi di eseguire la manutenzione senza interruzioni. Per le operazioni durante le ore non lavorative, come i fine settimana o i giorni festivi, è possibile disattivare le azioni di allarme non critiche quando non è richiesta una risposta immediata, riducendo il rumore degli allarmi e le notifiche non necessarie al team operativo. Negli ambienti di test, le regole di silenziamento consentono di disattivare temporaneamente le azioni di allarme durante scenari come i test di carico in cui sono previsti un utilizzo elevato delle risorse o tassi di errore e non richiedono un'attenzione immediata. Quando il team è impegnato attivamente nella risoluzione dei problemi, le regole di silenziamento consentono di evitare che vengano attivate azioni di allarme duplicate, aiutandovi a concentrarvi sulla risoluzione senza essere distratti da notifiche di allarme ridondanti.
## Definizione delle regole di silenziamento degli allarmi
**Le regole di silenziamento degli allarmi possono essere definite utilizzando: **regole e obiettivi**.**
+ **Regole**: definiscono le finestre temporali in cui le azioni di allarme devono essere disattivate. Le regole sono composte da tre attributi:
+ **Espressione**: definisce quando inizia il periodo di silenziamento e come si ripete. È possibile utilizzare due tipi di espressioni:
+ **Espressioni cron**: utilizza la sintassi cron standard per creare finestre mute ricorrenti. Questo approccio è ideale per programmi di manutenzione regolari, come aggiornamenti settimanali del sistema o operazioni di backup giornaliere. Le espressioni Cron consentono di specificare schemi ricorrenti complessi, inclusi giorni della settimana, mesi o orari specifici.
*Sintassi per l'espressione cron*
```
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12) (or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6) (0 or 7 is Sunday, or MON-SUN)
│ │ │ │ │
│ │ │ │ │
* * * * *
```
+ I caratteri`*`,`,`, `-` saranno supportati in tutti i campi.
+ I nomi inglesi possono essere usati per i campi `month` (JAN-DEC) e `day of week` (SUN-SAT)
+ **At expressions: utilizza le espressioni at** per finestre con silenziamento singolo. Questo approccio funziona bene per gli eventi operativi pianificati che si verificano una sola volta in un momento noto.
```
Syntax: `at(yyyy-MM-ddThh:mm)`
```
+ **Durata**: specifica per quanto tempo dura la regola di silenziamento una volta attivata. La durata deve essere specificata nel formato ISO-8601 con un minimo di 1 minuto (PT1M) e un massimo di 15 giorni (P15D).
+ **Fuso orario: specifica il fuso** orario in cui verrà applicata la finestra di silenziamento in base alle espressioni, utilizzando identificatori di fuso orario standard come "». America/Los\$1Angeles" or "Europe/London
+ **Obiettivi**: specifica l'elenco dei nomi degli allarmi le cui azioni verranno disattivate durante le finestre temporali definite. Puoi includere sia allarmi metrici che allarmi compositi nell'elenco degli obiettivi.
Facoltativamente, puoi includere i timestamp di inizio e fine per fornire limiti aggiuntivi per le finestre di silenziamento. I timestamp di inizio assicurano che le regole di silenziamento non si attivino prima di una data e un'ora specifiche, mentre i timestamp di fine impediscono l'applicazione delle regole oltre la data e l'ora specificate.
Per ulteriori informazioni sulla creazione di regole di silenziamento degli allarmi a livello di codice, consulta. [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html)
**Nota**
Gli allarmi mirati devono essere presenti nello stesso Account AWS e nello stesso Regione AWS in cui viene creata la regola di silenziamento.
Una singola regola di silenziamento degli allarmi può indirizzare fino a 100 allarmi in base al nome degli allarmi.
La CloudWatch console include una scheda dedicata «Alarm Mute Rules» che fornisce la gestione centralizzata di tutte le regole di silenziamento all'interno del sistema. Account AWSÈ possibile cercare regole di silenziamento specifiche utilizzando gli attributi delle regole di silenziamento come il nome della regola.
## Stato della regola di silenziamento
Una volta creata, una regola di silenziamento degli allarmi può trovarsi in uno dei tre stati seguenti:
+ **PIANIFICATO**: la regola di silenziamento diventerà attiva in futuro in base all'espressione della finestra temporale configurata.
+ **ATTIVA**: la regola di silenziamento è attualmente attiva in base all'espressione della finestra temporale configurata e disattiva attivamente le azioni di allarme mirate.
+ **SCADUTA**: la regola del silenziamento non sarà SCHEDULED/ACTIVE più valida in futuro. Ciò si verifica per le regole di silenziamento una tantum dopo la fine della finestra di silenziamento o per le regole di silenziamento ricorrenti quando è configurato un timestamp di fine e tale periodo è trascorso.
## Effetti delle regole di silenziamento sugli allarmi
Durante una finestra di silenziamento attiva, quando un allarme mirato cambia stato e ha delle azioni configurate, disattiva l' CloudWatch esecuzione di tali azioni. I silenziamenti vengono applicati solo alle azioni di allarme, il che significa che gli allarmi continuano a essere valutati e le modifiche di stato sono visibili nella CloudWatch console, ma le azioni configurate come le notifiche di Amazon Simple Notification Service, le azioni di Amazon Elastic Compute Cloud Auto Scaling o le azioni Amazon EC2 non possono essere eseguite. CloudWatch continua a valutare normalmente gli stati degli allarmi durante il periodo di silenziamento e puoi visualizzare queste informazioni nella cronologia degli allarmi.
Al termine di una finestra di disattivazione dell'audio, se gli allarmi interessati rimangono in uno stato di allarme (OK/ALARM/INSUFFICIENT\$1DATA), riattiva CloudWatch automaticamente le azioni di allarme che erano state disattivate durante la finestra. Ciò garantisce che le azioni di allarme vengano eseguite per problemi in corso una volta terminato il periodo di silenziamento pianificato, mantenendo l'integrità del sistema di monitoraggio.
**Nota**
Quando disattivi un allarme:
Tutte le azioni associate agli allarmi mirati vengono disattivate
Le azioni associate a tutti gli stati di allarme (OK, ALARM e INSUFFICIENT\$1DATA) vengono disattivate
## Visualizzazione e gestione degli allarmi disattivati
Per informazioni sulla visualizzazione e la gestione degli allarmi disattivati, vedere. [Visualizzazione e gestione degli allarmi disattivati](viewing-managing-muted-alarms.md)
# Come funzionano le regole di silenziamento degli allarmi
I seguenti scenari illustrano come le regole di silenziamento degli allarmi influiscono sugli allarmi mirati e come le azioni di allarme vengono disattivate o eseguite.
**Nota**
La disattivazione di un allarme disattiverà le azioni associate a tutti gli stati di allarme, inclusi OK, ALARM e INSUFFICIENT\$1DATA. I comportamenti illustrati di seguito si applicano alle azioni associate a tutti gli stati di allarme.
Quando disattivi un allarme Metrics Insights, anche tutte le serie di metriche dei contributori relative a quell'allarme vengono disattivate automaticamente.
## Scenario: le azioni di allarme vengono disattivate quando è attiva una regola di silenziamento
Considera che
+ Un allarme ha delle azioni configurate per il suo stato ALARM
+ È programmata una regola di silenziamento degli allarmi attiva da t1 a t5 che ha come obiettivo l'allarme
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-1.png)
+ A **t0** - L'allarme è in stato OK, lo stato della regola di silenziamento è PIANIFICATO
+ A **t1** - Lo stato della regola di silenziamento diventa ATTIVO
+ A **t2** - L'allarme passa allo stato ALARM, l'azione viene disattivata poiché l'allarme viene effettivamente disattivato dalla regola di silenziamento.
+ A **t4** - L'allarme torna allo stato OK mentre la regola di silenziamento è ancora attiva
+ A **t5** - La regola di silenziamento diventa inattiva, ma non viene eseguita alcuna azione ALARM perché l'allarme è ora nello stato OK
## Scenario: l'azione di allarme è disattivata quando la regola di silenziamento è attiva e riattivata dopo la finestra di silenziamento
Considera che
+ Un allarme ha delle azioni configurate per il suo stato ALARM
+ È programmata una regola di silenziamento degli allarmi attiva da t1 a t5 che ha come obiettivo l'allarme
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-2.png)
+ A **t0** - L'allarme è in stato OK, lo stato della regola di silenziamento è PIANIFICATO
+ A **t1** - Lo stato della regola di silenziamento diventa ATTIVO
+ A **t2** - L'allarme passa allo stato ALARM, l'azione viene disattivata poiché l'allarme viene effettivamente disattivato dalla regola di silenziamento.
+ A **t4** - La finestra Mute diventa inattiva, l'allarme è ancora nello stato ALARM
+ A **t5** - L'azione di allarme viene eseguita perché la finestra di silenziamento è terminata e l'allarme rimane nello stesso stato (ALARM) in cui era stato originariamente disattivato
## Scenario: più regole di silenziamento degli allarmi che si sovrappongono
Considera che
+ Un allarme ha delle azioni configurate per il suo stato ALARM
Considera che ci sono due regole di silenziamento,
+ Regola di disattivazione dell'allarme 1: disattiva l'allarme da t1 a t5
+ Regola di disattivazione dell'allarme 2: disattiva l'allarme da t3 a t9
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-3.png)
+ A **t0** - L'allarme è in stato OK, entrambe le regole di silenziamento sono PROGRAMMATE
+ A **t1** - La prima regola di silenziamento diventa ATTIVA
+ A **t2** - L'allarme passa allo stato ALARM, l'azione viene disattivata
+ A **t3** - La seconda regola di silenziamento diventa ATTIVA
+ A **t5** - La prima regola di silenziamento diventa inattiva, ma l'azione di allarme rimane disattivata perché la seconda regola di silenziamento è ancora attiva
+ A **t8** - L'azione di allarme viene eseguita perché la seconda finestra di silenziamento è terminata e l'allarme rimane nello stesso stato (ALARM) in cui era stato originariamente disattivato
## Scenario: le azioni di allarme disattivate vengono eseguite quando l'aggiornamento della regola di silenziamento termina la finestra di silenziamento
Considerate che
+ Un allarme ha delle azioni configurate per il suo stato ALARM
+ È programmata una regola di silenziamento degli allarmi attiva da t1 a t8 che ha come obiettivo l'allarme
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-4.png)
+ A **t0** - L'allarme è in stato OK, la regola di silenziamento è PIANIFICATA
+ A **t1** - La regola di silenziamento diventa ATTIVA
+ A **t2** - L'allarme passa allo stato ALARM, le azioni vengono disattivate
+ In **t6** - La configurazione della regola di silenziamento viene aggiornata in modo tale che la finestra temporale termini a t6. Le azioni di allarme vengono eseguite immediatamente su t6 perché la regola di silenziamento non è più attiva.
**Nota**
Si applica lo stesso comportamento,
Se la regola di silenziamento viene eliminata in t6. L'eliminazione della regola di silenziamento riattiva immediatamente l'allarme.
Se l'allarme viene rimosso dagli obiettivi della regola di silenziamento (a t6), l'allarme verrà riattivato immediatamente.
## Scenario: nuove azioni vengono eseguite se le azioni di allarme vengono aggiornate durante la finestra di silenziamento
Considerate che
+ Un allarme ha delle azioni configurate per il suo stato ALARM
+ È programmata una regola di silenziamento degli allarmi attiva da t1 a t8 che ha come obiettivo l'allarme
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-5.png)
+ Se **t0** - L'allarme è in stato OK, la regola di silenziamento è PROGRAMMATA. Un'azione SNS è configurata con lo stato di allarme ALARM.
+ A **t1** - La regola Mute diventa ACTIVE
+ A **t2** - L'allarme passa allo stato ALARM, l'azione SNS configurata viene disattivata
+ In **t6** - La configurazione degli allarmi viene aggiornata per rimuovere l'azione SNS e aggiungere l'azione Lambda
+ A **t8** - L'azione lambda configurata per l'allarme viene eseguita perché la finestra di silenziamento è terminata e l'allarme rimane nello stesso stato (ALARM) in cui era stato originariamente disattivato
**Nota**
Se tutte le azioni di allarme vengono rimosse durante la finestra di silenziamento (in t6 nell'esempio precedente), non verrà eseguita alcuna azione alla fine della finestra di silenziamento (in t8 sopra)
## Pianificazioni di esempio per casi d'uso comuni
Gli esempi seguenti mostrano come configurare le espressioni della finestra temporale per casi d'uso comuni.
**Scenario 1: disattivazione delle azioni di allarme durante le finestre di manutenzione programmata**: attività di manutenzione regolari che si verificano secondo una pianificazione prevedibile, come gli aggiornamenti del sistema o del database quando i servizi sono intenzionalmente non disponibili o funzionano in modalità degradata.
+ Espressione Cron `0 2 * * SUN` con durata`PT4H`: disattiva gli allarmi ogni domenica dalle 2:00 alle 6:00 per la manutenzione settimanale del sistema.
+ Espressione Cron `0 1 1 * *` con durata`PT6H`: disattiva gli allarmi il primo giorno di ogni mese dall'1:00 alle 7:00 per la manutenzione mensile del database.
**Scenario 2: disattivazione degli allarmi non critici durante le ore non lavorative: riduzione dell'affaticamento degli avvisi durante i fine settimana o le vacanze, quando non** è richiesta un'attenzione immediata.
+ Espressione Cron `0 18 * * FRI` con durata`P2DT12H`: disattiva gli allarmi ogni fine settimana dalle 18:00 di venerdì alle 6:00 di lunedì.
**Scenario 3: disattivazione degli allarmi prestazionali durante le operazioni di backup quotidiane — Processi di backup** automatizzati giornalieri che aumentano temporaneamente l'utilizzo delle risorse e possono attivare allarmi relativi alle prestazioni durante finestre temporali prevedibili.
+ Espressione Cron `0 23 * * *` con durata`PT2H`: disattiva gli allarmi ogni giorno dalle 23:00 all'1:00 durante le operazioni di backup notturne che aumentano temporaneamente l'utilizzo del disco e della CPU. I/O
**Scenario 4: disattivazione degli allarmi duplicati durante le sessioni attive di risoluzione dei problemi**: disattivazione temporanea delle azioni di allarme mentre i team indagano e risolvono attivamente i problemi, previene il rumore delle notifiche e consente una risoluzione mirata dei problemi.
+ All'espressione `at(2024-05-10T14:00)` con durata`PT4H`: disattiva gli allarmi il 10 maggio 2024 dalle 14:00 alle 18:00 durante una sessione attiva di risposta agli incidenti.
**Scenario 5: disattivazione delle azioni di allarme durante le chiusure aziendali pianificate: periodi di manutenzione prolungata una tantum o arresti a livello aziendale in cui tutti i** sistemi sono intenzionalmente offline per periodi prolungati.
+ All'espressione `at(2024-12-23T00:00)` con la durata`P7D`: disattiva gli allarmi per l'intera settimana dal 23 al 29 dicembre 2024 durante la chiusura annuale dell'azienda.
# Limits
## CloudWatch Quote generali
Per informazioni sulle quote di CloudWatch servizio generali applicabili agli allarmi, vedere. [CloudWatch quote di servizio](cloudwatch_limits.md)
## Limiti che si applicano agli allarmi basati sulle query di Approfondimenti sulle metriche
Quando lavori con gli allarmi CloudWatch Metrics Insights, tieni presente questi limiti funzionali:
+ Un valore predefinito di 200 allarmi che utilizzano la query Metrics Insights per account per regione
+ Per valutare le condizioni dell'allarme è possibile utilizzare solo i dati delle ultime 3 ore; tuttavia, sul grafico della pagina di dettaglio dell'allarme è possibile visualizzare fino a due settimane di dati
+ Gli allarmi che valutano più serie temporali limiteranno il numero di contributori in ALARM a 100
+ Supponendo che la query recuperi 150 serie temporali:
+ Se ci sono meno di 100 contributori in ALARM (ad esempio 95), `StateReason` saranno «95 delle 150 serie temporali valutate in ALARM»
+ Se in ALARM sono presenti più di 100 contributori (ad esempio 105), `StateReason` saranno «più di 100 serie temporali valutate in ALARM»
+ Inoltre, se il volume degli attributi è troppo grande, il numero di contributori in ALARM può essere limitato a meno di 100.
+ Si applicano i limiti di Approfondimenti sulle metriche sul numero massimo di serie temporali analizzate o restituite
+ Durante la valutazione degli allarmi, `EvaluationState` verranno impostati `PARTIAL_DATA` i seguenti limiti:
+ Se la query Metrics Insights restituisce più di 500 serie temporali.
+ Se la query Metrics Insights corrisponde a più di 10.000 metriche.
Per ulteriori informazioni sulle quote e sui limiti CloudWatch del servizio, consulta le quote del servizio [CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-limits.html).
## Limiti che si applicano agli allarmi basati sulle query PromQL
Quando lavori con gli allarmi CloudWatch PromQL, tieni presente questi limiti funzionali:
+ Gli allarmi che valutano più serie temporali limiteranno il numero di contributori in ALARM a 100
+ Se ci sono meno di 100 contributori in ALARM (ad esempio 95), `StateReason` saranno «95 serie temporali valutate in ALARM»
+ Se ci sono più di 100 contributori in ALARM (ad esempio 105), `StateReason` saranno «più di 100 serie temporali valutate in ALARM»
+ Inoltre, se il volume degli attributi è troppo grande, il numero di contributori in ALARM può essere limitato a meno di 100.
+ Si applicano i limiti delle query PromQL sul numero massimo di serie temporali analizzate o restituite
+ Durante la valutazione degli allarmi, `EvaluationState` verrà impostato `PARTIAL_DATA` se la query PromQL restituisce più di 500 serie temporali.
## Limiti che si applicano agli allarmi basati su fonti di dati connesse
+ Quando CloudWatch valuta un allarme, lo fa ogni minuto, anche se la durata dell'allarme è superiore a un minuto. Affinché l'allarme funzioni, la funzione Lambda deve essere in grado di restituire un elenco di timestamp a partire da un minuto qualsiasi, non solo da multipli della durata del periodo. Questi timestamp devono essere distanziati di un periodo.
Pertanto, se l'origine dati interrogata da Lambda può restituire solo timestamp multipli della durata del periodo, la funzione dovrebbe “ricampionare” i dati recuperati in modo che corrispondano ai timestamp previsti dalla richiesta. `GetMetricData`
Ad esempio, un allarme con un periodo di cinque minuti viene valutato ogni minuto utilizzando finestre di cinque minuti che si spostano di un minuto ogni volta. In questo caso:
+ Per la valutazione dell'allarme alle 12:15:00, CloudWatch prevede punti dati con timestamp pari a, e. `12:00:00` `12:05:00` `12:10:00`
+ Quindi, per la valutazione dell'allarme alle 12:16, si CloudWatch aspetta punti dati con timestamp di, e. `12:01:00` `12:06:00` `12:11:00`
+ Quando CloudWatch valuta un allarme, tutti i punti dati restituiti dalla funzione Lambda che non sono in linea con i timestamp previsti vengono eliminati e l'allarme viene valutato utilizzando i punti dati previsti rimanenti. Ad esempio, quando l'allarme viene valutato alle `12:15:00`, prevede dati con timestamp pari di `12:00:00`, `12:05:00` e `12:10:00`. Se riceve dati con timestamp pari a,, e `12:00:00` `12:05:00` `12:06:00``12:10:00`, i dati da `12:06:00` vengono eliminati e valuta l'allarme utilizzando gli altri timestamp. CloudWatch
Quindi, per la valutazione successiva alle `12:16:00`, prevede dati con timestamp di `12:01:00`, `12:06:00` e `12:11:00`. Se ha solo i dati con timestamp di `12:00:00`, `12:05:00` e `12:10:00`, tutti questi punti dati vengono ignorati alle 12:16:00 e l'allarme passa allo stato in base a come è stato specificato che tratti i dati mancanti. Per ulteriori informazioni, consulta [Valutazione degli allarmi](alarm-evaluation.md).
+ Ti consigliamo di creare questi allarmi per intraprendere azioni durante la transizione allo stato `INSUFFICIENT_DATA`, poiché diversi casi d'uso di errori della funzione Lambda faranno passare l'allarme a `INSUFFICIENT_DATA` indipendentemente dal modo in cui è stato specificato che tratti i dati mancanti.
+ Se la funzione Lambda restituisce un errore:
+ Se c'è un problema di autorizzazione con la chiamata alla funzione Lambda, l'allarme inizia ad presentare transizioni di dati mancanti in base a come è stato specificato che tratti i dati mancanti al momento della creazione.
+ Qualsiasi altro errore proveniente dalla funzione Lambda causa il passaggio dell'allarme a `INSUFFICIENT_DATA`.
+ Se il parametro richiesto dalla funzione Lambda presenta un certo ritardo che provoca sempre la mancanza dell'ultimo punto dati, è necessario utilizzare una soluzione alternativa. È possibile creare un allarme M di N o aumentare il periodo di valutazione dell'allarme. Per ulteriori informazioni sugli allarmi M di N, consulta [Valutazione degli allarmi](alarm-evaluation.md).
# Nozioni di base
**Topics**
+ [Creazione di allarmi](Create-Alarms.md)
+ [Operazioni sulle modifiche degli allarmi](Acting_Alarm_Changes.md)
+ [Configura le regole di silenziamento degli allarmi](alarm-mute-rules-configure.md)
# Creazione di allarmi
**Topics**
+ [Crea un CloudWatch allarme basato su una soglia statica](ConsoleAlarms.md)
+ [Crea un CloudWatch allarme basato su un'espressione matematica metrica](Create-alarm-on-metric-math-expression.md)
+ [Crea un CloudWatch allarme basato sul rilevamento delle anomalie](Create_Anomaly_Detection_Alarm.md)
+ [Crea un allarme basato su una query di Multi Time Series Metrics Insights](multi-time-series-alarm.md)
+ [Creazione di un allarme basato su un'origine dati connessa](Create_MultiSource_Alarm.md)
+ [Creare un allarme utilizzando una query PromQL](Create_PromQL_Alarm.md)
+ [Creazione di allarmi sui log](Alarm-On-Logs.md)
+ [Create a composite alarm](Create_Composite_Alarm.md)
# Crea un CloudWatch allarme basato su una soglia statica
Scegli una CloudWatch metrica per la sveglia da guardare e la soglia per quella metrica. L'allarme passa nello stato `ALARM` quando il parametro supera la soglia per un numero specificato di periodi di valutazione.
Se stai creando un allarme in un account configurato come account di monitoraggio in modalità osservabilità CloudWatch tra account diversi, puoi impostare l'allarme in modo che controlli una metrica in un account di origine collegato a questo account di monitoraggio. Per ulteriori informazioni, consulta [CloudWatch osservabilità tra più account](CloudWatch-Unified-Cross-Account.md).
**Per creare un allarme basato su un parametro singolo**
1. Apri la console all' CloudWatch indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All alarms** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **Select Metric** (Seleziona parametro).
1. Esegui una delle seguenti operazioni:
+ Scegli lo spazio dei nomi del servizio contenente il parametro desiderato. Continua scegliendo le opzioni così come vengono visualizzate per limitare le scelte. Quando viene visualizzato un elenco di parametri, seleziona la casella di controllo accanto al parametro desiderato.
+ Nella casella di ricerca immetti il nome di un parametro, l'ID account, l'etichetta dell'account, la dimensione o l'ID risorsa. Dopodiché, scegli uno dei risultati e continua finché non viene visualizzato un elenco di parametri. Seleziona la casella di controllo accanto al parametro desiderato.
1. Seleziona la scheda **Graphed metrics** (Parametri nel grafico).
1. In **Statistic ** (Statistiche), scegli una delle statistiche o percentili predefiniti oppure specifica un percentile personalizzato (ad esempio, **p95.45**).
1. In **Period** (Periodo), scegli il periodo di valutazione per l'allarme. Durante la valutazione dell’allarme, ogni periodo è aggregato in un punto dati.
Puoi anche scegliere se la legenda dell'asse Y viene visualizzata a sinistra o a destra durante la creazione dell'allarme. Questa preferenza viene utilizzata solo durante la creazione dell'allarme.
1. Scegli **Select Metric** (Seleziona parametro).
Viene visualizzata la pagina **Specify metric and conditions** (Specifica parametro e condizioni), contenente un grafico e altre informazioni sul parametro e le statistiche selezionate.
1. In **Conditions** (Condizioni), specifica quanto segue:
1. Per **Whenever *metric* is**, specifica se la metrica deve essere maggiore, minore o uguale alla soglia. In **than... (che...)**, specifica il valore di soglia.
1. Scegli **Additional configuration** (Configurazione aggiuntiva). In **Datapoints to Alarm** (Punti dati all'allarme), specifica il numero di periodi di valutazione (punti dati) che devono essere nello stato `ALARM` per attivare l'allarme. Se i due valori corrispondono, crea un allarme che passa nello stato `ALARM` se si verifica una violazione durante tali periodi consecutivi.
Per creare un allarme M di N, specifica un numero minore per il primo valore rispetto a quello specificato per il secondo valore. Per ulteriori informazioni, consulta la pagina [Valutazione degli allarmi](alarm-evaluation.md).
1. Per **Missing data treatment** (Trattamento dati mancanti), scegli la modalità di comportamento dell'allarme quando mancano alcuni punti dati. Per ulteriori informazioni, consulta la pagina [Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](alarms-and-missing-data.md).
1. Se l'allarme utilizza un percentile come statistica monitorata, viene visualizzata una casella **Percentiles with low samples** (Percentili con campioni ridotti). Utilizzala per scegliere se valutare o ignorare casi con bassa frequenza di campionamento. Se scegli **ignore (maintain alarm state) (ignora (mantieni stato dell'allarme))**, lo stato corrente dell'allarme viene sempre mantenuto quando la dimensione dell'esempio è troppo bassa. Per ulteriori informazioni, consulta la pagina [Allarmi basati su percentile ed esempi di dati ridotti](percentiles-with-low-samples.md).
1. Scegli **Next (Successivo)**.
1. In **Notification** (Notifica), seleziona un argomento SNS per segnalare quando l'allarme è nello stato `ALARM`, `OK` o `INSUFFICIENT_DATA`.
Per fare in modo che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi, scegli **Add notification** (Aggiungi notifica).
Nell' CloudWatch osservabilità tra più account, puoi scegliere di inviare le notifiche a più account. AWS Ad esempio, sia all'account di monitoraggio che all'account di origine.
Per fare in modo che l'allarme non invii notifiche, scegli **Remove** (Rimuovi).
1. Per fare in modo che l'allarme esegua operazioni Auto Scaling, EC2, Lambda o Systems Manager, scegli il pulsante appropriato e seleziona lo stato di allarme e l'operazione da eseguire. Gli allarmi possono eseguire le operazioni Systems Manager e le operazioni di indagine solo quando entrano nello stato ALARM. Per ulteriori informazioni sulle azioni di Systems Manager, vedere [Configurazione per la creazione CloudWatch OpsItems da allarmi](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) e Creazione di [incidenti](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
Per fare in modo che l'allarme avvii un'indagine, scegli **Aggiungi operazione di indagine**, quindi seleziona il tuo gruppo di indagine. Per ulteriori informazioni su , consulta [CloudWatch indagini](Investigations.md).
**Nota**
Per creare un allarme che esegua un'operazione SSM Incident Manager, è necessario disporre di determinate autorizzazioni. Per ulteriori informazioni, vedere [Esempi di policy basate sull'identità per AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Al termine, scegli **Apply** (Applica).
1. Inserisci un nome e una descrizione per l'allarme. Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella **scheda Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne. Quindi scegli **Successivo**.
1. In **Preview and create** (Visualizza anteprima e crea), conferma che le informazioni e le condizioni sono quelle desiderate, quindi scegli **Create alarm** (Crea allarme).
Puoi anche aggiungere allarmi a un pannello di controllo. Per ulteriori informazioni, consulta [Aggiungere un allarme a una CloudWatch dashboard](add_alarm_dashboard.md).
# Crea un CloudWatch allarme basato su un'espressione matematica metrica
Gli allarmi delle metriche sono progettati per valutare le serie temporali definite da una singola metrica o da un'espressione matematica calcolata sulle metriche, che combina o trasforma una o più metriche in una serie temporale che fornisce approfondimenti più strettamente allineati alle tue esigenze specifiche. Per creare un allarme basato su un'espressione matematica metrica, scegli una o più CloudWatch metriche da utilizzare nell'espressione. Quindi, specifica l'espressione, la soglia e i periodi di valutazione.
Non puoi creare un allarme in base all'espressione **SEARCH**. Solo gli allarmi basati sulle query SQL di Approfondimenti sulle metriche possono funzionare su più serie temporali.
**Creazione di un allarme basato su un'espressione matematica del parametro**
1. Apri la console all' CloudWatch indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), quindi **Create alarm** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **Select Metric** (Seleziona parametro) ed esegui una delle operazioni seguenti:
+ Seleziona uno spazio dei nomi dal menu a discesa **namespaces (Spazi dei nomi )AWS ** o dal menu a discesa **Custom namespaces (Spazi dei nomi personalizzati)**. Dopo aver selezionato uno spazio dei nomi, continua a scegliere le opzioni finché non viene visualizzato un elenco di parametri; seleziona quindi la casella di controllo accanto al parametro corretto.
+ Utilizza la casella di ricerca per trovare un parametro, un ID account, una dimensione o un ID risorsa. Dopo aver inserito il parametro, la dimensione o l'ID risorsa, continua a scegliere le opzioni finché non viene visualizzato un elenco di parametri; seleziona quindi la casella di controllo accanto al parametro corretto.
1. (Facoltativo) Se si desidera aggiungere un altro parametro a un'espressione matematica del parametro, puoi utilizzare la casella di ricerca per trovarne uno specifico. È possibile aggiungere un massimo di dieci parametri a un'espressione matematica del parametro.
1. Seleziona la scheda **Graphed metrics** (Parametri nel grafico). Per ogni parametro aggiunto in precedenza, svolgi le seguenti operazioni:
1. Nella colonna **Statistic** (Statistiche), seleziona il menu a discesa. Nel menu a discesa, scegli una delle statistiche o uno dei percentili predefiniti. Utilizza la casella di ricerca nel menu a discesa per definire un percentile personalizzato.
1. Nella colonna **Period** (Periodo), seleziona il menu a discesa. Nel menu a discesa, scegli uno dei periodi di valutazione predefiniti.
Durante la creazione dell'allarme, puoi definire se la legenda dell'asse Y viene visualizzata a sinistra o a destra del grafico.
**Nota**
Quando CloudWatch vengono valutati gli allarmi, i periodi vengono aggregati in singoli punti dati.
1. Scegli il menu a discesa **Add math** (Aggiungi matematica), quindi seleziona **Start with an empty expression** (Inizia con un'espressione vuota) nell'elenco delle espressioni matematiche predefinite del parametro.
Dopo aver scelto **Start with an empty expression** (Inizia con un'espressione vuota), viene visualizzata un riquadro in cui puoi applicare o modificare le espressioni matematiche.
1. Inserisci l'espressione matematica nel riquadro, quindi scegli **Apply** (Applica).
Dopo aver scelto **Apply** (Applica), viene visualizzata una colonna **ID** accanto alla colonna **Label** (Etichetta).
Per usare un parametro o il risultato di un'altra espressione matematica del parametro nella formula dell'espressione matematica attuale, utilizza il valore illustrato nella colonna **ID**. Per modificare il valore di **ID**, seleziona l' pen-and-papericona accanto al valore corrente. Il nuovo valore deve iniziare con una lettera minuscola e può includere numeri, lettere e il trattino basso. Modificare il valore di **ID** con un nome più significativo può rendere il grafico di allarme più comprensibile.
Per informazioni sulle funzioni disponibili per la matematica del parametro, consulta la pagina [Sintassi e funzioni della matematica dei parametri](using-metric-math.md#metric-math-syntax).
1. (Facoltativo) Aggiungi altre espressioni matematiche, utilizzando i parametri e i risultati di altre espressioni matematiche nelle formule delle nuove espressioni matematiche.
1. Quando disponi dell'espressione da utilizzare per l'allarme, deseleziona le caselle di controllo a sinistra di ogni altra espressione e ogni parametro sulla pagina. Solo la casella di controllo accanto all'espressione da utilizzare per l'allarme deve essere selezionata. L'espressione scelta per l'allarme deve produrre una singola serie temporale e visualizzare una sola linea sul grafico. Quindi, scegli **Select metric** (Seleziona parametro).
Viene visualizzata la pagina **Specify metric and conditions** (Specifica parametro e condizioni), contenente un grafico e altre informazioni relative all'espressione matematica selezionata.
1. Per **Whenever *expression* is**, specifica se l'espressione deve essere maggiore, minore o uguale alla soglia. In **than... (che...)**, specifica il valore di soglia.
1. Scegli **Additional configuration** (Configurazione aggiuntiva). In **Datapoints to Alarm** (Punti dati all'allarme), specifica il numero di periodi di valutazione (punti dati) che devono essere nello stato `ALARM` per attivare l'allarme. Se i due valori corrispondono, crea un allarme che passa nello stato `ALARM` se si verifica una violazione durante tali periodi consecutivi.
Per creare un allarme M di N, specifica un numero minore per il primo valore rispetto a quello specificato per il secondo valore. Per ulteriori informazioni, consulta la pagina [Valutazione degli allarmi](alarm-evaluation.md).
1. Per **Missing data treatment** (Trattamento dati mancanti), scegli la modalità di comportamento dell'allarme quando mancano alcuni punti dati. Per ulteriori informazioni, consulta la pagina [Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](alarms-and-missing-data.md).
1. Scegli **Next (Successivo)**.
1. In **Notification** (Notifica), seleziona un argomento SNS per segnalare quando l'allarme è nello stato `ALARM`, `OK` o `INSUFFICIENT_DATA`.
Per fare in modo che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi, scegli **Add notification** (Aggiungi notifica).
Per fare in modo che l'allarme non invii notifiche, scegli **Remove** (Rimuovi).
1. Per fare in modo che l'allarme esegua operazioni Auto Scaling, Amazon EC2, Lambda o Systems Manager, scegli il pulsante appropriato e seleziona lo stato di allarme e l'operazione da eseguire. Se scegli una funzione Lambda come operazione di allarme, specifichi il nome della funzione o l'ARN e, facoltativamente, puoi scegliere una versione specifica della funzione.
Gli allarmi possono eseguire le operazioni Systems Manager solo quando entrano nello stato ALARM. Per ulteriori informazioni sulle azioni di Systems Manager, vedere [Configurazione per la creazione CloudWatch OpsItems da allarmi e Creazione](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) di [incidenti](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**Nota**
Per creare un allarme che esegua un'operazione SSM Incident Manager, è necessario disporre di determinate autorizzazioni. Per ulteriori informazioni, vedere [Esempi di policy basate sull'identità per AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Al termine, scegli **Apply** (Applica).
1. Inserisci un nome e una descrizione per l'allarme. Quindi scegli **Successivo**.
Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella **scheda Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
1. In **Preview and create** (Visualizza anteprima e crea), conferma che le informazioni e le condizioni sono quelle desiderate, quindi scegli **Create alarm** (Crea allarme).
Puoi anche aggiungere allarmi a un pannello di controllo. Per ulteriori informazioni, consulta [Aggiungere un allarme a una CloudWatch dashboard](add_alarm_dashboard.md).
# Crea un CloudWatch allarme basato sul rilevamento delle anomalie
È possibile creare un allarme basato sul rilevamento delle CloudWatch anomalie, che analizza i dati metrici passati e crea un modello di valori previsti. I valori previsti fanno riferimento ai pattern orari, giornalieri e settimanali standard a livello di parametri.
Si imposta un valore per la soglia di rilevamento delle anomalie e CloudWatch si utilizza tale soglia con il modello per determinare l'intervallo di valori «normale» per la metrica. Un valore più alto per la soglia produce un intervallo più ampio di valori "normali".
Puoi decidere se l'allarme viene attivato quando il valore del parametro è al di sopra dell'intervallo di valori previsti, si trova al di sotto di tale intervallo oppure è sopra o sotto l'intervallo.
È inoltre possibile creare allarmi di rilevamento delle anomalie su singole metriche e gli output delle espressioni matematiche dei parametri. È possibile utilizzare queste espressioni per creare grafici che visualizzano le bande di rilevamento delle anomalie.
In un account configurato come account di monitoraggio per l'osservabilità CloudWatch tra più account, puoi creare rilevatori di anomalie sulle metriche negli account di origine oltre alle metriche nell'account di monitoraggio.
Per ulteriori informazioni, consulta [Utilizzo del CloudWatch rilevamento delle anomalie](CloudWatch_Anomaly_Detection.md).
**Nota**
Se si sta già utilizzando un rilevamento di anomalie a scopo di visualizzazione per un parametro nella console dei parametri , e su crea un allarme per il rilevamento delle anomali sullo stesso parametro, la soglia impostata per l'allarme non modifica la soglia già utilizzata per la visualizzazione. Per ulteriori informazioni, consulta [Creazione di un grafico](graph_a_metric.md#create-metric-graph).
**Per creare un allarme basato sul rilevamento di anomalie**
1. Apri la console all'indirizzo. CloudWatch [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All alarms** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **Select Metric** (Seleziona parametro).
1. Esegui una delle seguenti operazioni:
+ Scegliere lo spazio dei nomi del servizio che contiene il parametro, quindi continuare a scegliere le opzioni man mano che appaiono per restringere le opzioni. Quando viene visualizzato un elenco di parametri, seleziona la casella di controllo accanto al parametro desiderato.
+ Nella casella di ricerca, inserisci il nome di un parametro, una dimensione o un ID risorsa . Quindi scegli uno dei risultati e continuare finché non viene visualizzato un elenco di parametri. Seleziona la casella di controllo accanto a un parametro.
1. Seleziona **Metrica definita**.
1. (Facoltativo) Per *Statistica*, seleziona il menu a discesa e quindi seleziona una delle statistiche o un percentile predefinito. È possibile utilizzare la casella di ricerca nel menu a discesa per definire un percentile personalizzato come **p95.45**.
1. (Facoltativo) Per *Periodo*, seleziona il menu a discesa e quindi seleziona uno dei periodi di valutazione predefiniti.
**Nota**
Quando CloudWatch valuta l'allarme, aggrega il periodo in un singolo datapoint. Per gli allarmi basati sul rilevamento di anomalie, il valore deve essere maggiore o uguale a un minuto.
1. Scegli **Next (Successivo)**.
1. In ***Conditions*** (Condizioni), specifica quanto segue:
1. Scegli **Anomaly detection** (Rilevamento di anomalie).
Se il modello per questa metrica e statistica esiste già, CloudWatch visualizza un'anteprima della banda di rilevamento delle anomalie nel grafico nella parte superiore dello schermo. Dopo aver creato l'allarme, affinché l'intervallo di rilevamento di anomalie effettivo venga visualizzato nel grafico possono essere necessari fino a 15 minuti. Prima di ciò, l'intervallo visualizzato è un'approssimazione dell'intervallo di rilevamento di anomalie.
**Suggerimento**
Per visualizzare il grafico nella parte superiore dello schermo in un lasso di tempo più lungo, scegli **Edit** (Modifica) in alto a destra della pagina.
Se il modello per questa metrica e statistica non esiste già, CloudWatch genera la banda di rilevamento delle anomalie dopo aver completato la creazione dell'allarme. Per i nuovi modelli, possono essere necessarie fino a 3 ore affinché l'intervallo di rilevamento di anomalie effettivo venga visualizzato nel grafico. L'addestramento del nuovo modello può richiedere fino a due settimane, quindi l'intervallo di rilevamento delle anomalie mostra valori attesi più accurati.
1. Per ***metric*Whenever is**, specifica quando attivare l'allarme. Ad esempio, quando il parametro è maggiore, minore o esterno alla banda (in entrambe le direzioni).
1. Per **Anomaly detection threshold** (Soglia di rilevamento anomalie), scegli il numero da utilizzare per la soglia di rilevamento anomalie. Un numero più alto crea una banda più spessa di valori "normali" che è più tollerante alle modifiche dei parametri. Un numero più basso crea una banda più sottile, che entra nello stato `ALARM` a fronte di deviazioni dei parametri più piccole. Il numero non deve essere un numero intero.
1. Scegli **Additional configuration** (Configurazione aggiuntiva). In **Datapoints to Alarm** (Punti dati all'allarme), specifica il numero di periodi di valutazione (punti dati) che devono essere nello stato `ALARM` per attivare l'allarme. Se i due valori corrispondono, crea un allarme che passa nello stato `ALARM` se si verifica una violazione durante tali periodi consecutivi.
Per creare un allarme M di N, specifica un numero del primo valore inferiore a quello del secondo valore. Per ulteriori informazioni, consulta [Valutazione degli allarmi](alarm-evaluation.md).
1. Per **Missing data treatment** (Trattamento dati mancanti), scegli la modalità di comportamento dell'allarme quando mancano alcuni punti dati. Per ulteriori informazioni, consulta la pagina [Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](alarms-and-missing-data.md).
1. Se l'allarme utilizza un percentile come statistica monitorata, viene visualizzata una casella **Percentiles with low samples** (Percentili con campioni ridotti). Utilizzala per scegliere se valutare o ignorare casi con bassa frequenza di campionamento. Se scegli **Ignore (maintain alarm state)** (Ignora [mantieni stato dell'allarme]), lo stato corrente dell'allarme viene sempre mantenuto quando la dimensione del campione è troppo piccola. Per ulteriori informazioni, consulta la pagina [Allarmi basati su percentile ed esempi di dati ridotti](percentiles-with-low-samples.md).
1. Scegli **Next (Successivo)**.
1. In **Notification** (Notifica), seleziona un argomento SNS per segnalare quando l'allarme è nello stato `ALARM`, `OK` o `INSUFFICIENT_DATA`.
Per fare in modo che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi, scegli **Add notification** (Aggiungi notifica).
Scegli **Remove** se non desideri che l'allarme invii notifiche.
1. È possibile impostare l'allarme per eseguire azioni EC2 o richiamare una funzione Lambda quando cambia stato, oppure per creare un Systems Manager OpsItem o un incidente quando passa allo stato ALARM. A tale scopo, seleziona il pulsante appropriato, quindi scegli lo stato di allarme e l'operazione da eseguire.
Se scegli una funzione Lambda come operazione di allarme, specifichi il nome della funzione o l'ARN e, facoltativamente, puoi scegliere una versione specifica della funzione.
Per ulteriori informazioni sulle azioni di Systems Manager, vedere [Configurazione per la creazione CloudWatch OpsItems da allarmi](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) e Creazione di [incidenti](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**Nota**
Per creare un allarme che esegua un'azione di AWS Systems Manager Incident Manager, è necessario disporre di determinate autorizzazioni. Per ulteriori informazioni, vedere [Esempi di policy basate sull'identità per AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Scegli **Next (Successivo)**.
1. In ***Add a description* (Aggiungere una descrizione)**, immetti un nome e una descrizione per l'allarme e scegli **Next** (Successivo). Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella **scheda Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
**Suggerimento**
Il nome dell'allarme deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII
1. In ***Preview and create* (Visualizza anteprima e crea)**, conferma che le informazioni e le condizioni dell'allarme sono quelle desiderate, quindi scegli **Create alarm** (Crea allarme).
## Modifica di un modello di rilevamento delle anomalie
Dopo aver creato un allarme, è possibile modificare il modello di rilevamento delle anomalie. Puoi escludere l'utilizzo di determinati periodi di tempo nella creazione del modello. È fondamentale escludere dai dati di formazione eventi insoliti quali interruzioni del sistema, distribuzioni e festività. E' inoltre possibile specificare se regolare il modello per le modifiche all'ora legale.
**Per modificare il modello di rilevamento delle anomalie per un allarme**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All alarms** (Tutti gli allarmi).
1. Scegli il nome dell'allarme. Se necessario, utilizza la casella di ricerca per trovare l'allarme.
1. Scegli **Visualizza**, **In metriche**.
1. **Nella colonna **Dettagli**, scegli la parola chiave **ANOMALY\$1DETECTION\$1BAND, quindi scegli Modifica modello di rilevamento** delle anomalie nel popup.**
![\[Viene visualizzata la scheda Metriche definite con il menu popup ANOMALY_DETECTION_BAND.\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/Anomaly_Detection_Edit.PNG)
1. Per escludere l'utilizzo di un periodo di tempo per la produzione del modello, scegliete l'icona del calendario per **Data di fine**. Quindi, seleziona o inserisci i giorni e le ore da escludere dall'addestramento, quindi scegli **Apply** (Applica).
1. Se il parametro fa distinzione tra ora solare e ora legale, seleziona il fuso orario appropriato nella casella **Metric timezone** (Fuso orario parametro).
1. Scegliere **Aggiorna**.
## Eliminazione di un modello di rilevamento delle anomalie
L'uso del rilevamento delle anomalie per un allarme incrementa i costi addebitati da . Come best practice, se l'allarme non ha più bisogno di un modello di rilevamento delle anomalie, elimina prima l'allarme e poi il modello. Quando vengono valutati gli allarmi di rilevamento delle anomalie, vengono creati eventuali rilevatori di anomalie mancanti per tuo conto. Se si cancella il modello senza eliminare l'allarme, l'allarme ricrea automaticamente il modello.
**Come eliminare un allarme**
1. Apri [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)la console all'indirizzo. CloudWatch
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All Alarms** (Tutti gli allarmi).
1. Scegli il nome dell'allarme.
1. Scegli **Operazioni** > **Elimina**.
1. Nella finestra di dialogo di conferma, scegli **Elimina**.
**Per eliminare un modello di rilevamento delle anomalie utilizzato per un allarme**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Parametri** quindi scegli **Tutti i parametri**.
1. Scegli **Browse** (Sfoglia), quindi seleziona il parametro che include il modello di rilevamento delle anomalie. Puoi effettuare la ricerca del parametro tramite la casella di ricerca o selezionarne uno scegliendo tra le opzioni.
+ (Facoltativo) Se utilizzi l'interfaccia originale, scegli **All metrics** (Tutti i parametri), quindi seleziona il parametro che include il modello di rilevamento delle anomalie. Puoi effettuare la ricerca del parametro tramite la casella di ricerca o selezionarne uno scegliendo tra le opzioni.
1. Seleziona **Graphed metrics** (Parametri nel grafico).
1. **Nella scheda **Metriche grafiche**, nella colonna **Dettagli**, scegli la parola chiave **ANOMALY\$1DETECTION\$1BAND, quindi scegli Elimina modello di rilevamento delle anomalie** nel popup.**
![\[Viene visualizzata la scheda Metriche definite con il menu popup ANOMALY_DETECTION_BAND.\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/Anomaly_Detection_Edit.PNG)
+ (Facoltativo) Se utilizzi l'interfaccia originale, scegli **Edit model** (Modifica modello). Viene visualizzata una nuova schermata. In questa pagina, scegli **Delete model** (Elimina modello), quindi **Delete** (Elimina).
# Crea un allarme basato su una query di Multi Time Series Metrics Insights
Puoi creare un allarme per monitorare più serie temporali su un parco di risorse. A differenza degli allarmi a istanza singola che attivano operazioni su singole istanze, gli allarmi di monitoraggio del parco consentono di aggregare le metriche relative a più risorse e l'attivazione in base alle condizioni dell'intero parco.
## Configurazione di un allarme Multi Time Series utilizzando il Console di gestione AWS
Questo esempio mostra come creare un allarme che monitora l'utilizzo della memoria in un parco di istanze e avvisa l'utente quando più di due istanze superano una soglia.
**Per creare un allarme basato su più serie temporali**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All Alarms** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **Seleziona metrica**.
1. In **Metriche**, inserisci una query di Approfondimenti sulle metriche:
```
SELECT MAX(mem_used_percent)
FROM "CWAgent"
GROUP BY InstanceId
ORDER BY MAX() DESC
```
1. Scegli **Next (Successivo)**.
1. In **Conditions** (Condizioni), specifica quanto segue:
+ For **Threshold type (Tipo di soglia)**, scegli **Static (Statica)**.
+ Per **Quando la metrica è**, scegli **Maggiore di** e inserisci **80**.
+ Per **Punti dati su cui attivare allarmi**, inserisci **2**.
1. Configura le notifiche e le operazioni in base alle tue necessità.
1. Aggiungi un nome e una descrizione per l'allarme.
1. Scegli **Crea allarme**.
Questo allarme si differenzia dagli allarmi a istanza singola in diversi modi:
+ Monitora più serie temporali contemporaneamente tramite l'uso di una query delle metriche. La query delle metriche viene aggiornata ogni volta che viene valutato l'allarme, quindi l'allarme si adatta automaticamente man mano che le risorse vengono create, messe in pausa o eliminate.
+ Per ogni collaboratore che supera la soglia, l'allarme invia un evento di modifica dello stato del contributore, che ha un tipo di evento diverso EventBridge rispetto a un evento di cambiamento dello stato di allarme. Anche l'allarme stesso cambia stato: non appena almeno un collaboratore è in allarme, anche l'allarme entra nello stato di allarme.
+ Tuttavia, alcune operazioni, come SSM Incident, vengono attivate a livello di allarme. Tali operazioni non si ripetono quando l'elenco dei collaboratori in allarme cambia.
Questo allarme si differenzia dagli allarmi aggregati basati su query delle metriche in diversi modi:
+ Monitora le serie temporali singolarmente anziché aggregate, utilizzando la clausola `GROUP BY`.
+ Segue il livello di granularità impostato in base alle tue esigenze: ad esempio, può inviare allarmi su ogni istanza Amazon EC2 (il livello più granulare delle metriche di Amazon EC2) o per tabella Amazon RDS (aggregata tra varie operazioni su una tabella), a seconda dei campi impostati nella clausola `GROUP BY`
+ Dà priorità alla valutazione utilizzando la clausola `ORDER BY`.
+ Per ogni contributore che supera la soglia, l'allarme invia un evento di modifica dello stato del contributore, che ha un tipo di evento diverso EventBridge rispetto a un evento di cambiamento dello stato di allarme. Anche l'allarme stesso cambia stato: non appena almeno un collaboratore è in allarme, anche l'allarme entra nello stato di allarme.
+ Tuttavia, alcune operazioni, come SSM Incident, vengono attivate a livello di allarme. Tali operazioni non si ripetono quando l'elenco dei collaboratori in allarme cambia.
# Creazione di un allarme basato su un'origine dati connessa
Puoi creare allarmi che controllano le metriche provenienti da fonti di dati che non sono presenti. CloudWatch Per ulteriori informazioni sulla creazione di connessioni a queste altre origini dati, consulta [Recupero dei parametri da altre origini dati](MultiDataSourceQuerying.md).
**Per creare un allarme sui parametri da un'origine dati alla quale si è effettuata la connessione**
1. Apri la CloudWatch console all'indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, seleziona **Metrics** (Parametri), **All metrics** (Tutti i parametri).
1. Scegli la scheda **Query da più origini**.
1. Per **Origine dati**, seleziona l'origine dati che desideri utilizzare.
1. Il generatore di query richiede le informazioni necessarie affinché la query recuperi i parametri da utilizzare per l'allarme. Il flusso di lavoro è diverso per ogni origine dati ed è personalizzato in base a essa. Ad esempio, per le origini dati Amazon Managed Service for Prometheus e le origini dati Prometheus, viene visualizzata una casella di editor di query PromQL con una guida alle query.
1. Quando hai completato la creazione della query, scegli **Query a grafo**.
1. Se il grafico di esempio ha l'aspetto previsto, scegli **Crea allarme**.
1. Viene visualizzata la pagina **Specifica parametro e condizioni**. Se la query che stai usando produce più di una serie temporale, un banner di avviso viene visualizzato nella parte superiore della pagina. In tal caso, seleziona una funzione da utilizzare per aggregare le serie temporali nella **funzione di aggregazione**.
1. (Facoltativo) Aggiungi un'**etichetta** per l'allarme.
1. Per **Whenever *your-metric-name* is..** **, scegli **Maggiore**, **Maggiore/Uguale, Minore/Uguale** o **Inferiore**.** Per **di . . .**, specifica un numero per il valore di soglia.
1. Scegli **Additional configuration** (Configurazione aggiuntiva). In **Datapoints to Alarm** (Punti dati all'allarme), specifica il numero di periodi di valutazione (punti dati) che devono essere nello stato `ALARM` per attivare l'allarme. Se i due valori corrispondono, crea un allarme che passa nello stato `ALARM` se si verifica una violazione durante tali periodi consecutivi.
Per creare un allarme M di N, specifica un numero del primo valore inferiore a quello del secondo valore. Per ulteriori informazioni, consulta [Valutazione degli allarmi](alarm-evaluation.md).
1. Per **Missing data treatment** (Trattamento dati mancanti), scegli la modalità di comportamento dell'allarme quando mancano alcuni punti dati. Per ulteriori informazioni, consulta [Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](alarms-and-missing-data.md).
1. Scegli **Next (Successivo)**.
1. Per **Notifica**, seleziona un argomento Amazon SNS per segnalare quando l'allarme passa allo stato `ALARM`, `OK` o `INSUFFICIENT_DATA`.
1. (Facoltativo) Per fare in modo che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi, scegli **Add notification** (Aggiungi notifica).
**Nota**
Ti consigliamo di impostare l'allarme in modo da intervenire quando entra in stato **Dati insufficienti** oltre a quando entra in stato **Allarme**. Questo perché molti problemi relativi alla funzione Lambda che si connette all'origine dati possono causare il passaggio dell'allarme a **Dati insufficienti**.
1. (Facoltativo) Per fare in modo che l'allarme non invii notifiche Amazon SNS, scegli **Rimuovi**.
1. Per fare in modo che l'allarme esegua operazioni Auto Scaling, Lambda o Systems Manager scegli il pulsante appropriato e scegli lo stato di allarme e l'operazione da eseguire. Se scegli una funzione Lambda come operazione di allarme, specifichi il nome della funzione o l'ARN e, facoltativamente, puoi scegliere una versione specifica della funzione.
Gli allarmi possono eseguire le operazioni Systems Manager solo quando entrano nello stato ALARM. Per ulteriori informazioni sulle azioni di Systems Manager, vedere [Configurazione per la creazione CloudWatch OpsItems da allarmi e Creazione](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) di [incidenti](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**Nota**
Per creare un allarme che esegua un'operazione SSM Incident Manager, è necessario disporre di determinate autorizzazioni. Per ulteriori informazioni, vedere [Esempi di policy basate sull'identità per AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Scegli **Next (Successivo)**.
1. In **Add a description** (Aggiungere una descrizione), immetti un nome e una descrizione per l'allarme e scegli **Next** (Successivo). Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella **scheda Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
**Suggerimento**
Il nome dell'allarme deve contenere solo caratteri UTF-8. Non può contenere caratteri di controllo ASCII.
1. In **Preview and create** (Visualizza anteprima e crea), conferma che le informazioni e le condizioni dell'allarme sono quelle desiderate, quindi scegli **Create alarm** (Crea allarme).
# Creare un allarme utilizzando una query PromQL
È possibile creare un CloudWatch allarme che utilizza una query istantanea PromQL per monitorare le metriche inserite tramite l'endpoint OTLP. CloudWatch Tutte le serie temporali corrispondenti restituite dalla query sono considerate violazioni e l'allarme tiene traccia di ogni serie temporale che viola come contributore. Per ulteriori informazioni sul funzionamento degli allarmi ProMQL, vedere. [Allarmi ProMQL](alarm-promql.md)
## Creazione di un allarme PromQL utilizzando Console di gestione AWS
Questo esempio mostra come creare un allarme che monitora una metrica dell'indicatore e avvisa l'utente quando il suo valore scende al di sotto di 20.
**Per creare un allarme ProMQL**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All Alarms** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **PromQL** per il tipo di metrica.
1. In modalità **Editor**, inserisci la query PromQL:
```
my_gauge_metric < 20
```
1. In **Conditions** (Condizioni), specifica quanto segue:
+ Per **Intervallo di valutazione**, scegliete**1 minute**, per definire la frequenza con cui viene valutata la query PromQL.
+ Per **Periodo in sospeso**, immettere**120**, la durata in secondi che un collaboratore deve violare prima di entrare nello stato ALARM.
+ Per **Periodo di recupero****300**, inserisci la durata in secondi che un collaboratore non deve violare prima di entrare nello stato OK.
1. Configura le notifiche e le operazioni in base alle tue necessità.
1. Aggiungi un nome e una descrizione per l'allarme.
1. Scegli **Next (Successivo)**.
1. Scegli **Crea allarme**.
## Creazione di un allarme ProMQL ()AWS CLI
Usa l'azione [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)API per creare un allarme ProMQL.
**Example Crea un allarme ProMQL che si attiva quando una metrica dell'indicatore scende al di sotto di 20**
```
aws cloudwatch put-metric-alarm \
--alarm-name MyPromQLAlarm \
--evaluation-criteria '{"PromQLCriteria":{"Query":"my_gauge_metric < 20"}}' \
--evaluation-interval 60
```
**Example Crea un allarme PromQL con un periodo in sospeso**
Questo allarme attende 300 secondi (5 minuti) prima di passare allo `ALARM` stato e attende 600 secondi (10 minuti) prima di riattivarsi.
```
aws cloudwatch put-metric-alarm \
--alarm-name HighLatencyAlarm \
--evaluation-criteria '{"PromQLCriteria":{"Query":"histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5","PendingPeriod":300,"RecoveryPeriod":600}}' \
--evaluation-interval 60
```
**Example Crea un allarme PromQL con un'azione di notifica SNS**
```
aws cloudwatch put-metric-alarm \
--alarm-name MyPromQLAlarmWithAction \
--evaluation-criteria '{"PromQLCriteria":{"Query":"my_gauge_metric < 20","PendingPeriod":0,"RecoveryPeriod":0}}' \
--evaluation-interval 60 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:MyTopic
```
## Creazione di un allarme ProMQL da Query Studio
Questo esempio mostra come creare un allarme PromQL da Query Studio che avvisa l'utente quando la durata media della richiesta HTTP per un servizio supera i 500 millisecondi.
A differenza degli CloudWatch allarmi standard in cui la soglia è configurata come un passaggio separato, gli allarmi PromQL definiscono la condizione di allarme (soglia) come parte della query stessa. Ad esempio, l'operatore di confronto (`>`) e il valore di soglia (`0.5`) sono incorporati direttamente nell'espressione PromQL.
**Per creare un allarme ProMQL da Query Studio**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel riquadro di navigazione sotto **Metriche**, scegli **Query Studio (anteprima).**
1. Seleziona **PromQL** dal menu a discesa del linguaggio di interrogazione.
1. Crea la tua query utilizzando una delle seguenti modalità:
+ In modalità **Builder**, selezionate il nome di una metrica dal campo **Metrica** (ad esempio,). `http.server.request.duration` Aggiungi filtri di etichette in base alle esigenze (ad esempio, `@resource.service.name` =). `my-api` Per definire la soglia di allarme, selezionate un'**operazione di base** (ad esempio,`>`) e immettete un **numero** (ad esempio,`0.5`).
+ In modalità **Codice**, inserisci direttamente l'espressione PromQL, ad esempio:
```
histogram_avg({"http.server.request.duration", "@resource.service.name"="my-api"}) > 0.5
```
1. Scegliete **Esegui** per eseguire la query e verificare che restituisca i risultati previsti.
1. Scegli **Crea allarme** dal menu delle azioni.
1. Verrai reindirizzato alla pagina di creazione dell' CloudWatch allarme con la tua query ProMQL precompilata.
1. In **Conditions** (Condizioni), specifica quanto segue:
+ Per **Intervallo di valutazione**, scegli**1 minute**, per definire la frequenza con cui viene valutata la query PromQL.
+ Per **Periodo in sospeso****60**, immettete la durata in secondi della quale la query deve essere violata prima di entrare nello stato ALARM. Ciò significa che la latenza deve superare la soglia per almeno 60 secondi prima che venga attivato l'allarme.
+ Per **Periodo di ripristino****120**, immettere la durata in secondi della query prima di entrare nello stato OK. Ciò significa che la latenza deve rimanere al di sotto della soglia per almeno 120 secondi prima che l'allarme si riattivi.
1. Configura le notifiche e le operazioni in base alle tue necessità.
1. Aggiungi un nome e una descrizione per l'allarme.
1. Scegli **Next (Successivo)**.
1. Scegli **Crea allarme**.
**Nota**
La query PromQL deve restituire una singola serie temporale per creare un allarme. Se la query restituisce più serie temporali, utilizza funzioni di aggregazione come `sum``avg`, o `topk` per ridurre il risultato a una singola serie prima di creare l'allarme.
# Creazione di allarmi sui log
I passaggi descritti nelle sezioni seguenti spiegano come creare CloudWatch allarmi nei registri.
## Crea un CloudWatch allarme basato su un filtro metrico del gruppo di log
La procedura in questa sezione illustra come creare un allarme basato su un filtro parametri del gruppo di log. Con i filtri metrici, puoi cercare termini e modelli nei dati di registro man mano che i dati vengono inviati. CloudWatch Per ulteriori informazioni, consulta [Creare metriche dagli eventi di log utilizzando i filtri](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) nella *Amazon CloudWatch Logs User* Guide. Prima di creare un allarme basato su un filtro parametri del gruppo di log, devi completare le azioni seguenti:
+ Creazione di un gruppo di log. Per ulteriori informazioni, consulta [Working with log groups and log stream](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#Create-Log-Group) nella *Amazon CloudWatch Logs User* Guide.
+ Creazione di un filtro parametri. Per ulteriori informazioni, consulta [Creare un filtro metrico per un gruppo di log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) nella *Amazon CloudWatch Logs User* Guide.
**Creazione di un allarme basato su un filtro parametri del gruppo di log**
1. Apri la CloudWatch console all'indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione scegli **Logs** (Log), quindi **Log groups** (Gruppi di log).
1. Scegli il gruppo di log che include il filtro parametri.
1. Scegli **Metric filters** (Filtri parametri).
1. Nella scheda Metric filters (Filtri parametri), seleziona la casella relativa al filtro parametri su cui basare l'allarme.
1. Scegli **Crea allarme**.
1. (Facoltativo) In **Metric** (Parametro), modifica i campi **Metric name** (Nome parametro), **Statistic** (Statistica) e **Period** (Periodo).
1. In **Conditions** (Condizioni), specifica quanto segue:
1. Per **Threshold type** (Tipo di soglia), scegli **Static** (Statico) o **Anomaly detection** (Rilevamento anomalie).
1. Per **Whenever *your-metric-name* is..** **, scegli **Maggiore**, **Maggiore/Uguale, Minore/Uguale** o **Inferiore**.**
1. Per **than . . .** (di), specifica un numero per il valore di soglia.
1. Scegli **Additional configuration** (Configurazione aggiuntiva).
1. Per **Datapoints to alarm** (Punti dati per allarme), specifica quanti punti dati attivano l'allarme in modo da farlo entrare in uno stato `ALARM`. Se indichi dei valori corrispondenti, l'allarme passa nello stato `ALARM` nel caso in cui si verifichi una violazione durante tali periodi consecutivi. Per creare un M-out-of-N allarme, specifica un numero per il primo valore inferiore al numero specificato per il secondo valore. Per ulteriori informazioni, consulta [Valutazione degli allarmi](alarm-evaluation.md).
1. Per **Missing data treatment** (Trattamento dei dati mancanti), seleziona un'opzione dal menu a discesa per specificare come trattare i dati mancanti quando viene valutato l'allarme.
1. Scegli **Next (Successivo)**.
1. In **Notification** (Notifica), seleziona un argomento Amazon SNS per segnalare quando l'allarme si trova nello stato `ALARM`, `OK` o `INSUFFICIENT_DATA`.
1. (Facoltativo) Per fare in modo che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi, scegli **Add notification** (Aggiungi notifica).
1. (Facoltativo) Per fare in modo che l'allarme non invii notifiche, scegli **Remove** (Rimuovi).
1. Per fare in modo che l'allarme esegua operazioni Auto Scaling, EC2, Lambda o Systems Manager scegli il pulsante appropriato e scegli lo stato di allarme e l'operazione da eseguire. Se scegli una funzione Lambda come operazione di allarme, specifichi il nome della funzione o l'ARN e, facoltativamente, puoi scegliere una versione specifica della funzione.
Gli allarmi possono eseguire le operazioni Systems Manager solo quando entrano nello stato ALARM. Per ulteriori informazioni sulle azioni di Systems Manager, vedere [Configurazione per la creazione CloudWatch OpsItems da allarmi e Creazione](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) di [incidenti](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**Nota**
Per creare un allarme che esegua un'operazione SSM Incident Manager, è necessario disporre di determinate autorizzazioni. Per ulteriori informazioni, vedere [Esempi di policy basate sull'identità per AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Scegli **Next (Successivo)**.
1. Per **Name and description (Nome e descrizione)**, inserisci un nome e una descrizione per il tuo allarme. Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella **scheda Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
1. Per **Preview and create** (Anteprima e creazione), verifica che la configurazione sia corretta, quindi seleziona **Create alarm** (Crea allarme).
# Create a composite alarm
I passaggi di questa sezione spiegano come utilizzare la CloudWatch console per creare un allarme composito. Puoi anche utilizzare l'API o AWS CLI creare un allarme composito. Per ulteriori informazioni, consulta [PutCompositeAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutCompositeAlarm.html) o [put-composite-alarm](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-composite-alarm.html)
**Come creare un allarme composito**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), quindi **Create alarm** (Tutti gli allarmi).
1. Dall'elenco degli allarmi, seleziona la casella di controllo accanto a ciascuno degli allarmi esistenti a cui si desidera fare riferimento nell'espressione della regola, quindi scegli **Crea allarme composito**.
1. In **Specifica le condizioni di allarme composito**, specifica l'espressione della regola per il nuovo allarme composito.
**Nota**
Automaticamente, gli allarmi selezionati dall'elenco degli allarmi sono elencati nella casella **Conditions** (Condizioni). Per impostazione predefinita, la funzione `ALARM` è stata designata per ciascuno dei tuoi allarmi e ciascuno degli allarmi è affiancato dall'operatore logico `OR`.
Puoi utilizzare le seguenti operazioni secondarie per modificare l'espressione della regola:
1. Puoi modificare lo stato richiesto per ciascuno dei tuoi allarmi da `ALARM` a `OK` o `INSUFFICIENT_DATA`.
1. È possibile modificare l'operatore logico nell'espressione della regola da `OR` a `AND` o `NOT` e puoi aggiungere parentesi per raggruppare le tue funzioni.
1. Puoi includere altri allarmi nell'espressione della tua regola o eliminare allarmi dall'espressione della regola.
**Esempio: espressione della regola con condizioni**
```
(ALARM("CPUUtilizationTooHigh") OR
ALARM("DiskReadOpsTooHigh")) AND
OK("NetworkOutTooHigh")
```
Nell'espressione della regola di esempio in cui l'allarme composito entra in funzione `ALARM` quando ALARM (» CPUUtilization TooHigh "o ALARM (» DiskReadOpsTooHigh «) è attivo contemporaneamente `ALARM` a OK (» NetworkOutTooHigh «)`OK`.
1. Al termine, scegli **Apply** (Applica).
1. In **Configurazione delle operazioni**, puoi scegliere tra le seguenti opzioni:
Per ***Notifica***
+ **Seleziona un argomento SNS esistente**, **Creazione di un nuovo argomento di SNS**, oppure **Utilizzare un argomento di ARN** per definire l'argomento SNS che riceverà la notifica.
+ **Aggiungi notifica** per fare in modo che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi.
+ **Rimuovi** per impedire all'allarme di inviare notifiche o intraprendere operazioni.
(Facoltativo) Per fare in modo che l'allarme richiami una funzione Lambda quando cambia stato, scegli **Aggiungi operazione Lambda**. Quindi specifica il nome della funzione o l'ARN e, facoltativamente, scegli una versione specifica della funzione.
Per ***Operazione Systems Manager***
+ **Aggiungi operazione Systems Manager**, in modo che l'allarme possa eseguire un'azione SSM quando entra in stato ALARM.
Per ulteriori informazioni sulle azioni di Systems Manager, vedere [Configurazione CloudWatch per creare a OpsItems partire dagli allarmi](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) nella Guida per l'*AWS Systems Manager utente e [Creazione degli incidenti](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) nella Guida* per l'*utente di Incident Manager*. Per creare un allarme che esegua un'operazione SSM Incident Manager, è necessario disporre delle autorizzazioni corrette. Per ulteriori informazioni, vedere [Esempi di policy basate sull'identità per AWS Systems Manager Incident Manager nella Guida](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html) per l'utente di *Incident Manager*.
Per fare in modo che l'allarme avvii un'indagine, scegli **Aggiungi operazione di indagine**, quindi seleziona il tuo gruppo di indagine. Per ulteriori informazioni su , consulta [CloudWatch indagini](Investigations.md).
1. Al termine, scegli **Apply** (Applica).
1. In **Aggiungi nome e descrizione**, inserisci un nome dell'allarme e *opzionale* descrizione del nuovo allarme composito. Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella **scheda Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
1. Al termine, scegli **Apply** (Applica).
1. In **Visualizza l'anteprima e crea**, conferma le informazioni e scegli **Creazione di un allarme composito**.
**Nota**
È possibile creare un ciclo di allarmi compositi, in cui un allarme composito e un altro allarme composito dipendono l'uno dall'altro. Se ti trovi in questo scenario, i tuoi allarmi compositi smettono di essere valutati e non puoi eliminare i tuoi allarmi compositi perché dipendono l'uno dall'altro. Il modo più semplice per interrompere il ciclo di dipendenza tra i tuoi allarmi compositi è cambiare la funzione `AlarmRule` in uno dei tuoi allarmi compositi in `False`.
# Operazioni sulle modifiche degli allarmi
CloudWatch può notificare agli utenti due tipi di modifiche agli allarmi: quando un allarme cambia stato e quando la configurazione di un allarme viene aggiornata.
Quando un allarme viene valutato, può cambiare da uno stato all'altro, ad esempio ALARM oppure OK. Per gli allarmi di Approfondimenti sulle metriche che monitorano più serie temporali, ogni serie temporale (collaboratore) può essere solo nello stato ALARM o OK, mai nello stato INSUFFICIENT\$1DATA. Questo perché una serie temporale esiste solo quando sono presenti dati.
Inoltre, CloudWatch invia eventi ad Amazon EventBridge ogni volta che gli allarmi cambiano di stato e quando gli allarmi vengono creati, eliminati o aggiornati. Puoi scrivere EventBridge regole per intraprendere azioni o ricevere notifiche quando ricevi questi EventBridge eventi.
Per ulteriori informazioni sulle azioni di allarme, vedere[Operazione per gli allarmi](alarm-actions.md).
**Topics**
+ [Notifica agli utenti delle modifiche agli allarmi](Notify_Users_Alarm_Changes.md)
+ [Invocazione di una funzione Lambda da un allarme](alarms-and-actions-Lambda.md)
+ [Avvia un' CloudWatch indagine da un allarme](Start-Investigation-Alarm.md)
+ [Arresta, termina, riavvia o ripristina un'istanza EC2](UsingAlarmActions.md)
+ [Eventi di allarme e EventBridge](cloudwatch-and-eventbridge.md)
# Notifica agli utenti delle modifiche agli allarmi
Questa sezione spiega come utilizzare AWS User Notifications o Amazon Simple Notification Service per far sì che gli utenti vengano informati delle modifiche agli allarmi.
## Configurazione delle notifiche AWS utente
È possibile utilizzare [le notifiche AWS utente](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) per configurare i canali di consegna per ricevere notifiche sulla modifica dello stato CloudWatch dell'allarme e sugli eventi di modifica della configurazione. L'utente riceverà una notifica quando un evento corrisponde a una regola specificata. È possibile ricevere notifiche per gli eventi tramite più canali, tra cui e-mail, notifiche chat di [AWS Chatbot](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) o [notifiche push di AWS Console Mobile Application](https://docs.aws.amazon.com/consolemobileapp/latest/userguide/managing-notifications.html). È possibile visualizzare le notifiche anche nel [Centro notifiche della console](https://console.aws.amazon.com/notifications). La funzionalità Notifiche all'utente supporta l'aggregazione, che può ridurre il numero di notifiche ricevute durante eventi specifici.
Le configurazioni di notifica create con AWS User Notifications non vengono conteggiate ai fini del limite del numero di azioni che è possibile configurare per lo stato di allarme desiderato. Poiché AWS User Notifications corrisponde agli eventi trasmessi ad Amazon EventBridge, invia notifiche per tutti gli allarmi nel tuo account e nelle regioni selezionate, a meno che tu non specifichi un filtro avanzato per consentire o negare allarmi o schemi specifici.
L'esempio seguente di filtro avanzato corrisponde a una modifica dello stato dell'allarme da OK a ALARM sull'allarme denominato `ServerCpuTooHigh`.
```
{
"detail": {
"alarmName": ["ServerCpuTooHigh"],
"previousState": { "value": ["OK"] },
"state": { "value": ["ALARM"] }
}
}
```
Puoi utilizzare una qualsiasi delle proprietà pubblicate da un allarme negli EventBridge eventi per creare un filtro. Per ulteriori informazioni, consulta [Eventi di allarme e EventBridge](cloudwatch-and-eventbridge.md).
## Impostazione delle notifiche Amazon SNS
Puoi utilizzare Amazon Simple Notification Service per inviare sia messaggi application-to-application (A2A) che messaggi application-to-person (A2P), inclusi messaggi di testo mobili (SMS) ed e-mail. Per ulteriori informazioni, consulta le [Destinazioni di eventi Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html).
Per ogni stato in cui può verificarsi un allarme, puoi configurarlo per inviare un messaggio a un argomento SNS. Ogni argomento di Amazon SNS che configuri per uno stato di un determinato allarme conta ai fini del limite del numero di azioni che puoi configurare per tale allarme e stato. Puoi inviare messaggi allo stesso argomento Amazon SNS da qualsiasi allarme presente nel tuo account e utilizzare lo stesso argomento Amazon SNS per i consumer di applicazioni (A2A) e persone (A2P). Poiché questa configurazione viene eseguita a livello di allarme, solo gli allarmi che hai configurato invieranno messaggi all'argomento Amazon SNS selezionato.
Come prima cosa crea e sottoscrivi un argomento. Puoi anche pubblicare un messaggio di prova per l'argomento. Per vedere un esempio, consulta [Configurazione di un argomento Amazon SNS utilizzando Console di gestione AWS](#set-up-sns-topic-console). Per ulteriori informazioni, consulta [Nozioni di base su Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html).
In alternativa, se prevedi di utilizzare il Console di gestione AWS per creare il tuo CloudWatch allarme, puoi saltare questa procedura perché puoi creare l'argomento quando crei l'allarme.
Quando crei un CloudWatch allarme, puoi aggiungere azioni per qualsiasi stato target in cui entra l'allarme. Aggiungi una notifica Amazon SNS per lo stato di cui desideri ricevere una notifica e seleziona l'argomento Amazon SNS che hai creato nel passaggio precedente per inviare una notifica e-mail quando l'allarme entra nello stato selezionato.
**Nota**
Quando crei un argomento di Amazon SNS, scegli di renderlo un *argomento standard o un argomento* *FIFO*. CloudWatch garantisce la pubblicazione di tutte le notifiche di allarme relative a entrambi i tipi di argomenti. Tuttavia, anche se si utilizza un argomento FIFO, in rari casi CloudWatch invia le notifiche all'argomento in modo errato. Se si utilizza un argomento FIFO, l'allarme imposta l'ID del gruppo di messaggi delle notifiche di avviso come hash dell'ARN dell'allarme.
**Topics**
+ [Prevenzione dei problemi di sicurezza “confused deputy”](#SNS_Confused_Deputy)
+ [Configurazione di un argomento Amazon SNS utilizzando Console di gestione AWS](#set-up-sns-topic-console)
+ [Configurazione di un argomento SNS utilizzando AWS CLI](#set-up-sns-topic-cli)
### Prevenzione dei problemi di sicurezza “confused deputy”
Il problema confused deputy è un problema di sicurezza in cui un’entità che non dispone dell’autorizzazione per eseguire un’azione può costringere un’entità maggiormente privilegiata a eseguire l’azione. Nel frattempo AWS, l'impersonificazione tra servizi può portare al confuso problema del vice. La rappresentazione tra servizi può verificarsi quando un servizio (il *servizio chiamante*) effettua una chiamata a un altro servizio (il *servizio chiamato*). Il servizio chiamante può essere manipolato per utilizzare le proprie autorizzazioni e agire sulle risorse di un altro cliente, a cui normalmente non avrebbe accesso. Per evitare che ciò accada, AWS mette a disposizione strumenti che consentono di proteggere i dati relativi a tutti i servizi con responsabili del servizio a cui è stato concesso l'accesso alle risorse del vostro account.
Ti consigliamo di utilizzare le chiavi di contesto delle condizioni globali [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths) nelle policy delle risorse per limitare le autorizzazioni alla risorsa che Amazon SNS fornisce a un altro servizio. Utilizza `aws:SourceArn` per associare una sola risorsa all'accesso tra servizi. Utilizza `aws:SourceAccount` se desideri consentire l'associazione di qualsiasi risorsa in tale account all'uso tra servizi. Utilizza `aws:SourceOrgID` se desideri consentire l'associazione di qualsiasi risorsa di qualsiasi account interno a un'organizzazione all'uso tra servizi. Utilizza `aws:SourceOrgPaths` per associare qualsiasi risorsa dagli account in un percorso AWS Organizations all'uso tra servizi. Per ulteriori informazioni sull'utilizzo e la comprensione dei percorsi, consulta [aws: SourceOrgPaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths) nella IAM User Guide.
Il modo più efficace per proteggersi dal problema “confused deputy” è quello di utilizzare la chiave di contesto della condizione globale `aws:SourceArn` con l’ARN completo della risorsa. Se non si conosce l’ARN completo della risorsa o si scelgono più risorse, utilizzare la chiave di contesto della condizione globale `aws:SourceArn` con caratteri jolly (`*`) per le parti sconosciute dell’ARN. Ad esempio, `arn:aws:servicename:*:123456789012:*`.
Se il valore `aws:SourceArn` non contiene l'ID account, ad esempio un ARN di un bucket Amazon S3, è necessario utilizzare sia `aws:SourceAccount` che `aws:SourceArn` per limitare le autorizzazioni.
Per proteggersi dal problema "confused deputy" su larga scala, nelle policy basate sulle risorse utilizza la chiave di contesto della condizione globale `aws:SourceOrgID` o `aws:SourceOrgPaths` con l'ID dell'organizzazione o il percorso dell'organizzazione della risorsa. Quando aggiungi, rimuovi o sposti degli account all'interno dell'organizzazione, le policy che includono la chiave `aws:SourceOrgID` o `aws:SourceOrgPaths` includono automaticamente anche gli account corretti e non necessitano dell'aggiornamento manuale.
Il valore di `aws:SourceArn` deve essere l'ARN dell'allarme che invia le notifiche.
L'esempio seguente mostra come utilizzare le chiavi di contesto `aws:SourceArn` e `aws:SourceAccount` global condition CloudWatch per prevenire il confuso problema del vice.
```
{
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "cloudwatch.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-2:444455556666:MyTopic",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:cloudwatch:us-east-2:111122223333:alarm:*"
},
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}]
}
```
Se un ARN di allarme include caratteri non ASCII, utilizza solo la chiave di condizione globale `aws:SourceAccount` per limitare le autorizzazioni.
### Configurazione di un argomento Amazon SNS utilizzando Console di gestione AWS
Come prima cosa crea e sottoscrivi un argomento. Puoi anche pubblicare un messaggio di prova per l'argomento.
**Creazione di un argomento SNS**
1. [Apri la console Amazon SNS nella versione v3/home. https://console.aws.amazon.com/sns/](https://console.aws.amazon.com/sns/v3/home)
1. Sul pannello di controllo Amazon SNS sotto **Common actions** (Operazioni comuni), scegli **Create Topic** (Crea argomento).
1. Nella finestra di dialogo **Create new topic** (Crea nuovo argomento) per **Topic name** (Nome argomento), digita un nome per l'argomento (ad esempio, **my-topic**).
1. Scegli **Create topic** (Crea argomento).
1. Copia il valore di **Topic ARN** (ARN argomento) per l'attività successiva (ad esempio, arn:aws:sns:us-east-1:111122223333:my-topic).
**Abbonamento a un argomento SNS**
1. [Apri la console Amazon SNS nella versione v3/home. https://console.aws.amazon.com/sns/](https://console.aws.amazon.com/sns/v3/home)
1. Nel pannello di navigazione, scegli **Subscriptions** (Abbonamenti), quindi **Create subscription** (Crea abbonamento).
1. Nella finestra di dialogo **Create subscription** (Crea abbonamento), per **Topic ARN** (ARN argomento), copia l'ARN dell'argomento creato durante la precedente attività.
1. Per **Protocol**, scegli **Email**.
1. Per **Endpoint**, digita un indirizzo e-mail che puoi utilizzare per ricevere la notifica, quindi scegli **Create subscription** (Crea abbonamento).
1. Dalla tua applicazione di posta elettronica, apri il messaggio da AWS Notifiche e conferma l'abbonamento.
Nel Web browser viene visualizzata una risposta di conferma di Amazon SNS.
**Pubblicazione di messaggio test su un argomento SNS**
1. [Apri la console Amazon SNS nella versione v3/home. https://console.aws.amazon.com/sns/](https://console.aws.amazon.com/sns/v3/home)
1. Nel pannello di navigazione, scegli **Argomenti**.
1. Nella pagina **Topics** (Argomenti), seleziona un argomento e scegli **Publish to topic** (Pubblica nell'argomento).
1. Nella pagina **Publish a message** (Pubblica un messaggio), per **Subject** (Oggetto), digita l'oggetto del messaggio e per **Message** (Messaggio) digita un breve messaggio.
1. Seleziona **Publish Message** (Pubblica messaggio).
1. Controlla la tua e-mail per la conferma di ricezione del messaggio.
### Configurazione di un argomento SNS utilizzando AWS CLI
In primo luogo crea un argomento SNS, quindi pubblica un messaggio direttamente sull'argomento per verificare di averlo configurato correttamente.
**Per configurare un argomento SNS**
1. Crea l'argomento usando il comando [create-topic](https://docs.aws.amazon.com/cli/latest/reference/sns/create-topic.html) come segue.
```
1. aws sns create-topic --name my-topic
```
Amazon SNS restituisce un ARN dell'argomento con il seguente formato:
```
1. {
2. "TopicArn": "arn:aws:sns:us-east-1:111122223333:my-topic"
3. }
```
1. Sottoscrivi l'indirizzo e-mail per l'argomento utilizzando il comando [subscribe](https://docs.aws.amazon.com/cli/latest/reference/sns/subscribe.html). Se la richiesta di abbonamento va a buon fine, riceverai un'e-mail di conferma.
```
1. aws sns subscribe --topic-arn arn:aws:sns:us-east-1:111122223333:my-topic --protocol email --notification-endpoint my-email-address
```
Amazon SNS restituisce quanto segue:
```
1. {
2. "SubscriptionArn": "pending confirmation"
3. }
```
1. Dalla tua applicazione di posta elettronica, apri il messaggio da AWS Notifiche e conferma l'iscrizione.
Nel Web browser viene visualizzata una risposta di conferma da Amazon Simple Notification Service.
1. Controlla l'abbonamento usando il [list-subscriptions-by-topic](https://docs.aws.amazon.com/cli/latest/reference/sns/list-subscriptions-by-topic.html)comando.
```
1. aws sns list-subscriptions-by-topic --topic-arn arn:aws:sns:us-east-1:111122223333:my-topic
```
Amazon SNS restituisce quanto segue:
```
1. {
2. "Subscriptions": [
3. {
4. "Owner": "111122223333",
5. "Endpoint": "me@mycompany.com",
6. "Protocol": "email",
7. "TopicArn": "arn:aws:sns:us-east-1:111122223333:my-topic",
8. "SubscriptionArn": "arn:aws:sns:us-east-1:111122223333:my-topic:64886986-bf10-48fb-a2f1-dab033aa67a3"
9. }
10. ]
11. }
```
1. (Facoltativo) Pubblica un messaggio test per l'argomento utilizzando il comando [publish](https://docs.aws.amazon.com/cli/latest/reference/sns/publish.html).
```
1. aws sns publish --message "Verification" --topic arn:aws:sns:us-east-1:111122223333:my-topic
```
Amazon SNS restituisce quanto segue:
```
1. {
2. "MessageId": "42f189a0-3094-5cf6-8fd7-c2dde61a4d7d"
3. }
```
1. Controlla la tua e-mail per la conferma di ricezione del messaggio.
## Schema delle notifiche Amazon SNS quando gli allarmi cambiano stato
Questa sezione elenca gli schemi delle notifiche inviate agli argomenti di Amazon SNS quando gli allarmi cambiano stato.
**Schema quando un allarme per la metrica cambia stato**
```
{
"AlarmName": "string",
"AlarmDescription": "string",
"AWSAccountId": "string",
"AlarmConfigurationUpdatedTimestamp": "string",
"NewStateValue": "string",
"NewStateReason": "string",
"StateChangeTime": "string",
"Region": "string",
"AlarmArn": "string",
"OldStateValue": "string",
"OKActions": ["string"],
"AlarmActions": ["string"],
"InsufficientDataActions": ["string"],
"Trigger": {
"MetricName": "string",
"Namespace": "string",
"StatisticType": "string",
"Statistic": "string",
"Unit": "string or null",
"Dimensions": [
{
"value": "string",
"name": "string"
}
],
"Period": "integer",
"EvaluationPeriods": "integer",
"DatapointsToAlarm": "integer",
"ComparisonOperator": "string",
"Threshold": "number",
"TreatMissingData": "string",
"EvaluateLowSampleCountPercentile": "string or null"
}
}
```
**Schema quando un allarme composito cambia stato**
```
{
"AlarmName": "string",
"AlarmDescription": "string",
"AWSAccountId": "string",
"NewStateValue": "string",
"NewStateReason": "string",
"StateChangeTime": "string",
"Region": "string",
"AlarmArn": "string",
"OKActions": [String],
"AlarmActions": [String],
"InsufficientDataActions": [String],
"OldStateValue": "string",
"AlarmRule": "string",
"TriggeringChildren": [String]
}
```
# Invocazione di una funzione Lambda da un allarme
CloudWatch alarms garantisce un'invocazione asincrona della funzione Lambda per un determinato cambio di stato, tranne nei seguenti casi:
+ Quando la funzione non esiste.
+ When non CloudWatch è autorizzato a richiamare la funzione Lambda.
Se non CloudWatch riesce a raggiungere il servizio Lambda o il messaggio viene rifiutato per un altro motivo, CloudWatch riprova finché la chiamata non ha esito positivo. Lambda mette in coda il messaggio e gestisce i nuovi tentativi di esecuzione. Per ulteriori informazioni su questo modello di esecuzione, incluse informazioni su come Lambda gestisce gli errori, consulta [ Asynchronous invocation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) nella Guida per gli sviluppatori di AWS Lambda .
È possibile richiamare una funzione Lambda nello stesso account o in AWS altri account.
Quando specifichi un allarme per richiamare una funzione Lambda come operazione di allarme, puoi scegliere di specificare il nome della funzione, l'alias della funzione o una versione specifica di una funzione.
Quando si specifica una funzione Lambda come azione di allarme, è necessario creare una politica delle risorse per la funzione per consentire al responsabile del CloudWatch servizio di richiamare la funzione.
Un modo per farlo è utilizzare AWS CLI, come nell'esempio seguente:
```
aws lambda add-permission \
--function-name my-function-name \
--statement-id AlarmAction \
--action 'lambda:InvokeFunction' \
--principal lambda.alarms.cloudwatch.amazonaws.com \
--source-account 111122223333 \
--source-arn arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name
```
In alternativa, puoi creare una policy simile a uno degli esempi riportati di seguito e assegnarla alla funzione.
L'esempio seguente specifica l'account in cui si trova l'allarme, in modo che solo gli allarmi in quell'account (111122223333) possano richiamare la funzione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [{
"Sid": "AlarmAction",
"Effect": "Allow",
"Principal": {
"Service": "lambda.alarms.cloudwatch.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333"
}
}
}]
}
```
------
L'esempio seguente ha un ambito più limitato e consente solo all'allarme specificato nell'account specificato di richiamare la funzione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "AlarmAction",
"Effect": "Allow",
"Principal": {
"Service": "lambda.alarms.cloudwatch.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333",
"AWS:SourceArn": "arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name"
}
}
}]
}
```
------
Non è consigliabile creare una policy che non specifichi un account di origine, poiché tali policy sono vulnerabili a problemi di "confused deputy".
## Aggiungi metriche Lambda alle indagini CloudWatch
Puoi aggiungere metriche Lambda alle indagini attive. CloudWatch Quando si analizza un problema, le metriche Lambda possono fornire informazioni preziose sulle prestazioni e sul comportamento delle funzioni. Ad esempio, se stai esaminando un problema di prestazioni delle applicazioni, le metriche Lambda come la durata, i tassi di errore o le limitazioni potrebbero aiutarti a identificare la causa principale.
Per aggiungere metriche Lambda alle indagini: CloudWatch
1. Apri la console all' AWS Lambda indirizzo. [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)
1. Nella sezione **Monitoraggio**, individua la metrica.
1. Apri il menu contestuale della metrica, scegli **Indagine**, **Aggiungi all'indagine**. Quindi, nel pannello **Indaga**, seleziona il nome dell'indagine.
## Oggetto evento inviato da CloudWatch Lambda
Quando configuri una funzione Lambda come azione di allarme, CloudWatch fornisce un payload JSON alla funzione Lambda quando richiama la funzione. Questo payload JSON funge da oggetto evento per la funzione. Puoi estrarre dati da questo oggetto JSON e utilizzarli nella tua funzione. Di seguito è riportato un esempio di oggetto evento da un allarme del parametro.
```
{
'source': 'aws.cloudwatch',
'alarmArn': 'arn:aws:cloudwatch:us-east-1:444455556666:alarm:lambda-demo-metric-alarm',
'accountId': '444455556666',
'time': '2023-08-04T12:36:15.490+0000',
'region': 'us-east-1',
'alarmData': {
'alarmName': 'lambda-demo-metric-alarm',
'state': {
'value': 'ALARM',
'reason': 'test',
'timestamp': '2023-08-04T12:36:15.490+0000'
},
'previousState': {
'value': 'INSUFFICIENT_DATA',
'reason': 'Insufficient Data: 5 datapoints were unknown.',
'reasonData': '{"version":"1.0","queryDate":"2023-08-04T12:31:29.591+0000","statistic":"Average","period":60,"recentDatapoints":[],"threshold":5.0,"evaluatedDatapoints":[{"timestamp":"2023-08-04T12:30:00.000+0000"},{"timestamp":"2023-08-04T12:29:00.000+0000"},{"timestamp":"2023-08-04T12:28:00.000+0000"},{"timestamp":"2023-08-04T12:27:00.000+0000"},{"timestamp":"2023-08-04T12:26:00.000+0000"}]}',
'timestamp': '2023-08-04T12:31:29.595+0000'
},
'configuration': {
'description': 'Metric Alarm to test Lambda actions',
'metrics': [
{
'id': '1234e046-06f0-a3da-9534-EXAMPLEe4c',
'metricStat': {
'metric': {
'namespace': 'AWS/Logs',
'name': 'CallCount',
'dimensions': {
'InstanceId': 'i-12345678'
}
},
'period': 60,
'stat': 'Average',
'unit': 'Percent'
},
'returnData': True
}
]
}
}
}
```
Di seguito è riportato un esempio di oggetto evento da un allarme composito.
```
{
'source': 'aws.cloudwatch',
'alarmArn': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:SuppressionDemo.Main',
'accountId': '111122223333',
'time': '2023-08-04T12:56:46.138+0000',
'region': 'us-east-1',
'alarmData': {
'alarmName': 'CompositeDemo.Main',
'state': {
'value': 'ALARM',
'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC',
'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}',
'timestamp': '2023-08-04T12:56:46.138+0000'
},
'previousState': {
'value': 'ALARM',
'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC',
'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}',
'timestamp': '2023-08-04T12:54:46.138+0000',
'actionsSuppressedBy': 'WaitPeriod',
'actionsSuppressedReason': 'Actions suppressed by WaitPeriod'
},
'configuration': {
'alarmRule': 'ALARM(CompositeDemo.FirstChild) OR ALARM(CompositeDemo.SecondChild)',
'actionsSuppressor': 'CompositeDemo.ActionsSuppressor',
'actionsSuppressorWaitPeriod': 120,
'actionsSuppressorExtensionPeriod': 180
}
}
}
```
# Avvia un' CloudWatch indagine da un allarme
Avvia un' CloudWatch indagine a partire da un allarme o da qualsiasi momento nelle ultime due settimane della cronologia di un CloudWatch allarme.
Per ulteriori informazioni sulle CloudWatch indagini, vedere. [CloudWatch indagini](Investigations.md)
## Prerequisiti
Prima di poter avviare un' CloudWatch indagine sulla base di un CloudWatch allarme, è necessario creare una politica delle risorse per la funzione che consenta al responsabile del CloudWatch servizio di avviare l'indagine. A tale scopo AWS CLI, utilizzate un comando simile al seguente esempio:
```
aws aiops put-investigation-group-policy \
--identifier arn:aws:aiops:us-east-1:111122223333:investigation-group/investigation_group_id \
--policy "{\"Version\":\"2008-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"aiops.alarms.cloudwatch.amazonaws.com\"},\"Action\":[\"aiops:CreateInvestigation\",\"aiops:CreateInvestigationEvent\"],\"Resource\":\"*\",\"Condition\":{\"StringEquals\":{\"aws:SourceAccount\":\"111122223333\"},\"ArnLike\":{\"aws:SourceArn\":\"arn:aws:cloudwatch:us-east-1:111122223333:alarm:*\"}}}]}" \
--region eu-north-1
```
Sostituisci i valori di esempio con l'ID AWS dell'account, la regione e l'ID del gruppo di indagine.
**Avvia un'indagine partendo da un CloudWatch allarme**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione sinistro, seleziona **Allarmi**, **Tutti gli allarmi**.
1. Scegli il nome dell'allarme.
1. Scegli il periodo di tempo nella cronologia degli allarmi che desideri esaminare.
1. Scegli **Investiga**, **Avvia una nuova indagine**.
1. Per **Titolo della nuova indagine**, inserisci un nome per l'indagine. Quindi scegli **Avvia indagine**.
L'assistente CloudWatch alle indagini avvia e analizza i dati di telemetria per trovare dati che potrebbero essere associati a questa situazione.
1. Nel riquadro di navigazione della CloudWatch console, scegli **Investigazioni**, quindi scegli il nome dell'indagine che hai appena avviato.
La sezione **Esiti** mostra un riepilogo in linguaggio naturale dello stato dell'allarme e del motivo per cui è stato attivato.
1. (Facoltativo) Nel grafico dell'allarme, fai clic con il pulsante destro del mouse e scegli di approfondire l'allarme o la metrica che rileva.
1. Sul lato destro dello schermo, scegli la scheda **Suggerimenti**.
Viene visualizzato un elenco di altri dati di telemetria rilevati CloudWatch dalle indagini e che potrebbero essere rilevanti per l'indagine. Questi risultati possono includere altre metriche e CloudWatch risultati delle query di Logs Insights. CloudWatch le indagini hanno eseguito queste domande sulla base dell'allarme.
+ **Per ogni risultato, scegli **Aggiungi ai risultati o Elimina**.**
Quando scegli **Aggiungi ai risultati**, la telemetria viene aggiunta alla sezione **Risultati** e CloudWatch investigations utilizza queste informazioni per indirizzare ulteriori scansioni e suggerimenti.
+ **Per modificare o modificare la query ed eseguirla nuovamente, apri il menu contestuale (fai clic con il pulsante destro del mouse) relativo ai risultati, quindi scegli Apri in CloudWatch Logs Insights.** Per ulteriori informazioni, consulta [Analisi dei dati di registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) con Logs Insights. CloudWatch
Per eseguire una query diversa, quando arrivi alla pagina Logs Insights, scegli di utilizzare Query Assist per creare una query utilizzando il linguaggio naturale. Per ulteriori informazioni, consulta [Utilizzare il linguaggio naturale per generare e aggiornare le query di CloudWatch Logs Insights.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs-Insights-Query-Assist.html)
+ (Facoltativo) Se conosci la telemetria in un altro AWS servizio che potrebbe essere applicabile a questa indagine, vai alla console del servizio e aggiungi la telemetria all'indagine.
1. CloudWatch **le indagini potrebbero anche aggiungere ipotesi all'elenco nella scheda Suggerimenti.** L'indagine genera queste ipotesi in linguaggio naturale.
**Per ogni ipotesi, scegli **Aggiungi ai** risultati o Ignora.**
1. Quando ritieni di aver completato l'indagine e trovato la causa principale del problema, scegli la scheda **Panoramica** e quindi scegli Riepilogo **dell'indagine**. CloudWatch investigations crea quindi un riepilogo in linguaggio naturale dei risultati e delle ipotesi importanti dell'indagine.
# Arresta, termina, riavvia o ripristina un'istanza EC2
Utilizzando Amazon CloudWatch Alarm Actions, puoi creare allarmi che interrompono, terminano, riavviano o ripristinano automaticamente le tue istanze EC2. Puoi utilizzare le operazioni di arresto o termine per aiutarti a risparmiare denaro quando non necessiti più dell'esecuzione di un'istanza. Puoi utilizzare le operazioni di riavvio e recupero per riavviare automaticamente tali istanze o recuperarle in un nuovo hardware, se si verifica un danneggiamento del sistema.
Esistono diversi scenari in cui potresti voler arrestare o terminare automaticamente l'istanza. Ad esempio, potresti disporre di istanze dedicate a processi di elaborazione della retribuzione in batch o ad attività di calcolo scientifico che vengono eseguite per un periodo di tempo, dopodiché completano il proprio lavoro. Anziché lasciare tali istanze inattive (accumulando addebiti), puoi arrestarle o terminarle per risparmiare denaro. La differenza principale tra l'uso delle operazioni di allarme di arresto o di terminazione consiste nel poter riavviare comodamente un'istanza arrestata se è necessario eseguirla in un secondo momento, mantenendo gli stessi ID istanza e volume radice. Tuttavia, non puoi riavviare un'istanza terminata. Al contrario, è necessario avviare una nuova istanza.
Puoi aggiungere le azioni di arresto, terminazione o riavvio a qualsiasi allarme impostato su un parametro Amazon EC2 per istanza, inclusi i parametri di monitoraggio di base e dettagliati forniti da CloudWatch Amazon (nello spazio dei nomi AWS/EC2), oltre a qualsiasi metrica personalizzata che includa la dimensione InstanceId "=», purché il valore si riferisca a un'istanza Amazon EC2 valida in esecuzione. InstanceId Puoi anche aggiungere l'azione di ripristino agli allarmi impostati su qualsiasi parametro per istanza Amazon EC2, ad eccezione di `StatusCheckFailed_Instance`.
**Importante**
Gli allarmi configurati sulle metriche Amazon EC2 possono assumere temporaneamente lo stato INSUFFICIENT\$1DATA se mancano dei punti dati delle metriche. Si tratta di una circostanza rara, ma può verificarsi nel caso di un'interruzione della segnalazione delle metriche, anche quando l'istanza Amazon EC2 è integra. Per gli allarmi sulle metriche di Amazon EC2 configurati per eseguire operazioni di arresto, terminazione, riavvio o ripristino, consigliamo di configurare tali allarmi in modo che trattino i dati mancanti come `missing` e che questi allarmi si attivino solo nello stato ALARM.
Per ulteriori informazioni su come CloudWatch configurare l'azione sulle metriche mancanti su cui sono impostati degli allarmi, consulta[Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](alarms-and-missing-data.md).
Per impostare un'azione di CloudWatch allarme in grado di riavviare, arrestare o terminare un'istanza, devi utilizzare un ruolo IAM collegato al servizio,. *AWSServiceRoleForCloudWatchEvents* Il ruolo AWSService RoleForCloudWatchEvents IAM consente di AWS eseguire azioni di allarme per tuo conto.
Per creare il ruolo collegato al servizio per CloudWatch Events, usa il seguente comando:
```
aws iam create-service-linked-role --aws-service-name events.amazonaws.com
```
**Supporto della console**
Puoi creare allarmi utilizzando la CloudWatch console o la console Amazon EC2. Le procedure descritte in questa documentazione utilizzano la CloudWatch console. Per le procedure che utilizzano la console Amazon EC2, consulta [Create alarms that stop, terminate, reboot, or rcover an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingAlarmActions.html) nella *Guida per l'utente di Amazon EC2*.
**Permissions**
Se utilizzi un account AWS Identity and Access Management (IAM) per creare o modificare un allarme che esegue azioni EC2 o azioni Systems Manager OpsItem , devi disporre dell'`iam:CreateServiceLinkedRole`autorizzazione.
**Topics**
+ [Aggiungere azioni di interruzione agli CloudWatch allarmi Amazon](#AddingStopActions)
+ [Aggiungere azioni di terminazione agli allarmi Amazon CloudWatch](#AddingTerminateActions)
+ [Aggiungere azioni di riavvio agli allarmi Amazon CloudWatch](#AddingRebootActions)
+ [Aggiungere azioni di ripristino agli CloudWatch allarmi Amazon](#AddingRecoverActions)
+ [Visualizzazione della cronologia degli allarmi e delle operazioni attivati](#ViewAlarmHistory)
## Aggiungere azioni di interruzione agli CloudWatch allarmi Amazon
Puoi creare un allarme per arrestare un'istanza Amazon EC2 al raggiungimento di una determinata soglia. Ad esempio, potresti eseguire istanze di sviluppo o di test e occasionalmente dimenticare di disattivarle. Puoi creare un allarme che viene attivato quando la percentuale di utilizzo medio della CPU è inferiore al 10% per 24 ore, segnalando che la CPU è inattiva e non più in uso. Puoi regolare la soglia, la durata e il periodo di tempo in base alle tue esigenze. È possibile inoltre aggiungere una notifica SNS, in modo da ricevere un'e-mail all'attivazione dell'allarme.
Le istanze Amazon EC2 che utilizzano un volume Amazon Elastic Block Store come dispositivo root possono essere arrestate o terminate, mentre le istanze che utilizzano l'instance store come dispositivo root possono solo essere terminate.
**Per creare un allarme per interrompere un'istanza inattiva utilizzando la console Amazon CloudWatch**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All alarms** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **Select Metric** (Seleziona parametro).
1. Nel campo **Spazi dei nomi AWS **, scegli **EC2**.
1. Esegui questa operazione:
1. Scegli **Per-Instance Metrics** (Parametri per istanza).
1. Seleziona la casella di controllo nella riga con l'istanza e la **CPUUtilization**metrica corrette.
1. Seleziona la scheda **Graphed metrics** (Parametri nel grafico).
1. Per la statistica, scegli **Average** (Media).
1. Seleziona un periodo (ad esempio, **1 Hour**).
1. Scegli **Seleziona metrica**.
1. In **Condizioni**, effettuare le seguenti operazioni:
1. Scegli **Static** (Statico).
1. In **Ogni volta che CPUUtilization è**, scegli **Inferiore**.
1. Per **than** (di), inserisci **10**.
1. Scegli **Next (Successivo)**.
1. Sotto **Notification** (Notifica), in **Send notification to** (Invia notifica a), seleziona un argomento SNS esistente o creane uno nuovo.
Per creare un argomento SNS, seleziona **New list (Nuovo elenco)**. In **Invia notifica a**, digita un nome per l'argomento SNS (ad esempio, Stop\$1 EC2 \$1Instance). In **Email list** (Elenco e-mail), digita un elenco di indirizzi e-mail separati da virgola a cui inviare una notifica quando l'allarme passa allo stato `ALARM`. Viene inviato a ciascun indirizzo un'e-mail di conferma della sottoscrizione all'argomento. È necessario confermare la sottoscrizione prima che le notifiche possano essere inviate a un indirizzo e-mail.
1. Seleziona **Add EC2 action** (Aggiungi operazione EC2).
1. Per **Alarm state trigger** (Attivazione stato allarme), scegli **In alarm** (In allarme). Per **Take the following action** (Esegui la seguente operazione), scegli **Stop this instance** (Arresta questa istanza).
1. Scegli **Next (Successivo)**.
1. Inserisci un nome e una descrizione per l'allarme. Il nome deve contenere solo caratteri ASCII. Quindi scegli **Successivo**.
1. In **Preview and create** (Visualizza anteprima e crea), conferma che le informazioni e le condizioni sono quelle desiderate, quindi scegli **Create alarm** (Crea allarme).
## Aggiungere azioni di terminazione agli allarmi Amazon CloudWatch
Puoi creare un allarme per terminare automaticamente un'istanza EC2 al raggiungimento di una determinata soglia, purché non sia abilitata la protezione da cessazione dell'istanza. Ad esempio, potresti voler terminare un'istanza una volta completato il lavoro e non averne più bisogno. Se intendessi utilizzare l'istanza in un secondo momento, sarebbe necessario arrestare l'istanza anziché terminarla. Per informazioni sull'abilitazione e sulla disabilitazione della protezione da terminazione delle istanze, consulta [Enabling Termination Protection for an Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_ChangingDisableAPITermination.html) nella *Guida per l'utente di Amazon EC2*.
**Per creare un allarme per terminare un'istanza inattiva utilizzando la console Amazon CloudWatch**
1. Apri la CloudWatch console all'indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel riquadro di navigazione, seleziona **Alarms** (Allarmi), **Create Alarm** (Crea allarme).
1. Nella fase **Select Metric** (Seleziona parametro), effettua le operazioni seguenti:
1. In **EC2 Metrics** (Parametri di EC2), seleziona **Per-Instance Metrics** (Parametri per istanza).
1. Seleziona la riga con l'istanza e la **CPUUtilization**metrica.
1. Per la statistica, scegli **Average** (Media).
1. Seleziona un periodo (ad esempio, **1 Hour**).
1. Scegli **Next (Successivo)**.
1. Nella fase **Define Alarm** (Definisci allarme), effettua le operazioni seguenti:
1. In **Alarm Threshold** (Soglia allarme), digita un nome per l'allarme (ad esempio, "Termina istanza EC2") e una descrizione dell'allarme (ad esempio, "Termina istanza EC2 quando la CPU è inattiva troppo a lungo"). I nomi degli allarmi devono contenere solo caratteri ASCII.
1. In **Whenever (Ogni volta che)**, in **is (è)**, scegli **<** e digita **10**. Per **for (per)**, digita **24** periodi consecutivi.
Viene visualizzata una rappresentazione grafica della soglia in **Alarm Preview** (Anteprima allarme).
1. Sotto **Notification** (Notifica), in **Send notification to** (Invia notifica a), seleziona un argomento SNS esistente o creane uno nuovo.
Per creare un argomento SNS, seleziona **New list (Nuovo elenco)**. Per **Invia notifica a**, digita un nome per l'argomento SNS (ad esempio, EC2 Terminate\$1 \$1Instance). In **Email list** (Elenco e-mail), digita un elenco di indirizzi e-mail separati da virgola a cui inviare una notifica quando l'allarme passa allo stato `ALARM`. Viene inviato a ciascun indirizzo un'e-mail di conferma della sottoscrizione all'argomento. È necessario confermare la sottoscrizione prima che le notifiche possano essere inviate a un indirizzo e-mail.
1. Seleziona **EC2 Action** (Operazione EC2).
1. In **Whenever this alarm** (Ogniqualvolta questo allarme), seleziona **State is ALARM** (Lo stato è ALLARME). In **Take this action** (Esegui questa operazione), seleziona **Terminate this instance** (Termina questa istanza).
1. Scegli **Crea allarme**.
## Aggiungere azioni di riavvio agli allarmi Amazon CloudWatch
Puoi creare un CloudWatch allarme Amazon che monitora un'istanza Amazon EC2 e riavvia automaticamente l'istanza. L'operazione di allarme di riavvio è consigliata per gli errori di controllo dello stato dell'istanza (contrariamente all'operazione di allarme di recupero, adatta agli errori di controllo dello stato del sistema). Il riavvio di un'istanza equivale al riavvio di un sistema operativo. Nella maggior parte dei casi, sono necessari pochi minuti per riavviare l'istanza. Quando riavvii un'istanza, questa rimane sullo stesso host fisico, in modo che l'istanza conservi il proprio nome DNS pubblico, indirizzo IP privato e tutti i dati presenti nei volumi instance store.
Il riavvio di un'istanza non avvia una uovo ora di fatturazione di istanza, a differenza dell'arresto e del riavvio dell'istanza. Per ulteriori informazioni sul riavvio di un'istanza, consulta [Reboot Your Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html) nella *Guida per l'utente di Amazon EC2*.
**Importante**
Per evitare una race condition tra le operazioni di riavvio e di recupero, evita di impostare lo stesso periodo di valutazione per entrambi gli allarmi di riavvio e di recupero. È consigliabile impostare gli allarmi di riavvio su tre periodi di valutazione di un minuto ciascuno.
**Per creare un allarme per riavviare un'istanza utilizzando la console Amazon CloudWatch**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel riquadro di navigazione, seleziona **Alarms** (Allarmi), **Create Alarm** (Crea allarme).
1. Nella fase **Select Metric** (Seleziona parametro), effettua le operazioni seguenti:
1. In **EC2 Metrics** (Parametri di EC2), seleziona **Per-Instance Metrics** (Parametri per istanza).
1. Seleziona la riga con l'istanza e la metrica **StatusCheckFailed\$1Instance**.
1. Per la statistica, seleziona **Minimum** (Minimo).
1. Seleziona un periodo (ad esempio, **1 Minute**).
1. Scegli **Next (Successivo)**.
1. Nella fase **Define Alarm** (Definisci allarme), effettua le operazioni seguenti:
1. In **Alarm Threshold** (Soglia allarme), digita un nome per l'allarme (ad esempio, "Riavvia istanza EC2") e una descrizione dell'allarme (ad esempio, "Riavvia istanza EC2 quando i controlli dello stato hanno esito negativo). I nomi degli allarmi devono contenere solo caratteri ASCII.
1. In **Whenever (Ogni volta che)**, in **is (è)** scegli **>** e digita **0**. Per **for (per)**, digita **3** periodi consecutivi.
Viene visualizzata una rappresentazione grafica della soglia in **Alarm Preview** (Anteprima allarme).
1. Sotto **Notification** (Notifica), in **Send notification to** (Invia notifica a), seleziona un argomento SNS esistente o creane uno nuovo.
Per creare un argomento SNS, seleziona **New list (Nuovo elenco)**. Per **Invia notifica a**, digita un nome per l'argomento SNS (ad esempio, EC2 Reboot\$1 \$1Instance). In **Email list** (Elenco e-mail), digita un elenco di indirizzi e-mail separati da virgola a cui inviare una notifica quando l'allarme passa allo stato `ALARM`. Viene inviato a ciascun indirizzo un'e-mail di conferma della sottoscrizione all'argomento. È necessario confermare la sottoscrizione prima che le notifiche possano essere inviate a un indirizzo e-mail.
1. Seleziona **EC2 Action** (Operazione EC2).
1. In **Whenever this alarm** (Ogniqualvolta questo allarme), seleziona **State is ALARM** (Lo stato è ALLARME). In **Take this action** (Esegui questa operazione), seleziona **Reboot this instance** (Riavvia questa istanza).
1. Scegli **Crea allarme**.
## Aggiungere azioni di ripristino agli CloudWatch allarmi Amazon
Puoi creare un CloudWatch allarme Amazon che monitora un'istanza Amazon EC2 e ripristina automaticamente l'istanza se viene danneggiata a causa di un guasto hardware sottostante o di un problema che AWS richiede la riparazione. Le istanze terminate non possono essere recuperate. Un'istanza recuperata è identica all'istanza originale, incluso l'ID istanza, gli indirizzi IP privati, gli indirizzi IP elastici e tutti i metadati dell'istanza.
Quando viene attivato l'allarme `StatusCheckFailed_System` e viene avviata l'operazione di ripristino, riceverai una notifica dall'argomento Amazon SNS selezionato al momento della creazione dell'allarme e dell'associazione dell'operazione di ripristino. Durante il recupero dell'istanza, l'istanza viene migrata durante un riavvio di istanza e tutti i dati in memoria andranno persi. Una volta completato il processo, l'informazione viene pubblicata nell'argomento SNS configurato per l'allarme. Tutti coloro che hanno eseguito la sottoscrizione a questo argomento SNS riceveranno una notifica e-mail che include lo stato del tentativo di recupero ed eventuali ulteriori istruzioni. Noterai un riavvio di istanza nell'istanza recuperata.
L'operazione di recupero può essere utilizzata solo con `StatusCheckFailed_System`, non con `StatusCheckFailed_Instance`.
Esempi di problemi che causano il mancato superamento dei controlli dello stato del sistema:
+ Perdita di connettività di rete
+ Perdita di alimentazione elettrica del sistema
+ Problemi di software sull'host fisico
+ Problemi hardware sull'host fisico che incidono sulla raggiungibilità della rete
L'azione di ripristino è supportata solo su alcuni tipi di istanza. Per ulteriori informazioni sui tipi di istanza supportati e su altri requisiti, consulta [Ripristino dell'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) e [Requisiti](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html#requirements-for-recovery).
**Importante**
Per evitare una race condition tra le operazioni di riavvio e di recupero, evita di impostare lo stesso periodo di valutazione per entrambi gli allarmi di riavvio e di recupero. Consigliamo di impostare gli allarmi di recupero su periodi di valutazione di un minuto ciascuno e gli allarmi di riavvio su tre periodi di valutazione di un minuto ciascuno.
**Per creare un allarme per ripristinare un'istanza utilizzando la CloudWatch console Amazon**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All alarms** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **Seleziona metrica** ed esegui una delle operazioni seguenti:
1. In **Metriche EC2**, seleziona **Metriche per istanza**.
1. Seleziona la riga con l'istanza e la metrica **StatusCheckFailed\$1System**, quindi scegli **Seleziona** metrica.
1. Per la statistica, seleziona **Minimum** (Minimo).
1. Seleziona un periodo (ad esempio, **1 Minute**).
**Importante**
Per evitare una race condition tra le operazioni di riavvio e di recupero, evita di impostare lo stesso periodo di valutazione per entrambi gli allarmi di riavvio e di recupero. È consigliabile impostare gli allarmi di recupero su due periodi di valutazione di un minuto ciascuno.
1. Per **Condizioni**, effettua le seguenti operazioni:
1. Per **Tipo di soglia**, scegli **Statica**.
1. Per **Ogni volta**, scegli **Maggiore** e inserisci **0** per **di...**.
1. Scegli **Configurazione aggiuntiva**, quindi per **Punti dati su cui attivare allarmi** specifica 2 **su** 2.
1. Scegli **Next (Successivo)**.
1. In **Notifiche**, esegui le operazioni seguenti:
1. Per **Alarm state trigger** (Attivazione stato allarme), scegli **In alarm** (In allarme).
1. Per **Invia notifica al seguente argomento SNS**, scegli un argomento SNS esistente o creane uno nuovo.
1. Seleziona **Add EC2 action** (Aggiungi operazione EC2).
1. Per **Alarm state trigger** (Attivazione stato allarme), scegli **In alarm** (In allarme).
1. Per **Esegui la seguente operazione**, scegli **Ripristina questa istanza**.
1. Scegli **Next (Successivo)**.
1. In **Nome dell'allarme**, immetti un nome univoco (ad esempio, **Recover EC2 instance**) e una descrizione (ad esempio, **Recover EC2 instance when health checks fail**) dell'allarme. I nomi degli allarmi devono contenere solo caratteri ASCII.
1. Scegli **Next (Successivo)**.
1. Scegli **Crea allarme**.
## Visualizzazione della cronologia degli allarmi e delle operazioni attivati
Puoi visualizzare la cronologia degli allarmi e delle azioni nella CloudWatch console Amazon. Amazon CloudWatch conserva la cronologia degli ultimi 30 giorni di allarmi e azioni.
**Visualizzazione della cronologia degli allarmi e delle operazioni attivati**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel riquadro di navigazione, selezionare **Alarms (Allarmi)**, quindi selezionare un allarme.
1. Per visualizzare la transizione di stato più recente insieme ai valori di tempo e di parametro, seleziona **Details** (Dettagli).
1. Per visualizzare le voci più recenti della cronologia, selezionare **History (Cronologia)**.
# Eventi di allarme e EventBridge
CloudWatch invia eventi ad Amazon EventBridge ogni volta che un CloudWatch allarme viene creato, aggiornato, eliminato o cambia lo stato dell'allarme. Puoi utilizzare EventBridge questi eventi per scrivere regole che intraprendano azioni, come avvisarti quando un allarme cambia stato. Per ulteriori informazioni, consulta [What is Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
CloudWatch garantisce la trasmissione degli eventi di modifica dello stato di allarme a EventBridge.
## Eventi di modifica dello stato degli allarmi
Questa sezione mostra esempi di eventi inviati EventBridge quando cambia lo stato di un allarme. Seleziona una scheda per visualizzare i diversi tipi di eventi di modifica dello stato di allarme.
------
#### [ Single Metric Alarm ]
Eventi generati quando un singolo allarme per la metrica cambia stato. Questi eventi includono i campi `state` e `previousState` con i risultati della valutazione dell'allarme.
```
{
"version": "0",
"id": "c4c1c1c9-6542-e61b-6ef0-8c4d36933a92",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-02T17:04:40Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh"
],
"detail": {
"alarmName": "ServerCpuTooHigh",
"configuration": {
"description": "Goes into alarm when server CPU utilization is too high!",
"metrics": [
{
"id": "30b6c6b2-a864-43a2-4877-c09a1afc3b87",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "CPUUtilization",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
]
},
"previousState": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [0.0666851903306472 (01/10/19 13:46:00)] was not greater than the threshold (50.0) (minimum 1 datapoint for ALARM -> OK transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-01T13:56:40.985+0000\",\"startDate\":\"2019-10-01T13:46:00.000+0000\",\"statistic\":\"Average\",\"period\":300,\"recentDatapoints\":[0.0666851903306472],\"threshold\":50.0}",
"timestamp": "2019-10-01T13:56:40.987+0000",
"value": "OK"
},
"state": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [99.50160229693434 (02/10/19 16:59:00)] was greater than the threshold (50.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-02T17:04:40.985+0000\",\"startDate\":\"2019-10-02T16:59:00.000+0000\",\"statistic\":\"Average\",\"period\":300,\"recentDatapoints\":[99.50160229693434],\"threshold\":50.0}",
"timestamp": "2019-10-02T17:04:40.989+0000",
"value": "ALARM"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Metric Math Alarm ]
Eventi generati quando un allarme basato sulla matematica delle metriche cambia stato. Questi eventi includono i dettagli delle espressioni matematiche presenti nel campo `configuration`.
```
{
"version": "0",
"id": "2dde0eb1-528b-d2d5-9ca6-6d590caf2329",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-02T17:20:48Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh"
],
"detail": {
"alarmName": "TotalNetworkTrafficTooHigh",
"configuration": {
"description": "Goes into alarm if total network traffic exceeds 10Kb",
"metrics": [
{
"expression": "SUM(METRICS())",
"id": "e1",
"label": "Total Network Traffic",
"returnData": true
},
{
"id": "m1",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "NetworkIn",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "m2",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "NetworkOut",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
}
]
},
"previousState": {
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2019-10-02T17:20:03.642+0000",
"value": "INSUFFICIENT_DATA"
},
"state": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [45628.0 (02/10/19 17:10:00)] was greater than the threshold (10000.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-02T17:20:48.551+0000\",\"startDate\":\"2019-10-02T17:10:00.000+0000\",\"period\":300,\"recentDatapoints\":[45628.0],\"threshold\":10000.0}",
"timestamp": "2019-10-02T17:20:48.554+0000",
"value": "ALARM"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Anomaly Detection Alarm ]
Eventi generati quando un allarme di rilevamento di anomalie cambia stato. Questi eventi includono i limiti di soglia superiore e inferiore nel campo `reasonData`.
```
{
"version": "0",
"id": "daafc9f1-bddd-c6c9-83af-74971fcfc4ef",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-03T16:00:04Z",
"region": "us-east-1",
"resources": ["arn:aws:cloudwatch:us-east-1:123456789012:alarm:EC2 CPU Utilization Anomaly"],
"detail": {
"alarmName": "EC2 CPU Utilization Anomaly",
"state": {
"value": "ALARM",
"reason": "Thresholds Crossed: 1 out of the last 1 datapoints [0.0 (03/10/19 15:58:00)] was less than the lower thresholds [0.020599444741798756] or greater than the upper thresholds [0.3006915352732461] (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-03T16:00:04.650+0000\",\"startDate\":\"2019-10-03T15:58:00.000+0000\",\"period\":60,\"recentDatapoints\":[0.0],\"recentLowerThresholds\":[0.020599444741798756],\"recentUpperThresholds\":[0.3006915352732461]}",
"timestamp": "2019-10-03T16:00:04.653+0000"
},
"previousState": {
"value": "OK",
"reason": "Thresholds Crossed: 1 out of the last 1 datapoints [0.166666666664241 (03/10/19 15:57:00)] was not less than the lower thresholds [0.0206719426210418] or not greater than the upper thresholds [0.30076870222143803] (minimum 1 datapoint for ALARM -> OK transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-03T15:59:04.670+0000\",\"startDate\":\"2019-10-03T15:57:00.000+0000\",\"period\":60,\"recentDatapoints\":[0.166666666664241],\"recentLowerThresholds\":[0.0206719426210418],\"recentUpperThresholds\":[0.30076870222143803]}",
"timestamp": "2019-10-03T15:59:04.672+0000"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
},
"configuration": {
"description": "Goes into alarm if CPU Utilization is out of band",
"metrics": [{
"id": "m1",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 60,
"stat": "Average"
},
"returnData": true
}, {
"id": "ad1",
"expression": "ANOMALY_DETECTION_BAND(m1, 0.8)",
"label": "CPUUtilization (expected)",
"returnData": true
}]
}
}
}
```
------
#### [ Composite Alarm ]
Eventi generati quando un allarme composito cambia stato. Questi eventi includono informazioni sulla soppressione nei campi `actionsSuppressedBy` e `actionsSuppressedReason`.
```
{
"version": "0",
"id": "d3dfc86d-384d-24c8-0345-9f7986db0b80",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-22T15:57:45Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"actionsSuppressedReason": "Actions suppressed by WaitPeriod",
"value": "ALARM",
"reason": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:SuppressionDemo.EventBridge.FirstChild transitioned to ALARM at Friday 22 July, 2022 15:57:45 UTC",
"reasonData": "{\"triggeringAlarms\":[{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh\",\"state\":{\"value\":\"ALARM\",\"timestamp\":\"2022-07-22T15:57:45.394+0000\"}}]}",
"timestamp": "2022-07-22T15:57:45.394+0000"
},
"previousState": {
"value": "OK",
"reason": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:SuppressionDemo.EventBridge.Main was created and its alarm rule evaluates to OK",
"reasonData": "{\"triggeringAlarms\":[{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh\",\"state\":{\"value\":\"OK\",\"timestamp\":\"2022-07-14T16:28:57.770+0000\"}},{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh\",\"state\":{\"value\":\"OK\",\"timestamp\":\"2022-07-14T16:28:54.191+0000\"}}]}",
"timestamp": "2022-07-22T15:56:14.552+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Multi Time Series Alarm ]
Eventi generati quando un Alarm Contributor o un Alarm cambia stato. Gli eventi di modifica dello stato di Alarm Contributor contengono l'id e gli attributi di Alarm Contributor, nonché il datapoint più recente che ha violato la soglia. Gli eventi di modifica dello stato di Alarm hanno un riepilogo del numero di contributori che hanno causato la transizione dell'allarme e del relativo motivo.
**Esempio di collaboratore di Alarm**
```
{
"version": "0",
"id": "6d226bbc-07f0-9a31-3359-1736968f8ded",
"detail-type": "CloudWatch Alarm Contributor State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2025-12-01T13:42:04Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:DynamoDBInsightsAlarm"
],
"detail": {
"alarmName": "DynamoDBInsightsAlarm",
"alarmContributor": {
"id": "6d442278dba546f6",
"attributes": {
"TableName": "example-dynamodb-table-name"
}
},
"state": {
"value": "ALARM",
"reason": "Threshold Crossed: 1 datapoint was less than the threshold (1.0). The most recent datapoint which crossed the threshold: [0.0 (01/12/25 13:34:00)].",
"timestamp": "2025-12-01T13:42:04.919+0000"
},
"configuration": {
"metrics": [
{
"id": "m1",
"expression": "SELECT AVG(ConsumedWriteCapacityUnits) FROM \"AWS/DynamoDB\" GROUP BY TableName ORDER BY MAX() DESC",
"returnData":true,
"period": 60
}
],
"description": "Metrics Insights alarm for DynamoDB ConsumedWriteCapacity per TableName"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
**Esempio di allarme**
```
{
"version": "0",
"id": "80ddd249-dedf-7c4d-0708-0eb78132dd78",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2025-12-01T13:42:04Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:DynamoDBInsightsAlarm"
],
"detail": {
"alarmName": "DynamoDBInsightsAlarm",
"state": {
"value": "ALARM",
"reason": "6 out of 6 time series evaluated to ALARM",
"timestamp": "2025-12-01T13:42:04.919+0000"
},
"previousState": {
"value": "INSUFFICIENT_DATA",
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2025-12-01T13:40:50.600+0000"
},
"configuration": {
"metrics": [
{
"id": "m1",
"expression": "SELECT AVG(ConsumedWriteCapacityUnits) FROM \"AWS/DynamoDB\" GROUP BY TableName ORDER BY MAX() DESC",
"returnData": true,
"period": 60
}
],
"description": "Metrics Insights alarm for DynamoDB ConsumedWriteCapacity per TableName"
}
}
}
```
------
## Eventi di modifica della configurazione degli allarmi
Questa sezione mostra esempi di eventi inviati EventBridge quando la configurazione di un allarme cambia. Le modifiche alla configurazione includono la creazione, l'aggiornamento o l'eliminazione di allarmi.
------
#### [ Creation Events ]
Eventi generati quando vengono creati nuovi allarmi. Questi eventi includono la configurazione iniziale degli allarmi nel campo `configuration`, con `operation` impostato su “crea”.
**Esempio di allarme composito**
```
{
"version": "0",
"id": "91535fdd-1e9c-849d-624b-9a9f2b1d09d0",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:06:22Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "create",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:22.289+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"alarmName": "ServiceAggregatedAlarm",
"description": "Aggregated monitor for instance",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:22.289+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**Esempio di allarme composito con soppressore**
```
{
"version": "0",
"id": "454773e1-09f7-945b-aa2c-590af1c3f8e0",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T13:59:46Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "create",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:46.425+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
#### [ Update Events ]
Eventi generati quando gli allarmi esistenti vengono modificati. Questi eventi contengono entrambi i campi `configuration` e `previousConfiguration` per mostrare cosa è cambiato.
**Esempio di allarme per la metrica**
```
{
"version": "0",
"id": "bc7d3391-47f8-ae47-f457-1b4d06118d50",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:06:34Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh"
],
"detail": {
"alarmName": "ServerCpuTooHigh",
"operation": "update",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:13.757+0000"
},
"configuration": {
"evaluationPeriods": 1,
"threshold": 80,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [
{
"id": "86bfa85f-b14c-ebf7-8916-7da014ce23c0",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
],
"alarmName": "ServerCpuTooHigh",
"description": "Goes into alarm when server CPU utilization is too high!",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:34.267+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
},
"previousConfiguration": {
"evaluationPeriods": 1,
"threshold": 70,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [
{
"id": "d6bfa85f-893e-b052-a58b-4f9295c9111a",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
],
"alarmName": "ServerCpuTooHigh",
"description": "Goes into alarm when server CPU utilization is too high!",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:13.757+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**Esempio di allarme per la metrica con soppressore**
```
{
"version": "0",
"id": "4c6f4177-6bd5-c0ca-9f05-b4151c54568b",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T13:59:56Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "update",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"value": "ALARM",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 360,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:56.290+0000",
"okActions": [],
"alarmActions": [], Remove
"insufficientDataActions": []
},
"previousConfiguration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:46.425+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
#### [ Deletion Events ]
Eventi generati quando gli allarmi vengono eliminati. Questi eventi includono la configurazione finale dell'allarme e `operation` impostato su “elimina”.
**Esempio di allarme basato sulla matematica delle metriche**
```
{
"version": "0",
"id": "f171d220-9e1c-c252-5042-2677347a83ed",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:07:13Z",
"region": "us-east-*",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh"
],
"detail": {
"alarmName": "TotalNetworkTrafficTooHigh",
"operation": "delete",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:17.672+0000"
},
"configuration": {
"evaluationPeriods": 1,
"threshold": 10000,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [{
"id": "m1",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "NetworkIn",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "m2",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "NetworkOut",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "e1",
"expression": "SUM(METRICS())",
"label": "Total Network Traffic",
"returnData": true
}
],
"alarmName": "TotalNetworkTrafficTooHigh",
"description": "Goes into alarm if total network traffic exceeds 10Kb",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:17.672+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**Esempio di allarme basato sulla matematica delle metriche con soppressore**
```
{
"version": "0",
"id": "e34592a1-46c0-b316-f614-1b17a87be9dc",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T14:00:01Z",
"region": "us-east-*",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "delete",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"value": "ALARM",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 360,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:56.290+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
# Configura le regole di silenziamento degli allarmi
I passaggi di questa sezione spiegano come utilizzare la CloudWatch console per creare una regola di silenziamento degli allarmi. Puoi anche utilizzare l'API o creare una regola AWS CLI di silenziamento degli allarmi. Per ulteriori informazioni, consulta [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html).
**Per creare una regola di silenziamento degli allarmi**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Allarmi**, quindi scegli la scheda **Mute Rules**
1. Fai clic sul pulsante **Crea regola di silenziamento degli avvisi** per aprire una procedura guidata
1. Nella sezione **Dettagli della regola di silenziamento degli allarmi**, inserisci un nome e una descrizione opzionale per la regola di silenziamento degli allarmi
1. Nella sezione **Schema di pianificazione**, scegli una sola volta o una pianificazione ricorrente
1. Se scegli una ricorrenza unica,
1. Seleziona il fuso orario per applicare le pianificazioni di silenziamento
1. Scegli una data e un'ora di inizio, per definire quando la regola di silenziamento deve diventare attiva
1. Scegli la data e l'ora di fine, per definire quando la regola di silenziamento deve scadere
1. Se scegli Pianificazione ricorrente, avrai due opzioni. Per utilizzare il modulo Console o utilizzare l'espressione cron per configurare le pianificazioni orarie ricorrenti.
1. In **Tipo di creazione della pianificazione**, scegli «Specificare data, ora e ricorrenza» per utilizzare il modulo Console
1. Scegli il fuso orario per applicare la regola del silenziamento
1. Scegli la **data e l'ora di inizio**, per definire quando la regola di silenziamento deve diventare attiva
1. Scegli **Durata**, per definire per quanto tempo deve durare la regola di silenziamento una volta che diventa attiva
1. **Scegliete Ripeti** per definire in che modo il programma deve ripetersi ogni giorno, ogni mese, ogni fine settimana o in giorni specifici della settimana.
1. Scegliete l'opzione **Until**, per definire quando deve scadere la pianificazione di silenziamento. L'opzione predefinita è «Indefinitamente»
1. In **Tipo di creazione della pianificazione**, scegli «Imposta da un'espressione cron» per configurare le pianificazioni utilizzando le espressioni cron
1. Nella sezione **Cron expression** inserisci i valori di espressione cron desiderati.
1. Scegliete **Durata**, per definire per quanto tempo deve durare la regola di silenziamento una volta attivata
1. Nella sezione Intervallo di **tempo** opzionale, inserisci la data e l'ora di inizio e fine opzionali per definire quando la pianificazione di silenziamento deve diventare attiva e scadere.
1. Nella sezione **Target alarms**, scegli gli allarmi dal menu a discesa a cui desideri applicare questa regola di silenziamento
1. Nella sezione **Imposta i tag per la tua regola di silenziamento, allega i tag alla regola** di silenziamento della sveglia. Un tag è una coppia chiave-valore applicata a una risorsa per contenere i metadati relativi a quella risorsa. Per ulteriori informazioni, consulta [Cosa](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html) sono i tag?
1. Seleziona il pulsante **Crea regola di silenziamento dell'allarme** per creare la regola di silenziamento
## Silenziamento rapido
Gli allarmi potrebbero essere aggiunti per un breve periodo di tempo come segue,
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Allarmi**
1. Seleziona gli allarmi che desideri disattivare dall'elenco
1. **Nel menu **Azioni scegli** Mute**
1. **Nella sezione **Quick mute** scegli i periodi di tempo predefiniti (15 minuti, 1 ora, 3 ore) o seleziona Disattiva audio fino a impostare il periodo di tempo desiderato**
1. Fai clic su **Conferma** per disattivare immediatamente gli allarmi fino al periodo di tempo scelto
## Aggiungi allarmi alle regole di silenziamento esistenti
Gli allarmi possono essere aggiunti alle regole di silenziamento esistenti come segue,
1. Apri la CloudWatch console all'indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, scegli **Allarmi**
1. Seleziona gli allarmi che desideri disattivare dall'elenco
1. **Nel menu **Azioni scegli** Mute**
1. Scegli **Applica le regole di silenziamento esistenti**, che dovrebbe aprire una procedura guidata
1. Seleziona le regole di silenziamento dal menu a discesa a cui desideri aggiungere gli allarmi
1. **Clicca su Applica**
**Nota**
Le opzioni di silenziamento rapido e l'aggiunta di un allarme alle regole di silenziamento esistenti sono disponibili anche nella pagina dei dettagli dell'allarme. La scheda **Regole di silenziamento** nella pagina dei dettagli mostra tutte le regole di silenziamento associate all'allarme.
# Gestione degli allarmi
**Topics**
+ [Modificare o eliminare un CloudWatch avviso](Edit-CloudWatch-Alarm.md)
+ [Nascondere gli allarmi Auto Scaling](hide-autoscaling-alarms.md)
+ [Allarmi e tag](CloudWatch_alarms_and_tagging.md)
+ [Visualizzazione e gestione degli allarmi disattivati](viewing-managing-muted-alarms.md)
# Modificare o eliminare un CloudWatch avviso
È possibile modificare o eliminare un allarme esistente.
Il nome di un allarme esistente non può essere modificato. Puoi copiare un allarme e assegnare all'allarme un nome diverso. Per copiare un allarme, seleziona la casella di controllo accanto al nome di allarme nell'elenco di allarmi e scegli **Action** (Operazione), **Copy** (Copia).
**Modifica di un allarme**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All Alarms** (Tutti gli allarmi).
1. Scegli il nome dell'allarme.
1. Per aggiungere o rimuovere tag, scegli la scheda **Tag** e quindi **Gestisci tag**.
1. Per modificare altre parti dell'allarme, scegli **Operazioni**, **Modifica**.
Viene visualizzata la pagina **Specify metric and conditions** (Specifica parametro e condizioni), contenente un grafico e altre informazioni sul parametro e le statistiche selezionate.
1. Per modificare il parametro, scegli **Edit** (Modifica), seleziona la scheda **All metrics** (Tutti i parametri) e procedi in uno dei seguenti modi:
+ Scegli lo spazio dei nomi del servizio contenente il parametro desiderato. Continua scegliendo le opzioni così come vengono visualizzate per limitare le scelte. Quando viene visualizzato un elenco di parametri, seleziona la casella di controllo accanto al parametro desiderato.
+ Nella casella di ricerca, inserisci il nome di un parametro, dimensione o ID risorsa e premi INVIO. Quindi scegli uno dei risultati e continua finché non viene visualizzato un elenco di parametri. Seleziona la casella di controllo accanto al parametro desiderato.
Scegli **Seleziona metrica**.
1. Per modificare altri aspetti dell'allarme, scegli le opzioni appropriate. Per modificare il numero di punti dati che devono essere violati affinché venga attivato lo stato `ALARM` dell'allarme o per modificare il modo in cui i dati mancanti vengono gestiti, scegli **Additional configuration** (Configurazione aggiuntiva).
1. Scegli **Next (Successivo)**.
1. In **Notification** (Notifica), **Auto Scaling action** (Operazione Auto Scaling) e **EC2 action** (Operazione EC2), modifica facoltativamente le operazioni eseguite quando l'allarme viene attivato. Quindi scegli **Successivo**.
1. Modifica facoltativamente la descrizione dell'allarme.
Il nome di un allarme esistente non può essere modificato. Puoi copiare un allarme e assegnare all'allarme un nome diverso. Per copiare un allarme, seleziona la casella di controllo accanto al nome di allarme nell'elenco di allarmi e scegli **Action** (Operazione), **Copy** (Copia).
1. Scegli **Next (Successivo)**.
1. In **Preview and create** (Visualizza anteprima e crea), conferma che le informazioni e le condizioni sono quelle desiderate, quindi scegli **Update alarm** (Aggiorna allarme).
**Aggiornamento di un elenco di notifiche e-mail creato usando la console di Amazon SNS**
1. [Apri la console Amazon SNS nella versione v3/home. https://console.aws.amazon.com/sns/](https://console.aws.amazon.com/sns/v3/home)
1. Nel riquadro di navigazione, scegli **Topics** (Argomenti), quindi seleziona l'ARN per l'elenco di notifiche (argomento).
1. Esegui una delle seguenti operazioni:
+ Per aggiungere un indirizzo e-mail, scegli **Create subscription** (Crea abbonamento). Per **Protocollo**, scegli **E-mail**. Per **Endpoint** (Endpoint), immetti l'indirizzo e-mail del nuovo destinatario. Scegli **Create Subscription** (Crea sottoscrizione).
+ Per rimuovere un indirizzo e-mail, scegli **Subscription ID** (ID abbonamento). Scegli **Other subscription actions** (Altre operazioni di abbonamento), **Delete subscriptions** (Elimina abbonamenti).
1. Scegli **Publish to topic (Pubblica nell'argomento)**.
**Come eliminare un allarme**
1. Apri la console all' CloudWatch indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, seleziona **Alarms** (Allarmi).
1. Seleziona la casella di controllo a sinistra del nome dell'avviso e scegli **Azioni**, **Elimina**.
1. Seleziona **Delete** (Elimina).
# Nascondere gli allarmi Auto Scaling
Quando visualizzi gli allarmi in Console di gestione AWS, puoi nascondere gli allarmi relativi ad Amazon EC2 Auto Scaling e Application Auto Scaling. Questa funzione è disponibile solo nella Console di gestione AWS.
**Per nascondere temporaneamente gli allarmi Auto Scaling**
1. Apri la console all'indirizzo. CloudWatch [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All alarms** (Tutti gli allarmi) e seleziona **Hide Auto Scaling alarms** (Nascondi gli allarmi Auto Scaling).
# Allarmi e tag
I *tag* sono coppie chiave-valore che consentono di organizzare e classificare le risorse. Puoi utilizzarle anche per definire l'ambito delle autorizzazioni dell'utente, assegnandogli l'autorizzazione ad accedere o modificare solo le risorse con determinati valori di tag. [Per informazioni più generali sull'etichettatura delle risorse, consulta Etichettare le risorse AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)
L'elenco seguente spiega alcuni dettagli su come funziona l'etichettatura con gli allarmi. CloudWatch
+ Per poter impostare o aggiornare i tag per una CloudWatch risorsa, devi accedere a un account che dispone dell'`cloudwatch:TagResource`autorizzazione. Ad esempio, per creare un allarme e applicarvi dei tag, è necessario disporre dell'autorizzazione `cloudwatch:TagResource` in aggiunta all'autorizzazione `the cloudwatch:PutMetricAlarm `. Ti consigliamo di assicurarti che tutti i membri dell'organizzazione che creeranno o aggiorneranno CloudWatch le risorse dispongano dell'`cloudwatch:TagResource`autorizzazione.
+ I tag possono essere utilizzati per il controllo delle autorizzazioni basato sui tag. Ad esempio, le autorizzazioni di utente o ruolo IAM possono includere condizioni per limitare le CloudWatch chiamate a risorse specifiche in base ai relativi tag. Tuttavia, è importante tenere a mente le seguenti avvertenze.
+ I tag con nomi che iniziano con `aws:` non possono essere utilizzati per il controllo delle autorizzazioni basato su tag.
+ Gli allarmi compositi non supportano il controllo dell'autorizzazione basato su tag.
# Visualizzazione e gestione degli allarmi disattivati
**Visualizzazione degli allarmi disattivati:** è possibile identificare facilmente quali allarmi sono attualmente disattivati tramite la console. CloudWatch Sia nella visualizzazione dell'elenco degli allarmi che nelle pagine dei dettagli dei singoli allarmi, accanto agli allarmi le cui azioni sono attualmente disattivate dalle regole di silenziamento attive viene visualizzata un'icona di silenziamento. Questo indicatore visivo aiuta a capire rapidamente quali azioni degli allarmi sono attualmente disattivate fino alla scadenza della finestra di disattivazione dell'audio.
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_icon.png)
**Cronologia degli allarmi: la console degli CloudWatch allarmi offre una visualizzazione completa della sequenza temporale** che mostra quando le azioni degli allarmi sono state disattivate. Questa sequenza temporale mostra i periodi di silenziamento insieme alle modifiche dello stato degli allarmi, offrendoti una visione storica completa del comportamento degli allarmi e dell'attività di silenziamento. Puoi utilizzare questa sequenza temporale per analizzare l'efficacia delle tue regole di silenziamento e capire in che modo sono correlate alle tue attività operative.
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/alarm-mutes-timelineview.png)
**Controllo programmatico dello stato di silenziamento degli allarmi:** per determinare a livello di codice se un allarme è attualmente disattivato, puoi utilizzare l'[ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html)API con il nome dell'allarme come criterio di filtro. Questa API restituisce tutte le regole di silenziamento attive che influiscono sull'allarme specificato, consentendoti di integrare i controlli dello stato di silenziamento nei flussi di lavoro di automazione, nei dashboard di monitoraggio o negli strumenti operativi.
Ad esempio: per verificare se un allarme denominato «AltoCPUAlarm" è attualmente disattivato, chiama l'[ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html)API con il parametro del filtro impostato sul nome dell'allarme. La risposta includerà tutte le regole di silenziamento relative a quell'allarme, insieme al loro stato attuale (PROGRAMMATO, ATTIVO o SCADUTO).
**Cronologia degli allarmi:** ogni volta che le azioni di allarme vengono disattivate a causa di una regola di silenziamento attiva, CloudWatch scrive una voce di cronologia nel registro della cronologia dell'allarme. Ciò fornisce una traccia di controllo completa del momento in cui gli allarmi sono stati disattivati, aiutandovi a comprendere la cronologia degli eventi di silenziamento e a correlarli alle attività operative. Puoi visualizzare questa cronologia tramite la CloudWatch console o recuperarla a livello di codice utilizzando l'API. [DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html)
**Nota**
Quando più regole di silenziamento degli allarmi sono attive contemporaneamente, il nome della regola di silenziamento creato più di recente viene scritto nella cronologia degli allarmi insieme al numero totale di altre regole di silenziamento attive.
La timeline mostra i periodi di silenziamento solo quando uno stato di allarme passa durante una finestra di silenziamento attiva e le azioni non possono essere eseguite.
**Suggerimento**
È possibile gestire le regole di silenziamento degli allarmi in modo programmatico utilizzando l'API. CloudWatch Per ulteriori informazioni, consulta [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html), [GetAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetAlarmMuteRule.html), [ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html) e [DeleteAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DeleteAlarmMuteRule.html).
## Caratteristiche comuni degli allarmi CloudWatch
Le seguenti funzionalità si applicano a tutti gli CloudWatch allarmi:
+ Non è previsto alcun limite per il numero di allarmi che puoi creare. Per creare o aggiornare un avviso, si utilizza la CloudWatch console, l'azione [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)API o il [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html)comando contenuto in. AWS CLI
+ I nomi degli allarmi devono contenere solo caratteri UTF-8 e non possono contenere caratteri di controllo ASCII
+ Puoi elencare alcuni o tutti gli allarmi attualmente configurati ed elencare tutti gli allarmi in uno stato particolare utilizzando la CloudWatch console, l'azione [DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html)API o il comando [describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html) in. AWS CLI
+ È possibile disabilitare e abilitare le azioni di allarme utilizzando le azioni [DisableAlarmActions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DisableAlarmActions.html)e [EnableAlarmActions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_EnableAlarmActions.html)API o i comandi and in. [disable-alarm-actions[enable-alarm-actions](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/enable-alarm-actions.html)](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/disable-alarm-actions.html) AWS CLI
+ È possibile testare un allarme impostandolo su qualsiasi stato utilizzando l'azione [SetAlarmState](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_SetAlarmState.html)API o il [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html)comando in AWS CLI. Questa modifica temporanea dello stato permane solamente finché non viene effettuato un successivo confronto tra allarmi.
+ È possibile creare un allarme per una metrica personalizzata prima di creare quella metrica personalizzata. Affinché l'allarme sia valido, è necessario includere tutte le dimensioni per il parametro personalizzato in aggiunta allo spazio dei nomi parametro e al nome parametro nella definizione dell'allarme. A tale scopo, è possibile utilizzare l'azione [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)API o il [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html)comando contenuto in AWS CLI.
+ È possibile visualizzare la cronologia di un allarme utilizzando la CloudWatch console, l'azione [DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html)API o il [describe-alarm-history](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarm-history.html)comando in AWS CLI. CloudWatch conserva la cronologia degli allarmi per 30 giorni. Ogni transizione di stato viene contrassegnata con un timestamp univoco. In rari casi, la cronologia potrebbe mostrare più di una notifica per una modifica di stato. Il timestamp consente di confermare le modifiche di stato univoche.
+ Puoi aggiungere avvisi *ai preferiti dall'opzione Preferiti e recenti* nel pannello di navigazione della CloudWatch console passando il mouse sulla sveglia che desideri aggiungere ai preferiti e scegliendo il simbolo a forma di stella accanto ad essa.
+ Gli allarmi prevedono una quota per il periodo di valutazione. Il periodo di valutazione viene calcolato moltiplicando il periodo di allarme per il numero di periodi di valutazione utilizzati.
+ Il periodo di valutazione massimo è di sette giorni per gli allarmi con un periodo di almeno un'ora (3.600 secondi).
+ Il periodo di valutazione massimo è di un giorno per gli allarmi con un periodo più breve.
+ Il periodo di valutazione massimo è di un giorno per gli allarmi che utilizzano l'origine dati Lambda personalizzata.
**Nota**
Alcune AWS risorse non inviano dati metrici a in determinate condizioni. CloudWatch
Ad esempio, Amazon EBS potrebbe non inviare i dati dei parametri per un volume disponibile non collegato a un'istanza Amazon EC2, poiché non vi è alcuna attività dei parametri da monitorare per tale volume. Se disponi di un set di allarmi per tale parametro, il relativo stato potrebbe cambiare in `INSUFFICIENT_DATA`. Questo potrebbe indicare che la risorsa non è attiva e non necessariamente significare la presenza di un problema. È possibile specificare il modo in cui ogni allarme tratta i dati mancanti. Per ulteriori informazioni, consulta [Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](alarms-and-missing-data.md).
# Le migliori pratiche e consigli sugli allarmi per i servizi AWS
CloudWatch fornisce consigli sugli allarmi dei out-of-the box. Si tratta di CloudWatch allarmi che consigliamo di creare per le metriche pubblicate da altri AWS servizi. Queste raccomandazioni possono aiutarti a identificare i parametri per i quali attivare gli allarmi, in linea con le best practice per il monitoraggio. Le raccomandazioni suggeriscono anche le soglie di allarme da impostare. Seguendo le raccomandazioni, puoi evitare di trascurare il monitoraggio di aspetti importanti della tua infrastruttura AWS .
Per trovare i consigli sugli allarmi, utilizza la sezione metriche della CloudWatch console e seleziona l'interruttore del filtro dei consigli sugli allarmi. Se accedi agli avvisi consigliati nella console e poi crei un allarme consigliato, CloudWatch puoi precompilare alcune delle impostazioni degli allarmi. Per alcuni allarmi raccomandati, anche il valore della soglia di allarme è precompilato. Puoi anche utilizzare la console per scaricare infrastructure-as-code le definizioni degli allarmi consigliati e quindi utilizzare questo codice per creare l'allarme in AWS CloudFormation AWS CLI, the o Terraform.
È inoltre possibile visualizzare l'elenco degli allarmi consigliati in [Allarmi raccomandati](Best_Practice_Recommended_Alarms_AWS_Services.md).
Ti vengono addebitati i costi per gli allarmi che crei, alla stessa velocità di tutti gli altri allarmi che crei in. CloudWatch L'utilizzo delle raccomandazioni non comporta costi aggiuntivi. Per ulteriori informazioni, consulta la pagina [ CloudWatch dei prezzi di Amazon](https://aws.amazon.com/cloudwatch/pricing/).
## Ricerca e creazione di allarmi raccomandati
Segui questi passaggi per trovare le metriche per cui CloudWatch ti consigliamo di impostare gli allarmi e, facoltativamente, per creare uno di questi allarmi. La prima procedura spiega come trovare i parametri per i quali gli allarmi sono raccomandati e come creare uno di questi allarmi.
Puoi anche scaricare in blocco le definizioni degli infrastructure-as-code allarmi per tutti gli allarmi consigliati in un AWS namespace, ad esempio o. `AWS/Lambda` `AWS/S3` Le relative istruzioni vengono fornite più avanti in questo argomento.
**Individuazione dei parametri con gli allarmi raccomandati e creazione di un unico allarme raccomandato**
1. Apri la console all'indirizzo. CloudWatch [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, seleziona **Metrics** (Parametri), **All metrics** (Tutti i parametri).
1. Sopra la tabella **Parametri**, scegli **Raccomandazioni di allarme**.
L'elenco degli spazi dei nomi dei parametri viene filtrato in modo da includere soltanto i parametri che dispongono di raccomandazioni di allarme e che i servizi dell'account stanno pubblicando.
1. Scegli lo spazio dei nomi per un servizio.
L'elenco dei parametri in questo spazio dei nomi viene filtrato in modo da includere soltanto quelli che dispongono di raccomandazioni di allarme.
1. Per visualizzare lo scopo dell'allarme e la soglia raccomandata per un parametro, scegli **Visualizza dettagli**.
1. Per creare un allarme per uno dei parametri, procedi in uno dei seguenti modi:
+ Per utilizzare la console per creare un allarme, procedi come segue:
1. Seleziona la casella di controllo relativa al parametro e scegli la scheda **Parametri definiti**.
1. Seleziona l'icona dell'allarme.
![\[Creazione di un allarme a partire da un parametro in un grafico\]](http://docs.aws.amazon.com/it_it/AmazonCloudWatch/latest/monitoring/images/metric_graph_alarm.png)
Viene visualizzata la procedura guidata per la creazione dell'allarme, con il nome del parametro, la statistica e il periodo compilati in base alla raccomandazione di allarme. Se la raccomandazione include un valore di soglia specifico, anche quel valore è precompilato.
1. Scegli **Next (Successivo)**.
1. In **Notifica**, seleziona un argomento SNS per segnalare quando l'allarme passa allo stato `ALARM`, `OK` o `INSUFFICIENT_DATA`.
Per fare in modo che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi, scegli **Add notification** (Aggiungi notifica).
Per fare in modo che l'allarme non invii notifiche, scegli **Remove** (Rimuovi).
1. Per fare in modo che l'allarme esegua operazioni Auto Scaling o EC2, scegli il pulsante appropriato e scegli lo stato di allarme e l'operazione da eseguire.
1. Al termine, scegli **Apply** (Applica).
1. Inserisci un nome e una descrizione per l'allarme. Il nome deve contenere solo caratteri ASCII. Quindi scegli **Successivo**.
1. In **Preview and create** (Visualizza anteprima e crea), conferma che le informazioni e le condizioni sono quelle desiderate, quindi scegli **Create alarm** (Crea allarme).
+ Per scaricare una definizione di infrastructure-as-code allarme da utilizzare in Terraform o in Terraform, scegli **Scarica codice di allarme** e seleziona il formato che desideri. AWS CloudFormation AWS CLI Il codice scaricato avrà le impostazioni raccomandate per il nome del parametro, la statistica e la soglia.
**Per scaricare le definizioni infrastructure-as-code degli allarmi per tutti gli allarmi consigliati per un servizio AWS**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, seleziona **Metrics** (Parametri), **All metrics** (Tutti i parametri).
1. Sopra la tabella **Parametri**, scegli **Raccomandazioni di allarme**.
L'elenco degli spazi dei nomi dei parametri viene filtrato in modo da includere soltanto i parametri che dispongono di raccomandazioni di allarme e che i servizi dell'account stanno pubblicando.
1. Scegli lo spazio dei nomi per un servizio.
L'elenco dei parametri in questo spazio dei nomi viene filtrato in modo da includere soltanto quelli che dispongono di raccomandazioni di allarme.
1. **Scarica codice dell'allarme** mostra quanti allarmi sono raccomandati per le metriche in questo namespace. Per scaricare le definizioni degli infrastructure-as-code allarmi per tutti gli allarmi consigliati, scegli **Scarica codice di allarme**, quindi scegli il formato di codice che desideri.
# Allarmi raccomandati
Le sezioni seguenti elencano i parametri per i quali suggeriamo di attivare gli allarmi basati sulle best practice. Per ogni parametro, vengono visualizzati anche le dimensioni, lo scopo dell'allarme, la soglia consigliata, la giustificazione della soglia, la durata del periodo e il numero di punti dati.
Alcuni parametri potrebbero apparire due volte nell'elenco. Ciò accade quando allarmi diversi sono raccomandati per combinazioni differenti di dimensioni di tale parametro.
Il valore **Punti dati su cui attivare allarmi** rappresenta il numero di punti dati che devono essere violati per mettere l'allarme nello stato ALARM. Il valore **Periodi di valutazione** rappresenta il numero di periodi che vengono presi in considerazione quando viene valutato l'allarme. Se questi due numeri coincidono, l'allarme passa allo stato ALARM solo quando tale numero di periodi consecutivi presenta valori che superano la soglia. Se **Punti dati su cui attivare allarmi** è inferiore a **Periodi di valutazione**, l'allarme è del tipo "M su N" e passa allo stato ALARM se almeno un numero di punti dati pari a **Punti dati su cui attivare allarmi** viene violato all'interno di qualsiasi set di punti dati pari a **Periodi di valutazione**. Per ulteriori informazioni, consulta [Valutazione degli allarmi](alarm-evaluation.md).
**Topics**
+ [Amazon API Gateway](#ApiGateway)
+ [Amazon EC2 Auto Scaling](#AutoScaling)
+ [AWS Certificate Manager (ACM)](#CertificateManager)
+ [Amazon CloudFront](#CloudFront)
+ [Amazon Cognito](#Cognito)
+ [Amazon DynamoDB](#DynamoDB)
+ [Amazon EBS](#Recommended_EBS)
+ [Amazon EC2](#EC2)
+ [Amazon ElastiCache](#ElastiCache)
+ [Amazon ECS](#ECS)
+ [Amazon ECS con Container Insights](#ECS-ContainerInsights)
+ [Amazon ECS con Approfondimenti sui container con osservabilità avanzata](#ECS-ContainerInsights_enhanced)
+ [Amazon EFS](#EFS)
+ [Amazon EKS con Container Insights](#EKS-ContainerInsights)
+ [Pianificatore Amazon EventBridge](#Eventbridge-Scheduler)
+ [Amazon Kinesis Data Streams](#Kinesis)
+ [Lambda](#Lambda)
+ [Lambda Insight](#LambdaInsights)
+ [Amazon VPC (`AWS/NATGateway`)](#NATGateway)
+ [AWS Link privato () `AWS/PrivateLinkEndpoints`](#PrivateLinkEndpoints)
+ [AWS Link privato (`AWS/PrivateLinkServices`)](#PrivateLinkServices)
+ [`Amazon RDS`](#RDS)
+ [`Amazon Route 53 Public Data Plane`](#Route53)
+ [`Amazon S3`](#S3)
+ [`S3ObjectLambda`](#S3ObjectLambda)
+ [Amazon SNS](#SNS)
+ [Amazon SQS](#SQS)
+ [Site-to-Site VPN](#VPN)
## Amazon API Gateway
**4XXError**
**Dimensioni:**ApiName, Stage
**Descrizione dell'allarme: **questo allarme rileva un tasso elevato di errori lato client. Ciò può indicare un problema nei parametri di autorizzazione o di richiesta del client. Potrebbe anche significare che una risorsa è stata rimossa o che un client ne sta richiedendo una che non esiste. Valuta la possibilità di abilitare CloudWatch i registri e verificare la presenza di eventuali errori che potrebbero causare gli errori 4XX. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per risorsa e metodo e restringere la fonte degli errori. Gli errori potrebbero essere causati anche dal superamento del limite di limitazione della larghezza di banda della rete impostato. Se le risposte e i log riportano percentuali elevate e impreviste di 429 errori, segui [questa guida](https://repost.aws/knowledge-center/api-gateway-429-limit) per risolvere il problema.
**Scopo: **questo allarme può rilevare tassi elevati di errori lato client per le richieste di Gateway API.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia: **la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 4XX. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 4XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**5XXError**
**Dimensioni:**ApiName, Stage
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un tasso elevato di errori lato client. Ciò può indicare un errore nel back-end dell'API, nella rete o nell'integrazione tra il gateway API e l'API di back-end. Questa [documentazione](https://repost.aws/knowledge-center/api-gateway-5xx-error) può aiutarti a risolvere la causa degli errori 5xx.
**Scopo: **questo allarme può rilevare tassi elevati di errori lato server per le richieste di Gateway API.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia: **la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 5XX. Tuttavia, è possibile regolare la soglia in base al traffico delle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 5XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**Conteggio**
**Dimensioni:**ApiName, Stage
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un basso volume di traffico per la fase della REST API. Questo potrebbe segnalare un problema con l'applicazione che chiama l'API, ad esempio a causa dell'utilizzo di endpoint errati. Potrebbe anche essere un indicatore di un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.
**Scopo: **questo allarme può rilevare un volume di traffico inaspettatamente basso per la fase di REST API. Consigliamo di creare questo allarme se l'API invia un numero prevedibile e regolare di richieste in condizioni normali. Se hai abilitato le CloudWatch metriche dettagliate e puoi prevedere il normale volume di traffico per metodo e risorsa, ti consigliamo di creare allarmi alternativi per avere un monitoraggio più preciso delle cadute di volume di traffico per ogni risorsa e metodo. Questo allarme non è consigliato per chi non prevede un APIs traffico costante e costante.
**Statistica:** SampleCount
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base all'analisi dei dati storici per determinare il numero di richieste di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**Conteggio**
**Dimensioni:** faseApiName, risorsa, metodo
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un basso volume di traffico per la risorsa e il metodo nella fase di REST API. Ciò può indicare un problema con l'applicazione che chiama l'API, ad esempio a causa dell'utilizzo di endpoint errati. Potrebbe anche essere un indicatore di un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.
**Scopo: **questo allarme può rilevare un volume di traffico inaspettatamente basso per la risorsa e il metodo nella fase di REST API. Consigliamo di creare questo allarme se l'API invia un numero prevedibile e regolare di richieste in condizioni normali. Questo allarme è sconsigliato per APIs chi non si aspetta un traffico costante e costante.
**Statistica:** SampleCount
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base all'analisi dei dati storici per determinare il numero di richieste di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**Conteggio**
**Dimensioni:ApiId, Stage**
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un basso volume di traffico per la fase dell'API HTTP. Ciò può indicare un problema con l'applicazione che chiama l'API, ad esempio a causa dell'utilizzo di endpoint errati. Potrebbe anche essere un indicatore di un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.
**Scopo: **questo allarme può rilevare un volume di traffico inaspettatamente basso per la fase dell'API HTTP. Consigliamo di creare questo allarme se l'API invia un numero prevedibile e regolare di richieste in condizioni normali. Se hai abilitato le CloudWatch metriche dettagliate e puoi prevedere il normale volume di traffico per percorso, ti consigliamo di creare allarmi alternativi a questo per avere un monitoraggio più preciso delle cadute di volume di traffico per ogni percorso. Questo allarme non è consigliato per chi non prevede un APIs traffico costante e costante.
**Statistica:** SampleCount
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta il valore della soglia in base all'analisi dei dati storici per determinare il numero di richieste di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**Conteggio**
**Dimensioni:** faseApiId, risorsa, metodo
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un basso volume di traffico per la route dell'API HTTP nella fase. Ciò può indicare un problema con l'applicazione che chiama l'API, ad esempio a causa dell'utilizzo di endpoint errati. Potrebbe anche indicare un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.
**Scopo: **questo allarme può rilevare un volume di traffico inaspettatamente basso per la route dell'API HTTP nella fase. Consigliamo di creare questo allarme se l'API invia un numero prevedibile e regolare di richieste in condizioni normali. Questo allarme è sconsigliato per APIs chi non si aspetta un traffico costante e costante.
**Statistica:** SampleCount
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta il valore della soglia in base all'analisi dei dati storici per determinare il numero di richieste di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**IntegrationLatency**
**Dimensioni:ApiId, Stage**
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un'elevata latenza di integrazione per le richieste API in una fase. Puoi stabilire un collegamento tra il valore del parametro `IntegrationLatency` e il parametro della latenza corrispondente per il back-end, ad esempio il parametro `Duration` per le integrazioni Lambda. Questo ti aiuta a determinare se il back-end dell'API impiega più tempo a elaborare le richieste dei client a causa di problemi di prestazioni o se sussiste qualche altro sovraccarico dovuto all'inizializzazione o all'avvio a freddo. Inoltre, valuta la possibilità di abilitare CloudWatch i log per la tua API e di controllare i log per eventuali errori che potrebbero causare problemi di elevata latenza. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per avere una visione di questa metrica per percorso, per aiutarti a restringere l'origine della latenza di integrazione.
**Scopo: **questo allarme può rilevare quando le richieste di Gateway API in una fase hanno una latenza di integrazione elevata. Consigliamo questo allarme per e lo consideriamo facoltativo per HTTP WebSocket APIs, APIs poiché offrono già raccomandazioni separate sugli allarmi per la metrica di latenza. Se hai abilitato CloudWatch metriche dettagliate e hai requisiti prestazionali di latenza di integrazione diversi per percorso, ti consigliamo di creare allarmi alternativi per avere un monitoraggio più preciso della latenza di integrazione per ogni percorso.
**Statistica: **p90
**Soglia raccomandata: **2.000,0
**Giustificazione della soglia: **il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, puoi utilizzarlo come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, imposta un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**IntegrationLatency**
**Dimensioni:, tappa, percorso** ApiId
**Descrizione dell'allarme:** questo allarme aiuta a rilevare se c'è un'elevata latenza di integrazione per le richieste WebSocket API per un percorso in una fase. Puoi stabilire un collegamento tra il valore del parametro `IntegrationLatency` e il parametro della latenza corrispondente per il back-end, ad esempio il parametro `Duration` per le integrazioni Lambda. Questo ti aiuta a determinare se il back-end dell'API impiega più tempo a elaborare le richieste dei client a causa di problemi di prestazioni o se sussiste qualche altro sovraccarico dovuto all'inizializzazione o all'avvio a freddo. Inoltre, valuta la possibilità di abilitare CloudWatch i log per la tua API e di controllare i log per eventuali errori che potrebbero causare problemi di alta latenza.
**Scopo: **questo allarme può rilevare quando le richieste di Gateway API per una route in una fase hanno una latenza di integrazione elevata.
**Statistica: **p90
**Soglia raccomandata: **2.000,0
**Giustificazione della soglia: **il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, puoi utilizzarlo come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, puoi impostare un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latenza**
**Dimensioni:**, Palco ApiName
**Descrizione dell'allarme: **questo allarme rileva un'elevata latenza in una fase. Trova il valore del parametro `IntegrationLatency` per verificare la latenza del back-end dell'API. Se i due parametri sono per lo più allineati, il back-end dell'API è l'origine della latenza più elevata e dovrebbe essere esaminato per individuare eventuali problemi. Prendi in considerazione anche l'attivazione CloudWatch dei log e il controllo degli errori che potrebbero causare l'elevata latenza. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per risorsa e metodo e restringere la fonte della latenza. Se applicabile, consulta le guide alla [risoluzione dei problemi con Lambda](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda) o alla [risoluzione dei problemi per gli endpoint API ottimizzati per l'edge](https://repost.aws/knowledge-center/source-latency-requests-api-gateway).
**Scopo: **questo allarme può rilevare quando le richieste di Gateway API in una fase hanno una latenza elevata. Se hai abilitato CloudWatch metriche dettagliate e hai requisiti di prestazioni di latenza diversi per ogni metodo e risorsa, ti consigliamo di creare allarmi alternativi per avere un monitoraggio più dettagliato della latenza per ogni risorsa e metodo.
**Statistica: **p90
**Soglia raccomandata: **2.500,0
**Giustificazione della soglia: **il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, puoi utilizzarlo come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, puoi impostare un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latenza**
**Dimensioni: fase**, risorsa, metodo ApiName
**Descrizione dell'allarme: **questo allarme rileva un'elevata latenza per un metodo e una risorsa in una fase. Trova il valore del parametro `IntegrationLatency` per verificare la latenza del back-end dell'API. Se i due parametri sono per lo più allineati, il back-end dell'API è l'origine della latenza più elevata e dovrebbe essere esaminato per individuare eventuali problemi di prestazioni. Prendi in considerazione anche l'attivazione CloudWatch dei log e il controllo di eventuali errori che potrebbero causare l'elevata latenza. Se applicabile, puoi anche fare riferimento alle guide alla [risoluzione dei problemi con Lambda](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda) o alla [risoluzione dei problemi per gli endpoint API ottimizzati per l'edge](https://repost.aws/knowledge-center/source-latency-requests-api-gateway).
**Scopo: **questo allarme può rilevare quando le richieste di Gateway API per una risorsa e un metodo in una fase hanno una latenza elevata.
**Statistica: **p90
**Soglia raccomandata: **2.500,0
**Giustificazione della soglia: **il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, puoi utilizzarlo come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, puoi impostare un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latenza**
**Dimensioni:**ApiId, Stage
**Descrizione dell'allarme: **questo allarme rileva un'elevata latenza in una fase. Trova il valore del parametro `IntegrationLatency` per verificare la latenza del back-end dell'API. Se i due parametri sono per lo più allineati, il back-end dell'API è l'origine della latenza più elevata e dovrebbe essere esaminato per individuare eventuali problemi di prestazioni. Valuta anche la possibilità di abilitare CloudWatch i log e di verificare la presenza di eventuali errori che potrebbero causare l'elevata latenza. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per percorso e restringere la fonte della latenza. Puoi anche fare riferimento alla [guida alla risoluzione dei problemi con le integrazioni Lambda](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda), se applicabile.
**Scopo: **questo allarme può rilevare quando le richieste di Gateway API in una fase hanno una latenza elevata. Se hai abilitato CloudWatch metriche dettagliate e hai requisiti di prestazioni di latenza diversi per percorso, ti consigliamo di creare allarmi alternativi per avere un monitoraggio più dettagliato della latenza per ogni percorso.
**Statistica: **p90
**Soglia raccomandata: **2.500,0
**Giustificazione della soglia: **il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, può essere utilizzato come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se in generale è accettabile che l'API abbia una latenza più elevata, puoi impostare un valore di soglia più elevato per renderla meno sensibile. Tuttavia, se all'API è richiesto di fornire risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latenza**
**Dimensioni:**, fase, risorsa, metodo ApiId
**Descrizione dell'allarme: **questo allarme rileva un'elevata latenza per una route in una fase. Trova il valore del parametro `IntegrationLatency` per verificare la latenza del back-end dell'API. Se i due parametri sono per lo più allineati, il back-end dell'API è l'origine della latenza più elevata e dovrebbe essere esaminato per individuare eventuali problemi di prestazioni. Prendi in considerazione anche l'abilitazione CloudWatch dei log e il controllo di eventuali errori che potrebbero causare l'elevata latenza. Puoi anche fare riferimento alla [guida alla risoluzione dei problemi con le integrazioni Lambda](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda), se applicabile.
**Scopo: **questo allarme è impiegato per rilevare quando le richieste di Gateway API per una route in una fase hanno una latenza elevata.
**Statistica: **p90
**Soglia raccomandata: **2.500,0
**Giustificazione della soglia: **il valore di soglia raccomandato non funziona per tutti i carichi di lavoro dell'API. Tuttavia, può essere utilizzato come punto di partenza per la soglia. Dopodiché, è possibile scegliere valori di soglia diversi in base al carico di lavoro e ai requisiti di latenza, prestazioni e SLA accettabili per l'API. Se è accettabile che l'API abbia una latenza più elevata in generale, puoi impostare un valore di soglia più alto per rendere l'allarme meno sensibile. Tuttavia, se è necessario che l'API fornisca risposte quasi in tempo reale, imposta un valore di soglia inferiore. Inoltre, è possibile analizzare i dati storici per determinare la latenza di base prevista per il carico di lavoro dell'applicazione e ottimizzare il valore della soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**4xx**
**Dimensioni:**ApiId, Stage
**Descrizione dell'allarme: **questo allarme rileva un tasso elevato di errori lato client. Ciò può indicare un problema nei parametri di autorizzazione o di richiesta del client. Potrebbe anche significare che una route è stata rimossa o che un client sta richiedendo una route che non esiste nell'API. Valuta la possibilità di abilitare CloudWatch i registri e verificare la presenza di eventuali errori che potrebbero causare gli errori 4xx. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per percorso, per aiutarti a restringere la fonte degli errori. Gli errori potrebbero essere causati anche dal superamento del limite di limitazione della larghezza di banda della rete impostato. Se le risposte e i log riportano percentuali elevate e impreviste di 429 errori, segui [questa guida](https://repost.aws/knowledge-center/api-gateway-429-limit) per risolvere il problema.
**Scopo: **questo allarme può rilevare tassi elevati di errori lato client per le richieste di Gateway API.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia: **la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 4xx. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 4XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**5xx**
**Dimensioni:**ApiId, Stage
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un tasso elevato di errori lato client. Ciò può indicare un errore nel back-end dell'API, nella rete o nell'integrazione tra il gateway API e l'API di back-end. Questa [documentazione](https://repost.aws/knowledge-center/api-gateway-5xx-error) può aiutarti a risolvere la causa degli errori 5xx.
**Scopo: **questo allarme può rilevare tassi elevati di errori lato server per le richieste di Gateway API.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia: **la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 5xx. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 5xx che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**MessageCount**
**Dimensioni:**ApiId, Stage
**Descrizione dell'allarme:** Questo allarme aiuta a rilevare un basso volume di traffico per la fase WebSocket API. Ciò può indicare un problema quando i client chiamano l'API, ad esempio in caso di utilizzo di endpoint errati o problemi con il back-end che invia messaggi ai client. Potrebbe anche indicare un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.
**Intento:** questo allarme può rilevare un volume di traffico inaspettatamente basso per la WebSocket fase API. Suggeriamo di creare questo allarme se l'API riceve e invia un numero prevedibile e regolare di messaggi in condizioni normali. Se hai abilitato le CloudWatch metriche dettagliate e puoi prevedere il normale volume di traffico per percorso, è meglio creare allarmi alternativi a questo, in modo da avere un monitoraggio più preciso delle cadute di volume di traffico per ogni percorso. Non consigliamo questo allarme perché non ti aspetti un APIs traffico costante e costante.
**Statistica:** SampleCount
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta il valore della soglia in base all'analisi dei dati storici per determinare il numero di messaggi di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**MessageCount**
**Dimensioni:**ApiId, tappa, percorso
**Descrizione dell'allarme:** questo allarme aiuta a rilevare un basso volume di traffico per il percorso WebSocket API nella fase. Ciò può indicare un problema relativo ai client che chiamano l'API, ad esempio in caso di utilizzo di endpoint errati o problemi con il back-end che invia messaggi ai client. Potrebbe anche indicare un problema relativo alla configurazione o alle autorizzazioni dell'API che la rendono irraggiungibile per i client.
**Intento:** questo allarme è in grado di rilevare un volume di traffico inaspettatamente basso per il percorso WebSocket API nella fase. Suggeriamo di creare questo allarme se l'API riceve e invia un numero prevedibile e regolare di messaggi in condizioni normali. Non consigliamo questo allarme perché APIs non ti aspetti un traffico costante e costante.
**Statistica:** SampleCount
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base all'analisi dei dati storici per determinare il numero di messaggi di base previsto per l'API. L'impostazione della soglia su un valore molto alto potrebbe rendere l'allarme troppo sensibile nei periodi di traffico normale e di traffico basso previsto. Viceversa, l'impostazione su un valore molto basso potrebbe far sì che l'allarme non rilevi piccoli cali anomali del volume di traffico.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**ClientError**
**Dimensioni:ApiId, Stage**
**Descrizione dell'allarme: **questo allarme rileva un tasso elevato di errori dei client. Ciò può indicare un problema nei parametri di autorizzazione o dei messaggi. Potrebbe anche significare che una route è stata rimossa o che un client sta richiedendo una route che non esiste nell'API. Valuta la possibilità di abilitare CloudWatch i registri e verificare la presenza di eventuali errori che potrebbero causare gli errori 4xx. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per visualizzare questa metrica per percorso, per aiutarti a restringere la fonte degli errori. Gli errori potrebbero essere causati anche dal superamento del limite di limitazione della larghezza di banda della rete impostato. Se le risposte e i log riportano percentuali elevate e impreviste di 429 errori, segui [questa guida](https://repost.aws/knowledge-center/api-gateway-429-limit) per risolvere il problema.
**Intento:** questo allarme è in grado di rilevare tassi elevati di errori del client per i messaggi WebSocket API Gateway.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia: **la soglia raccomandata rileva quando più del 5% del totale delle richieste presenta errori di tipo 4xx. È possibile regolare la soglia in base al traffico delle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 4XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ExecutionError**
**Dimensioni:ApiId, Palco**
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un tasso elevato di errori di esecuzione. Questo potrebbe derivare da errori 5xx generati dall'integrazione, da problemi di autorizzazione o da altri fattori che ostacolano la corretta invocazione dell'integrazione, come la sua rimozione o la limitazione della larghezza di banda della rete associata. Valuta la possibilità di abilitare CloudWatch i log per la tua API e di controllare i log per il tipo e la causa degli errori. Inoltre, valuta la possibilità di abilitare CloudWatch metriche dettagliate per avere una visione di questa metrica per percorso, per aiutarti a restringere la fonte degli errori. Anche questa [documentazione](https://repost.aws/knowledge-center/api-gateway-websocket-error) può aiutarti a risolvere la causa degli errori di connessione.
**Intento:** questo allarme può rilevare alti tassi di errori di esecuzione per i messaggi WebSocket API Gateway.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia: **la soglia suggerita rileva quando più del 5% del totale delle richieste presenta errori di esecuzione. È possibile regolare la soglia in base al traffico delle richieste e ai tassi di errore accettabili. È possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori di esecuzione che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon EC2 Auto Scaling
**GroupInServiceCapacity**
**Dimensioni:** AutoScalingGroupName
**Descrizione dell'allarme: **questo allarme aiuta a rilevare quando la capacità del gruppo è inferiore alla capacità desiderata richiesta per il carico di lavoro. Per risolvere il problema, controlla le attività di dimensionamento per individuare eventuali errori di avvio e verifica che la configurazione della capacità desiderata sia corretta.
**Scopo: **questo allarme può rilevare una bassa disponibilità nel gruppo con dimensionamento automatico a causa di errori di avvio o avvii sospesi.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **il valore della soglia deve essere la capacità minima richiesta per eseguire il carico di lavoro. Nella maggior parte dei casi, puoi impostarlo in modo che corrisponda alla GroupDesiredCapacity metrica.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
## AWS Certificate Manager (ACM)
**DaysToExpiry**
**Dimensioni:** CertificateArn
**Descrizione dell'allarme:** questo allarme consente di rilevare quando un certificato gestito o importato in ACM si avvicina alla data di scadenza. Aiuta a prevenire scadenze impreviste dei certificati, che potrebbero determinare interruzioni del servizio. Quando l'allarme passa allo stato ALARM, è necessario agire immediatamente per rinnovare o reimportare il certificato. Per i certificati gestiti da ACM, consulta le istruzioni riportate nella [procedura di rinnovo del certificato](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html). Per i certificati importati, consulta le istruzioni riportate nella [procedura di reimportazione](https://docs.aws.amazon.com/acm/latest/userguide/import-reimport.html).
**Scopo:** questo allarme può avvisarti in modo proattivo sulle scadenze imminenti dei certificati. Fornisce un preavviso sufficiente per consentire l'intervento manuale, consentendo di rinnovare o sostituire i certificati prima che scadano. Ciò consente di garantire la sicurezza e la disponibilità dei servizi compatibili con TLS. Quando lo stato passa ad ALARM, verifica immediatamente lo stato del certificato e, se necessario, avvia la procedura di rinnovo.
**Statistica: **Minimum
**Soglia raccomandata: **44,0
**Giustificazione della soglia:** la soglia di 44 giorni rappresenta un buon compromesso tra l'allerta precoce e la prevenzione dei falsi allarmi. Concede un tempo sufficiente per l'intervento manuale in caso di mancato rinnovo automatico. Modifica questo valore in base alla procedura di rinnovo del certificato e ai tempi di risposta operativi.
**Periodo:** 8640
**Punti dati su cui attivare allarmi: **1
**Periodi di valutazione: **1
**Operatore di confronto: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon CloudFront
**5xxErrorRate**
**Dimensioni:**DistributionId, Region=Global
**Descrizione dell'allarme:** questo allarme monitora la percentuale di 5xx risposte di errore dal server di origine, per aiutarti a rilevare se il CloudFront servizio presenta problemi. Consulta la pagina [Troubleshooting error responses from your origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-response-errors.html) per informazioni su come comprendere i problemi del server. Inoltre, [attiva parametri aggiuntivi](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html#monitoring-console.distributions-additional) per ottenere parametri dettagliati sugli errori.
**Intento:** questo allarme viene utilizzato per rilevare problemi relativi alla gestione delle richieste dal server di origine o problemi di comunicazione tra CloudFront e il server di origine.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dalla tolleranza per le risposte 5xx. È possibile analizzare i dati storici e le tendenze e impostare la soglia di conseguenza. Poiché gli errori 5xx possono essere causati da problemi transitori, consigliamo di impostare la soglia su un valore maggiore di 0 in modo che l'allarme non sia troppo sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**OriginLatency**
**Dimensioni:DistributionId, Region=Global**
**Descrizione dell'allarme: **l'allarme aiuta a monitorare se il server di origine impiega troppo tempo a rispondere. Se il server impiega troppo tempo a rispondere, potrebbe verificarsi un timeout. Consulta la pagina [Find and fix delayed responses from applications on your origin server](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-504-gateway-timeout.html#http-504-gateway-timeout-slow-application) se riscontri valori di `OriginLatency` costantemente elevati.
**Scopo: **questo allarme viene utilizzato per rilevare problemi con un server di origine che impiega troppo tempo a rispondere.
**Statistica: **p90
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **la soglia va impostata su un valore pari a circa l'80% del valore di timeout di risposta del server di origine. Se questo parametro è costantemente vicino al valore di timeout di risposta del server di origine, potresti iniziare a riscontrare errori di tipo 504.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**FunctionValidationErrors**
**Dimensioni:**DistributionId, Region=Global FunctionName
**Descrizione dell'allarme:** questo allarme consente di monitorare gli errori di convalida delle CloudFront funzioni in modo da poter adottare le misure necessarie per risolverli. Analizza i registri delle CloudWatch funzioni e guarda il codice della funzione per trovare e risolvere la causa principale del problema. Vedi [Restrizioni sulle funzioni edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions-restrictions.html) per comprendere gli errori di configurazione comuni delle funzioni. CloudFront
**Intento:** questo allarme viene utilizzato per rilevare gli errori di convalida delle funzioni. CloudFront
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia:** un valore maggiore di 0 indica un errore di convalida. Si consiglia di impostare la soglia su 0 perché gli errori di convalida implicano un problema quando CloudFront le funzioni vengono restituite a. CloudFront Ad esempio, CloudFront necessita dell'intestazione HTTP Host per elaborare una richiesta. Non c'è nulla che impedisca a un utente di eliminare l'intestazione Host nel codice delle funzioni. CloudFront Ma quando CloudFront riceve la risposta e manca l'intestazione Host, CloudFront genera un errore di convalida.
**Periodo: **60
**Punti dati su cui attivare allarmi: **2
**Periodi di valutazione: **2
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**FunctionExecutionErrors**
**Dimensioni:**DistributionId,, Region=Global FunctionName
**Descrizione dell'allarme:** Questo allarme consente di monitorare gli errori di esecuzione CloudFront delle funzioni in modo da poter adottare le misure necessarie per risolverli. Analizza i log delle CloudWatch funzioni e guarda il codice della funzione per trovare e risolvere la causa principale del problema.
**Intento:** questo allarme viene utilizzato per rilevare gli errori di esecuzione delle funzioni. CloudFront
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia:** si consiglia di impostare la soglia su 0 perché un errore di esecuzione indica un problema con il codice che si verifica in fase di runtime.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**FunctionThrottles**
**Dimensioni:DistributionId,, FunctionName Region=Global**
**Descrizione dell'allarme:** Questo allarme ti aiuta a monitorare se la tua CloudFront funzione è limitata. Se la tua funzione è sottoposta a limitazione della larghezza di banda della rete, significa che l'esecuzione sta impiegando troppo tempo. Per evitare limitazioni della larghezza di banda della rete nelle funzioni, valuta la possibilità di ottimizzarne il codice.
Scopo**: questo allarme è in grado di rilevare quando la CloudFront funzione è limitata, in modo da consentire all'utente di reagire e risolvere il problema per un'esperienza utente senza intoppi**.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia:** si consiglia di impostare la soglia su 0, per consentire una risoluzione più rapida delle accelerazioni delle funzioni.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon Cognito
**SignUpThrottles**
**Dimensioni:,** UserPool UserPoolClient
**Descrizione dell'allarme: **questo allarme monitora il numero di richieste sottoposte a limitazione della larghezza di banda della rete. Se gli utenti vengono costantemente sottoposti a limitazione della larghezza di banda della rete, è necessario aumentare il limite richiedendo un aumento della quota di servizio. Consulta la pagina [Quotas in Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) per informazioni su come richiedere un aumento delle quote. Per intraprendere operazioni in modo proattivo, prendi in considerazione la possibilità di tracciare la [quota di utilizzo](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#track-quota-usage).
**Scopo: **questo allarme aiuta a monitorare se si verificano richieste di registrazione sottoposte a limitazione della larghezza di banda della rete. Questo può aiutarti a sapere quando intraprendere operazioni per mitigare qualsiasi deterioramento dell'esperienza di registrazione. Una limitazione prolungata della larghezza di banda della rete per le richieste incide negativamente sull'esperienza di registrazione degli utenti.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **un pool di utenti con provisioning adeguato non dovrebbe subire alcuna limitazione della larghezza di banda della rete su più punti dati. Pertanto, la soglia tipica per un carico di lavoro previsto dovrebbe essere zero. Per un carico di lavoro irregolare con interruzioni frequenti, è possibile analizzare i dati storici per determinare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. Per ridurre al minimo l'impatto sull'applicazione, è necessario ritentare una richiesta sottoposta a limitazione della larghezza di banda della rete.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**SignInThrottles**
**Dimensioni:**UserPool, UserPoolClient
**Descrizione dell'allarme: **questo allarme monitora il numero di richieste di autenticazione utente sottoposte a limitazione della larghezza di banda della rete. Se gli utenti vengono costantemente sottoposti a limitazione della larghezza di banda della rete, potrebbe essere necessario aumentare il limite richiedendo un aumento della quota di servizio. Consulta la pagina [Quotas in Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) per informazioni su come richiedere un aumento delle quote. Per intraprendere operazioni in modo proattivo, prendi in considerazione la possibilità di tracciare la [quota di utilizzo](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#track-quota-usage).
**Scopo: **questo allarme aiuta a monitorare se si verificano richieste di accesso sottoposte a limitazione della larghezza di banda della rete. Questo può aiutarti a sapere quando intraprendere operazioni per mitigare qualsiasi deterioramento dell'esperienza di accesso. Una limitazione prolungata della larghezza di banda della rete per le richieste è un'esperienza di autenticazione utente negativa.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **un pool di utenti con provisioning adeguato non dovrebbe subire alcuna limitazione della larghezza di banda della rete su più punti dati. Pertanto, la soglia tipica per un carico di lavoro previsto dovrebbe essere zero. Per un carico di lavoro irregolare con interruzioni frequenti, è possibile analizzare i dati storici per determinare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. Per ridurre al minimo l'impatto sull'applicazione, è necessario ritentare una richiesta sottoposta a limitazione della larghezza di banda della rete.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**TokenRefreshThrottles**
**Dimensioni:**UserPool, UserPoolClient
**Descrizione dell'allarme: **è possibile impostare il valore di soglia in base al traffico della richiesta e in modo che corrisponda a una limitazione della larghezza di banda della rete accettabile per le richieste di aggiornamento dei token. La limitazione della larghezza di banda della rete viene utilizzata per proteggere il sistema da un numero eccessivo di richieste. Tuttavia, è importante monitorare anche se le risorse di cui si dispone sono insufficienti per il normale traffico. È possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia di allarme in modo che sia superiore al livello di limitazione accettabile. Le richieste limitate devono essere ritentate da the application/service poiché sono transitorie. Pertanto, un valore di soglia molto basso può rendere l'allarme sensibile.
**Scopo: **questo allarme aiuta a monitorare se si verificano richieste di aggiornamento dei token sottoposte a limitazione della larghezza di banda della rete. Questo può aiutarti a sapere quando intraprendere operazioni per mitigare eventuali problemi, al fine di garantire un'esperienza utente fluida unita all'integrità e all'affidabilità del tuo sistema di autenticazione. Una limitazione prolungata della larghezza di banda della rete per le richieste è un'esperienza di autenticazione utente negativa.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore della soglia può anche essere set/tuned adeguato al traffico della richiesta, nonché una limitazione accettabile per le richieste di aggiornamento dei token. La limitazione della larghezza di banda della rete serve a proteggere il sistema da un numero eccessivo di richieste, tuttavia è importante monitorare anche che le risorse per il traffico normale non siano insufficienti e controllare se è proprio questo a causare l'impatto. È possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia in modo che sia superiore al livello di limitazione accettabile abituale. Le richieste limitate devono essere ritentate dal momento che sono transitorie. application/service Pertanto, un valore di soglia molto basso può rendere l'allarme sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**FederationThrottles**
**Dimensioni:,,** UserPool UserPoolClient IdentityProvider
**Descrizione dell'allarme: **questo allarme monitora il numero di richieste di federazione delle identità sottoposte a limitazione della larghezza di banda della rete. Se si riscontra una continua limitazione della larghezza di banda della rete, potrebbe essere necessario aumentare il limite richiedendo un aumento della quota di servizio. Consulta la pagina [Quotas in Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) per informazioni su come richiedere un aumento delle quote.
**Scopo: **questo allarme aiuta a monitorare se si verificano richieste di federazione delle identità sottoposte a limitazione della larghezza di banda della rete. Questo può aiutarti a reagire in modo proattivo ai colli di bottiglia in termini di prestazioni o alle configurazioni errate e a garantire un'esperienza di autenticazione fluida per gli utenti. Una limitazione prolungata della larghezza di banda della rete per le richieste è un'esperienza di autenticazione utente negativa.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **è possibile impostare la soglia in base al traffico della richiesta e in modo che corrisponda alla limitazione della larghezza di banda della rete accettabile per le richieste di federazione delle identità. La limitazione della larghezza di banda della rete viene utilizzata per proteggere il sistema da un numero eccessivo di richieste. Tuttavia, è importante monitorare anche se le risorse di cui si dispone sono insufficienti per il normale traffico. È possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare il valore della soglia in modo che sia superiore al livello di limitazione accettabile. Le richieste limitate devono essere ritentate da the application/service poiché sono transitorie. Pertanto, un valore di soglia molto basso può rendere l'allarme sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon DynamoDB
**AccountProvisionedReadCapacityUtilization**
**Dimensions: **nessuna
**Descrizione dell'allarme: **questo allarme rileva se la capacità di lettura dell'account sta raggiungendo il limite previsto. In tal caso, è possibile aumentare la quota dell'account per l'utilizzo della capacità di lettura. È possibile visualizzare le quote correnti per le unità di capacità di lettura e richiedere eventuali aumenti utilizzando [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).
**Scopo: **l'allarme può rilevare se l'utilizzo della capacità di lettura dell'account si avvicina all'utilizzo della capacità di lettura assegnata. Se l'utilizzo raggiunge il limite massimo, DynamoDB inizia a limitare la larghezza di banda della rete per le richieste di lettura.
**Statistica: **Maximum
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **imposta la soglia all'80%, in modo che sia possibile intraprendere operazioni (ad esempio innalzare i limiti dell'account) prima che raggiunga la piena capacità al fine di evitare una limitazione della larghezza di banda della rete.
**Periodo: **300
**Punti dati su cui attivare allarmi: **2
**Periodi di valutazione: **2
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**AccountProvisionedWriteCapacityUtilization**
**Dimensions: **nessuna
**Descrizione dell'allarme: **questo allarme rileva se la capacità di scrittura dell'account sta raggiungendo il limite previsto. In tal caso, è possibile aumentare la quota dell'account per l'utilizzo della capacità di scrittura. È possibile visualizzare le quote correnti per le unità di capacità di scrittura e richiedere eventuali aumenti utilizzando [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).
**Scopo: **questo allarme può rilevare se l'utilizzo della capacità di scrittura dell'account si avvicina all'utilizzo della capacità di scrittura assegnata. Se l'utilizzo raggiunge il limite massimo, DynamoDB inizia a limitare la larghezza di banda della rete per le richieste di scrittura.
**Statistica: **Maximum
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **imposta la soglia all'80%, in modo che sia possibile intraprendere operazioni (ad esempio innalzare i limiti dell'account) prima che raggiunga la piena capacità al fine di evitare una limitazione della larghezza di banda della rete.
**Periodo: **300
**Punti dati su cui attivare allarmi: **2
**Periodi di valutazione: **2
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**AgeOfOldestUnreplicatedRecord**
**Dimensioni:,** TableName DelegatedOperation
**Descrizione dell'allarme: **questo allarme rileva il ritardo nella replica in un flusso di dati Kinesis. In condizioni di funzionamento normale, `AgeOfOldestUnreplicatedRecord` dovrebbe essere di pochi millisecondi. Questo numero aumenta in base ai tentativi di replica non riusciti causati da scelte di configurazione controllate dal cliente. Gli esempi di configurazioni controllate dal cliente che portano a tentativi di replica non riusciti sono una capacità del flusso di dati Kinesis con provisioning insufficiente, che comporta una limitazione della larghezza di banda della rete eccessiva, o un aggiornamento manuale delle policy di accesso del flusso di dati Kinesis, che impedisce a DynamoDB di aggiungere dati al flusso dei dati. Per mantenere questo parametro il più basso possibile, potrebbe essere necessario garantire il corretto provisioning della capacità del flusso di dati Kinesis e assicurarsi che le autorizzazioni di DynamoDB siano invariate.
**Scopo: **questo allarme può monitorare i tentativi di replica non riusciti e il conseguente ritardo nella replica nel flusso di dati Kinesis.
**Statistica: **Maximum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base al ritardo di replica desiderato misurato in millisecondi. Questo valore dipende dai requisiti del carico di lavoro e dalle prestazioni previste.
**Periodo: **300
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**FailedToReplicateRecordCount**
**Dimensioni:**TableName, DelegatedOperation
**Descrizione dell'allarme: **il numero di record che DynamoDB non è riuscito a replicare nel flusso di dati Kinesis. Alcuni elementi di dimensioni superiori a 34 KB potrebbero espandersi per modificare i record di dati superiori al limite di dimensioni di 1 MB degli elementi di Kinesis Data Streams. Questo aumento delle dimensioni si verifica quando gli elementi più grandi di 34 KB includono un numero elevato di valori booleani o vuoti degli attributi. I valori booleani e vuoti degli attributi vengono archiviati come 1 byte in DynamoDB, ma si espandono fino a 5 byte quando vengono serializzati utilizzando JSON standard per la replica di Kinesis Data Streams. DynamoDB non può replicare tali record di modifica nel flusso dei dati Kinesis. DynamoDB ignora questi record di dati di modifica e continua automaticamente a replicare i record successivi.
**Scopo: **questo allarme può monitorare il numero di record che DynamoDB non è riuscito a replicare nel flusso di dati Kinesis a causa del limite delle dimensioni degli elementi dei flussi di dati Kinesis.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia: **imposta la soglia su 0 per rilevare eventuali record che DynamoDB non è riuscito a replicare.
**Periodo: **60
**Punti dati su cui attivare allarmi: **1
**Periodi di valutazione: **1
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ReadThrottleEvents**
**Dimensioni:** TableName
**Descrizione dell'allarme: **questo allarme rileva la presenza di un numero elevato di richieste di lettura sottoposte a limitazione della larghezza di banda della rete per la tabella DynamoDB. Per risolvere il problema, consulta la pagina [Troubleshooting throttling issues in Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html).
**Scopo: **questo allarme può rilevare una limitazione della larghezza di banda della rete prolungata delle richieste di lettura alla tabella DynamoDB. Una limitazione prolungata della larghezza di banda della rete per le richieste di lettura può influire negativamente sulle operazioni di lettura del carico di lavoro e ridurre l'efficienza complessiva del sistema.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base al traffico di lettura previsto per la tabella DynamoDB, tenendo conto di un livello accettabile di limitazione della larghezza di banda della rete. È importante verificare di disporre di un numero sufficiente di risorse e che non si verifichino limitazioni della larghezza di banda della rete costanti. Inoltre, è possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia in modo che sia superiore al livello di limitazione accettabile abituale. Le richieste soggette a limitazione della larghezza di banda della rete devono essere ritentate dall'applicazione/dal servizio poiché sono transitorie. Pertanto, una soglia molto bassa potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ReadThrottleEvents**
**Dimensioni:**TableName, GlobalSecondaryIndexName
**Descrizione dell'allarme: **questo allarme rileva la presenza di un numero elevato di richieste di lettura sottoposte a limitazione della larghezza di banda della rete per l'indice secondario globale della tabella DynamoDB. Per risolvere il problema, consulta la pagina [Troubleshooting throttling issues in Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html).
**Scopo: **l'allarme può rilevare una limitazione della larghezza di banda della rete prolungata delle richieste di lettura per l'indice secondario globale della tabella DynamoDB. Una limitazione prolungata della larghezza di banda della rete per le richieste di lettura può influire negativamente sulle operazioni di lettura del carico di lavoro e ridurre l'efficienza complessiva del sistema.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base al traffico di lettura previsto per la tabella DynamoDB, tenendo conto di un livello accettabile di limitazione della larghezza di banda della rete. È importante verificare di disporre di un numero sufficiente di risorse e che non si verifichino limitazioni della larghezza di banda della rete costanti. Inoltre, è possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia in modo che sia superiore al livello di limitazione accettabile abituale. Le richieste soggette a limitazione della larghezza di banda della rete devono essere ritentate dall'applicazione/dal servizio poiché sono transitorie. Pertanto, una soglia molto bassa potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ReplicationLatency**
**Dimensioni:**TableName, ReceivingRegion
**Descrizione dell'allarme: **l'allarme rileva se la replica della tabella globale in una regione è in ritardo rispetto alla regione di origine. La latenza può aumentare se una AWS regione si deteriora e in quella regione è presente una tabella di replica. In questo caso, puoi reindirizzare temporaneamente l'attività di lettura e scrittura dell'applicazione verso un'altra regione. AWS Se si utilizza la versione 2017.11.29 (Legacy) di tabelle globali, è necessario verificare che le unità di capacità di scrittura (WCUs) siano identiche per ciascuna tabella di replica. Puoi anche assicurarti di seguire le raccomandazioni elencate nella pagina [Best practices and requirements for managing capacity](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables_reqs_bestpractices.html#globaltables_reqs_bestpractices.tables).
**Scopo: **l'allarme può rilevare se la tabella di replica in una regione è in ritardo rispetto alla replica delle modifiche da un'altra regione. Ciò potrebbe far sì che la replica diverga dalle altre repliche. È utile conoscere la latenza di replica di ciascuna AWS regione e avvisare se tale latenza di replica aumenta continuamente. La replica della tabella si applica solo alle tabelle globali.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dal caso d'uso. Solitamente, sono oggetto di indagine le latenze di replica superiori a 3 minuti. Esamina la criticità e i requisiti del ritardo di replica e analizza le tendenze storiche, quindi seleziona la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**SuccessfulRequestLatency**
**Dimensioni:, Funzionamento** TableName
**Descrizione dell'allarme: **questo allarme rileva un'elevata latenza per il funzionamento della tabella DynamoDB (indicata dal valore della dimensione `Operation`nell'allarme). Consulta [questo documento sulla risoluzione dei problemi](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingLatency.html) per risolvere i problemi di latenza in Amazon DynamoDB.
**Scopo: **questo allarme può rilevare una latenza elevata delle operazioni della tabella DynamoDB. Una latenza delle operazioni più elevata può influire negativamente sull'efficienza complessiva del sistema.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** DynamoDB fornisce una latenza media di un millisecondo per operazioni singleton come, e così via. GetItem PutItem Tuttavia, puoi impostare la soglia in base alla tolleranza accettabile per la latenza, considerando il tipo di operazione e la tabella coinvolta nel carico di lavoro. È possibile analizzare i dati storici di questo parametro per individuare la latenza abituale per l'operazione sulla tabella e quindi impostare la soglia su un numero che rappresenti il ritardo critico per l'operazione.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**SystemErrors**
**Dimensioni:** TableName
**Descrizione dell'allarme: **questo allarme rileva un numero elevato e prolungato di errori di sistema per le richieste delle tabelle DynamoDB. Se continui a ricevere errori 5xx, apri il [Pannello di controllo per lo stato dei servizi AWS](https://status.aws.amazon.com/) per verificare la presenza di problemi operativi con il servizio. Puoi utilizzare questo allarme per ricevere una notifica da DynamoDB in caso di un problema prolungato del servizio interno, aiutandoti a stabilire un collegamento con il problema che l'applicazione client sta riscontrando. Per ulteriori informazioni, consulta la pagina [Error handling for DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.MessagesAndCodes.http5xx).
**Scopo: **questo allarme può rilevare errori di sistema prolungati nelle richieste della tabella DynamoDB. Gli errori di sistema indicano errori interni del servizio di DynamoDB e contribuiscono a stabilire un collegamento con il problema riscontrato dal client.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base al traffico di lettura previsto, tenendo conto di un livello accettabile di errori di sistema. Inoltre, è possibile analizzare i dati storici per determinare il numero di errori accettabili per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. Gli errori di sistema devono essere riprovati dal application/service momento che sono transitori. Pertanto, una soglia molto bassa potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ThrottledPutRecordCount**
**Dimensioni:,** TableName DelegatedOperation
**Descrizione dell'allarme:** questo allarme rileva i record sottoposti a limitazione della larghezza di banda della rete dal flusso di dati Kinesis durante la replica dell'acquisizione dei dati di modifica su Kinesis. Questa limitazione della larghezza di banda della rete si verifica a causa della capacità del flusso di dati Kinesis insufficiente. Se si verifica una limitazione eccessiva e regolare, potrebbe essere necessario aumentare il numero di partizioni del flusso Kinesis proporzionalmente alla velocità di scrittura osservata della tabella. Per ulteriori informazioni su come determinare le dimensioni di un flusso di dati Kinesis, consulta [Determinazione delle dimensioni iniziali di un flusso di dati Kinesis](https://docs.aws.amazon.com/streams/latest/dev/amazon-kinesis-streams.html#how-do-i-size-a-stream).
**Scopo: **questo allarme può monitorare il numero di record sottoposti a limitazione della larghezza di banda della rete dal flusso di dati Kinesis a causa della capacità insufficiente di Kinesis Data Streams.
**Statistica: **Maximum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **è possibile che si verifichino delle limitazioni della larghezza di banda della rete durante i picchi di utilizzo eccezionali, ma i record limitati devono rimanere il più bassi possibile per evitare una maggiore latenza di replica (DynamoDB riprova a inviare i record limitati al flusso di dati Kinesis). Imposta la soglia su un numero che possa aiutarti a rilevare una limitazione della larghezza di banda della rete regolarmente eccessiva. Inoltre, è possibile analizzare i dati storici di questo parametro per individuare i tassi di limitazione della larghezza di banda della rete accettabili per il carico di lavoro dell'applicazione. Regola la soglia su un valore che l'applicazione può tollerare in base al tuo caso d'uso.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**UserErrors**
**Dimensions: **nessuna
**Descrizione dell'allarme: **questo allarme rileva un numero elevato e prolungato di errori utente per le richieste delle tabelle DynamoDB. È possibile controllare i log delle applicazioni client durante il periodo del problema per vedere perché le richieste non sono valide. Puoi controllare il [codice di stato HTTP 400](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.MessagesAndCodes.http400) per vedere il tipo di errore che stai riscontrando e agire di conseguenza. Potrebbe essere necessario correggere la logica dell'applicazione per creare richieste valide.
**Scopo: **questo allarme può rilevare errori degli utenti prolungati nelle richieste della tabella DynamoDB. Gli errori degli utenti nelle operazioni richieste indicano che il client sta producendo richieste non valide e che l'operazione non va a buon fine.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia su zero per rilevare eventuali errori sul lato client. Oppure impostalo su un valore più alto se vuoi evitare che si attivi l'allarme per un numero molto basso di errori. Decidi in base al tuo caso d'uso e al traffico per le richieste.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**WriteThrottleEvents**
**Dimensioni:** TableName
**Descrizione dell'allarme: **questo allarme rileva la presenza di un numero elevato di richieste di scrittura sottoposte a limitazione della larghezza di banda della rete per la tabella DynamoDB. Per risolvere il problema, consulta la pagina [Troubleshooting throttling issues in Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html).
**Scopo: **questo allarme può rilevare una limitazione della larghezza di banda della rete prolungata delle richieste di scrittura alla tabella DynamoDB. Una limitazione prolungata della larghezza di banda della rete per le richieste di scrittura può influire negativamente sulle operazioni di scrittura del carico di lavoro e ridurre l'efficienza complessiva del sistema.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base al traffico di scrittura previsto per la tabella DynamoDB, tenendo conto di un livello accettabile di limitazione della larghezza di banda della rete. È importante verificare di disporre di un numero sufficiente di risorse e che non si verifichino limitazioni della larghezza di banda della rete costanti. Inoltre, è possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia su un valore superiore al livello di limitazione accettabile abituale. Le richieste limitate devono essere application/service ritentate da Pertanto, una soglia molto bassa potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**WriteThrottleEvents**
**Dimensioni:,** TableName GlobalSecondaryIndexName
**Descrizione dell'allarme: **questo allarme rileva la presenza di un numero elevato di richieste di scrittura sottoposte a limitazione della larghezza di banda della rete per l'indice secondario globale della tabella DynamoDB. Per risolvere il problema, consulta la pagina [Troubleshooting throttling issues in Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html).
**Scopo: **questo allarme può rilevare una limitazione della larghezza di banda della rete prolungata delle richieste di scrittura per l'indice secondario globale della tabella DynamoDB. Una limitazione prolungata della larghezza di banda della rete per le richieste di scrittura può influire negativamente sulle operazioni di scrittura del carico di lavoro e ridurre l'efficienza complessiva del sistema.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base al traffico di scrittura previsto per la tabella DynamoDB, tenendo conto di un livello accettabile di limitazione della larghezza di banda della rete. È importante verificare di disporre di un numero sufficiente di risorse e che non si verifichino limitazioni della larghezza di banda della rete costanti. Inoltre, è possibile analizzare i dati storici per individuare la limitazione della larghezza di banda della rete accettabile per il carico di lavoro dell'applicazione e regolare la soglia su un valore superiore al livello di limitazione accettabile abituale. Le richieste limitate devono essere ritentate da the application/service poiché sono transitorie. Pertanto, un valore molto basso potrebbe rendere l'allarme troppo sensibile, causando transizioni di stato indesiderate.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon EBS
**VolumeStalledIOCheck**
**Dimensioni:,** VolumeId InstanceId
**Descrizione dell'allarme:** questo allarme consente di monitorare le prestazioni di I/O dei volumi Amazon EBS. Questo controllo rileva problemi di fondo con l'infrastruttura Amazon EBS, come problemi hardware o software sui sottosistemi di archiviazione alla base dei volumi Amazon EBS così come problemi hardware sull'host fisico che influiscono sulla raggiungibilità dei volumi Amazon EBS dall'istanza Amazon EC2, e può rilevare problemi di connettività tra l'istanza e i volumi Amazon EBS. Se lo Stalled IO Check fallisce, è possibile AWS attendere la risoluzione del problema oppure intraprendere azioni quali la sostituzione del volume interessato o l'arresto e il riavvio dell'istanza a cui è collegato il volume. Nella maggior parte dei casi, quando la metrica ha esito negativo, Amazon EBS diagnostica e ripristina automaticamente il volume entro pochi minuti.
**Intento:** questo allarme è in grado di rilevare lo stato dei volumi Amazon EBS per determinare quando tali volumi sono compromessi e non possono completare le operazioni. I/O
**Statistica: **Maximum
**Soglia raccomandata: **1,0
**Giustificazione della soglia: **quando una verifica dello stato non riesce, il valore di questo parametro è 1. La soglia è impostata in modo tale che ogni volta che il controllo dello stato non riesce, l'allarme sia in stato ALARM.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon EC2
**CPUUtilization**
**Dimensioni:** InstanceId
**Descrizione dell'allarme:** questo allarme aiuta a monitorare l'utilizzo della CPU di un'istanza EC2. A seconda dell'applicazione, potrebbero essere normali livelli di utilizzo costantemente elevati. Tuttavia, se le prestazioni si deteriorano e l'applicazione non è limitata dall'I/O del disco, dalla memoria o dalle risorse di rete, una CPU al massimo potrebbe indicare un collo di bottiglia in termini di risorse o problemi di prestazioni delle applicazioni. Un utilizzo elevato della CPU potrebbe indicare che è necessario un aggiornamento a un'istanza con un uso più intensivo della CPU. Se è abilitato il monitoraggio dettagliato, è possibile modificare il periodo a 60 secondi anziché 300 secondi. Per ulteriori informazioni, consulta la pagina [Enable or turn off detailed monitoring for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html).
**Scopo: **questo allarme viene utilizzato per rilevare un elevato utilizzo della CPU.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **in genere, è possibile impostare la soglia per l'utilizzo della CPU al 70-80%. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili. Per alcuni sistemi, un utilizzo costantemente elevato della CPU può essere normale e non indicare un problema, mentre per altri può essere motivo di preoccupazione. Analizza i dati storici sull'utilizzo della CPU per stabilire qual è un valore di utilizzo della CPU accettabile per il sistema e imposta la soglia di conseguenza.
**Periodo: **300
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**StatusCheckFailed**
**Dimensioni:** InstanceId
**Descrizione dell'allarme: **questo allarme aiuta a monitorare sia i controlli dello stato del sistema che i controlli dello stato dell'istanza. Se uno dei due tipi di controllo dello stato fallisce, questo allarme dovrebbe essere nello stato ALARM.
**Scopo: **questo allarme viene utilizzato per rilevare i problemi sottostanti delle istanze, inclusi gli errori di controllo dello stato del sistema e gli errori di controllo dello stato delle istanze.
**Statistica: **Maximum
**Soglia raccomandata: **1,0
**Giustificazione della soglia: **quando una verifica dello stato non riesce, il valore di questo parametro è 1. La soglia è impostata in modo tale che ogni volta che il controllo dello stato non riesce, l'allarme sia in stato ALARM.
**Periodo: **300
**Punti dati su cui attivare allarmi: **2
**Periodi di valutazione: **2
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**StatusCheckFailed\$1attachedEBS**
**Dimensioni:** InstanceId
**Descrizione dell'allarme:** questo allarme ti aiuta a monitorare se i volumi Amazon EBS collegati a un'istanza sono raggiungibili e in grado di completare I/O le operazioni. Questo controllo rileva problemi di fondo con l'infrastruttura di calcolo o Amazon EBS, come i seguenti:
+ problemi hardware o software sui sottosistemi di archiviazione alla base dei volumi Amazon EBS;
+ problemi hardware sull'host fisico che incidono sulla raggiungibilità dei volumi Amazon EBS;
+ problemi di connettività tra l'istanza e i volumi Amazon EBS.
Quando il controllo dello stato del volume EBS collegato ha esito negativo, è possibile attendere la risoluzione del problema da parte di Amazon oppure intraprendere un'operazione, come sostituire i volumi interessati o arrestare e riavviare l'istanza.
**Scopo:** questo allarme viene utilizzato per rilevare volumi Amazon EBS collegati a un'istanza che non sono raggiungibili. Questi possono causare guasti nelle operazioni. I/O
**Statistica: **Maximum
**Soglia raccomandata: **1,0
**Giustificazione della soglia: **quando una verifica dello stato non riesce, il valore di questo parametro è 1. La soglia è impostata in modo tale che ogni volta che il controllo dello stato non riesce, l'allarme sia in stato ALARM.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon ElastiCache
**CPUUtilization**
**Dimensioni:**CacheClusterId, CacheNodeId
**Descrizione dell'allarme:** questo allarme aiuta a monitorare l'utilizzo della CPU per l'intera ElastiCache istanza, inclusi i processi del motore di database e altri processi in esecuzione sull'istanza. AWS Elasticache supporta due tipi di motore: Memcached e Redis OSS. Se raggiungi un utilizzo della CPU elevato su un nodo Memcached, dovresti prendere in considerazione la possibilità di aumentare il tipo di istanza o aggiungere nuovi nodi di cache. Per Redis OSS, se il carico di lavoro principale riguarda le richieste di lettura, dovresti prendere in considerazione l'aggiunta di altre repliche di lettura al cluster di cache. Se il tuo carico di lavoro principale è costituito da richieste di scrittura, dovresti prendere in considerazione l'aggiunta di altri shard per distribuire il carico di lavoro su più nodi primari (se utilizzi la modalità cluster) o l'aumento verticale del tipo di istanza (se esegui Redis OSS in modalità non cluster).
**Intento:** questo allarme viene utilizzato per rilevare un elevato utilizzo della CPU da parte degli host. ElastiCache È utile avere una visione generale dell'utilizzo della CPU nell'intera istanza, compresi i processi non legati al motore.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia sulla percentuale che riflette un livello di utilizzo della CPU critico per l'applicazione. Per Memcached, il motore può utilizzare fino a num\$1threads core. Per Redis OSS, il motore è principalmente a thread singolo, ma potrebbe utilizzare core aggiuntivi, se disponibili, per accelerare l'I/O. Nella maggior parte dei casi, è possibile impostare la soglia su circa il 90% della CPU disponibile. Poiché Redis OSS è a thread singolo, il valore di soglia effettivo deve essere calcolato come una frazione della capacità totale del nodo.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**CurrConnections**
**Dimensioni:**, CacheClusterId CacheNodeId
**Descrizione dell'allarme: **questo allarme rileva un numero elevato di connessioni, che potrebbe indicare problemi di carico o prestazioni elevati. Un aumento costante di `CurrConnections` potrebbe portare all'esaurimento delle 65.000 connessioni disponibili. Potrebbe indicare che le connessioni sono state chiuse erroneamente sul lato dell'applicazione e che sul lato server sono rimaste stabilite. È consigliabile utilizzare il pool di connessioni o i timeout di connessione inattivi per limitare il numero di connessioni effettuate al cluster oppure, per Redis OSS, valutare la possibilità di ottimizzare [tcp-keepalive](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html) sul cluster per rilevare e terminare potenziali peer morti.
**Intento:** l'allarme consente di identificare un numero elevato di connessioni che potrebbero influire sulle prestazioni e sulla stabilità del ElastiCache cluster.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dall'intervallo di connessioni accettabile per il cluster. Esamina la capacità e il carico di lavoro previsto del ElastiCache cluster e analizza il numero storico delle connessioni durante l'uso regolare per stabilire una linea di base, quindi seleziona una soglia di conseguenza. Ricorda che ogni nodo può supportare fino a 65.000 connessioni simultanee.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**DatabaseMemoryUsagePercentage**
**Dimensioni:** CacheClusterId
**Descrizione dell'allarme: **questo allarme consente di monitorare l'utilizzo della memoria del cluster. Quando il valore di `DatabaseMemoryUsagePercentage` raggiunge il 100%, viene attivata la policy Redis OSS maxmemory e potrebbero verificarsi espulsioni in base alla policy selezionata. Se nessun oggetto nella cache corrisponde alla policy di espulsione, le operazioni di scrittura hanno esito negativo. Alcuni carichi di lavoro prevedono espulsioni o si basano su di esse, ma in caso contrario sarà necessario aumentare la capacità di memoria del cluster. È possibile dimensionare il cluster aggiungendo altri nodi primari oppure aumentarlo utilizzando un tipo di nodo più grande. Per ulteriori informazioni, consulta [Scaling ElastiCache for Redis OSS clusters.](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html)
**Scopo: **questo allarme viene utilizzato per rilevare un elevato utilizzo della memoria del cluster in modo da evitare errori durante la scrittura sul cluster. È utile sapere quando sarà necessario aumentare il cluster se per l'applicazione non sono previste espulsioni.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** a seconda dei requisiti di memoria dell'applicazione e della capacità di memoria del ElastiCache cluster, è necessario impostare la soglia sulla percentuale che riflette il livello critico di utilizzo della memoria del cluster. È possibile utilizzare i dati storici sull'utilizzo della memoria come indicazione per la soglia di utilizzo della memoria accettabile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**Motore CPUUtilization**
**Dimensioni:** CacheClusterId
**Descrizione dell'allarme:** questo allarme aiuta a monitorare l'utilizzo della CPU di un thread del motore Redis OSS all'interno dell' ElastiCache istanza. I motivi più comuni dell'utilizzo della CPU elevato da parte di un motore sono i comandi a esecuzione prolungata con un utilizzo elevato di CPU, un numero elevato di richieste, l'aumento delle nuove richieste di connessione client in un breve periodo di tempo e un numero elevato di espulsioni quando la cache non dispone di memoria sufficiente per contenere nuovi dati. Dovresti prendere in considerazione la possibilità [di scalare ElastiCache i cluster Redis OSS](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html) aggiungendo più nodi o aumentando il tipo di istanza.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della CPU da parte del thread del motore Redis OSS. È utile se si desidera monitorare l'utilizzo della CPU del motore di database stesso.
**Statistica: **Average
**Soglia raccomandata: **90,0
**Giustificazione della soglia: **imposta la soglia su una percentuale che rifletta il livello di utilizzo della CPU del motore critico per l'applicazione. Puoi eseguire il benchmark del cluster utilizzando l'applicazione e il carico di lavoro previsto per correlare Engine CPUUtilization e prestazioni come riferimento, quindi impostare la soglia di conseguenza. Nella maggior parte dei casi, è possibile impostare la soglia su circa il 90% della CPU disponibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ReplicationLag**
**Dimensioni:** CacheClusterId
**Descrizione dell'allarme:** questo allarme aiuta a monitorare lo stato della replica del ElastiCache cluster. Un ritardo di replica elevato significa che il nodo primario o la replica non sono in grado di mantenere il ritmo della replica. Se l'attività di scrittura è troppo elevata, valuta la possibilità di dimensionare il cluster aggiungendo altri nodi primari oppure di aumentarlo utilizzando un tipo di nodo più grande. Per i dettagli, consulta [Scaling ElastiCache for Redis OSS clusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html). Se le repliche di lettura sono sovraccaricate dalla quantità di richieste di lettura, valuta la possibilità di aggiungere altre repliche di lettura.
**Scopo: **questo allarme viene utilizzato per rilevare un ritardo tra l'aggiornamento dei dati sul nodo primario e la loro sincronizzazione con il nodo di replica. Contribuisce a garantire la coerenza dei dati di un nodo cluster di replica in lettura.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base ai requisiti dell'applicazione e al potenziale impatto del ritardo di replica. È necessario considerare le velocità di scrittura e le condizioni di rete previste dell'applicazione per stabilire un ritardo di replica accettabile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon ECS
Di seguito sono riportati gli allarmi consigliati per Amazon ECS.
**CPUReservation**
**Dimensioni:** ClusterName
**Descrizione dell'allarme: **questo allarme consente di rilevare un'elevata prenotazione della CPU del cluster ECS. Un elevato livello di prenotazione della CPU potrebbe indicare che il cluster è in esaurimento o non è registrato CPUs per l'attività. Per risolvere il problema, è possibile aggiungere più capacità, dimensionare il cluster o configurare il dimensionamento automatico.
**Scopo: **l'allarme viene utilizzato per rilevare se le unità di CPU totali riservate dalle attività sul cluster stanno raggiungendo le unità di CPU totali registrate per il cluster. Questo ti aiuta a sapere quando aumentare il cluster. Il raggiungimento del numero totale di unità CPU per il cluster può comportare l'esaurimento della CPU per le attività. Se hai attivato il dimensionamento gestito dai provider di capacità EC2 o hai associato Fargate ai provider di capacità, questo allarme non è consigliato.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **imposta la soglia per la prenotazione della CPU all'80%. In alternativa, è possibile scegliere un valore inferiore in base alle caratteristiche del cluster.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**CPUUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme: **questo allarme consente di rilevare un elevato utilizzo della CPU del servizio ECS. In assenza di un'implementazione ECS continua, un utilizzo massimo della CPU potrebbe indicare un collo di bottiglia in termini di risorse o problemi di prestazioni delle applicazioni. Per risolvere il problema, è possibile aumentare il limite della CPU.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della CPU per il servizio Amazon ECS. Un utilizzo costantemente elevato della CPU può indicare un collo di bottiglia in termini di risorse o problemi di prestazioni delle applicazioni.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **i parametri di servizio per l'utilizzo della CPU potrebbero superare il 100% di utilizzo. Tuttavia, ti suggeriamo di monitorare il parametro per un elevato utilizzo della CPU per evitare che influisca su altri servizi. Imposta la soglia su circa l'80-85%. Ti suggeriamo di aggiornare le definizioni delle attività in modo che riflettano l'utilizzo effettivo per evitare problemi futuri con altri servizi.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**EBSFilesystemUtilizzo**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme:** questo allarme consente di rilevare un utilizzo elevato dello spazio di archiviazione del volume Amazon EBS collegato alle attività Amazon ECS. Se l'utilizzo del volume Amazon EBS è costantemente elevato, puoi controllarlo e aumentarne le dimensioni per nuove attività.
**Scopo:** questo allarme viene utilizzato per rilevare un utilizzo elevato dello spazio di archiviazione dei volumi Amazon EBS collegati alle attività Amazon ECS. L'uso costantemente elevato dello spazio di archiviazione può indicare che il volume Amazon EBS è pieno e potrebbe causare errori del container.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **puoi impostare la soglia per l'utilizzo del file system Amazon EBS all'80% circa. Puoi modificare questo valore in base all'utilizzo accettabile dello spazio di archiviazione. Per un volume di snapshot di sola lettura, un utilizzo elevato potrebbe indicare che il volume è di dimensioni corrette. Per un volume di dati attivo, un utilizzo elevato dello spazio di archiviazione potrebbe indicare che l'applicazione sta scrivendo una grande quantità di dati, il che potrebbe causare un errore del container se la capacità non è sufficiente.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**MemoryReservation**
**Dimensioni:** ClusterName
**Descrizione dell'allarme: **questo allarme consente di rilevare un'elevata prenotazione di memoria del cluster Amazon ECS. Una prenotazione di memoria elevata potrebbe indicare un collo di bottiglia in termini di risorse del cluster. Per risolvere il problema, analizza le prestazioni dell'attività di servizio per vedere se l'utilizzo della memoria dell'attività può essere ottimizzato. Inoltre, puoi registrare più memoria o impostare il dimensionamento automatico.
**Scopo: **l'allarme viene utilizzato per rilevare se le unità di memoria totali riservate dalle attività sul cluster stanno raggiungendo le unità di memoria totali registrate per il cluster. Questo può aiutarti a sapere quando aumentare il cluster. Il raggiungimento delle unità di memoria totali per il cluster può impedire al cluster di avviare nuove attività. Se hai attivato il dimensionamento gestito dai provider di capacità EC2 o hai associato Fargate ai provider di capacità, questo allarme non è consigliato.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **imposta la soglia per la prenotazione della memoria all'80%. È possibile regolare questo valore su un valore inferiore in base alle caratteristiche del cluster.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**MemoryUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato della memoria del servizio Amazon ECS. In assenza di un'implementazione Amazon ECS continua, un utilizzo massimo della memoria potrebbe indicare un collo di bottiglia in termini di risorse o problemi di prestazioni delle applicazioni. Per risolvere il problema, è possibile aumentare il limite della memoria.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della memoria per il servizio Amazon ECS. Un utilizzo costantemente elevato della memoria può indicare un collo di bottiglia in termini di risorse o problemi di prestazioni delle applicazioni.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **le metriche di servizio per l'utilizzo della memoria potrebbero superare il 100% di utilizzo. Tuttavia, ti suggeriamo di monitorare la metrica per un utilizzo elevato della memoria per evitare che influisca su altri servizi. Imposta la soglia su circa l'80%. Ti suggeriamo di aggiornare le definizioni delle attività in modo che riflettano l'utilizzo effettivo per evitare problemi futuri con altri servizi.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**HTTPCode\$1target\$15XX\$1Count**
**Dimensioni:,** ClusterName ServiceName
**Descrizione dell'allarme: **questo allarme consente di rilevare un elevato numero di errori lato server per il servizio ECS. Ciò può indicare che sono presenti errori che impediscono al server di evadere le richieste. Per risolvere il problema, controlla i log dell'applicazione.
**Scopo: **questo allarme viene utilizzato per rilevare un elevato numero di errori lato server per il servizio ECS.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **calcola il valore di circa il 5% del traffico medio e utilizza questo valore come punto di partenza per la soglia. Puoi trovare il traffico medio utilizzando il parametro `RequestCount`. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza. È necessario attivare gli allarmi per gli errori 5XX che si verificano frequentemente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**TargetResponseTime**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme: **questo allarme consente di rilevare un tempo di risposta previsto elevato per le richieste del servizio ECS. Ciò può indicare che sono presenti problemi che impediscono al servizio di evadere le richieste in tempo. Per risolvere i problemi, controlla la CPUUtilization metrica per vedere se la CPU del servizio sta esaurendo o controlla l'utilizzo della CPU di altri servizi downstream da cui dipende il tuo servizio.
**Scopo: **questo allarme viene utilizzato per rilevare un tempo di risposta previsto elevato per le richieste del servizio ECS.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dal caso d'uso. Esamina la criticità e i requisiti del tempo di risposta previsto del servizio e analizza il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon ECS con Container Insights
Di seguito sono riportati gli allarmi consigliati per Amazon ECS con Approfondimenti sui container.
**EphemeralStorageUtilized**
**Dimensioni:,** ClusterName ServiceName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato dello spazio di archiviazione temporaneo del cluster Fargate. Se è costantemente elevato, puoi controllare l'utilizzo dello spazio di archiviazione temporaneo e aumentarlo.
**Intento: **questo allarme viene utilizzato per rilevare un utilizzo elevato dello spazio di archiviazione temporaneo per il cluster Fargate. L'uso costantemente elevato dello spazio di archiviazione temporaneo può indicare che il disco è pieno e potrebbe causare errori del container.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia al 90% circa della dimensione dello spazio di archiviazione temporaneo. Puoi modificare questo valore in base all'utilizzo accettabile dello spazio di archiviazione temporaneo del cluster Fargate. Per alcuni sistemi, l'uso costantemente elevato dello spazio di archiviazione temporaneo potrebbe essere normale, mentre per altri potrebbe causare un errore del container.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**RunningTaskCount**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme:** questo allarme consente di rilevare un numero basso di processi in esecuzione del servizio Amazon ECS. Un numero di processi in esecuzione troppo basso può indicare che l'applicazione non è in grado di gestire il carico del servizio, il che potrebbe causare problemi di prestazioni. Se non è presente alcun processo in esecuzione, il servizio Amazon ECS potrebbe non essere disponibile o potrebbero esserci problemi di implementazione.
**Intento: **questo allarme viene utilizzato per rilevare se il numero di processi in esecuzione è troppo basso. Un numero costantemente basso di processi in esecuzione può indicare problemi di implementazione o di prestazioni del servizio Amazon ECS.
**Statistica: **Average
**Soglia raccomandata: **0,0
**Giustificazione della soglia: **puoi modificare la soglia in base al numero minimo di processi in esecuzione del servizio Amazon ECS. Se il numero di processi in esecuzione è 0, il servizio Amazon ECS non sarà disponibile.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**TaskCpuUtilization**
**Dimensioni:** ClusterName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato della CPU da parte delle attività del cluster Amazon ECS. Se l'utilizzo della CPU è costantemente elevato, potrebbe essere necessario ottimizzare le attività o aumentare la prenotazione della CPU.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della CPU da parte delle attività nel cluster Amazon ECS. Un utilizzo costantemente elevato della CPU può indicare che le attività sono sotto stress e potrebbero richiedere più risorse della CPU o un'ottimizzazione per mantenere le prestazioni.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa della prenotazione della CPU dell'attività. Puoi modificare questo valore in base all'utilizzo accettabile della CPU da parte delle attività. Per alcuni carichi di lavoro, un utilizzo costantemente elevato della CPU potrebbe essere normale, mentre per altri potrebbe indicare problemi di prestazioni o la necessità di maggiori risorse.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**TaskCpuUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato della CPU da parte delle attività appartenenti al servizio Amazon ECS. Se l'utilizzo della CPU è costantemente elevato, potrebbe essere necessario ottimizzare le attività o aumentare la prenotazione della CPU.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della CPU da parte delle attività appartenenti al servizio Amazon ECS. Un utilizzo costantemente elevato della CPU può indicare che le attività sono sotto stress e potrebbero richiedere più risorse della CPU o un'ottimizzazione per mantenere le prestazioni.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa della prenotazione della CPU dell'attività. Puoi modificare questo valore in base all'utilizzo accettabile della CPU da parte delle attività. Per alcuni carichi di lavoro, un utilizzo costantemente elevato della CPU potrebbe essere normale, mentre per altri potrebbe indicare problemi di prestazioni o la necessità di maggiori risorse.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ContainerCpuUtilization**
**Dimensioni:** ClusterName
**Descrizione dell'allarme:** questo allarme monitora la percentuale di unità CPU utilizzate dai container nel cluster Amazon ECS rispetto alla CPU prenotata. Aiuta a rilevare quando i container si avvicinano ai limiti della CPU in base al ContainerCpuUtilized/ContainerCpuReserved rapporto.
**Scopo:** questo allarme rileva quando i container nel cluster Amazon ECS utilizzano un'alta percentuale della loro capacità CPU prenotata, calcolata come `ContainerCpuUtilized/ContainerCpuReserved`. Valori costantemente elevati indicano che i container funzionano vicino ai limiti della CPU e potrebbero richiedere modifiche della capacità.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa del rapporto di utilizzo della CPU del container. Ciò fornisce un avviso tempestivo quando i container si avvicinano ai limiti di capacità della CPU, tenendo conto al contempo delle normali fluttuazioni nell'utilizzo della CPU. La soglia può essere modificata in base alle caratteristiche del carico di lavoro e ai requisiti prestazionali.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ContainerCpuUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme:** questo allarme monitora la percentuale di unità CPU utilizzate dai container appartenenti al servizio Amazon ECS rispetto alla rispettiva CPU prenotata. Aiuta a rilevare quando i container si avvicinano ai limiti della CPU in base al ContainerCpuUtilized/ContainerCpuReserved rapporto.
**Intento:** questo allarme rileva quando i container appartenenti al servizio Amazon ECS utilizzano un'alta percentuale della loro capacità CPU riservata, calcolata come/. ContainerCpuUtilized ContainerCpuReserved Valori costantemente elevati indicano che i container funzionano vicino ai limiti della CPU e potrebbero richiedere modifiche della capacità.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa del rapporto di utilizzo della CPU del container. Ciò fornisce un avviso tempestivo quando i container si avvicinano ai limiti di capacità della CPU, tenendo conto al contempo delle normali fluttuazioni nell'utilizzo della CPU. La soglia può essere modificata in base alle caratteristiche del carico di lavoro e ai requisiti prestazionali.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**Dimensioni:** ClusterName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato dello spazio di archiviazione temporaneo da parte delle attività del cluster Amazon ECS. Se l'utilizzo dello spazio di archiviazione è costantemente elevato, potrebbe essere necessario ottimizzare l'utilizzo dello spazio di archiviazione o aumentare la prenotazione dello stesso.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato dello spazio di archiviazione temporaneo da parte delle attività nel cluster Amazon ECS. Un utilizzo costantemente elevato dello spazio di archiviazione può indicare che l'attività sta esaurendo lo spazio su disco e potrebbe richiedere più risorse di archiviazione o l'ottimizzazione per mantenere il corretto funzionamento.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa della prenotazione dello spazio di archiviazione temporaneo dell'attività. Puoi modificare questo valore in base all'utilizzo accettabile dello spazio di archiviazione da parte delle attività. Per alcuni carichi di lavoro, un utilizzo costantemente elevato dello spazio di archiviazione potrebbe essere normale, mentre per altri potrebbe indicare potenziali problemi di spazio sul disco o la necessità di maggiore spazio di archiviazione.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato dello spazio di archiviazione temporaneo da parte delle attività appartenenti al servizio Amazon ECS. Se l'utilizzo dello spazio di archiviazione è costantemente elevato, potrebbe essere necessario ottimizzare l'utilizzo dello spazio di archiviazione o aumentare la prenotazione dello stesso.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato dello spazio di archiviazione temporaneo da parte delle attività appartenenti al servizio Amazon ECS. Un utilizzo costantemente elevato dello spazio di archiviazione può indicare che l'attività sta esaurendo lo spazio su disco e potrebbe richiedere più risorse di archiviazione o l'ottimizzazione per mantenere il corretto funzionamento.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa della prenotazione dello spazio di archiviazione temporaneo dell'attività. Puoi modificare questo valore in base all'utilizzo accettabile dello spazio di archiviazione da parte delle attività. Per alcuni carichi di lavoro, un utilizzo costantemente elevato dello spazio di archiviazione potrebbe essere normale, mentre per altri potrebbe indicare potenziali problemi di spazio sul disco o la necessità di maggiore spazio di archiviazione.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**Dimensioni:** ClusterName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato della memoria da parte delle attività del cluster Amazon ECS. Se l'utilizzo della memoria è costantemente elevato, potrebbe essere necessario ottimizzare le attività o aumentare la prenotazione della memoria.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della memoria da parte delle attività nel cluster Amazon ECS. Un utilizzo costantemente elevato della memoria può indicare che le attività sono sotto stress e potrebbero richiedere più risorse di memoria o un'ottimizzazione per mantenere la stabilità.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa della prenotazione della memoria dell'attività. Puoi modificare questo valore in base all'utilizzo accettabile della memoria da parte delle attività. Per alcuni carichi di lavoro, un utilizzo costantemente elevato della memoria potrebbe essere normale, mentre per altri potrebbe indicare un'eccessiva pressione sulla memoria o la necessità di maggiori risorse.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato della memoria da parte delle attività appartenenti al servizio Amazon ECS. Se l'utilizzo della memoria è costantemente elevato, potrebbe essere necessario ottimizzare le attività o aumentare la prenotazione della memoria.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della memoria da parte delle attività appartenenti al servizio Amazon ECS. Un utilizzo costantemente elevato della memoria può indicare che le attività sono sotto stress e potrebbero richiedere più risorse di memoria o un'ottimizzazione per mantenere la stabilità.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa della prenotazione della memoria dell'attività. Puoi modificare questo valore in base all'utilizzo accettabile della memoria da parte delle attività. Per alcuni carichi di lavoro, un utilizzo costantemente elevato della memoria potrebbe essere normale, mentre per altri potrebbe indicare un'eccessiva pressione sulla memoria o la necessità di maggiori risorse.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**Dimensioni:** ClusterName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato della memoria da parte dei container del cluster Amazon ECS. Se l'utilizzo della memoria è costantemente elevato, potrebbe essere necessario ottimizzare i container o aumentare la prenotazione della memoria.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della memoria da parte dei container nel cluster Amazon ECS. Un utilizzo costantemente elevato della memoria può indicare che il container è sotto stress e potrebbe richiedere più risorse di memoria o un'ottimizzazione per mantenere la stabilità.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa della prenotazione della memoria del container. Puoi modificare questo valore in base all'utilizzo accettabile della memoria da parte dei container. Per alcuni carichi di lavoro, un utilizzo costantemente elevato della memoria potrebbe essere normale, mentre per altri potrebbe indicare un'eccessiva pressione sulla memoria o la necessità di maggiori risorse.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato della memoria da parte dei container appartenenti al servizio Amazon ECS. Se l'utilizzo della memoria è costantemente elevato, potrebbe essere necessario ottimizzare i container o aumentare la prenotazione della memoria.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della memoria da parte dei container appartenenti al servizio Amazon ECS. Un utilizzo costantemente elevato della memoria può indicare che il container è sotto stress e potrebbe richiedere più risorse di memoria o un'ottimizzazione per mantenere la stabilità.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** imposta la soglia all'80% circa della prenotazione della memoria del container. Puoi modificare questo valore in base all'utilizzo accettabile della memoria da parte dei container. Per alcuni carichi di lavoro, un utilizzo costantemente elevato della memoria potrebbe essere normale, mentre per altri potrebbe indicare un'eccessiva pressione sulla memoria o la necessità di maggiori risorse.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**instance\$1filesystem\$1utilization**
**Dimensioni:** InstanceId ContainerInstanceId, ClusterName
**Descrizione dell'allarme: **questo allarme consente di rilevare un utilizzo elevato del file system del cluster Amazon ECS. Se l'utilizzo del file system è costantemente elevato, controlla l'utilizzo del disco.
**Intento: **questo allarme rileva un elevato utilizzo del file system per il cluster Amazon ECS. Un utilizzo costantemente elevato del file system può indicare un collo di bottiglia delle risorse o problemi di prestazioni delle applicazioni e impedire l'esecuzione di nuove attività.
**Statistica: **Average
**Soglia raccomandata: **90,0
**Giustificazione della soglia: **puoi impostare la soglia per l'utilizzo del file system al 90-95% circa. Puoi modificare questo valore in base al livello di capacità accettabile del file system del cluster Amazon ECS. Per alcuni sistemi, un utilizzo costantemente elevato del file system potrebbe essere normale e non indicare alcun problema, mentre per altri potrebbe essere motivo di preoccupazione e causare problemi di prestazioni e impedire l'esecuzione di nuove attività.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon ECS con Approfondimenti sui container con osservabilità avanzata
Di seguito sono riportati gli allarmi consigliati per Amazon ECS con Approfondimenti sui container con osservabilità avanzata.
**TaskCpuUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme:** questo allarme consente di rilevare la percentuale totale di unità CPU utilizzate da un'attività.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della CPU da parte di un'attività.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **in genere, è possibile impostare la soglia per l'utilizzo della CPU all'80%. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili. Per alcune attività, un utilizzo costantemente elevato della CPU può essere normale e non indicare un problema, mentre per altre può essere motivo di preoccupazione. Analizza i dati storici sull'utilizzo della CPU per stabilire qual è un valore di utilizzo della CPU accettabile per le attività e imposta la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme:** questo allarme consente di rilevare la percentuale totale di memoria utilizzata da un'attività.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della memoria.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **in genere, è possibile impostare la soglia per l'utilizzo della memoria all'80%. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili. Per alcune attività, un utilizzo costantemente elevato della memoria può essere normale e non indicare un problema, mentre per altre può essere motivo di preoccupazione. Analizza i dati storici sull'utilizzo della memoria per stabilire qual è un valore di utilizzo della memoria accettabile per le attività e imposta la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Contenitore CPUUtilization**
**Dimensioni:**ContainerName, ClusterName, ServiceName
**Descrizione dell'allarme:** questo allarme consente di rilevare la percentuale totale di unità CPU utilizzate da un container.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della CPU da parte di un'attività.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **in genere, è possibile impostare la soglia per l'utilizzo della CPU all'80%. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili. Per alcuni container, un utilizzo costantemente elevato della CPU può essere normale e non indicare un problema, mentre per altri può essere motivo di preoccupazione. Analizza i dati storici sull'utilizzo della CPU per stabilire qual è un valore di utilizzo della CPU accettabile per i container e imposta la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**Dimensioni:**ContainerName, ClusterName, ServiceName
**Descrizione dell'allarme:** questo allarme consente di rilevare la percentuale totale di unità di memoria utilizzate da un container.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato della memoria da parte di un'attività.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **in genere, è possibile impostare la soglia per l'utilizzo della memoria all'80%. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili. Per alcuni container, un utilizzo costantemente elevato della memoria può essere normale e non indicare un problema, mentre per altri può essere motivo di preoccupazione. Analizza i dati storici sull'utilizzo della memoria per stabilire qual è un valore di utilizzo della memoria accettabile per le attività e imposta la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**EBSfilesystemUtilizzo delle attività**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme:** questo allarme consente di rilevare la percentuale totale di spazio di archiviazione temporaneo utilizzato da un'attività.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato del file system Amazon EBS per un'attività.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **imposta la soglia all'80% circa della dimensione del file system Amazon EBS.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**Dimensioni:**ClusterName, ServiceName
**Descrizione dell'allarme:** questo allarme consente di rilevare la percentuale totale di spazio di archiviazione temporaneo utilizzato da un'attività.
**Scopo: **questo allarme viene utilizzato per rilevare un utilizzo elevato dello spazio di archiviazione temporaneo per un'attività. L'uso costantemente elevato dello spazio di archiviazione temporaneo può indicare che il disco è pieno e potrebbe causare errori dell'attività.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **imposta la soglia all'80% circa della dimensione dello spazio di archiviazione temporaneo.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon EFS
**Percentuale IOLimit**
**Dimensioni:** FileSystemId
**Descrizione dell'allarme:** questo allarme aiuta a garantire che il carico di lavoro rimanga entro il I/O limite disponibile per il file system. Se la metrica raggiunge costantemente il I/O limite, valuta la possibilità di spostare l'applicazione su un file system che utilizza Max I/O performance come modalità. Per la risoluzione dei problemi, controlla i client connessi al file system e le applicazioni dei client che limitano la larghezza di banda della rete del file system.
**Intento:** questo allarme viene utilizzato per rilevare quanto manca al file system il raggiungimento del I/O limite della modalità di prestazioni General Purpose. Una I/O percentuale elevata e costante può indicare che il file system non è in grado di scalare in misura sufficiente rispetto alle I/O richieste e che il file system può rappresentare un collo di bottiglia in termini di risorse per le applicazioni che utilizzano il file system.
**Statistica: **Average
**Soglia raccomandata: **100,0
**Giustificazione della soglia:** quando il file system raggiunge il I/O limite, può rispondere alle richieste di lettura e scrittura più lentamente. Pertanto, si consiglia di monitorare il parametro per evitare di influire sulle applicazioni che utilizzano il file system. La soglia può essere impostata intorno al 100%. Tuttavia, questo valore può essere regolato su un valore inferiore in base alle caratteristiche del file system.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**BurstCreditBalance**
**Dimensioni:** FileSystemId
**Descrizione dell'allarme: **questo allarme aiuta a garantire che sia disponibile un saldo di credito di espansione disponibile per l'utilizzo da parte del file system. Quando non è disponibile alcun credito di espansione, l'accesso delle applicazioni al file system sarà limitato a causa della bassa velocità di trasmissione effettiva. Se il parametro scende costantemente a 0, valuta la possibilità di modificare la modalità di velocità di trasmissione effettiva nella [modalità di velocità di trasmissione effettiva elastica o assegnata](https://docs.aws.amazon.com/efs/latest/ug/performance.html#throughput-modes).
**Scopo: **questo allarme viene utilizzato per rilevare un saldo di credito di espansione basso del file system. Un saldo di credito costantemente basso può essere un indicatore del rallentamento del throughput e dell'aumento della latenza. I/O
**Statistica: **Average
**Soglia raccomandata: **0,0
**Giustificazione della soglia:** quando il file system esaurisce i crediti burst e anche se la velocità di throughput di base è inferiore, EFS continua a fornire un throughput misurato pari a 1 a tutti i file system. MiBps Tuttavia, si consiglia di monitorare il parametro verificando la presenza di un saldo di credito basso per evitare che il file system costituisca un collo di bottiglia in termini di risorse per le applicazioni. La soglia può essere impostata intorno a 0 byte.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon EKS con Container Insights
**node\$1cpu\$1utilization**
**Dimensioni:** ClusterName
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un elevato utilizzo della CPU nei nodi worker del cluster EKS. Un utilizzo costantemente elevato potrebbe indicare la necessità di sostituire i nodi worker con istanze con una CPU maggiore o la necessità di eseguire un dimensionamento orizzontale del sistema.
**Scopo: **questo allarme aiuta a monitorare l'utilizzo della CPU dei nodi worker nel cluster EKS in modo che le prestazioni del sistema non si deteriorino.
**Statistica: **Maximum
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** si consiglia di impostare la soglia su un valore inferiore o uguale all'80% per avere tempo sufficiente per eseguire il debug del problema prima che il sistema inizi a vederne l'impatto.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**node\$1filesystem\$1utilization**
**Dimensioni:** ClusterName
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un utilizzo elevato del file system nei nodi worker del cluster EKS. Se l'utilizzo è costantemente elevato, potrebbe essere necessario aggiornare i nodi worker per incrementare le dimensioni del volume del disco oppure potrebbe essere necessario sottoporli a un dimensionamento orizzontale.
**Scopo: **questo allarme aiuta a monitorare l'utilizzo del file system nei nodi worker del cluster EKS. Se l'utilizzo raggiunge il 100%, è possibile che si verifichino errori dell'applicazione, I/O blocchi del disco, rimozione del pod o che il nodo non risponda completamente.
**Statistica: **Maximum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **in presenza di una capacità di archiviazione prossima alla saturazione (il disco si sta riempiendo), i nodi vengono segnalati come non integri e i pod vengono espulsi dal nodo. I pod su un nodo con un carico elevato sul disco vengono espulsi quando il file system disponibile è inferiore alle soglie di espulsione impostate sul kubelet. Imposta la soglia di allarme in modo da avere abbastanza tempo per reagire prima che il nodo venga espulso dal cluster.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**node\$1memory\$1utilization**
**Dimensioni:** ClusterName
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un elevato utilizzo della memoria nei nodi worker del cluster EKS. Se l'utilizzo è costantemente elevato, potrebbe indicare la necessità di dimensionare il numero di repliche dei pod o ottimizzare l'applicazione.
**Scopo: **questo allarme aiuta a monitorare l'utilizzo della memoria dei nodi worker nel cluster EKS in modo che le prestazioni del sistema non si deteriorino.
**Statistica: **Maximum
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** si consiglia di impostare la soglia su un valore inferiore o uguale all'80% per avere tempo sufficiente per eseguire il debug del problema prima che il sistema cominci a vederne l'impatto.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**pod\$1cpu\$1utilization\$1over\$1pod\$1limit**
**Dimensioni:**ClusterName, Namespace, Service
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un elevato utilizzo della CPU nei pod del cluster EKS. Se l'utilizzo è costantemente elevato, potrebbe indicare la necessità di aumentare il limite di CPU per il pod interessato.
**Scopo: **questo allarme aiuta a monitorare l'utilizzo della CPU dei pod appartenenti a un servizio Kubernetes nel cluster EKS, in modo da poter identificare rapidamente se il pod di un servizio sta utilizzando più CPU del previsto.
**Statistica: **Maximum
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** si consiglia di impostare la soglia su un valore inferiore o uguale all'80% per avere tempo sufficiente per eseguire il debug del problema prima che il sistema cominci a vederne l'impatto.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**pod\$1memory\$1utilization\$1over\$1pod\$1limit**
**Dimensioni:**ClusterName, Namespace, Service
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un elevato utilizzo della memoria nei pod del cluster EKS. Se l'utilizzo è costantemente elevato, potrebbe indicare la necessità di aumentare il limite di memoria per il pod interessato.
**Scopo: **questo allarme aiuta a monitorare l'utilizzo della memoria dei pod nel cluster EKS in modo che le prestazioni del sistema non si deteriorino.
**Statistica: **Maximum
**Soglia raccomandata: **80,0
**Giustificazione della soglia:** si consiglia di impostare la soglia su un valore inferiore o uguale all'80% per avere tempo sufficiente per eseguire il debug del problema prima che il sistema cominci a vederne l'impatto.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Pianificatore Amazon EventBridge
**TargetErrorThrottledCount**
**Dimensions: **nessuna
**Descrizione dell'allarme:** questo allarme consente di identificare la limitazione della destinazione. Per evitare errori di limitazione della destinazione, prendi in considerazione la possibilità di [configurare finestre temporali flessibili](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule-flexible-time-windows.html) per distribuire il carico di invocazione o aumentare il limite del servizio di destinazione.
**Scopo:** questo allarme viene utilizzato per rilevare gli errori di limitazione della destinazione, che possono causare ritardi nella pianificazione.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia:** se l'errore di limitazione previsto è costantemente superiore a 0, la consegna pianificata viene ritardata. Per alcuni sistemi, gli errori di limitazione della destinazione per un breve periodo di tempo potrebbero essere normali, mentre per altri potrebbero essere motivo di preoccupazione. Imposta la soglia di questo allarme, `datapointsToAlarm`, e `evaluationPeriods` di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**InvocationThrottleCount**
**Dimensions: **nessuna
**Descrizione dell'allarme: **questo allarme consente di identificare la limitazione dell'invocazione da parte di Pianificatore Amazon EventBridge. Per evitare errori di limitazione delle invocazioni, prendi in considerazione la possibilità di [configurare finestre temporali flessibili](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule-flexible-time-windows.html) per distribuire il carico di invocazione o [aumentare il limite di limitazione delle invocazioni](https://docs.aws.amazon.com/scheduler/latest/UserGuide/scheduler-quotas.html).
**Intento:** questo allarme viene utilizzato per rilevare errori di limitazione Pianificatore Amazon EventBridge delle chiamate, che possono causare ritardi nella pianificazione.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia:** se la limitazione dell'invocazione è costantemente superiore a 0, la consegna pianificata viene ritardata. Per alcuni sistemi, gli errori di limitazione delle invocazioni per un breve periodo di tempo potrebbero essere normali, mentre per altri potrebbero essere motivo di preoccupazione. Imposta la soglia di questo allarme, `datapointsToAlarm`, e `evaluationPeriods` di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**InvocationDroppedCount**
**Dimensions: **nessuna
**Descrizione dell'allarme: **questo allarme consente di identificare le invocazioni scartate da Pianificatore Amazon EventBridge. Valuta la possibilità di effettuare un'indagine [configurando un DLQ](https://docs.aws.amazon.com/scheduler/latest/UserGuide/configuring-schedule-dlq.html) per la pianificazione.
**Intento:** questo allarme viene utilizzato per rilevare le chiamate interrotte da. Pianificatore Amazon EventBridge Se hai configurato correttamente un DLQ in tutte le pianificazioni, le invocazioni scartate appariranno nel DLQ e puoi saltare la configurazione di questo allarme.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia:** imposta la soglia su 0 per rilevare le invocazioni scartate.
**Periodo: **60
**Punti dati su cui attivare allarmi: **1
**Periodi di valutazione: **1
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**InvocationsFailedToBeSentToDeadLetterCount**
**Dimensions: **nessuna
**Descrizione dell'allarme:** questo allarme consente di identificare le invocazioni che non sono state inviate al DLQ configurato da Pianificatore Amazon EventBridge. Se la metrica è costantemente maggiore di 0, modifica la configurazione del DLQ per risolvere il problema. Usa `InvocationsFailedToBeSentToDeadLetterCount`\$1metrics per determinare il problema.
**Intento:** questo allarme viene utilizzato per rilevare le chiamate che non sono state inviate al DLQ configurato da. Pianificatore Amazon EventBridge
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia:** imposta la soglia su 0 per rilevare eventuali invocazioni che non sono state inviate al DLQ configurato. In questa metrica vengono visualizzati anche gli errori ripetibili, quindi `datapointsToAlarm` per questo allarme è stato impostato su 15.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon Kinesis Data Streams
**GetRecords.IteratorAgeMilliseconds**
**Dimensioni:** StreamName
**Descrizione dell'allarme: **questo allarme può rilevare se l'età massima dell'iteratore è troppo alta. Per le applicazioni di elaborazione dei dati in tempo reale, configura la conservazione dei dati in base alla tolleranza del ritardo. Di solito si tratta di pochi minuti. Per le applicazioni che elaborano dati storici, utilizza questo parametro per monitorare la velocità di recupero dell'arretrato. Una soluzione rapida per arrestare la perdita di dati consiste nell'aumentare il periodo di conservazione durante la risoluzione del problema. Inoltre, è possibile aumentare il numero di worker che elaborano i record nella propria applicazione per consumatori. Le ragioni più comuni dell'incremento graduale dell'età dell'iteratore includono la mancanza di risorse fisiche adeguate o una logica di elaborazione dei record che non è stata dimensionata per gestire un aumento della velocità di trasmissione effettiva del flusso. Consulta questo [collegamento](https://repost.aws/knowledge-center/kinesis-data-streams-iteratorage-metric) per ulteriori dettagli.
**Scopo: **questo allarme viene utilizzato per rilevare se i dati del flusso stanno per scadere perché conservati troppo a lungo o perché l'elaborazione dei record è troppo lenta. Contribuisce a evitare la perdita di dati dopo aver raggiunto il 100% del tempo di conservazione del flusso.
**Statistica: **Maximum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dal periodo di conservazione del flusso e dalla tolleranza del ritardo di elaborazione per i record. Esamina i requisiti e analizza le tendenze storiche, quindi imposta la soglia sul numero di millisecondi che rappresenta un ritardo di elaborazione critico. Se l'età di un iteratore supera il 50% del periodo di conservazione (per impostazione predefinita, 24 ore, configurabile fino a 365 giorni), esiste il rischio di una perdita di dati a causa della scadenza del record. Puoi monitorare il parametro per assicurarti che nessuna delle partizioni si avvicini mai a questo limite.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**GetRecords.Successo**
**Dimensioni:** StreamName
**Descrizione dell'allarme: **questo parametro aumenta ogni volta che i consumatori leggono correttamente i dati dal flusso. `GetRecords` non restituisce alcun dato quando genera un'eccezione. L'eccezione più comune è `ProvisionedThroughputExceededException`, dovuta al fatto che il tasso di richiesta del flusso è troppo alto o la velocità di trasmissione effettiva disponibile è già utilizzata per il secondo in questione. Riduci la frequenza o le dimensioni delle richieste. Per ulteriori informazioni, consulta la pagina [Limits](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) relativa ai flussi nella Guida per gli sviluppatori di Flusso di dati Amazon Kinesis e la pagina [Error Retries and Exponential Backoff in AWS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html).
**Scopo: **questo allarme è in grado di rilevare se il recupero dei record dal flusso da parte dei consumatori ha esito negativo. Attivando un allarme per questo parametro, puoi rilevare in modo proattivo eventuali problemi relativi all'utilizzo dei dati, ad esempio un aumento dei tassi di errore o un calo dei recuperi riusciti. Ciò consente di intraprendere operazioni tempestive per risolvere potenziali problemi e preservare la fluidità della pipeline di elaborazione dei dati.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **a seconda dell'importanza del recupero dei record dal flusso, imposta la soglia in base alla tolleranza dell'applicazione per i record non riusciti. La soglia deve essere la percentuale corrispondente di operazioni riuscite. È possibile utilizzare i dati GetRecords metrici storici come riferimento per il tasso di errore accettabile. Inoltre, quando si imposta la soglia, è necessario considerare i nuovi tentativi, poiché i record con errori possono essere ritentati. Ciò consente di evitare che i picchi transitori generino avvisi non necessari.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**PutRecord.Successo**
**Dimensioni:** StreamName
**Descrizione dell'allarme: **questo allarme rileva quando il numero di operazioni `PutRecord` non riuscite supera la soglia. Esamina i log del produttore di dati per individuare le cause principali degli errori. Il motivo più comune è la velocità di trasmissione effettiva insufficiente assegnata alla partizione che ha causato l'eccezione `ProvisionedThroughputExceededException`. Ciò accade perché il tasso delle richieste per il flusso è troppo alto o la velocità di trasmissione effettiva con cui si tenta di importare nella partizione è troppo alto. Riduci la frequenza o le dimensioni delle richieste. Per ulteriori informazioni, consulta Streams [Limits](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) and [Error Retries e Exponential](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) Backoff in. AWS
**Scopo: **questo allarme può rilevare se l'importazione dei record nel flusso non riesce. Ti aiuta a identificare i problemi nella scrittura dei dati nel flusso. Attivando un allarme per questo parametro, puoi rilevare in modo proattivo eventuali problemi dei produttori nella pubblicazione dei dati nel flusso, come un aumento dei tassi di errore o una diminuzione dei record pubblicati con successo. Ciò consente di intraprendere operazioni tempestive per risolvere potenziali problemi e preservare l'affidabilità del processo di importazione dei dati.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **a seconda dell'importanza dell'importazione e dell'elaborazione dei dati per il servizio, imposta la soglia in base alla tolleranza dell'applicazione per i record non riusciti. La soglia deve essere la percentuale corrispondente di operazioni riuscite. Puoi utilizzare i dati PutRecord metrici storici come riferimento per il tasso di errore accettabile. Inoltre, quando si imposta la soglia, è necessario considerare i nuovi tentativi, poiché i record con errori possono essere ritentati.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**PutRecords.FailedRecords**
**Dimensioni:** StreamName
**Descrizione dell'allarme: **questo allarme rileva quando il numero di errori `PutRecords` supera la soglia. Flusso di dati Kinesis tenta di elaborare tutti i record in ogni richiesta `PutRecords`, ma l'errore di un singolo record non interrompe l'elaborazione di quelli successivi. Il motivo principale di questi errori è il superamento della velocità di trasmissione effettiva di un flusso o di una singola partizione. Le cause più comuni sono i picchi di traffico e le latenze di rete che causano l'arrivo dei record al flusso in modo non uniforme. È necessario rilevare i record non elaborati correttamente e ritentarli nella chiamata successiva. Per ulteriori dettagli, fare riferimento a [Gestione degli errori durante PutRecords l'utilizzo](https://docs.aws.amazon.com/streams/latest/dev/developing-producers-with-sdk.html).
**Scopo: **questo allarme può rilevare errori costanti quando si utilizza l'operazione in batch per inviare i record al flusso. Attivando un allarme per questo parametro, puoi rilevare in modo proattivo un aumento dei record non riusciti, al fine di intraprendere operazioni tempestive per risolvere i problemi sottostanti e garantire un processo di importazione dei dati fluido e affidabile.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia sul numero di record non riusciti che riflette la tolleranza dell'applicazione per i record non riusciti. È possibile utilizzare i dati storici come indicazione per il valore di errore accettabile. È inoltre necessario considerare i nuovi tentativi quando si imposta la soglia, poiché i record non riusciti possono essere riprovati nelle chiamate successive. PutRecords
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ReadProvisionedThroughputExceeded**
**Dimensioni:** StreamName
**Descrizione dell'allarme: **l'allarme tiene traccia del numero di record che determinano una limitazione della larghezza di banda della rete della capacità effettiva di trasmissione in lettura. Se noti che la larghezza di banda della rete viene continuamente limitata, dovresti prendere in considerazione l'aggiunta di altre partizioni al flusso per aumentare la velocità di trasmissione effettiva di lettura assegnata. Se nel flusso è in esecuzione più di un'applicazione consumatore che condivide il limite `GetRecords`, ti consigliamo di registrare le nuove applicazioni consumatori tramite il fan-out avanzato. Se l'aggiunta di altre partizioni non riduce il numero di limitazioni della larghezza di banda della rete, è possibile che una partizione "calda" riceva più letture rispetto alle altre partizioni. Abilita il monitoraggio avanzato, individua la partizione "calda" e suddividila.
**Scopo:** questo allarme è in grado di rilevare se la larghezza di banda della rete dei consumatori viene limitata quando i consumatori stessi superano la velocità di trasmissione effettiva di lettura assegnata (determinata dal numero di partizioni di cui disponi). In tal caso, non sarai in grado di leggere dal flusso e potrà essere avviato il backup del flusso.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **in genere le richieste sottoposte a limitazione della larghezza di banda della rete possono essere ritentate, quindi l'impostazione della soglia su zero rende l'allarme troppo sensibile. Tuttavia, la continua limitazione della larghezza di banda della rete può influire sulla lettura dal flusso e far scattare l'allarme. Imposta la soglia su una percentuale in base alle richieste sottoposte a limitazioni della larghezza di banda della rete per l'applicazione e ritenta le configurazioni.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**SubscribeToShardEvent.MillisBehindLatest**
**Dimensioni:**StreamName, ConsumerName
**Descrizione dell'allarme: **questo allarme rileva quando il ritardo di elaborazione dei record nell'applicazione supera la soglia. Problemi transitori, come i malfunzionamenti delle API di un'applicazione a valle, possono causare un aumento improvviso del parametro. È necessario indagare se si verificano costantemente. Una causa comune è che il consumatore non elabora i record con una velocità sufficiente a causa delle risorse fisiche insufficienti o della logica di elaborazione dei record che non si è dimensionata all'aumento della velocità di trasmissione effettiva. Il blocco delle chiamate nel percorso critico è spesso causa di rallentamenti nell'elaborazione dei record. È possibile aumentare il parallelismo aumentando il numero di partizioni. Inoltre, è necessario verificare che i nodi di elaborazione sottostanti dispongano di risorse fisiche sufficienti durante i picchi di domanda.
**Scopo: **questo allarme può rilevare un ritardo nell'abbonamento all'evento di partizione del flusso. Ciò indica un ritardo di elaborazione e può contribuire a identificare potenziali problemi con le prestazioni dell'applicazione consumatore o l'integrità generale del flusso. Quando il ritardo di elaborazione diventa significativo, è necessario analizzare e risolvere eventuali colli di bottiglia o inefficienze delle applicazioni consumatore per garantire l'elaborazione dei dati in tempo reale e ridurre al minimo il backlog dei dati.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dal ritardo che l'applicazione è in grado di tollerare. Esamina i requisiti dell'applicazione e analizza le tendenze storiche, quindi seleziona una soglia di conseguenza. Quando la SubscribeToShard chiamata ha esito positivo, l'utente inizia a ricevere SubscribeToShardEvent eventi tramite la connessione persistente per un massimo di 5 minuti, dopodiché è necessario chiamare SubscribeToShard nuovamente per rinnovare l'abbonamento se si desidera continuare a ricevere registrazioni.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**WriteProvisionedThroughputExceeded**
**Dimensioni:** StreamName
**Descrizione dell'allarme: **questo allarme rileva quando il numero di record con conseguente limitazione della larghezza di banda della rete della capacità effettiva di trasmissione di scrittura ha raggiunto la soglia. Quando superano la velocità di trasmissione effettiva di scrittura assegnata (determinata dal numero di partizioni di cui disponi), i produttori vengono sottoposti a limitazione della larghezza di banda della rete e non sarà possibile inviare record al flusso. Per ovviare alla continua limitazione della larghezza di banda della rete, dovresti prendere in considerazione l'aggiunta di partizioni al flusso. Ciò aumenta la velocità di trasmissione effettiva di scrittura assegnata e previene future limitazioni della larghezza di banda della rete. Inoltre, è necessario prendere in considerazione la scelta della chiave di partizione quando si importano i record. La chiave di partizione casuale è preferita perché distribuisce i record in modo uniforme tra le partizioni del flusso, quando possibile.
**Scopo: **questo allarme può rilevare se ai produttori viene rifiutata la scrittura dei record a causa della limitazione della larghezza di banda della rete del flusso o della partizione. Se il flusso è in modalità assegnata, l'impostazione di questo allarme consente di intervenire in modo proattivo quando il flusso di dati raggiunge i limiti, ottimizzando la capacità fornita o adottando le operazioni di dimensionamento appropriate per evitare la perdita di dati e garantire un'elaborazione dei dati fluida.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **in genere le richieste sottoposte a limitazione della larghezza di banda della rete possono essere ritentate, quindi l'impostazione della soglia su zero rende l'allarme troppo sensibile. Tuttavia, una continua limitazione della larghezza di banda della rete può influire sulla scrittura nel flusso ed è necessario impostare una soglia di allarme per rilevarla. Imposta la soglia su una percentuale in base alle richieste sottoposte a limitazioni della larghezza di banda della rete per l'applicazione e ritenta le configurazioni.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Lambda
**ClaimedAccountConcurrency**
**Dimensions: **nessuna
**Descrizione dell'allarme: **questo allarme aiuta a monitorare se la simultaneità delle tue funzioni Lambda si avvicina al limite di simultaneità a livello di Regione dell'account. La larghezza di banda della rete di una funzione inizia a essere limitata se raggiunge il limite di simultaneità. È possibile eseguire le seguenti operazioni per evitare la limitazione della larghezza di banda della rete.
1. [Richiedi un aumento della simultaneità](https://repost.aws/knowledge-center/lambda-concurrency-limit-increase) in questa Regione.
1. Identifica e riduci qualsiasi simultaneità prenotata non utilizzata o allocata.
1. Identifica i problemi di prestazioni delle funzioni per migliorare la velocità di elaborazione e di conseguenza il throughput.
1. Aumenta la dimensione del batch delle funzioni, in modo che a ogni invocazione della funzione vengano elaborati più messaggi.
**Scopo: **questo allarme può rilevare in modo proattivo se la simultaneità delle funzioni Lambda si avvicina alla quota di simultaneità a livello di Regione per l'account, in modo che tu possa agire di conseguenza. Le funzioni vengono limitate se `ClaimedAccountConcurrency` raggiunge la quota di simultaneità a livello di Regione per l'account. Se si utilizza la simultaneità prenotata (RC) o la simultaneità allocata (PC), questo allarme offre una maggiore visibilità sull'utilizzo della simultaneità rispetto a un allarme attivo su `ConcurrentExecutions`.
**Statistica: **Maximum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **calcola il valore di circa il 90% della quota di simultaneità per l'account nella Regione e utilizza il risultato come valore della soglia. Per impostazione predefinita, l'account ha un limite di simultaneità pari a 1.000 per tutte le funzioni in una regione. Tuttavia, dovresti controllare la quota del tuo account nel pannello di controllo di Service Quotas.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**Errori**
**Dimensioni:** FunctionName
**Descrizione dell'allarme: **questo allarme rileva un numero elevato di errori. Gli errori includono eccezioni generate dal codice e eccezioni generate dal runtime Lambda. È possibile controllare i log relativi alla funzione per diagnosticare il problema.
**Scopo: **l'allarme aiuta a rilevare un numero elevato di errori nelle invocazioni di funzioni.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia su un numero maggiore di zero. Il valore esatto può dipendere dalla tolleranza agli errori nell'applicazione. Comprendi la criticità delle chiamate gestite dalla funzione. Per alcune applicazioni, qualsiasi errore potrebbe essere inaccettabile, mentre altre applicazioni potrebbero consentire un certo margine di errore.
**Periodo: **60
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**Throttles**
**Dimensioni:** FunctionName
**Descrizione dell'allarme:** questo allarme rileva un numero elevato di richieste di invocazione sottoposte a limitazione della larghezza di banda della rete. La limitazione della larghezza di banda della rete si verifica quando non è disponibile simultaneità per l'aumento. Esistono diversi approcci per risolvere il problema. 1) Richiedi un aumento simultaneo all' AWS assistenza in questa regione. 2) Identificare i problemi di prestazioni della funzione per migliorare la velocità di elaborazione e di conseguenza la velocità di trasmissione effettiva. 3) Aumentare la dimensione del batch della funzione, in modo che a ogni invocazione della funzione vengano elaborati più messaggi.
**Scopo: **l'allarme aiuta a rilevare un numero elevato di richieste di invocazione con limitazione della larghezza di banda della rete per una funzione Lambda. È importante sapere se le richieste vengono costantemente rifiutate a causa della limitazione della larghezza di banda della rete e se è necessario migliorare le prestazioni della funzione Lambda o aumentare la capacità di simultaneità per evitare la limitazione costante.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia su un numero maggiore di zero. Il valore esatto della soglia può dipendere dalla tolleranza dell'applicazione. Imposta la soglia in base all'utilizzo e ai requisiti di dimensionamento della funzione.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Durata**
**Dimensioni:** FunctionName
**Descrizione dell'allarme: **questo allarme rileva tempi di elaborazione di un evento prolungati da parte di una funzione Lambda. Durate significative potrebbero essere dovute a modifiche nel codice della funzione che rendono più lunga l'esecuzione della funzione o delle rispettive dipendenze.
**Scopo:** questo allarme può rilevare una lunga durata di esecuzione di una funzione Lambda. Un'elevata durata di runtime indica che una funzione impiega più tempo per l'invocazione e può anche influire sulla capacità di chiamata simultanea nel caso in cui Lambda stia gestendo un numero maggiore di eventi. È fondamentale sapere se la funzione Lambda richiede costantemente tempi di esecuzione più lunghi del previsto.
**Statistica: **p90
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **la soglia per la durata dipende dall'applicazione e dai carichi di lavoro e dai requisiti di prestazioni. Per requisiti di prestazione elevati, imposta la soglia su un periodo di tempo più breve per verificare se la funzione soddisfa le aspettative. Puoi anche analizzare i dati storici dei parametri di durata per vedere se il tempo impiegato corrisponde alle aspettative di prestazioni della funzione e impostare la soglia su un periodo più lungo rispetto alla media storica. Assicurati di impostare la soglia al di sotto del timeout della funzione configurata.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ConcurrentExecutions**
**Dimensioni:** FunctionName
**Descrizione dell'allarme: **questo allarme aiuta a monitorare se la simultaneità della funzione si avvicina al limite di simultaneità a livello regionale dell'account. La larghezza di banda della rete di una funzione inizia a essere limitata se raggiunge il limite di simultaneità. È possibile eseguire le seguenti operazioni per evitare la limitazione della larghezza di banda della rete.
1. Richiedi un aumento della simultaneità in questa Regione.
1. Identifica i problemi di prestazioni delle funzioni per migliorare la velocità di elaborazione e di conseguenza il throughput.
1. Aumenta la dimensione del batch delle funzioni, in modo che a ogni invocazione della funzione vengano elaborati più messaggi.
Per ottenere una migliore visibilità sull'utilizzo della simultaneità prenotata e della simultaneità allocata, imposta invece un allarme sulla nuova metrica `ClaimedAccountConcurrency`.
**Scopo: **questo allarme può rilevare in modo proattivo se la simultaneità della funzione si avvicina alla quota di simultaneità a livello di regione per l'account, in modo che tu possa agire di conseguenza. La larghezza di banda della rete di una funzione viene limitata se raggiunge la quota di simultaneità a livello di regione per l'account.
**Statistica: **Maximum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia su circa il 90% della quota di simultaneità impostata per l'account nella regione. Per impostazione predefinita, l'account ha un limite di simultaneità pari a 1.000 per tutte le funzioni in una regione. Tuttavia, puoi verificare la quota del tuo account, poiché può essere aumentata contattando l' AWS assistenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Lambda Insight
Come best practice, consigliamo di attivare allarmi basati sui seguenti parametri di Lambda Insights.
**memory\$1utilization**
**Dimensioni: **function\$1name
**Descrizione dell'allarme: **questo allarme viene utilizzato per rilevare se l'utilizzo della memoria di una funzione Lambda si avvicina al limite configurato. Per risolvere il problema, puoi provare a: 1) Ottimizzare il codice. 2) Dimensionare correttamente l'allocazione di memoria stimando accuratamente i requisiti di memoria. A tale scopo, puoi fare riferimento a [Lambda Power Tuning](https://docs.aws.amazon.com/lambda/latest/operatorguide/profile-functions.html). 3) Utilizzare il pooling delle connessioni. Per il pooling delle connessioni per i database RDS, consulta la pagina [Using Amazon RDS Proxy with Lambda](https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/). 4) Puoi anche prendere in considerazione la possibilità di progettare le tue funzioni per evitare di archiviare grandi quantità di dati in memoria tra un'invocazione e l'altra.
**Scopo: **questo allarme viene utilizzato per rilevare se l'utilizzo della memoria per la funzione Lambda si avvicina al limite configurato.
**Statistica: **Average
**Soglia raccomandata: **90,0
**Giustificazione della soglia: **imposta la soglia al 90% per ricevere un avviso quando l'utilizzo della memoria supera il 90% della memoria allocata. Se l'utilizzo della memoria da parte del carico di lavoro rappresenta un fattore critico, è possibile impostarla su un valore inferiore. È inoltre possibile controllare i dati storici per questo parametro e impostare la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
ComparisonOperator: **GREATER\$1THAN\$1THRESHOLD**
## Amazon VPC (`AWS/NATGateway`)
**ErrorPortAllocation**
**Dimensioni:** NatGatewayId
**Descrizione dell'allarme: **questo allarme aiuta a rilevare quando il gateway NAT non è in grado di allocare le porte a nuove connessioni. Per risolvere questo problema, consulta la pagina [Resolve port allocation errors on NAT Gateway](https://repost.aws/knowledge-center/vpc-resolve-port-allocation-errors).
**Scopo: **questo allarme viene utilizzato per rilevare se il gateway NAT non è in grado di allocare una porta di origine.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia:** se il valore di ErrorPortAllocation è maggiore di zero, significa che sono aperte troppe connessioni simultanee verso una singola destinazione popolare. NATGateway
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**PacketsDropCount**
**Dimensioni:** NatGatewayId
**Descrizione dell'allarme: **questo allarme aiuta a rilevare quando i pacchetti vengono eliminati dal Gateway NAT. Ciò potrebbe accadere a causa di un problema con NAT Gateway, quindi controllate lo stato di [AWS NAT Gateway nella vostra regione nel pannello di controllo dello stato del AWS servizio](https://health.aws.amazon.com/health/status). Questo può aiutarti a stabilire un collegamento con il problema di rete relativo al traffico che utilizza il gateway NAT.
**Scopo: **questo allarme viene utilizzato per rilevare se i pacchetti vengono eliminati dal gateway NAT.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **è necessario calcolare il valore dello 0,01% del traffico totale sul gateway NAT e utilizzare tale risultato come valore di soglia. Utilizza i dati storici del traffico sul gateway NAT per stabilire la soglia.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## AWS Link privato () `AWS/PrivateLinkEndpoints`
**PacketsDropped**
**Dimensioni: **ID VPC, ID endpoint VPC, tipo di endpoint, ID sottorete, nome del servizio
**Descrizione dell'allarme: **questo allarme aiuta a rilevare se l'endpoint o il servizio endpoint non è integro monitorando il numero di pacchetti rilasciati dall'endpoint. I pacchetti con dimensioni superiori a 8.500 byte che arrivano all'endpoint VPC vengono eliminati. Per la risoluzione dei problemi, consulta la pagina [Connectivity problems between an interface VPC endpoint and an endpoint service](https://repost.aws/knowledge-center/connect-endpoint-service-vpc).
**Scopo: **questo allarme viene utilizzato per rilevare se l'endpoint o il servizio endpoint non è integro.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base al caso d'uso. Per essere consapevole dello stato di non integrità dell'endpoint o del servizio endpoint, dovresti impostare la soglia su un valore basso in modo da avere la possibilità di risolvere il problema prima che si verifichi un'enorme perdita di dati. È possibile utilizzare i dati storici per comprendere la tolleranza in caso di perdita di pacchetti e impostare la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## AWS Link privato (`AWS/PrivateLinkServices`)
**RstPacketsSent**
**Dimensioni: **ID servizio, ARN sistema di bilanciamento del carico, AZ
**Descrizione dell'allarme: **questo allarme consente di rilevare gli obiettivi non integri di un servizio endpoint in base al numero di pacchetti di ripristino inviati agli endpoint. Quando esegui il debug degli errori di connessione con un utente del tuo servizio, puoi verificare se il servizio sta ripristinando le connessioni con la RstPacketsSent metrica o se qualcos'altro non funziona sul percorso di rete.
**Scopo: **questo allarme viene utilizzato per rilevare gli obiettivi non integri di un servizio endpoint.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: ** a soglia dipende dal caso d'uso. Se il tuo caso d'uso può tollerare obiettivi non integri, puoi impostare la soglia su un valore alto. Se il caso d'uso non è in grado di tollerare obiettivi non integri, puoi impostare la soglia su un valore molto basso.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## `Amazon RDS`
**CPUUtilization**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a monitorare un utilizzo costantemente elevato della CPU. L'utilizzo della CPU misura il tempo di non inattività. Prendi in considerazione l'utilizzo di [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.Enabling.html) o [Performance Insights](https://aws.amazon.com/rds/performance-insights/) per verificare quale [tempo di attesa](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring-Available-OS-Metrics.html) consuma la maggior parte del tempo della CPU (`guest`, `irq`, `wait`, `nice` e così via) per MariaDB, MySQL, Oracle e PostgreSQL. Quindi valuta quali query consumano la maggiore quantità di CPU. Se non riesci a ottimizzare il carico di lavoro, valuta la possibilità di passare a una classe di istanze database più ampia.
**Intento: **questo allarme viene utilizzato per rilevare un utilizzo elevato e costante della CPU al fine di evitare tempi di risposta e timeout molto elevati. Se si desidera verificare il micro-bursting dell'utilizzo della CPU, è possibile impostare un tempo inferiore di valutazione degli allarmi.
**Statistica: **Average
**Soglia raccomandata: **90,0
**Giustificazione della soglia: **i picchi casuali nel consumo di CPU potrebbero non influire sulle prestazioni del database, ma un utilizzo elevato e prolungato della CPU può ostacolare le richieste del database in arrivo. A seconda del carico di lavoro complessivo del database, un elevato livello di CPU dell' RDS/Aurora istanza può compromettere le prestazioni complessive.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**DatabaseConnections**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme rileva un numero elevato di connessioni. Controlla le connessioni esistenti e interrompi quelle che sono in stato di “sospensione” o che non sono chiuse correttamente. Prendi in considerazione l'uso del pool di connessioni per limitare il numero di nuove connessioni. In alternativa, aumenta la dimensione dell'istanza database per utilizzare una classe con più memoria e quindi un valore predefinito più alto per “max\$1connections” oppure aumenta il valore “max\$1connections” in [RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html) e Aurora [MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Performance.html) e [PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Managing.html) per la classe corrente se può supportare il tuo carico di lavoro.
**Intento: **questo allarme viene utilizzato per prevenire il rifiuto delle connessioni quando viene raggiunto il numero massimo di connessioni DB. Questo allarme non è consigliato nel caso in cui si cambi frequentemente la classe dell'istanza database, poiché così facendo si modificano la memoria e il numero massimo predefinito di connessioni.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **il numero di connessioni consentite dipende dalla dimensione della classe dell'istanza database e dai parametri specifici del motore di database relativi a processi/connessioni. È necessario calcolare un valore compreso tra il 90 e il 95% del numero massimo di connessioni per il database e utilizzare tale risultato come valore di soglia.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**EBSByteSaldo%**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a monitorare una bassa percentuale di crediti della velocità di trasmissione effettiva rimanenti. Per la risoluzione dei problemi, controlla i [problemi di latenza in RDS](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck).
**Intento: **questo allarme è utilizzato per rilevare una bassa percentuale di crediti della velocità di trasmissione effettiva rimanenti nel burst bucket. Una bassa percentuale di saldo byte può causare problemi di velocità di trasmissione effettiva. Questo allarme non è consigliato per le istanze Aurora PostgreSQL.
**Statistica: **Average
**Soglia raccomandata: **10,0
**Giustificazione della soglia: **un saldo a credito della velocità di trasmissione effettiva inferiore al 10% è considerato insufficiente ed è necessario impostare la soglia di conseguenza. È anche possibile impostare una soglia inferiore se l'applicazione è in grado di tollerare una velocità di trasmissione effettiva inferiore per il carico di lavoro.
**Periodo: **60
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**EBSIOBalance%**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a monitorare una bassa percentuale di crediti IOPS rimanenti. Per la risoluzione dei problemi, consulta i [problemi di latenza in RDS](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck).
**Intento:** questo allarme viene utilizzato per rilevare una bassa percentuale di I/O crediti rimanenti nel burst bucket. Una bassa percentuale di saldo IOPS può causare problemi di colli di bottiglia. Questo allarme non è consigliato per le istanze Aurora.
**Statistica: **Average
**Soglia raccomandata: **10,0
**Giustificazione della soglia: **un saldo a credito IOPS inferiore al 10% è considerato insufficiente ed è possibile impostare la soglia di conseguenza. È anche possibile impostare una soglia inferiore, se l'applicazione è in grado di tollerare IOPS inferiore per il carico di lavoro.
**Periodo: **60
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**FreeableMemory**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a monitorare una scarsa memoria liberabile, il che può indicare un picco nelle connessioni al database o che l'istanza potrebbe essere sottoposta a un'elevata pressione di memoria. Controlla la pressione della memoria monitorando le CloudWatch metriche relative a `SwapUsage` `in aggiunta a. `FreeableMemory` Se il consumo di memoria dell'istanza è spesso troppo elevato, è necessario controllare il carico di lavoro o aggiornare la classe di istanza. Per un'istanza database di lettura Aurora, valuta la possibilità di aggiungere più istanze database di lettura al cluster. Per ulteriori informazioni sulla risoluzione dei problemi di Aurora, consulta i [problemi di memoria liberabile](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#Troubleshooting.FreeableMemory).
**Intento: **questo allarme viene utilizzato per evitare l'esaurimento della memoria, che può causare il rifiuto delle connessioni.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **a seconda del carico di lavoro e della classe di istanza, possono essere appropriati diversi valori per la soglia. Idealmente, la memoria disponibile non dovrebbe scendere al di sotto del 25% della memoria totale per periodi prolungati. Per Aurora, puoi impostare la soglia vicino al 5%, poiché un parametro vicino a 0 indica che l'istanza database ha eseguito il dimensionamento al valore massimo possibile. È possibile analizzare il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**FreeLocalStorage**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a monitorare uno scarso spazio di archiviazione locale. Aurora edizione compatibile con PostgreSQL utilizza l'archiviazione locale per memorizzare i log degli errori e i file temporanei. Aurora MySQL utilizza l'archiviazione locale per archiviare i log degli errori, i log generali, i log delle query lente, i log di audit e le tabelle temporanee non InnoDB. Questi volumi di archiviazione locale sono supportati da Amazon EBS Store e possono essere estesi utilizzando una classe di istanza database più grande. Per la risoluzione dei problemi, verifica Aurora [edizione compatibile con PostgreSQL](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue) ed [edizione compatibile con MySQL](https://repost.aws/knowledge-center/aurora-mysql-local-storage).
**Intento: **questo allarme viene utilizzato per rilevare quanto manca all'istanza di database Aurora per raggiungere il limite di archiviazione locale, se non si usa Aurora Serverless v2 o versione successiva. L'archiviazione locale può raggiungere il limite di capacità quando si archiviano dati non persistenti, come tabelle e file di log temporanei, nella memoria locale. Questo allarme può prevenire un out-of-space errore che si verifica quando l'istanza DB esaurisce lo storage locale.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **è necessario calcolare circa il 10%-20% dello spazio di archiviazione disponibile in base alla velocità e all'andamento dell'utilizzo del volume, quindi utilizzare tale risultato come valore di soglia per intervenire in modo proattivo prima che il volume raggiunga il limite.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**FreeStorageSpace**
**Dimensioni:** DBInstance identificatore
**Descrizione dell'allarme: **questo allarme rileva una scarsa quantità di spazio di archiviazione disponibile. Se ti avvicini spesso ai limiti di capacità di archiviazione, prendi in considerazione la possibilità di aumentare lo spazio di archiviazione del database. Includi un buffer di memoria per soddisfare gli aumenti imprevisti della domanda delle tue applicazioni. In alternativa, valuta la possibilità di abilitare il dimensionamento automatico dell'archiviazione RDS. Puoi anche valutare la possibilità di liberare più spazio eliminando dati e log obsoleti o inutilizzati. Per ulteriori informazioni, consulta il [documento sulla mancanza di spazio per RDS](https://repost.aws/knowledge-center/rds-out-of-storage) e il [documento sui problemi di archiviazione di PostgreSQL](https://repost.aws/knowledge-center/diskfull-error-rds-postgresql).
**Intento: **questo allarme aiuta a prevenire problemi di esaurimento dell'archiviazione. Può aiutare a prevenire il tempo di inattività che si verifica quando l'istanza di database esaurisce lo spazio di archiviazione. Si sconsiglia di utilizzare questo allarme se è abilitato il dimensionamento automatico dell'archiviazione o se si modifica frequentemente la capacità di archiviazione dell'istanza di database.
**Statistica: **Minimum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **il valore della soglia dipenderà dallo spazio di archiviazione attualmente allocato. In genere, è necessario calcolare il 10% dello spazio di archiviazione allocato e utilizzare tale risultato come valore di soglia.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**MaximumUsedTransactionIDs**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a impedire il wraparound dell'ID delle transazioni per PostgreSQL. Fai riferimento alla procedura di risoluzione dei problemi in [questo blog](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) per esaminare e risolvere il problema. Puoi anche fare riferimento a [questo blog](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) per acquisire maggiore familiarità con i concetti relativi all'autovacuum, i problemi più comuni e le best practice.
**Intento: **questo allarme viene utilizzato per impedire il wraparound dell'ID delle transazioni per PostgreSQL.
**Statistica: **Average
**Soglia raccomandata: **1,0E9
**Giustificazione della soglia: **l'impostazione di questa soglia a 1 miliardo dovrebbe darti il tempo di esaminare il problema. Il valore predefinito di autovacuum\$1freeze\$1max\$1age è 200 milioni. Se l'età della transazione più vecchia è di 1 miliardo, Autovacuum ha problemi a mantenere questa soglia al di sotto dell'obiettivo di 200 milioni di transazioni. IDs
**Periodo: **60
**Punti dati su cui attivare allarmi: **1
**Periodi di valutazione: **1
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ReadLatency**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a monitorare una latenza di lettura elevata. Se la latenza dell'archiviazione è elevata, il carico di lavoro supera i limiti delle risorse. È possibile esaminare I/O l'utilizzo relativo all'istanza e alla configurazione dello storage allocato. Fai riferimento alla [risoluzione dei problemi di latenza dei volumi Amazon EBS causata da un collo di bottiglia IOPS](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck). Per Aurora, puoi passare a una classe di istanza con una [configurazione di archiviazione con ottimizzazione per I/O](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html). Per informazioni, consulta [Pianificazione I/O in Aurora](https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/).
**Intento: **questo allarme viene utilizzato per rilevare una latenza di lettura elevata. I dischi del database normalmente hanno una read/write latenza bassa, ma possono presentare problemi che possono causare operazioni ad alta latenza.
**Statistica: **p90
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dal caso d'uso. Le latenze di lettura superiori a 20 millisecondi richiedono probabilmente un'analisi. È inoltre possibile impostare una soglia più alta se l'applicazione può avere una latenza più elevata per le operazioni di lettura. Esamina la criticità e i requisiti della latenza di lettura e analizza il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**ReplicaLag**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: ** questo allarme ti aiuta a capire il numero di secondi di ritardo di una replica di lettura rispetto all'istanza principale. Una replica di lettura PostgreSQL segnala un ritardo di replica fino a cinque minuti se non ci sono transazioni di utenti sull'istanza database di origine. Quando la ReplicaLag metrica raggiunge 0, la replica ha raggiunto l'istanza database principale. Se la ReplicaLag metrica restituisce -1, la replica non è attualmente attiva. [Per indicazioni relative a RDS PostgreSQL, consulta le [migliori pratiche di replica e per `ReplicaLag` la risoluzione dei problemi e gli errori correlati, consulta](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) Risoluzione dei problemi. ReplicaLag](https://repost.aws/knowledge-center/rds-postgresql-replication-lag)
**Intento: **questo allarme è in grado di rilevare il ritardo di replica che riflette la perdita di dati che potrebbe verificarsi in caso di errore dell'istanza principale. Se la replica è troppo indietro rispetto alla principale e la principale riscontra errori, alla replica mancheranno i dati presenti nell'istanza principale.
**Statistica: **Maximum
**Soglia raccomandata: **60,0
**Giustificazione della soglia: **in genere, il ritardo accettabile dipende dall'applicazione. Si consiglia di non superare i 60 secondi.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**WriteLatency**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a monitorare una latenza di scrittura elevata. Se la latenza dell'archiviazione è elevata, il carico di lavoro supera i limiti delle risorse. È possibile esaminare I/O l'utilizzo relativo all'istanza e alla configurazione dello storage allocato. Fai riferimento alla [risoluzione dei problemi di latenza dei volumi Amazon EBS causata da un collo di bottiglia IOPS](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck). Per Aurora, puoi passare a una classe di istanza con una [configurazione di archiviazione con ottimizzazione per I/O](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html). Per informazioni, consulta [Pianificazione I/O in Aurora](https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/).
**Intento: **questo allarme viene utilizzato per rilevare una latenza di scrittura elevata. Sebbene i dischi del database abbiano in genere una bassa read/write latenza, possono presentare problemi che causano operazioni a latenza elevata. Il monitoraggio della latenza di scrittura garantirà che la latenza del disco sia bassa come previsto.
**Statistica: **p90
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dal caso d'uso. Le latenze di scrittura superiori a 20 millisecondi richiedono probabilmente un'analisi. È inoltre possibile impostare una soglia più alta se l'applicazione può avere una latenza più elevata per le operazioni di scrittura. Esamina la criticità e i requisiti della latenza di scrittura e analizza il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**DBLoad**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a monitorare un carico del database elevato. Se il numero di processi supera il numero di vCPUs, i processi iniziano a mettersi in coda. Quando la coda aumenta, le prestazioni diminuiscono. Se il carico è spesso sopra la vCPU massima e lo stato di attesa primario è CPU, la CPU è sovraccarica. In questo caso, è possibile monitorare `CPUUtilization` `DBLoadCPU` e mettere in coda le attività in Performance Monitoring. Insights/Enhanced Si potrebbero limitare le connessioni all'istanza, ottimizzare le eventuali query SQL con un elevato carico CPU o valutare la possibilità di una classe istanza di maggiori dimensioni. Istanze elevate e costanti di qualsiasi stato di attesa indicano che possono verificarsi colli di bottiglia o problemi di conflitto delle risorse da risolvere.
**Scopo: **questo allarme viene utilizzato per rilevare un elevato carico del database. Un carico del database elevato può causare problemi di prestazioni nell'istanza di database. Questo allarme non è applicabile alle istanze di database serverless.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **il valore vCPU massimo è determinato dal numero di core vCPU (CPU virtuale) per l'istanza database. A seconda della vCPU massima, possono essere appropriati valori diversi per la soglia. Idealmente, il carico del database non dovrebbe superare la linea vCPU.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**AuroraVolumeBytesLeftTotal**
**Dimensioni: identificatore** DBCluster
**Descrizione dell'allarme: **questo allarme aiuta a monitorare uno scarso livello di volume totale residuo. Quando il volume totale rimasto raggiunge il limite di dimensione, il cluster segnala un out-of-space errore. L'archiviazione di Aurora viene automaticamente dimensionata con i dati del volume cluster e si espande fino a 128 TiB o 64 TiB a seconda della [versione del motore del database](https://repost.aws/knowledge-center/aurora-version-number). Valuta la possibilità di eliminare le tabelle e i database che non sono più necessari. Per ulteriori informazioni, controlla il [dimensionamento dell'archiviazione](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html).
**Intento: **questo allarme viene utilizzato per rilevare quanto manca al cluster Aurora per raggiungere il limite delle dimensioni del volume. Questo allarme può prevenire un out-of-space errore che si verifica quando lo spazio del cluster si esaurisce. Questo allarme è consigliato solo per Aurora MySQL.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **è necessario calcolare il 10%-20% del limite delle dimensioni corrente in base alla velocità e all'andamento dell'aumento dell'utilizzo del volume, quindi usare tale risultato come valore di soglia per intervenire in modo proattivo prima che il volume raggiunga il limite.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**AuroraBinlogReplicaLag**
**Dimensioni:** DBCluster Identifier, role=Writer
**Descrizione dell'allarme: **questo allarme aiuta a monitorare lo stato di errore della replica dell'istanza di scrittura di Aurora. Per ulteriori informazioni, consulta [Replica dei cluster Aurora MySQL DB](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html) tra le regioni. AWS Per la risoluzione dei problemi, consulta i [roblemi di replica di Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.MySQL).
**Intento: **questo allarme viene utilizzato per rilevare se l'istanza di scrittura è in uno stato di errore e non è in grado di replicare l'origine. Questo allarme è consigliato solo per Aurora MySQL.
**Statistica: **Average
**Soglia raccomandata: **-1,0
**Giustificazione della soglia: **si consiglia di utilizzare -1 come valore di soglia perché Aurora MySQL pubblica questo valore se la replica è in uno stato di errore.
**Periodo: **60
**Punti dati su cui attivare allarmi: **2
**Periodi di valutazione: **2
**Operatore di confronto: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**BlockedTransactions**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme aiuta a monitorare un elevato numero di transazioni bloccate in un'istanza di database Aurora. Le transazioni bloccate possono terminare con un rollback o un commit. L'elevata simultaneità, le transazioni inattive o le transazioni di lunga durata possono portare al blocco delle transazioni. Per la risoluzione dei problemi, consulta la documentazione di [Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/ams-waits.row-lock-wait.html).
**Intento: **questo allarme viene utilizzato per rilevare un numero elevato di transazioni bloccate in un'istanza di database Aurora al fine di prevenire i rollback delle transazioni e il peggioramento delle prestazioni.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **è necessario calcolare il 5% di tutte le transazioni dell'istanza utilizzando il parametro `ActiveTransactions` e utilizzare tale risultato come valore di soglia. Puoi anche esaminare la criticità e i requisiti delle transazioni bloccate e analizzare il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**BufferCacheHitRatio**
**Dimensioni: identificatore** DBInstance
**Descrizione dell'allarme: **questo allarme consente di monitorare un rapporto di riscontri nella cache costantemente basso del cluster Aurora. Una percentuale di riscontri bassa indica che le query su questa istanza database vengono spesso trasferite su disco. Per la risoluzione del problemi, esamina il carico di lavoro per vedere quali query causano questo comportamento e controlla il documento [Suggerimenti relativi alla RAM per un'istanza di database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.BestPractices.html#Aurora.BestPractices.Performance.Sizing).
**Intento: **questo allarme viene utilizzato per rilevare un rapporto di riscontri nella cache costantemente basso al fine di prevenire una riduzione sostenuta delle prestazioni nell'istanza Aurora.
**Statistica: **Average
**Soglia raccomandata: **80,0
**Giustificazione della soglia: **è possibile impostare la soglia per la percentuale di riscontri nella cache del buffer all'80%. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili.
**Periodo: **60
**Punti dati su cui attivare allarmi: **10
**Periodi di valutazione: **10
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**EngineUptime**
**Dimensioni:** DBCluster Identifier, Role=Writer
**Descrizione dell'allarme: **questo allarme aiuta a monitorare tempi di inattività ridotti dell'istanza database di scrittura. L'istanza database di scrittura può interrompersi a causa di un riavvio, una manutenzione, un aggiornamento o un failover. Se l'uptime raggiunge 0 a causa di un failover nel cluster e il cluster ha una o più repliche Aurora, una replica Aurora Replica viene promossa all'istanza di scrittura principale durante un evento di errore. Per aumentare la disponibilità del cluster database, valuta la possibilità di creare almeno una o più repliche Aurora in due o più due zone di disponibilità. Per ulteriori informazioni, controlla [i fattori che influenzano i tempi di inattività di Aurora](https://repost.aws/knowledge-center/aurora-mysql-downtime-factors).
**Intento: **questo allarme viene utilizzato per rilevare se l'istanza database di scrittura di Aurora è in fase di inattività. In questo modo è possibile evitare errori di lunga durata nell'istanza di scrittura dovuti a un arresto anomalo o a un failover.
**Statistica: **Average
**Soglia raccomandata: **0,0
**Giustificazione della soglia: **un evento di errore ha come conseguenza una breve interruzione, durante la quale le operazioni di lettura e scrittura falliscono con un'eccezione. Tuttavia, il servizio viene in genere ripristinato in meno di 60 secondi e spesso in meno di 30 secondi.
**Periodo: **60
**Punti dati su cui attivare allarmi: **2
**Periodi di valutazione: **2
**Operatore di confronto: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**RollbackSegmentHistoryListLength**
**Dimensioni:** DBInstance Identifier
**Descrizione dell'allarme: **questo allarme aiuta a monitorare una costante elevata lunghezza della cronologia dei segmenti di rollback di un'istanza Aurora. Una lunghezza dell'elenco della cronologia di InnoDB elevata indica che un grande numero di precedenti versioni di riga, la chiusura delle query e l'arresto del database sono diventati più lenti. Per ulteriori informazioni e risoluzione dei problemi, consulta la documentazione relativa all'[aumento significativo della lunghezza dell'elenco della cronologia di InnoDB](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/proactive-insights.history-list.html).
**Intento: **questo allarme viene utilizzato per rilevare una costante elevata lunghezza della cronologia dei segmenti di rollback. Può aiutarti a impedire un peggioramento sostenuto delle prestazioni e un elevato utilizzo della CPU nell'istanza Aurora. Questo allarme è consigliato solo per Aurora MySQL.
**Statistica: **Average
**Soglia raccomandata: **1000000,0
**Giustificazione della soglia: **l'impostazione di questa soglia a 1 milione dovrebbe darti il tempo di esaminare il problema. Tuttavia, puoi regolare questo valore in base al livello di prestazioni e alle caratteristiche del carico di lavoro accettabili.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**StorageNetworkThroughput**
**Dimensioni:** DBCluster Identifier, Role=Writer
**Descrizione dell'allarme: **questo allarme aiuta a monitorare l'elevata velocità di trasmissione effettiva della rete di archiviazione. Se la velocità di trasmissione effettiva della rete di archiviazione supera la larghezza di banda di rete totale dell'[istanza EC2](https://aws.amazon.com/ec2/instance-types/), la latenza di lettura e scrittura può essere elevata e causare un peggioramento delle prestazioni. Puoi controllare il tipo di istanza EC2 dalla Console. AWS Per la risoluzione dei problemi, controlla eventuali modifiche alle write/read latenze e valuta se hai attivato un allarme anche in base a questa metrica. In tal caso, esamina lo schema del carico di lavoro durante i momenti in cui è stato attivato l'allarme. Questo può aiutarti a capire se puoi ottimizzare il tuo carico di lavoro per ridurre la quantità totale di traffico di rete. Se ciò non è possibile, potresti dover valutare la possibilità di ridimensionare l'istanza.
**Intento: **questo allarme viene utilizzato per rilevare un'elevata velocità di trasmissione effettiva della rete di archiviazione. Il rilevamento di una elevata velocità di trasmissione effettiva può prevenire perdite di pacchetti di rete e un peggioramento delle prestazioni.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **è necessario calcolare circa l'80%-90% della larghezza di banda della rete totale del tipo di istanza EC2 e quindi utilizzare tale risultato come valore di soglia, in modo da agire proattivamente prima che i pacchetti di rete siano coinvolti. Puoi anche esaminare la criticità e i requisiti della velocità di trasmissione effettiva della rete di archiviazione e analizzare il comportamento storico di questo parametro per determinare livelli di soglia ragionevoli.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## `Amazon Route 53 Public Data Plane`
**HealthCheckStatus**
**Dimensioni:** HealthCheckId
**Descrizione dell'allarme: **questo allarme aiuta a rilevare gli endpoint non integri secondo gli strumenti di controllo dello stato. Per comprendere il motivo di un errore che causa uno stato di malfunzionamento, utilizza la scheda Strumenti di controllo dell'integrità nella Console di controllo dell'integrità di Route 53 per visualizzare lo stato di ciascuna regione e l'ultimo errore del controllo dell'integrità. La scheda di stato mostra anche il motivo per cui l'endpoint viene segnalato come non integro. Consulta la [procedura per la risoluzione dei problemi](https://repost.aws/knowledge-center/route-53-fix-unhealthy-health-checks).
**Scopo: **questo allarme utilizza gli strumenti di controllo dell'integrità di Route53 per rilevare endpoint non integri.
**Statistica: **Average
**Soglia raccomandata: **1,0
**Giustificazione della soglia: **lo stato dell'endpoint è riportato come 1 quando è integro. Tutti i valori inferiori a 1 equivalgono a non integro.
**Periodo: **60
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
## `Amazon S3`
**4xxErrors**
**Dimensioni:**BucketName, FilterId
**Descrizione dell'allarme: **questo allarme contribuisce a segnalare il numero totale di codici di stato di errore 4xx creati in risposta alle richieste dei client. I codici di errore 403 possono indicare una policy IAM errata, mentre i codici di errore 404 possono segnalare, ad esempio, un comportamento errato dell'applicazione client. L'[abilitazione temporanea della registrazione degli accessi al server S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html) ti aiuterà a individuare l'origine del problema utilizzando i campi Stato HTTP e Codice errore. Per ulteriori informazioni sul codice di errore, consulta la pagina [Error Responses](https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html).
**Scopo: **questo allarme viene utilizzato per creare un valore di base per i tassi di errore 4xx tipici, in modo da poter esaminare eventuali anomalie che potrebbero indicare un problema di configurazione.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia:** la soglia raccomandata consiste nel rilevare se più del 5% del totale delle richieste presenta errori 4XX. È consigliabile attivare gli allarmi per gli errori 4XX che si verificano di frequente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile. Inoltre, è possibile regolare la soglia in base al carico delle richieste, tenendo conto del livello accettabile di errori 4XX. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**5xxErrors**
**Dimensioni:**BucketName, FilterId
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un numero elevato di errori lato server. Questi errori indicano che un client ha effettuato una richiesta che il server non è riuscito a completare. Questo può aiutarti a stabilire un collegamento con il problema che la tua applicazione sta riscontrando a causa di S3. Per ulteriori informazioni su come gestire o ridurre in modo efficiente gli errori, consulta la pagina [Optimizing performance design patterns](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html#optimizing-performance-timeouts-retries). Gli errori potrebbero essere causati anche da un problema con S3; controlla lo stato di Amazon S3 nella tua regione nel [Pannello di controllo per lo stato dei servizi AWS](https://health.aws.amazon.com/health/status).
**Scopo: **questo allarme può aiutare a rilevare se l'applicazione presenta problemi dovuti a errori 5xx.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia:** consigliamo di impostare la soglia per rilevare se più del 5% delle richieste totali riceve 5XXError. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**OperationsFailedReplication**
**Dimensioni:**SourceBucket,, DestinationBucket RuleId
**Descrizione dell'allarme: **questo allarme aiuta a comprendere un errore di replica. Questo parametro tiene traccia dello stato dei nuovi oggetti replicati utilizzando S3 CRR o S3 SRR così come degli oggetti esistenti replicati utilizzando la replica in batch S3. Per ulteriori dettagli, consulta la sezione [Replication troubleshooting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-troubleshoot.html).
**Scopo: **questo allarme viene utilizzato per rilevare se è presente un'operazione di replica non riuscita.
**Statistica: **Maximum
**Soglia raccomandata: **0,0
**Giustificazione della soglia: **questo parametro emette un valore pari a 0 per le operazioni riuscite e nulla quando non vengono eseguite operazioni di replica per un minuto. Quando il parametro emette un valore maggiore di 0, l'operazione di replica non ha avuto esito positivo.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## `S3ObjectLambda`
**4xxErrors**
**Dimensioni:**AccessPointName, DataSource ARN
**Descrizione dell'allarme: **questo allarme aiuta a segnalare il numero totale di codici di stato di errore 4xx creati in risposta alle richieste dei client. L'[abilitazione temporanea della registrazione degli accessi al server S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html) ti aiuterà a individuare l'origine del problema utilizzando i campi Stato HTTP e Codice errore.
**Scopo: **questo allarme viene utilizzato per creare un valore di base per i tassi di errore 4xx tipici, in modo da poter esaminare eventuali anomalie che potrebbero indicare un problema di configurazione.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia:** consigliamo di impostare la soglia per rilevare se più del 5% delle richieste totali riceve 4. XXError È consigliabile attivare gli allarmi per gli errori 4XX che si verificano di frequente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile. Inoltre, è possibile regolare la soglia in base al carico delle richieste, tenendo conto del livello accettabile di errori 4XX. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**5xxErrors**
**Dimensioni:**AccessPointName, DataSource ARN
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un numero elevato di errori lato client. Questi errori indicano che un client ha effettuato una richiesta che il server non è riuscito a completare. Questi errori potrebbero essere causati anche da un problema con S3; controlla lo stato di Amazon S3 nella tua regione nel [Pannello di controllo per lo stato dei servizi AWS](https://health.aws.amazon.com/health/status). Questo può aiutarti a stabilire un collegamento con il problema che la tua applicazione sta riscontrando a causa di S3. Per informazioni su come gestire o ridurre in modo efficiente questi errori, consulta la pagina [Optimizing performance design patterns](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html#optimizing-performance-timeouts-retries).
**Scopo: **questo allarme può aiutare a rilevare se l'applicazione presenta problemi dovuti a errori 5xx.
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia:** consigliamo di impostare la soglia per rilevare se più del 5% del totale delle richieste riceve errori 5XX. Tuttavia, puoi regolare la soglia in base al traffico relativo alle richieste e ai tassi di errore accettabili. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**LambdaResponse4xx**
**Dimensioni:**AccessPointName, DataSource ARN
**Descrizione dell'allarme: **questo allarme consente di rilevare e diagnosticare gli errori (500) nelle chiamate a S3 Object Lambda. Questi errori possono essere causati da errori o configurazioni errate nella funzione Lambda responsabile della risposta alle richieste. L'analisi dei flussi di CloudWatch log della funzione Lambda associata all'access point Object Lambda può aiutarti a individuare l'origine del problema in base alla risposta di S3 Object Lambda.
**Intento:** questo allarme viene utilizzato per rilevare gli errori del client 4xx per le chiamate. WriteGetObjectResponse
**Statistica: **Average
**Soglia raccomandata: **0,05
**Giustificazione della soglia:** consigliamo di impostare la soglia per rilevare se più del 5% del totale delle richieste riceve 4. XXError È consigliabile attivare gli allarmi per gli errori 4XX che si verificano di frequente. Tuttavia, l'impostazione di un valore molto basso per la soglia può rendere l'allarme troppo sensibile. Inoltre, è possibile regolare la soglia in base al carico delle richieste, tenendo conto del livello accettabile di errori 4XX. Inoltre, è possibile analizzare i dati storici per determinare il tasso di errore accettabile per il carico di lavoro dell'applicazione e regolare la soglia di conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon SNS
**NumberOfMessagesPublished**
**Dimensioni:** TopicName
**Descrizione dell'allarme: **questo allarme può rilevare quando il numero di messaggi SNS pubblicati è troppo basso. Per la risoluzione dei problemi, controlla perché gli editori inviano una quantità minore di traffico.
**Scopo: **questo allarme aiuta a monitorare e rilevare in modo proattivo cali significativi nella pubblicazione delle notifiche. Ciò consente di identificare potenziali problemi con l'applicazione o i processi aziendali, in modo da intraprendere le operazioni appropriate per mantenere il flusso di notifiche previsto. È necessario creare questo allarme se si prevede che il sistema debba servire un traffico minimo.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **il numero di messaggi pubblicati deve essere in linea con il numero previsto di messaggi pubblicati per l'applicazione. Inoltre, è possibile analizzare i dati storici, le tendenze e il traffico per individuare la soglia giusta.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**NumberOfNotificationsDelivered**
**Dimensioni:** TopicName
**Descrizione dell'allarme: **questo allarme può rilevare quando il numero di messaggi SNS consegnati è troppo basso. Ciò potrebbe essere dovuto all'annullamento involontario dell'abbonamento di un endpoint o a un evento SNS che causa un ritardo nei messaggi.
**Scopo: **questo allarme consente di rilevare un calo del volume dei messaggi consegnati. È necessario creare questo allarme se si prevede che il sistema debba servire un traffico minimo.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **il numero di messaggi consegnati deve essere in linea con il numero previsto di messaggi prodotti e il numero di consumatori. Inoltre, è possibile analizzare i dati storici, le tendenze e il traffico per individuare la soglia giusta.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**NumberOfNotificationsFailed**
**Dimensioni:** TopicName
**Descrizione dell'allarme: **questo allarme può rilevare quando il numero di messaggi SNS consegnati è troppo alto. Per risolvere i problemi relativi alle notifiche non riuscite, abilita la registrazione nei registri. CloudWatch L'esame dei log può aiutarti a scoprire quali abbonati non funzionano e i codici di stato che restituiscono.
**Scopo: **questo allarme ti aiuta a individuare in modo proattivo i problemi relativi alla consegna delle notifiche e a prendere le misure necessarie per risolverli.
**Statistica: **Sum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dall'impatto delle notifiche non riuscite. Controlla i dati SLAs forniti agli utenti finali, la tolleranza agli errori e la criticità delle notifiche e analizza i dati storici, quindi seleziona una soglia di conseguenza. Il numero di notifiche non riuscite dovrebbe essere 0 per gli argomenti che hanno solo abbonamenti SQS, Lambda o Firehose.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFilteredOut-InvalidAttributes**
**Dimensioni:** TopicName
**Descrizione dell'allarme: **questo allarme aiuta a monitorare e risolvere potenziali problemi con l'editore o gli abbonati. Controlla se un editore pubblica messaggi con attributi non validi o se a un abbonato viene applicato un filtro inappropriato. Puoi anche analizzare CloudWatch i log per individuare la causa principale del problema.
**Scopo: **l'allarme viene utilizzato per rilevare se i messaggi pubblicati non sono validi o se a un abbonato sono stati applicati filtri inappropriati.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia: **gli attributi non validi sono quasi sempre un errore dell'editore. Si consiglia di impostare la soglia su 0 perché in un sistema integro non sono previsti attributi non validi.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFilteredOut-InvalidMessageBody**
**Dimensioni:** TopicName
**Descrizione dell'allarme: **questo allarme aiuta a monitorare e risolvere potenziali problemi con l'editore o gli abbonati. Controlla se un editore pubblica messaggi con corpi dei messaggi non validi o se a un abbonato viene applicato un filtro inappropriato. Puoi anche analizzare CloudWatch i log per individuare la causa principale del problema.
**Scopo: **l'allarme viene utilizzato per rilevare se i messaggi pubblicati non sono validi o se a un abbonato sono stati applicati filtri inappropriati.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia: **i corpi dei messaggi non validi sono quasi sempre un errore dell'editore. Si consiglia di impostare la soglia su 0 perché in un sistema integro non sono previsti messaggi non validi.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsRedrivenToDlq**
**Dimensioni:** TopicName
**Descrizione dell'allarme: **questo allarme aiuta a monitorare il numero di messaggi che vengono spostati in una coda DLQ.
**Scopo: **l'allarme viene utilizzato per rilevare i messaggi che vengono spostati in una coda DLQ. Ti consigliamo di creare questo allarme quando SNS è abbinato a SQS, Lambda o Firehose.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia: **in un sistema integro, indipendentemente dal tipo di abbonato, i messaggi non devono essere spostati nella coda DLQ. Ti consigliamo di ricevere una notifica se qualche messaggio finisce nella coda, in modo da poter identificare e risolvere la causa principale e, potenzialmente, reindirizzare i messaggi nella coda DLQ per evitare la perdita di dati.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFailedToRedriveToDlq**
**Dimensioni:** TopicName
**Descrizione dell'allarme: **questo allarme aiuta a monitorare i messaggi che non possono essere spostati in una coda DLQ. Controlla se la tua coda DLQ esiste e che sia configurata correttamente. Inoltre, verifica che SNS disponga delle autorizzazioni per accedere alla coda DLQ. Per ulteriori informazioni, consulta la [documentazione sulle code DLQ](https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html).
**Scopo: **l'allarme viene utilizzato per rilevare i messaggi che non possono essere spostati in una coda DLQ.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia: **è quasi sempre un errore se i messaggi non possono essere spostati nella coda DLQ. La soglia raccomandata è 0, il che significa che tutti i messaggi che non vengono elaborati devono essere in grado di raggiungere la coda DLQ quando la coda è stata configurata.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**SMSMonthToDateSpentUSD**
**Dimensioni:** TopicName
**Descrizione dell'allarme: **l'allarme aiuta a controllare se nell'account è disponibile una quota sufficiente per consentire a SNS di consegnare i messaggi. Se raggiungi la quota, SNS non sarà in grado di consegnare messaggi SMS. Per informazioni sull'impostazione della quota di spesa mensile per gli SMS o per informazioni sulla richiesta di un aumento della quota di spesa con AWS, consulta [Impostazione delle preferenze per i messaggi SMS](https://docs.aws.amazon.com/sns/latest/dg/sms_preferences.html).
**Scopo:** questo allarme viene utilizzato per rilevare se la quota dell'account è sufficiente per garantire la corretta consegna dei tuoi messaggi SMS.
**Statistica: **Maximum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia in base alla quota (limite di spesa dell'account) per l'account. Scegli una soglia che ti informi con sufficiente anticipo del raggiungimento del limite di quota, in modo da avere il tempo di richiedere un aumento.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
**SMSSuccessTariffa**
**Dimensioni:** TopicName
**Descrizione dell'allarme: **questo allarme aiuta a monitorare il tasso di mancata consegna dei messaggi SMS. Puoi configurare [File di log CloudWatch](https://docs.aws.amazon.com/sns/latest/dg/sms_stats_cloudwatch.html) per comprendere la natura dell'errore e agire di conseguenza.
**Scopo: **questo allarme viene utilizzato per rilevare le mancate consegne di messaggi SMS.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **imposta la soglia per l'allarme in base alla tua tolleranza in caso di mancata consegna dei messaggi SMS.
**Periodo: **60
**Punti dati su cui attivare allarmi: **5
**Periodi di valutazione: **5
**Operatore di confronto: **GREATER\$1THAN\$1THRESHOLD
## Amazon SQS
**ApproximateAgeOfOldestMessage**
**Dimensioni:** QueueName
**Descrizione dell'allarme: **questo allarme rileva l'età del messaggio più vecchio nella coda. È possibile utilizzare questo allarme per verificare se i consumatori elaborano i messaggi SQS alla velocità desiderata. Valuta la possibilità di aumentare il numero di consumatori o la velocità di trasmissione effettiva degli stessi per ridurre l'età dei messaggi. Questo parametro può essere utilizzato in combinazione con `ApproximateNumberOfMessagesVisible` per determinare l'entità del backlog della coda e la velocità di elaborazione dei messaggi. Per evitare che i messaggi vengano eliminati prima dell'elaborazione, prendi in considerazione la possibilità di configurare la coda DLQ in modo da mettere da parte i potenziali messaggi avvelenati.
**Intento:** questo allarme viene utilizzato per rilevare se l'età del messaggio più vecchio nella QueueName coda è troppo alta. L'età elevata può indicare che i messaggi non vengono elaborati abbastanza velocemente o che alcuni messaggi avvelenanti sono bloccati in coda e non possono essere elaborati.
**Statistica: **Maximum
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dal tempo previsto per l'elaborazione del messaggio. È possibile utilizzare i dati storici per calcolare il tempo medio di elaborazione dei messaggi e quindi impostare la soglia su un valore del 50% superiore al tempo massimo di elaborazione dei messaggi SQS previsto dai consumatori in coda.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ApproximateNumberOfMessagesNotVisible**
**Dimensioni:** QueueName
**Descrizione dell'allarme: **questo allarme aiuta a rilevare un numero elevato di messaggi in transito relativamente a `QueueName`. Per la risoluzione dei problemi, consulta la sezione sulla [riduzione del backlog dei messaggi](https://repost.aws/knowledge-center/sqs-message-backlog).
**Scopo: **questo allarme viene utilizzato per rilevare un numero elevato di messaggi in transito nella coda. Se i consumatori non eliminano i messaggi entro il periodo di timeout di visibilità, quando avviene il polling della coda, i messaggi riappaiono nella coda. Per le code FIFO, possono esserci al massimo 20.000 messaggi in transito. Se raggiungi questa quota, SQS non restituisce alcun messaggio di errore. Una coda FIFO esamina i primi 20.000 messaggi per determinare i gruppi di messaggi disponibili. Ciò significa che se in un singolo gruppo di messaggi è presente un backlog, non è possibile utilizzare i messaggi provenienti da altri gruppi di messaggi inviati successivamente alla coda fino a quando non si gestisce correttamente il backlog.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia:** il valore di soglia raccomandato per questo allarme dipende in larga misura dal numero previsto di messaggi in transito. È possibile utilizzare i dati storici per calcolare il numero massimo previsto di messaggi in transito e impostare una soglia del 50% superiore a questo valore. Se i consumatori della coda elaborano i messaggi della coda ma non li eliminano, questo numero aumenterà improvvisamente.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ApproximateNumberOfMessagesVisible**
**Dimensioni:** QueueName
**Descrizione dell'allarme: **questo allarme rileva se il backlog della coda di messaggi è maggiore del previsto, indicando che i consumatori sono troppo lenti o che il loro numero è insufficiente. Se l'allarme entra nello stato ALARM, valuta la possibilità di aumentare il numero di consumatori o di velocizzarli.
**Scopo: **questo allarme viene utilizzato per rilevare se il numero di messaggi della coda attiva è troppo elevato e i consumatori sono lenti nell'elaborazione dei messaggi o se non sono sufficienti per la loro elaborazione.
**Statistica: **Average
**Soglia raccomandata: **dipende dalla situazione
**Giustificazione della soglia: **un numero inaspettatamente elevato di messaggi visibili indica che i messaggi non vengono elaborati da un consumatore alla velocità prevista. È consigliabile analizzare i dati storici per impostare questa soglia.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**NumberOfMessagesSent**
**Dimensioni:** QueueName
**Descrizione dell'allarme: **questo allarme aiuta a rilevare se non ci sono messaggi inviati da un produttore in merito a `QueueName`. Per la risoluzione dei problemi, controlla il motivo per cui il produttore non invia messaggi.
**Scopo: **questo allarme viene utilizzato per rilevare quando un produttore interrompe l'invio di messaggi.
**Statistica: **Sum
**Soglia raccomandata: **0,0
**Giustificazione della soglia: **se il numero di messaggi inviati è 0, il produttore non invia alcun messaggio. Se questa coda ha un TPS basso, aumenta il numero di EvaluationPeriods conseguenza.
**Periodo: **60
**Punti dati su cui attivare allarmi: **15
**Periodi di valutazione: **15
**Operatore di confronto: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Site-to-Site VPN
**TunnelState**
**Dimensioni:** VpnId
**Descrizione dell'allarme: **questo allarme permette di capire se lo stato di uno o più tunnel è DOWN. Per la risoluzione dei problemi, consulta la pagina [VPN tunnel troubleshooting](https://repost.aws/knowledge-center/vpn-tunnel-troubleshooting).
**Scopo: **questo allarme viene utilizzato per rilevare se almeno un tunnel è in stato DOWN per questa VPN, in modo da poter risolvere i problemi relativi alla VPN interessata. Questo allarme sarà sempre nello stato ALARM per le reti in cui è configurato un solo tunnel.
**Statistica: **Minimum
**Soglia raccomandata: **1,0
**Giustificazione della soglia: **un valore inferiore a 1 indica che almeno un tunnel è in stato DOWN.
**Periodo: **300
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
**TunnelState**
**Dimensioni:** TunnelIpAddress
**Descrizione dell'allarme: **questo allarme permette di capire se lo stato di questo tunnel è DOWN. Per la risoluzione dei problemi, consulta la pagina [VPN tunnel troubleshooting](https://repost.aws/knowledge-center/vpn-tunnel-troubleshooting).
**Scopo: **questo allarme viene utilizzato per rilevare se il tunnel è in stato DOWN, in modo da poter risolvere i problemi relativi alla VPN interessata. Questo allarme sarà sempre nello stato ALARM per le reti in cui è configurato un solo tunnel.
**Statistica: **Minimum
**Soglia raccomandata: **1,0
**Giustificazione della soglia: **un valore inferiore a 1 indica che il tunnel è in stato DOWN.
**Periodo: **300
**Punti dati su cui attivare allarmi: **3
**Periodi di valutazione: **3
**Operatore di confronto: **LESS\$1THAN\$1THRESHOLD
# Casi d'uso degli allarmi ed esempi
Le sezioni seguenti forniscono esempi e tutorial sugli allarmi per casi d'uso comuni.
**Topics**
+ [Crea un allarme di fatturazione per monitorare gli addebiti stimati AWS](monitor_estimated_charges_with_cloudwatch.md)
+ [Creazione di un allarme legato all'utilizzo della CPU](US_AlarmAtThresholdEC2.md)
+ [Creazione di un allarme di latenza per il sistema di bilanciamento del carico che invia e-mail](US_AlarmAtThresholdELB.md)
+ [Creazione di un allarme della velocità di trasmissione effettiva dell'archiviazione che invia e-mail](US_AlarmAtThresholdEBS.md)
+ [Crea un allarme sulle metriche dei contatori di Performance Insights da un database AWS](CloudWatch_alarm_database_performance_insights.md)
# Crea un allarme di fatturazione per monitorare gli addebiti stimati AWS
Puoi monitorare i AWS costi stimati utilizzando Amazon CloudWatch. Quando abiliti il monitoraggio degli addebiti stimati per il tuo AWS account, gli addebiti stimati vengono calcolati e inviati più volte al giorno CloudWatch come dati metrici.
I dati dei parametri di fatturazione sono archiviati nella regione Stati Uniti orientali (Virginia settentrionale) e rappresentano i costi a livello mondiale. Questi dati includono i costi stimati per ogni servizio utilizzato, oltre al totale stimato dei AWS costi. AWS
L'allarme scatta nel momento in cui la fatturazione dell'account supera il limite specificato. Viene attivato solo quando la fatturazione attuale supera la soglia. Non utilizza proiezioni in base all'utilizzo fino a un momento specifico nel mese.
Se si crea un allarme di fatturazione nel momento in cui i costi hanno già superato la soglia, l'allarme passa allo stato `ALARM` immediatamente.
**Nota**
Per informazioni sull'analisi degli CloudWatch addebiti che ti sono già stati fatturati, consulta. [Analisi, ottimizzazione e riduzione dei costi CloudWatch](cloudwatch_billing.md)
**Topics**
+ [Attivazione di avvisi di fatturazione](#turning_on_billing_metrics)
+ [Creazione di un allarme di fatturazione](#creating_billing_alarm_with_wizard)
+ [Eliminazione di un allarme di fatturazione](#deleting_billing_alarm)
## Attivazione di avvisi di fatturazione
Prima di poter creare un allarme per gli addebiti stimati, è necessario abilitare gli avvisi di fatturazione, in modo da poter monitorare gli AWS addebiti stimati e creare un allarme utilizzando i dati metrici di fatturazione. Dopo aver attivato gli avvisi di fatturazione, non è possibile disabilitare la raccolta di dati, ma è possibile eliminare qualsiasi allarme di fatturazione creato.
Dopo aver attivato gli avvisi di fatturazione per la prima volta, sono necessari circa 15 minuti prima di visualizzare i dati di fatturazione e di impostare gli allarmi di fatturazione.
**Requisiti**
+ È necessario aver effettuato l'accesso utilizzando le credenziali dell'utente root dell'account o come utente IAM a cui è stata concessa l'autorizzazione per visualizzare le informazioni di fatturazione.
+ Per gli account di fatturazione consolidata, puoi individuare i dati di fatturazione di ciascun account collegato accedendo come account di pagamento. Puoi visualizzare i dati di fatturazione per i costi stimati totali e i costi stimati per servizio per ogni account collegato aggiunto all'account consolidato.
+ In un conto di fatturazione consolidato, le metriche degli account collegati ai membri vengono acquisite solo se il conto pagatore abilita la preferenza **Ricevi avvisi di fatturazione**. Se cambi l'account del tuo management/payer account, devi abilitare gli avvisi di fatturazione nel nuovo account. management/payer
+ L'account non deve far parte dell'Amazon Partner Network (APN) perché le metriche di fatturazione non vengono pubblicate sugli account APN. CloudWatch Per ulteriori informazioni, consulta la pagina [Partner Network AWS](https://aws.amazon.com/partners/).
**Attivazione del monitoraggio dei costi stimati**
1. Apri la console all'indirizzo. Gestione dei costi e fatturazione AWS [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/)
1. Nel riquadro di navigazione, scegli **Billing preferences (Preferenze di fatturazione)**.
1. Per **Preferenze di avviso**, scegli **Modifica**.
1. Scegli **Ricevi avvisi di CloudWatch fatturazione**.
1. Scegli **Save preferences** (Salva preferenze).
## Creazione di un allarme di fatturazione
**Importante**
Prima di creare un allarme di fatturazione, imposta la regione su Stati Uniti orientali (Virginia settentrionale). I dati dei parametri di fatturazione sono archiviati in questa regione e rappresentano i costi a livello mondiale. È inoltre necessario abilitare gli avvisi di fatturazione per il proprio account o nell' management/payer account (se si utilizza la fatturazione consolidata). Per ulteriori informazioni, consulta [Attivazione di avvisi di fatturazione](#turning_on_billing_metrics).
In questa procedura, crei un allarme che invia una notifica quando gli addebiti stimati AWS superano una soglia definita.
**Per creare un allarme di fatturazione utilizzando la console CloudWatch**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), quindi **Create alarm** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **Seleziona metrica**. In **Namespace AWS **, scegli **Fatturazione**, quindi seleziona **Addebito totale stimato**.
**Nota**
Se non visualizzi il parametro **Fatturazione**/**Addebito totale stimato**, abilita gli avvisi di fatturazione e passa alla Regione Stati Uniti orientali (Virginia settentrionale). Per ulteriori informazioni, consulta [Attivazione di avvisi di fatturazione](#turning_on_billing_metrics).
1. Seleziona la casella per la **EstimatedCharges**metrica, quindi scegli **Seleziona metrica**.
1. Per **Statistic (Statistica)**, scegli **Maximum (Massima)**.
1. Per **Period** (Periodo), scegli **6 hours** (6 ore).
1. For **Threshold type (Tipo di soglia)**, scegli **Static (Statica)**.
1. Per ** EstimatedCharges Whenever is..** , scegli **Maggiore**.
1. Per **than . . .**, definisci il valore che desideri attivi l'allarme. Per un esempio, **200** USD.
I valori delle **EstimatedCharges**metriche sono solo in dollari USA (USD) e la conversione di valuta è fornita da Amazon Services LLC. Per ulteriori informazioni, consulta [Cos'è AWS Billing?](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html)
**Nota**
Dopo aver definito un valore di soglia, il grafico di anteprima mostra i costi stimati per il mese corrente.
1. Scegli **Configurazione aggiuntiva** e completa le seguenti operazioni:
+ In **Datapoints to alarm** (Data point per allarme), specifica **1 out of 1** (1 su 1).
+ In **Missing data treatment** (Trattamento dei dati mancanti), scegli **Treat missing data as missing** (Tratta i dati mancanti come mancanti).
1. Scegli **Next (Successivo)**.
1. In **Notifica**, assicurati che sia selezionata l'opzione **In allarme**. Quindi, specifica un argomento Amazon SNS per segnalare quando l'allarme si trova nello stato `ALARM`. L'argomento Amazon SNS può includere il tuo indirizzo e-mail in modo da ricevere un messaggio e-mail quando l'importo della fatturazione supera la soglia specificata.
Puoi selezionare un argomento Amazon SNS esistente, crearne uno nuovo o utilizzare un ARN dell'argomento per inviare una notifica a un altro account. Se vuoi che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi, scegli **Add notification** (Aggiungi notifica).
1. Scegli **Next (Successivo)**.
1. In **Name and description** (Nome e descrizione), immetti un nome per l'allarme. Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII.
1. (Facoltativo) Immetti una descrizione per l'allarme. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella scheda **Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
1. Scegli **Next (Successivo)**.
1. In **Preview and create** (Anteprima e creazione), verifica che la configurazione sia corretta, quindi seleziona **Create alarm** (Crea allarme).
## Eliminazione di un allarme di fatturazione
Puoi eliminare l'allarme di fatturazione quando non è più necessario.
**Per eliminare un allarme di fatturazione**
1. Apri la CloudWatch console all'indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Se necessario modifica la regione in Stati Uniti orientali (Virginia settentrionale). I dati dei parametri di fatturazione sono archiviati in questa regione e riflettono i costi mondiali.
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All alarms** (Tutti gli allarmi).
1. Seleziona la casella di controllo accanto all'allarme e scegli **Actions** (Operazioni), **Delete** (Elimina).
1. Quando viene richiesta la conferma, seleziona **Yes, Delete** (Sì, elimina).
# Creazione di un allarme legato all'utilizzo della CPU
Puoi creare un CloudWatch allarme che invia una notifica utilizzando Amazon SNS quando lo stato dell'allarme cambia da a`OK`. `ALARM`
L'allarme modifica lo stato in `ALARM` quando l'utilizzo medio della CPU di un'istanza EC2 supera una specifica soglia per determinati periodi consecutivi.
## Configurazione di un allarme relativo all'utilizzo della CPU utilizzando il Console di gestione AWS
Usa questi passaggi per Console di gestione AWS creare un allarme sull'utilizzo della CPU.
**Per creare un allarme basato sull'utilizzo della CPU**
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All Alarms** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **Seleziona metrica**.
1. Nella scheda **Tutte le metriche** scegli **Parametri EC2**.
1. Scegli una categoria di parametri (ad esempio, **Per-Instance Metrics**).
1. Trova la riga con l'istanza che desideri venga elencata nella **InstanceId**colonna e **CPUUtilization**nella colonna **Metric Name**. Seleziona la casella di controllo accanto a questa riga e scegli **Seleziona metrica**.
1. In **Specifica metrica e condizioni**, per **Statistica** scegli **Media**, scegli uno dei percentili predefiniti oppure specifichi un percentile personalizzato (ad esempio **p95.45**).
1. Seleziona un periodo (ad esempio, **5 minutes**).
1. In **Conditions** (Condizioni), specifica quanto segue:
1. For **Threshold type (Tipo di soglia)**, scegli **Static (Statica)**.
1. Per **Whenever CPUUtilization is**, specifica **Greater**. In **di...**, specificare la soglia che deve attivare l'avviso per passare allo stato ALARM se l'utilizzo della CPU supera questa percentuale. Ad esempio, 70.
1. Scegli **Additional configuration** (Configurazione aggiuntiva). In **Datapoints to Alarm** (Punti dati all'allarme), specifica il numero di periodi di valutazione (punti dati) che devono essere nello stato `ALARM` per attivare l'allarme. Se i due valori corrispondono, crea un allarme che passa nello stato `ALARM` se si verifica una violazione durante tali periodi consecutivi.
Per creare un allarme M di N, specifica un numero minore per il primo valore rispetto a quello specificato per il secondo valore. Per ulteriori informazioni, consulta la pagina [Valutazione degli allarmi](alarm-evaluation.md).
1. Per **Missing data treatment** (Trattamento dati mancanti), scegli la modalità di comportamento dell'allarme quando mancano alcuni punti dati. Per ulteriori informazioni, consulta la pagina [Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](alarms-and-missing-data.md).
1. Se l'allarme utilizza un percentile come statistica monitorata, viene visualizzata una casella **Percentiles with low samples** (Percentili con campioni ridotti). Utilizzala per scegliere se valutare o ignorare casi con bassa frequenza di campionamento. Se scegli **ignore (maintain alarm state) (ignora (mantieni stato dell'allarme))**, lo stato corrente dell'allarme viene sempre mantenuto quando la dimensione dell'esempio è troppo bassa. Per ulteriori informazioni, consulta la pagina [Allarmi basati su percentile ed esempi di dati ridotti](percentiles-with-low-samples.md).
1. Scegli **Next (Successivo)**.
1. In **Notifica**, scegli **In allarme** e seleziona un argomento SNS per notificare quando l'avviso è in stato `ALARM`
Per fare in modo che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi, scegli **Add notification** (Aggiungi notifica).
Per fare in modo che l'allarme non invii notifiche, scegli **Remove** (Rimuovi).
1. Al termine, scegli **Apply** (Applica).
1. Inserisci un nome e una descrizione per l'allarme. Quindi scegli **Successivo**.
Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella scheda **Dettagli** dell'allarme nella CloudWatch console. Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
1. In **Preview and create** (Visualizza anteprima e crea), conferma che le informazioni e le condizioni sono quelle desiderate, quindi scegli **Create alarm** (Crea allarme).
## Impostazione di un allarme relativo all'utilizzo della CPU utilizzando il AWS CLI
Usa questi passaggi per AWS CLI creare un allarme sull'utilizzo della CPU.
**Per creare un allarme basato sull'utilizzo della CPU**
1. Imposta un argomento SNS. Per ulteriori informazioni, consulta [Impostazione delle notifiche Amazon SNS](Notify_Users_Alarm_Changes.md#US_SetupSNS).
1. Crea un allarme utilizzando il [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html)comando seguente.
```
aws cloudwatch put-metric-alarm --alarm-name cpu-mon --alarm-description "Alarm when CPU exceeds 70%" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 70 --comparison-operator GreaterThanThreshold --dimensions Name=InstanceId,Value=i-12345678 --evaluation-periods 2 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-topic --unit Percent
```
1. Prova l'allarme forzando la modifica dello stato dell'allarme utilizzando il [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html)comando.
1. Modifica lo stato di un allarme da `INSUFFICIENT_DATA` a `OK`.
```
aws cloudwatch set-alarm-state --alarm-name cpu-mon --state-reason "initializing" --state-value OK
```
1. Modifica lo stato di un allarme da `OK` a `ALARM`.
```
aws cloudwatch set-alarm-state --alarm-name cpu-mon --state-reason "initializing" --state-value ALARM
```
1. Verifica di aver ricevuto una notifica sull'allarme.
# Creazione di un allarme di latenza per il sistema di bilanciamento del carico che invia e-mail
Puoi impostare una notifica Amazon SNS e configurare un allarme che monitora la latenza che supera i 100 ms per Classic Load Balancer.
## Impostazione di un allarme di latenza utilizzando il Console di gestione AWS
Usa questi passaggi per creare un allarme Console di gestione AWS di latenza del load balancer.
**Per creare un allarme di latenza per il load balancer**
1. Apri la CloudWatch console all'indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All Alarms** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. In **CloudWatch Metriche per categoria**, scegli la categoria **Metriche ELB**.
1. Seleziona la riga con il sistema Classic Load Balancer e il parametro **Latency** (Latenza).
1. Per la statistica, scegli **Average (Media)**, seleziona uno dei percentili predefiniti oppure specifica un percentile personalizzato (ad esempio, **p95.45**).
1. Per il periodo, scegli **1 Minute (1 minuto)**.
1. Scegli **Next (Successivo)**.
1. In **Alarm Threshold (Soglia di allarme)**, immetti un nome univoco per l'allarme (ad esempio, **myHighCpuAlarm**) e una descrizione dell'allarme (ad esempio, **Alarm when Latency exceeds 100s**). I nomi degli allarmi devono contenere solo caratteri UTF-8 e non possono contenere caratteri di controllo ASCII
Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella **scheda Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
1. In **Whenever (Ogni volta che)**, per **is (è)**, scegli **>** e immetti **0.1**. In **for (per)**, immetti **3**.
1. In **Additional settings (Impostazioni aggiuntive)**, per **Treat missing data as (Tratta i dati mancanti come)**, seleziona **ignore (maintain alarm state) (ignora (mantieni lo stato dell'allarme))**, in modo tale che i punti dati mancanti non attivino le modifiche di stato dell'allarme.
In **Percentiles with low samples (Percentili con campioni ridotti)**, scegli **ignore (maintain the alarm state) (ignora (mantieni lo stato dell'allarme))** in modo che l'allarme consideri solo situazioni con un numero sufficiente di esempi di dati.
1. In **Actions** (Operazioni), in **Whenever this alarm** (Ogni volta che questo allarme), scegli **State is ALARM** (Lo stato è ALLARME). Per **Send notification to** (Invia notifica a), scegli un argomento SNS esistente o creane uno nuovo.
Per creare un argomento SNS, seleziona **New list (Nuovo elenco)**. Per **Send notification to (Invia notifica a)** immetti un nome per l'argomento SNS (ad esempio, **myHighCpuAlarm**) e per **Email list (Elenco e-mail)** immetti un elenco di indirizzi e-mail separati da virgola a cui inviare una notifica quando l'allarme passa nello stato `ALARM`. Viene inviato a ciascun indirizzo un'e-mail di conferma della sottoscrizione all'argomento. È necessario confermare l'abbonamento prima del possibile invio delle notifiche.
1. Scegli **Create Alarm** (Crea allarme).
## Impostazione di un allarme di latenza utilizzando il AWS CLI
Usa questi passaggi per creare un allarme AWS CLI di latenza del load balancer.
**Per creare un allarme di latenza per il load balancer**
1. Imposta un argomento SNS. Per ulteriori informazioni, consulta [Impostazione delle notifiche Amazon SNS](Notify_Users_Alarm_Changes.md#US_SetupSNS).
1. Crea l'allarme utilizzando il [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html)comando seguente:
```
1. aws cloudwatch put-metric-alarm --alarm-name lb-mon --alarm-description "Alarm when Latency exceeds 100s" --metric-name Latency --namespace AWS/ELB --statistic Average --period 60 --threshold 100 --comparison-operator GreaterThanThreshold --dimensions Name=LoadBalancerName,Value=my-server --evaluation-periods 3 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-topic --unit Seconds
```
1. Verifica l'allarme forzando la modifica dello stato dell'allarme utilizzando il [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html)comando.
1. Modifica lo stato di un allarme da `INSUFFICIENT_DATA` a `OK`.
```
1. aws cloudwatch set-alarm-state --alarm-name lb-mon --state-reason "initializing" --state-value OK
```
1. Modifica lo stato di un allarme da `OK` a `ALARM`.
```
1. aws cloudwatch set-alarm-state --alarm-name lb-mon --state-reason "initializing" --state-value ALARM
```
1. Verifica di aver ricevuto una notifica tramite e-mail sull'allarme.
# Creazione di un allarme della velocità di trasmissione effettiva dell'archiviazione che invia e-mail
Puoi impostare una notifica di SNS e configurare un allarme che si attiva quando Amazon EBS supera 100 MB di throughput.
## Impostazione di un allarme di throughput di archiviazione utilizzando il Console di gestione AWS
Utilizza questi passaggi per Console di gestione AWS creare un allarme basato sul throughput di Amazon EBS.
**Per creare un allarme del throughput dello storage**
1. Apri la CloudWatch console all'indirizzo. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), **All Alarms** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. In **EBS Metrics** (Parametri di EBS), scegli la categoria di un parametro.
1. Seleziona la riga con il volume e la **VolumeWriteBytes**metrica.
1. Per la statistica, scegli **Average** (Media). Per il periodo, scegli **5 Minute** (5 minuto). Scegli **Next (Successivo)**.
1. In **Alarm Threshold (Soglia di allarme)**, immetti un nome univoco per l'allarme (ad esempio, **myHighWriteAlarm**) e una descrizione dell'allarme (ad esempio, **VolumeWriteBytes exceeds 100,000 KiB/s**). Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella scheda **Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
1. In **Whenever (Ogni volta che)**, per **is (è)**, scegli **>** e immetti **100000**. Per **for (per)**, immetti **15** periodi consecutivi.
Viene visualizzata una rappresentazione grafica della soglia in **Alarm Preview** (Anteprima allarme).
1. In **Additional settings (Impostazioni aggiuntive)**, per **Treat missing data as (Tratta i dati mancanti come)**, seleziona **ignore (maintain alarm state) (ignora (mantieni lo stato dell'allarme))**, in modo tale che i punti dati mancanti non attivino le modifiche di stato dell'allarme.
1. In **Actions** (Operazioni), in **Whenever this alarm** (Ogni volta che questo allarme), scegli **State is ALARM** (Lo stato è ALLARME). Per **Send notification to** (Invia notifica a), scegli un argomento SNS esistente o creane uno nuovo.
Per creare un argomento SNS, seleziona **New list (Nuovo elenco)**. Per **Send notification to (Invia notifica a)** immetti un nome per l'argomento SNS (ad esempio, **myHighCpuAlarm**) e per **Email list (Elenco e-mail)** immetti un elenco di indirizzi e-mail separati da virgola a cui inviare una notifica quando l'allarme passa nello stato `ALARM`. Viene inviato a ciascun indirizzo un'e-mail di conferma della sottoscrizione all'argomento. È necessario confermare la sottoscrizione prima che le notifiche possano essere inviate a un indirizzo e-mail.
1. Scegli **Crea allarme**.
## Configurazione di un allarme di throughput di archiviazione utilizzando il AWS CLI
Utilizza questi passaggi per AWS CLI creare un allarme basato sul throughput di Amazon EBS.
**Per creare un allarme del throughput dello storage**
1. Creare un argomento SNS. Per ulteriori informazioni, consulta la pagina [Impostazione delle notifiche Amazon SNS](Notify_Users_Alarm_Changes.md#US_SetupSNS).
1. Crea l'allarme.
```
1. aws cloudwatch put-metric-alarm --alarm-name ebs-mon --alarm-description "Alarm when EBS volume exceeds 100MB throughput" --metric-name VolumeReadBytes --namespace AWS/EBS --statistic Average --period 300 --threshold 100000000 --comparison-operator GreaterThanThreshold --dimensions Name=VolumeId,Value=my-volume-id --evaluation-periods 3 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-alarm-topic --insufficient-data-actions arn:aws:sns:us-east-1:111122223333:my-insufficient-data-topic
```
1. Testa l'allarme forzando la modifica dello stato dell'allarme utilizzando il [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html)comando.
1. Modifica lo stato di un allarme da `INSUFFICIENT_DATA` a `OK`.
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value OK
```
1. Modifica lo stato di un allarme da `OK` a `ALARM`.
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value ALARM
```
1. Modifica lo stato di un allarme da `ALARM` a `INSUFFICIENT_DATA`.
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value INSUFFICIENT_DATA
```
1. Verifica di aver ricevuto una notifica tramite e-mail sull'allarme.
# Crea un allarme sulle metriche dei contatori di Performance Insights da un database AWS
CloudWatch include una funzione matematica di metrica **DB\$1PERF\$1INSIGHTS** che puoi utilizzare per importare i parametri dei contatori di Performance Insights da Amazon Relational Database CloudWatch Service e Amazon DocumentDB (con compatibilità MongoDB). **DB\$1PERF\$1INSIGHTS** introduce il parametro `DBLoad` anche a intervalli inferiori al minuto. Puoi CloudWatch impostare allarmi in base a questi parametri.
Per ulteriori informazioni su Approfondimenti sulle prestazioni di Amazon RDS, consulta [Utilizzo di Approfondimenti sulle prestazioni di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
Per ulteriori informazioni su Approfondimenti sulle prestazioni di Amazon DocumentDB, consulta [Monitoraggio con Approfondimenti sulle prestazioni](https://docs.aws.amazon.com/documentdb/latest/developerguide/performance-insights.html.html).
Il rilevamento delle anomalie non è supportato per gli allarmi basati sulla funzione **DB\$1PERF\$1INSIGHTS**.
**Nota**
Le metriche ad alta risoluzione con granularità inferiore al minuto recuperate da **DB\$1PERF\$1INSIGHTS** sono applicabili solo alla metrica o alle **DBLoad**metriche del sistema operativo se hai abilitato il monitoraggio avanzato a una risoluzione più elevata. Per ulteriori informazioni sul monitoraggio avanzato di Amazon RDS, consulta [Monitoraggio dei parametri del sistema operativo con il monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html).
È possibile creare un allarme ad alta risoluzione utilizzando la funzione **DB\$1PERF\$1INSIGHTS**. L'intervallo di valutazione massimo per un allarme ad alta risoluzione è di tre ore. **Puoi utilizzare la CloudWatch console per rappresentare graficamente le metriche recuperate con la funzione DB\$1PERF\$1INSIGHTS per qualsiasi intervallo di tempo.**
**Creazione di un allarme basato sui parametri di Approfondimenti sulle prestazioni**
1. Apri la [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)console all'indirizzo. CloudWatch
1. Nel pannello di navigazione, scegli **Alarms** (Allarmi), quindi **Create alarm** (Tutti gli allarmi).
1. Scegli **Crea allarme**.
1. Scegli **Select Metric** (Seleziona parametro).
1. Scegli il menu a discesa **Aggiungi formula**, quindi seleziona **Tutte le funzioni**, **DB\$1PERF\$1INSIGHTS** dall'elenco.
Dopo aver scelto **DB\$1PERF\$1INSIGHTS**, viene visualizzata una casella di espressione matematica in cui applicare o modificare le espressioni matematiche.
1. Inserisci l'espressione matematica **DB\$1PERF\$1INSIGHTS** nella relativa casella, quindi scegli **Applica**.
Ad esempio, **DB\$1PERF\$1INSIGHTS(‘RDS’, ‘db-ABCDEFGHIJKLMNOPQRSTUVWXY1’, ‘os.cpuUtilization.user.avg’)**
**Importante**
Quando si utilizza l'espressione matematica **DB\$1PERF\$1INSIGHTS**, è necessario specificare l'ID univoco della risorsa del database. È diverso dall'identificatore del database. Per trovare l'ID della risorsa del database nella console Amazon RDS, scegli l'istanza database per vederne i dettagli. Quindi seleziona la scheda **Configurazione**. **ID risorsa** è visualizzato nella sezione **Configurazione**.
Per informazioni sulla funzione **DB\$1PERF\$1INSIGHTS** e su altre funzioni disponibili per la formula dei parametri, consulta [Sintassi e funzioni della matematica dei parametri](using-metric-math.md#metric-math-syntax).
1. Scegli **Seleziona metrica**.
Viene visualizzata la pagina **Specify metric and conditions** (Specifica parametro e condizioni), contenente un grafico e altre informazioni relative all'espressione matematica selezionata.
1. Per **Whenever *expression* is**, specifica se l'espressione deve essere maggiore, minore o uguale alla soglia. In **than... (che...)**, specifica il valore di soglia.
1. Scegli **Additional configuration** (Configurazione aggiuntiva). In **Datapoints to Alarm** (Punti dati all'allarme), specifica il numero di periodi di valutazione (punti dati) che devono essere nello stato `ALARM` per attivare l'allarme. Se i due valori corrispondono, crea un allarme che passa nello stato `ALARM` se si verifica una violazione durante tali periodi consecutivi.
Per creare un allarme M di N, specifica un numero minore per il primo valore rispetto a quello specificato per il secondo valore. Per ulteriori informazioni, consulta la pagina [Valutazione degli allarmi](alarm-evaluation.md).
1. Per **Missing data treatment** (Trattamento dati mancanti), scegli la modalità di comportamento dell'allarme quando mancano alcuni punti dati. Per ulteriori informazioni, consulta la pagina [Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti](alarms-and-missing-data.md).
1. Scegli **Next (Successivo)**.
1. In **Notification** (Notifica), seleziona un argomento SNS per segnalare quando l'allarme è nello stato `ALARM`, `OK` o `INSUFFICIENT_DATA`.
Per fare in modo che l'allarme invii più notifiche per lo stesso stato di allarme o per stati di allarme diversi, scegli **Add notification** (Aggiungi notifica).
Per fare in modo che l'allarme non invii notifiche, scegli **Remove** (Rimuovi).
1. Per fare in modo che l'allarme esegua operazioni Auto Scaling, EC2, Lambda o Systems Manager scegli il pulsante appropriato e scegli lo stato di allarme e l'operazione da eseguire. Se scegli una funzione Lambda come operazione di allarme, specifichi il nome della funzione o l'ARN e, facoltativamente, puoi scegliere una versione specifica della funzione.
Gli allarmi possono eseguire le operazioni Systems Manager solo quando entrano nello stato ALARM. Per ulteriori informazioni sulle azioni di Systems Manager, vedere [Configurazione per la creazione CloudWatch OpsItems da allarmi e Creazione](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) di [incidenti](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html).
**Nota**
Per creare un allarme che esegua un'operazione SSM Incident Manager, è necessario disporre di determinate autorizzazioni. Per ulteriori informazioni, vedere [Esempi di policy basate sull'identità per AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html).
1. Al termine, scegli **Apply** (Applica).
1. Inserisci un nome e una descrizione per l'allarme. Quindi scegli **Successivo**.
Il nome deve contenere solo caratteri UTF-8 e non può contenere caratteri di controllo ASCII. La descrizione può includere la formattazione del markdown, che viene visualizzata solo nella **scheda Dettagli** dell'allarme nella console. CloudWatch Il markdown può essere utile per aggiungere collegamenti ai runbook o ad altre risorse interne.
1. In **Preview and create** (Visualizza anteprima e crea), conferma che le informazioni e le condizioni sono quelle desiderate, quindi scegli **Create alarm** (Crea allarme).