Utilizzo di allarmi Amazon CloudWatch - Amazon CloudWatch

Utilizzo di allarmi Amazon CloudWatch

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.

In Amazon CloudWatch è possibile creare allarmi di metrica e compositi.

È possibile creare allarmi sulle query di Approfondimenti sulle metriche che utilizzano tag delle risorse AWS per filtrare e raggruppare le metriche. Per utilizzare i tag con gli allarmi, su https://console.aws.amazon.com/connect/, scegli Impostazioni. Nella pagina Impostazioni di CloudWatch, in Abilita i tag delle risorse sulla telemetria, scegli Abilita. Per un monitoraggio sensibile al contesto che si adatta automaticamente alla tua strategia di applicazione di tag, crea allarmi sulle query di Approfondimenti sulle metriche utilizzando i tag delle risorse AWS. Ciò consente di monitorare tutte le risorse taggate con applicazioni o ambienti specifici.

  • Puoi creare un allarme per un parametro che monitora un singolo parametro CloudWatch o il risultato di un'espressione matematica in base ai parametri 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'operazione può essere l'invio di una notifica a un argomento Amazon SNS, l'esecuzione di un'operazione Amazon EC2 o di un'operazione Amazon EC2 Auto Scaling, l'avvio di un'indagine nelle indagini operative di CloudWatch Investigations, oppure la creazione di un oggetto OpsItem o di un evento imprevisto in Systems Manager.

  • 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 di Amazon SNS quando cambiano stato e possono creare indagini, oggetti OpsItem di Systems Manager o eventi imprevisti quando passano allo stato ALARM, ma non possono eseguire operazioni EC2 oppure Auto Scaling.

Nota

Nel tuo account AWS puoi creare tutti gli allarmi che desideri.

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 contrassegnare come preferiti gli allarmi consultati di recente tramite l'opzione Favorites and recents (Preferiti e recenti) nel riquadro di navigazione della console CloudWatch. 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 più account nella tua console CloudWatch, puoi anche creare allarmi che osservino le metriche in 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 testa o convalida le operazioni che specifichi, né è in grado di rilevare errori di Amazon EC2 Auto Scaling o Amazon SNS risultanti da un tentativo di richiamare operazioni inesistenti. Assicurati che le tue operazioni relative agli allarmi esistano.

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.

Valutazione di un allarme

