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à.
# 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).