Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Utilizzo degli CloudWatch allarmi Amazon
Puoi creare allarmi metrici e compositi in Amazon. CloudWatch
-
Un allarme metrico controlla una singola CloudWatch metrica o il risultato di un'espressione matematica basata su metriche. CloudWatch L'allarme esegue una o più operazioni basate sul valore del parametro o espressione relativa a una soglia su un certo numero di periodi. L'azione può consistere nell'invio di una notifica a un SNS argomento Amazon, nell'esecuzione di un'EC2azione Amazon o di un'azione Amazon EC2 Auto Scaling o nella creazione di un incidente OpsItem or 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 ALARM stato 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 ALARM stato solo quando tutti gli allarmi metrici sottostanti sono attivi. ALARM
Gli allarmi compositi possono inviare SNS notifiche ad Amazon quando cambiano stato e possono creare Systems Manager OpsItems o incidenti quando entrano in ALARM stato, ma non possono eseguire EC2 azioni o azioni di Auto Scaling.
Nota
Puoi creare tutti gli allarmi che desideri nel tuo account. AWS
Puoi aggiungere allarmi alle dashboard, in modo da monitorare e ricevere avvisi sulle tue AWS risorse e applicazioni in più regioni. Dopo avere aggiunto un allarme a un pannello di controllo, l'allarme diventa grigio quando è nello stato INSUFFICIENT_DATA
e rosso quando è nello stato ALARM
. L'allarme non ha alcun colore quando è nello stato OK
.
Puoi anche aggiungere ai preferiti gli allarmi visitati di recente dall'opzione Preferiti e recenti nel pannello 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 account nella tua CloudWatch console, puoi anche creare allarmi che controllano le metriche di altri account. AWS La creazione di allarmi compositi tra più account non è supportata. È supportata la creazione di allarmi tra più account che utilizzano espressioni matematiche, ad eccezione del fatto che le funzioni ANOMALY_DETECTION_BAND
, INSIGHT_RULE
e SERVICE_QUOTA
non sono supportate per gli allarmi tra più account.
Nota
CloudWatch non verifica o convalida le azioni specificate, né rileva errori di Amazon EC2 Auto Scaling o SNS Amazon derivanti da un tentativo di richiamare azioni 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 crei un allarme, specifichi tre impostazioni per consentire di valutare quando modificare CloudWatch 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 o 30 secondi, l'allarme viene valutato ogni 10 secondi.
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
.
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 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.
Operazione per gli allarmi
È possibile specificare le azioni intraprese da un allarme quando cambia stato tra gli stati OK e ALARM 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.
Inviare una notifica a uno o più abbonati tramite un argomento Amazon Simple Notification Service. Gli abbonati possono essere sia applicazioni che persone. Per ulteriori informazioni su AmazonSNS, consulta What is AmazonSNS? .
Richiamare una funzione Lambda. Questo è il modo più semplice per automatizzare le azioni personalizzate relative alle dello stato degli allarmi.
-
Gli allarmi basati sulle EC2 metriche possono anche eseguire EC2 azioni, come l'arresto, la chiusura, il riavvio o il ripristino di un'istanza. EC2 Per ulteriori informazioni, consulta Crea allarmi per interrompere, terminare, riavviare o ripristinare un'istanza EC2.
Gli allarmi possono anche eseguire operazioni per dimensionare un gruppo Auto Scaling. Per ulteriori informazioni, consulta Step and simple scaling policies for Amazon EC2 Auto Scaling.
-
Gli allarmi possono essere creati OpsItems in Systems Manager Ops Center o creare incidenti in AWS Systems Manager Incident Manager. Queste azioni vengono eseguite solo quando l'allarme entra in ALARM stato. Per ulteriori informazioni, consulta Configurazione per la creazione CloudWatch a OpsItems partire da allarmi e Creazione di incidenti.
Operazioni allarme Lambda
CloudWatch alarms garantisce un'invocazione asincrona della funzione Lambda per un determinato cambio di stato, tranne nei seguenti casi:
Quando la funzione non esiste.
When non CloudWatch è autorizzato a richiamare la funzione Lambda.
Se non CloudWatch riesce a raggiungere il servizio Lambda o il messaggio viene rifiutato per un altro motivo, CloudWatch riprova finché la chiamata non ha esito positivo. Lambda mette in coda il messaggio e gestisce i tentativi di esecuzione. Per ulteriori informazioni su questo modello di esecuzione, incluse informazioni su come Lambda gestisce gli errori, consulta Asynchronous invocation nella Developer Guide. AWS Lambda
È possibile richiamare una funzione Lambda nello stesso account o in AWS altri account.
Quando specifichi un allarme per richiamare una funzione Lambda come operazione di allarme, puoi scegliere di specificare il nome della funzione, l'alias della funzione o una versione specifica di una funzione.
Quando si specifica una funzione Lambda come azione di allarme, è necessario creare una politica delle risorse per la funzione per consentire al responsabile del CloudWatch servizio di richiamare la funzione.
Un modo per eseguire questa operazione consiste nell'utilizzare AWS CLI, come nell'esempio seguente:
aws lambda add-permission \ --function-name
my-function-name
\ --statement-id AlarmAction \ --action 'lambda:InvokeFunction' \ --principal lambda.alarms.cloudwatch.amazonaws.com \ --source-account111122223333
\ --source-arn arn:aws:cloudwatch:us-east-1
:111122223333
:alarm:alarm-name
In alternativa, puoi creare una policy simile a uno degli esempi riportati di seguito e assegnarla alla funzione.
L'esempio seguente specifica l'account in cui si trova l'allarme, in modo che solo gli allarmi in quell'account (111122223333) possano richiamare la funzione.
{ "Version": "2012-10-17", "Id": "default", "Statement": [{ "Sid": "AlarmAction", "Effect": "Allow", "Principal": { "Service": "lambda.alarms.cloudwatch.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name", "Condition": { "StringEquals": { "AWS:SourceAccount": "111122223333" } } }] }
L'esempio seguente ha un ambito più limitato e consente solo all'allarme specificato nell'account specificato di richiamare la funzione.
{ "Version": "2012-10-17", "Id": "default", "Statement": [ { "Sid": "AlarmAction", "Effect": "Allow", "Principal": { "Service": "lambda.alarms.cloudwatch.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:
us-east-1
:444455556666
:function:function-name
", "Condition": { "StringEquals": { "AWS:SourceAccount": "111122223333
", "AWS:SourceArn": "arn:aws:cloudwatch:us-east-1:111122223333
:alarm:alarm-name
" } } }] }
Non è consigliabile creare una policy che non specifichi un account di origine, poiché tali policy sono vulnerabili a problemi di "confused deputy".
Oggetto evento inviato da CloudWatch Lambda
Quando configuri una funzione Lambda come azione di allarme, CloudWatch fornisce un JSON payload alla funzione Lambda quando richiama la funzione. Questo JSON payload funge da oggetto evento per la funzione. È possibile estrarre dati da questo JSON oggetto e utilizzarli nella funzione. Di seguito è riportato un esempio di oggetto evento da un allarme del parametro.
{ 'source': 'aws.cloudwatch', 'alarmArn': 'arn:aws:cloudwatch:us-east-1:444455556666:alarm:lambda-demo-metric-alarm', 'accountId': '444455556666', 'time': '2023-08-04T12:36:15.490+0000', 'region': 'us-east-1', 'alarmData': { 'alarmName': 'lambda-demo-metric-alarm', 'state': { 'value': 'ALARM', 'reason': 'test', 'timestamp': '2023-08-04T12:36:15.490+0000' }, 'previousState': { 'value': 'INSUFFICIENT_DATA', 'reason': 'Insufficient Data: 5 datapoints were unknown.', 'reasonData': '{"version":"1.0","queryDate":"2023-08-04T12:31:29.591+0000","statistic":"Average","period":60,"recentDatapoints":[],"threshold":5.0,"evaluatedDatapoints":[{"timestamp":"2023-08-04T12:30:00.000+0000"},{"timestamp":"2023-08-04T12:29:00.000+0000"},{"timestamp":"2023-08-04T12:28:00.000+0000"},{"timestamp":"2023-08-04T12:27:00.000+0000"},{"timestamp":"2023-08-04T12:26:00.000+0000"}]}', 'timestamp': '2023-08-04T12:31:29.595+0000' }, 'configuration': { 'description': 'Metric Alarm to test Lambda actions', 'metrics': [ { 'id': '1234e046-06f0-a3da-9534-EXAMPLEe4c', 'metricStat': { 'metric': { 'namespace': 'AWS/Logs', 'name': 'CallCount', 'dimensions': { 'InstanceId': 'i-12345678' } }, 'period': 60, 'stat': 'Average', 'unit': 'Percent' }, 'returnData': True } ] } } }
Di seguito è riportato un esempio di oggetto evento da un allarme composito.
{ 'source': 'aws.cloudwatch', 'alarmArn': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:SuppressionDemo.Main', 'accountId': '111122223333', 'time': '2023-08-04T12:56:46.138+0000', 'region': 'us-east-1', 'alarmData': { 'alarmName': 'CompositeDemo.Main', 'state': { 'value': 'ALARM', 'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC', 'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}', 'timestamp': '2023-08-04T12:56:46.138+0000' }, 'previousState': { 'value': 'ALARM', 'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC', 'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}', 'timestamp': '2023-08-04T12:54:46.138+0000', 'actionsSuppressedBy': 'WaitPeriod', 'actionsSuppressedReason': 'Actions suppressed by WaitPeriod' }, 'configuration': { 'alarmRule': 'ALARM(CompositeDemo.FirstChild) OR ALARM(CompositeDemo.SecondChild)', 'actionsSuppressor': 'CompositeDemo.ActionsSuppressor', 'actionsSuppressorWaitPeriod': 120, 'actionsSuppressorExtensionPeriod': 180 } } }
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 al modo in cui 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 di CloudWatch trattare i punti dati mancanti in uno dei seguenti modi:
-
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 dati nell'intervallo di valutazione dell'allarme, l'allarme passa a INSUFFICIENT _DATA.
La scelta migliore dipende dal tipo di metrica e dallo scopo dell'allarme. Ad esempio, se state creando un allarme di rollback delle applicazioni utilizzando una metrica che riporta continuamente i dati, potreste considerare i punti dati mancanti come violazioni, perché ciò potrebbe indicare che qualcosa non va. 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 sui EC2 parametri di Amazon possono inserire temporaneamente DATA lo stato INSUFFICIENT _ se mancano dei punti dati delle metriche. Ciò è raro, ma può verificarsi quando il reporting dei parametri viene interrotto, anche quando l'EC2istanza Amazon è integra. Per gli allarmi sui EC2 parametri di Amazon configurati per eseguire azioni di arresto, terminazione, riavvio o ripristino, ti consigliamo di configurare tali allarmi in modo che trattino i dati mancanti allo stesso missing
modo e che questi allarmi si attivino solo quando si trovano 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/DynamoDB
spazio 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/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 di punti dati superiore 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 | MISSING | IGNORE | BREACHING | NOT BREACHING |
---|---|---|---|---|---|
0 - X - X |
0 |
|
|
|
|
- - - - 0 |
2 |
|
|
|
|
- - - - - |
3 |
|
Mantieni lo stato attuale |
|
|
0 X X - X |
0 |
|
|
|
|
- - X - - |
2 |
|
Mantieni lo stato attuale |
|
|
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 dati mancanti vengono considerati violati, l'allarme passa ALARM allo stato, mentre se vengono considerati non violati, l'allarme passa allo 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 dati mancanti vengono semplicemente considerati mancanti, allora l'allarme non dispone di dati reali recenti sufficienti per effettuare una valutazione e passa INSUFFICIENT a _. 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 | MISSING | IGNORE | BREACHING | NOT BREACHING |
---|---|---|---|---|---|
0 - X - X |
0 |
|
|
|
|
0 0 X 0 X |
0 |
|
|
|
|
0 - X - - |
1 |
|
|
|
|
- - - - 0 |
2 |
|
|
|
|
- - - - X |
2 |
|
Mantieni lo stato attuale |
|
|
Nelle righe 1 e 2, l'allarme diventa sempre attivo ALARM perché 2 dei 3 punti dati più recenti sono in fase di 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 ALARM stato solo se i dati mancanti vengono considerati una violazione, nel qual caso i due punti dati mancanti più recenti vengono entrambi considerati come violazioni. Nella riga 4, questi due punti dati mancanti che vengono considerati violazioni forniscono i due punti dati di 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 volta a evitare i falsi allarmi, in cui l'allarme entra prematuramente in presenza di ALARM dati 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 dati successivo potrebbe non essere violato, l'allarme non entra immediatamente in ALARM stato quando i dati sono - - - - X
o - - - X -
se Datapoints to Alarm è 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 dati lo sono- - X - -
, l'allarme entra in ALARM stato anche se i punti dati mancanti vengono considerati mancanti. Questo perché gli allarmi sono progettati per entrare sempre ALARM nello stato in cui il datapoint di violazione più vecchio disponibile durante i periodi di valutazione ha almeno lo stesso valore di Datapoints to Alarm e tutti gli altri punti dati più recenti risultano violati o mancanti. In questo caso, l'allarme entra in ALARM stato anche se il numero totale di punti dati disponibili è inferiore a M (Datapoints to Alarm).
Questa logica di allarme si applica anche a M allarmi su N. Se il punto dati di violazione più vecchio durante l'intervallo di valutazione è vecchio almeno quanto il valore di Datapoints to Alarm e tutti i punti dati più recenti sono violati o mancano, l'allarme entra in ALARM stato indipendentemente dal valore di M (Datapoints to Alarm).
Allarmi ad alta risoluzione
Se imposti un allarme su un parametro ad alta risoluzione, puoi specificare un allarme ad alta risoluzione con un periodo di 10 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
È possibile impostare un allarme in base al risultato di un'espressione matematica basata su una o più metriche. 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 vuoi 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.
Gli allarmi basati su espressioni matematiche non possono eseguire azioni AmazonEC2.
Per ulteriori informazioni sulle espressioni matematiche e la sintassi dei parametri, consulta Utilizzo di espressioni matematiche con metriche CloudWatch .
Allarmi basati su percentili ed esempi di dati limitati CloudWatch
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 seguenti funzionalità si applicano a tutti gli CloudWatch allarmi:
-
Non è previsto alcun limite per il numero di allarmi che puoi creare. Per creare o aggiornare un avviso, si utilizza la CloudWatch console, l'PutMetricAlarmAPIazione o il put-metric-alarmcomando in. AWS CLI
-
I nomi degli allarmi devono contenere solo UTF -8 caratteri e non possono contenere caratteri ASCII di controllo
-
È possibile elencare alcuni o tutti gli allarmi attualmente configurati ed elencare tutti gli allarmi in uno stato particolare utilizzando la CloudWatch console, l'DescribeAlarmsAPIaction o il comando describe-alarms in. AWS CLI
-
È possibile disabilitare e abilitare gli allarmi utilizzando le EnableAlarmActionsAPIazioni DisableAlarmActionse o i comandi and in. disable-alarm-actionsenable-alarm-actions AWS CLI
-
È possibile testare un allarme impostandolo su qualsiasi stato utilizzando l'SetAlarmStateAPIazione o il set-alarm-statecomando 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'PutMetricAlarmAPIazione o il put-metric-alarmcomando contenuto in AWS CLI.
-
È possibile visualizzare la cronologia di un allarme utilizzando la CloudWatch console, l'DescribeAlarmHistoryAPIazione o il describe-alarm-historycomando in AWS CLI. CloudWatch conserva la cronologia degli allarmi per 30 giorni. Ogni transizione di stato viene contrassegnata con un timestamp univoco. In rari casi, la cronologia potrebbe mostrare più di una notifica per una modifica di stato. Il timestamp consente di confermare le modifiche di stato univoche.
-
Puoi aggiungere avvisi ai preferiti dall'opzione Preferiti e recenti nel pannello di navigazione della CloudWatch console passando il mouse sulla sveglia che desideri aggiungere ai preferiti e scegliendo il simbolo a stella accanto ad essa.
-
Il numero di periodi di valutazione per un allarme moltiplicato per la durata di ciascun periodo di valutazione non può superare un giorno.
Nota
Alcune AWS risorse non inviano dati metrici a in determinate condizioni. CloudWatch
Ad esempio, Amazon EBS potrebbe non inviare dati metrici per un volume disponibile che non è collegato a un'EC2istanza Amazon, perché non vi è alcuna attività metrica da monitorare per quel volume. Se disponi di un set di allarmi per tale parametro, il relativo stato potrebbe cambiare in INSUFFICIENT_DATA
. Questo potrebbe indicare che la risorsa non è attiva e non necessariamente significare la presenza di un problema. È possibile specificare il modo in cui ogni allarme tratta i dati mancanti. Per ulteriori informazioni, consulta Configurazione del modo in cui gli CloudWatch allarmi trattano i dati mancanti.