Quando si crea un allarme, è necessario specificare tre impostazioni per permettere a CloudWatch 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.

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 l'esempio alla fine di questa sezione.

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

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 (Punti di dati all'allarme) è ("M") e Evaluation Periods (Periodi di valutazione) è ("N"). L'intervallo di valutazione è il numero di punti dati moltiplicato per il 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 risultano mancanti subito dopo la creazione di un allarme e il parametro è stato segnalato a CloudWatch prima della creazione dell'allarme, CloudWatch recupera i punti dati più recenti prima della creazione dell'allarme nella fase di valutazione.

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 prende in considerazione solo le 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.

  2. Alle 10:03, l'allarme viene valutato e rimane nello stato OK, poiché la valutazione considera i dati solo fino alle 10:00.

  3. Alle 11:03, l'allarme considera i dati fino alle 11:00 e passa allo stato ALARM.

  4. Alle 11:43, l'errore viene corretto e il processo ora viene eseguito correttamente.

  5. Alle 12:03, l'allarme viene nuovamente valutato, rileva che il processo è riuscito e torna allo stato OK.

Operazioni per gli allarmi

È possibile specificare le operazioni intraprese da un allarme quando cambia stato tra gli stati OK, ALARM e INSUFFICIENT_DATA.

È 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. È possibile sfruttare il fatto che sono consentite più operazioni per un allarme per inviare un'e-mail quando viene superata una soglia e poi un'altra quando la condizione di violazione termina. Ciò consente di verificare che le operazioni di dimensionamento o ripristino vengano attivate quando previsto e funzionino come desiderato.

Le seguenti sono supportate come operazioni di allarme.

Gli allarmi emettono eventi Amazon EventBridge anche quando cambiano stato ed è possibile configurare Amazon EventBridge in modo da attivare altre operazioni per questi cambiamenti di stato. Per ulteriori informazioni, consulta Cos'è Amazon EventBridge?

Configurazione della modalità in cui gli allarmi CloudWatch trattano i dati mancanti

A volte, non tutti i punti di dati previsti per un parametro vengono segnalati a 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 permette 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.

Così come ogni allarme si trova sempre in uno dei tre stati, ogni punto dati specifico segnalato a CloudWatch rientra in una di queste tre categorie:

  • Non superato (entro la soglia)

  • Superato (fuori dalla soglia)

  • Mancante

Per ogni allarme, è possibile specificare che CloudWatch deve trattare i punti dati mancanti in uno dei modi seguenti:

  • 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_DATA.

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_DATA 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 i parametri nelloAWS/DynamoDBspazio dei nomi ignorano sempre i dati mancanti anche se si sceglie un'opzione diversa per il modo in cui l'allarme dovrebbe trattare i dati mancanti. Quando unAWS/DynamoDBparametro 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 modificare lo stato, CloudWatch tenta di recuperare un maggior numero di punti dati rispetto al numero specificato come Evaluation Periods (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.

Quando CloudWatch recupera questi punti dati, si verifica quanto segue:

  • Se non ci sono punti dati mancanti nell'intervallo di valutazione, CloudWatch valuta l'allarme in base ai punti dati raccolti più recenti. 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 alcuni punti dati nell'intervallo di valutazione risultano mancanti, ma il numero totale di punti dati esistenti correttamente recuperati dall'intervallo di valutazione è uguale o superiore a quanto specificato in Evaluation Periods (Periodi di valutazione) per l'allarme, CloudWatch valuta lo stato dell'allarme in base ai punti dati reali più recenti di cui è stato completato il recupero, inclusi i punti dati extra necessari da un punto più indietro nel tempo 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 che sono stati recuperati è inferiore al numero di Evaluation Periods (Periodi di valutazione) dell'allarme, CloudWatch compila i punti dati mancanti con il risultato specificato per la modalità di gestione dei dati mancanti e quindi valuta l'allarme. Tuttavia, i punti di dati reali nell'intervallo di valutazione sono inclusi nella valutazione. CloudWatch usa i punti di dati mancanti solo poche volte.

Nota

Un caso specifico di questo comportamento è che gli allarmi CloudWatch potrebbero rivalutare ripetutamente l'ultimo set di punti dati per un periodo di tempo successivo all'arresto del flusso del parametro. 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 per Alarm (Punti di dati all'allarme) e Evaluation Periods (Periodi di valutazione) sono entrambi 3. CloudWatch recupera i 5 punti dati più recenti durante la valutazione dell'allarme, nel caso in cui alcuni dei 3 punti dati più recenti risultino mancanti. 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_DATA.

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.

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

La valutazione dell'allarme CloudWatch include la logica per cercare di evitare falsi allarmi, dove l'allarme entra in stato ALARM prematuramente 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)).

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 viene visualizzato nel campo EvaluationState quando utilizzi il comando describe-alarms di AWS CLI o l'API DescribeAlarms.

Gli allarmi pubblicano anche eventi su Amazon EventBridge quando entrano in uno stato parziale dei dati, quindi puoi creare una regola EventBridge per controllare tali eventi. In questi eventi, il campo evaluationState presenta il valore PARTIAL_DATA. Di seguito è riportato un esempio.

{ "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.

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, oppure puoi impostare un allarme regolare con un periodo di qualsiasi multiplo di più di 60 secondi. Per gli allarmi ad alta risoluzione il costo è più elevato. Per ulteriori informazioni sui parametri ad alta risoluzione, consulta Publish custom metrics.

Allarmi basati su espressioni matematiche

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, è possibile specificare il modo in cui CloudWatch deve 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 le metriche di CloudWatch.

Allarmi CloudWatch 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.

Caratteristiche comuni degli allarmi CloudWatch

Le caratteristiche seguenti si applicano a tutti gli allarmi CloudWatch:

  • Non è previsto alcun limite per il numero di allarmi che puoi creare. Per creare o aggiornare un allarme, puoi utilizzare la console CloudWatch, l'azione API PutMetricAlarm o il comando put-metric-alarm nella AWS CLI.

  • I nomi degli allarmi devono contenere solo caratteri UTF-8 e non possono contenere caratteri di controllo ASCII

  • È possibile elencare uno o tutti gli allarmi attualmente configurati ed elencare eventuali allarmi in uno stato particolare utilizzando la console CloudWatch, l'azione API DescribeAlarms oppure il comando describe-alarms nella AWS CLI.

  • È possibile disabilitare e abilitare le operazioni di allarme utilizzando le operazioni API DisableAlarmActions ed EnableAlarmActions o i comandi disable-alarm-actions ed enable-alarm-actions nella AWS CLI.

  • È possibile testare un allarme avviso impostandolo su qualsiasi stato utilizzando l'azione API SetAlarmState o il comando set-alarm-state 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 API PutMetricAlarm o il comando put-metric-alarm in AWS CLI.

  • È possibile visualizzare la cronologia di un allarme utilizzando la console CloudWatch, l'azione API DescribeAlarmHistory oppure il comando describe-alarm-history nella AWS CLI. CloudWatch conserva la cronologia dell'allarme 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 gli allarmi ai preferiti dell'opzione Favorites and recents (Preferiti e recenti) nel riquadro di navigazione della console CloudWatch passando il mouse sull'allarme che desideri contrassegnare come preferito e selezionando il simbolo della stella accanto al suo nome.

  • 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 risorse AWS non inviano i dati dei parametri a CloudWatch in determinate condizioni.

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 della modalità in cui gli allarmi CloudWatch trattano i dati mancanti.