Questo documento descrive in che modo le impostazioni del periodo di allineamento e della durata determinano quando una condizione è soddisfatta, come i criteri di avviso combinano più condizioni e come i criteri di avviso sostituiscono i punti dati mancanti. Descrive inoltre il numero massimo di incidenti aperti per un criterio, il numero di notifiche per incidente e cosa determina i ritardi nelle notifiche.
Questi contenuti non si applicano ai criteri di avviso basati su log. Per informazioni sui criteri di avviso basati su log, consulta Monitoraggio dei log.
Impostazioni del periodo e della durata dell'allineamento
Il periodo di allineamento e la finestra di durata sono due campi che imposti quando specifichi una condizione per un criterio di avviso. Questa sezione fornisce una breve illustrazione del significato di questi campi.
Periodo allineamento
Il periodo di allineamento è un intervallo di ricerca da un determinato momento. L'allineatore è la funzione che combina i punti nell'intervallo di ricerca in un valore allineato. Ad esempio, quando il periodo di allineamento è di cinque minuti, alle 13:00 il periodo di allineamento include i campioni ricevuti tra le 12:55 e le 13:00. Alle 13:01, il periodo di allineamento scorre un minuto e contiene i campioni ricevuti tra le 12:56 e le 13:01.
Console Google Cloud
Puoi configurare i campi di allineamento con i menu Finestra temporale continua e Funzione finestra temporale continua che fanno parte della finestra di dialogo Nuova condizione.
Per ulteriori informazioni sulle funzioni disponibili, consulta Aligner nel riferimento API. Alcune funzioni di allineamento allineano i dati e li convertono da un tipo o da un tipo di metrica a un altro. Per una spiegazione
dettagliata, consulta Tipi, tipi e conversioni.
API
Puoi configurare i campi di allineamento impostando i campi aggregations.alignmentPeriod e aggregations.perSeriesAligner nelle strutture MetricThreshold e MetricAbsence.
Per ulteriori informazioni sulle funzioni disponibili, consulta Aligner nel riferimento API. Alcune funzioni di allineamento allineano i dati e li convertono da un tipo o da un tipo di metrica a un altro. Per una spiegazione
dettagliata, consulta Tipi, tipi e conversioni.
Per illustrare l'effetto del periodo di allineamento su una condizione in un criterio di avviso, considera una condizione di soglia di metrica che monitora una metrica con un periodo di campionamento di un minuto. Supponiamo che il periodo di allineamento sia impostato su cinque minuti e che l'allineatore sia impostato su sum. Inoltre, supponiamo che la condizione sia soddisfatta quando il valore allineato della serie temporale è maggiore di due per almeno tre minuti e che la condizione venga valutata ogni minuto.
La figura seguente illustra diverse valutazioni sequenziali della condizione:
Ogni riga nella figura illustra una singola valutazione della condizione. Vengono visualizzati i dati delle serie temporali. I punti nel periodo di allineamento sono indicati
con punti blu, quelli più vecchi sono neri. Ogni riga mostra il valore allineato e
indica se questo valore è maggiore della soglia di due. Per la riga denominata
start, il valore allineato viene calcolato in base a uno, che è inferiore alla soglia.
Alla valutazione successiva, la somma dei campioni nel periodo di allineamento è pari a due.
Nella terza valutazione, la somma è tre e, poiché questo valore è maggiore della soglia, viene avviato un timer per la durata.
Finestra di durata
Per evitare che una condizione venga soddisfatta a causa di una singola misurazione o previsione, puoi utilizzare la durata o la finestra di durata. Ad esempio, supponiamo che il campo della durata di una condizione sia impostato su 15 minuti. Di seguito viene descritto il comportamento della condizione in base al tipo:
- Le condizioni di soglia di metrica vengono soddisfatte quando, per una singola serie temporale, ogni misurazione allineata in un intervallo di 15 minuti viola la soglia.
- Le condizioni di assenza di metriche sono soddisfatte quando non arrivano dati per una serie temporale in un intervallo di 15 minuti.
- Le condizioni di previsione vengono soddisfatte quando ogni previsione prodotta durante un periodo di 15 minuti prevede che la serie temporale violerà la soglia all'interno della finestra di previsione.
Per i criteri con una sola condizione, viene aperto un incidente e vengono inviate notifiche quando la condizione è soddisfatta. Questi incidenti rimangono aperti finché la condizione continua a essere soddisfatta.
Console Google Cloud
Puoi configurare la finestra della durata utilizzando il campo Finestra di nuovo test nel passaggio Configura trigger.
API
Puoi configurare la finestra della durata impostando il campo duration nelle strutture MetricThreshold e MetricAbsence.
La figura precedente mostrava tre valutazioni di una condizione di soglia di metrica. Nel momento
start + 2 minutes, il valore allineato è maggiore della soglia;
tuttavia, la condizione non è soddisfatta perché la finestra della durata è impostata su
tre minuti. La figura seguente illustra i risultati per le successive valutazioni della condizione:
Anche se il valore allineato è maggiore della soglia al momento start + 2 minutes, la condizione non viene soddisfatta finché il valore allineato non supera la soglia per tre minuti. Questo evento si verifica alle ore start + 5 minutes.
Una condizione reimposta la durata ogni volta che una misurazione o una previsione non soddisfa la condizione. Questo comportamento è illustrato nel seguente esempio:
Esempio: questo criterio di avviso contiene una condizione di soglia di metrica che specifica una finestra di durata di cinque minuti.
Se la latenza della risposta HTTP è superiore a 2 secondi
e se la latenza è superiore alla soglia di cinque minuti,
attiva un incidente e invia un'email al team di assistenza.La seguente sequenza illustra in che modo la finestra di durata influisce sulla valutazione della condizione:
- La latenza HTTP è inferiore a 2 secondi.
- Per i tre minuti consecutivi successivi, la latenza HTTP è superiore a 2 secondi.
- Nella misurazione successiva, la latenza è inferiore a 2 secondi, quindi la condizione reimposta la finestra della durata.
Per i cinque minuti consecutivi, la latenza HTTP è superiore a due secondi, quindi la condizione è soddisfatta.
Poiché il criterio di avviso ha una condizione, Monitoring invia delle notifiche quando la condizione è soddisfatta.
Imposta una finestra di durata sufficientemente lunga da ridurre al minimo i falsi positivi, ma abbastanza breve da garantire che gli incidenti vengano aperti in modo tempestivo.
Best practice per impostare il periodo di allineamento e la finestra di durata
Il periodo di allineamento determina quanti campioni vengono combinati con l'allineatore:
Il valore minimo del periodo di allineamento per un tipo di metrica è il periodo di campionamento di quel tipo di metrica. Ad esempio, se il tipo di metrica viene campionato ogni 300 secondi, il periodo di allineamento deve essere di almeno 300 secondi. Tuttavia, se vuoi combinare 5 campioni, imposta il periodo di allineamento su 5 * 300 secondi o 1500 secondi.
Il valore massimo del periodo di allineamento è di 24 ore meno il ritardo di importazione del tipo di metrica. Ad esempio, se il ritardo di importazione di una metrica è di 6 ore, il valore massimo del periodo di allineamento è 18 ore.
Utilizza la finestra della durata per specificare la reattività dell'avviso. Ad esempio, se imposti una finestra di durata su 20 minuti per una condizione assenza metrica, non devono esserci dati per 20 minuti prima che la condizione venga soddisfatta. Per un criterio di avviso più reattivo, imposta la durata su un valore inferiore. Per le condizioni di soglia delle metriche, per avere il criterio di avviso più reattivo, imposta la durata su zero. Un singolo valore allineato fa soddisfare questi tipi di condizioni.
Le condizioni dei criteri di avviso vengono valutate con una frequenza fissa. Le scelte che fai per il periodo di allineamento e la finestra di durata non determinano la frequenza con cui viene valutata la condizione.
Criteri con più condizioni
Un criterio di avviso può contenere fino a sei condizioni.
Se utilizzi l'API Cloud Monitoring o se il criterio di avviso ha più condizioni, devi specificare quando viene aperto un incidente. Per configurare la modalità di combinazione di più condizioni, procedi in uno dei seguenti modi:
Console Google Cloud
Puoi configurare le opzioni del combinatore nel passaggio Trigger per più condizioni.
API
Puoi configurare le opzioni del combinatore con il campo combiner della struttura di
AlertPolicy.
Questa tabella elenca le impostazioni nella console Google Cloud, il valore equivalente nell'API Cloud Monitoring e una descrizione di ogni impostazione:
| Valore di trigger del criterio console Google Cloud |
Valore combiner API Cloud Monitoring |
Significato |
|---|---|---|
| Qualsiasi condizione è soddisfatta | OR |
Un incidente viene aperto se una risorsa fa sì che una qualsiasi condizione venga soddisfatta. |
| Tutte le condizioni sono soddisfatte anche per risorse diverse per ogni condizione (valore predefinito) |
AND |
Un incidente viene aperto se ogni condizione è soddisfatta, anche se una risorsa diversa fa sì che queste condizioni siano soddisfatte. |
| Tutte le condizioni sono soddisfatte | AND_WITH_MATCHING_RESOURCE |
Un incidente viene aperto se la stessa risorsa fa sì che ogni condizione sia soddisfatta. Questa impostazione è la combinazione più rigorosa. |
In questo contesto, il termine met indica che la configurazione della condizione ha valore true. Ad
esempio, se la configurazione è
Any time series is greater than 10 for 5 minutes,
quando questa istruzione ha valore true, la condizione è soddisfatta.
Esempio
Considera un progetto Google Cloud che contiene due istanze VM, vm1 e vm2. Inoltre, supponiamo di creare un criterio di avviso con 2 condizioni:
- La condizione
CPU usage is too highmonitora l'utilizzo della CPU delle istanze. Questa condizione è soddisfatta quando l'utilizzo della CPU di qualsiasi istanza è superiore a 100 ms/s per 1 minuto. - La condizione
Excessive utilizationmonitora l'utilizzo della CPU delle istanze. Questa condizione è soddisfatta quando l'utilizzo della CPU di qualsiasi istanza è superiore al 60% per 1 minuto.
Inizialmente, supponiamo che entrambe le condizioni abbiano il valore false.
Quindi, supponiamo che l'utilizzo della CPU di vm1 superi i 100 ms/s per 1 minuto. Poiché l'utilizzo della CPU è superiore alla soglia per un minuto, è soddisfatta la condizione CPU usage is too high. Se le condizioni vengono combinate con Qualsiasi condizione è soddisfatta, viene creato un incidente perché una condizione è soddisfatta. Se le condizioni vengono combinate con Tutte le condizioni sono soddisfatte o Tutte le condizioni sono soddisfatte anche per risorse diverse per ogni condizione, non viene creato un incidente. Queste scelte del combinatore richiedono
che entrambe le condizioni siano soddisfatte.
Quindi, supponiamo che l'utilizzo della CPU di vm1 rimanga superiore a 100 ms/s e che l'utilizzo della CPU di vm2 superi il 60% per 1 minuto. Il risultato è che entrambe le condizioni sono soddisfatte. Di seguito viene descritto cosa accade in base al modo in cui le condizioni vengono combinate:
Qualsiasi condizione è soddisfatta: viene creato un incidente quando una risorsa fa sì che una condizione sia soddisfatta. In questo esempio, con VM2 viene soddisfatta la condizione
Excessive utilization.Se vm2 soddisfa la condizione
CPU usage is too high, viene creato anche un incidente. Viene creato un incidente perché VM1 e vm2 che soddisfano la condizioneCPU usage is too highsono eventi distinti.Tutte le condizioni sono soddisfatte anche per risorse diverse per ogni condizione: viene creato un incidente perché entrambe le condizioni sono soddisfatte.
Tutte le condizioni sono soddisfatte: non viene creato un incidente perché questo combinatore richiede che la stessa risorsa provochi il rispetto di tutte le condizioni. In questo esempio, non viene creato nessun incidente perché vm1 viene soddisfatto
CPU usage is too high, mentre vm2 viene soddisfattoExcessive utilization.
Dati delle metriche parziali
Quando i dati della serie temporale non arrivano o subiscono un ritardo, Monitoring li classifica come mancanti. La mancanza di dati può impedire la chiusura degli incidenti. I ritardi nei dati provenienti da provider cloud di terze parti possono arrivare fino a 30 minuti, con un ritardo di 5-15 minuti che è il più comune. Un lungo ritardo, maggiore della durata della finestra, può far sì che le condizioni entrino in uno stato "sconosciuto". Quando finalmente arriveranno i dati, Monitoring potrebbe aver perso parte della storia recente delle condizioni. Un'analisi successiva dei dati delle serie temporali potrebbe non rivelare questo problema perché non ci sono prove di ritardi una volta che arrivano i dati.
Console Google Cloud
Puoi configurare il modo in cui Monitoring valuta una condizione di soglia di metrica all'arrivo dei dati. Ad esempio, se un incidente è aperto e non arriva una misurazione prevista, vuoi che Monitoring lasci l'incidente aperto o lo chiuda immediatamente? Analogamente, se i dati smettono di arrivare e non si è verificato alcun incidente, vuoi che si apra? Infine, per quanto tempo un incidente deve rimanere aperto quando i dati smettono di arrivare?
Sono disponibili due campi configurabili che specificano in che modo Monitoring valuta le condizioni di soglia di metriche all'interruzione dei dati:
Per configurare il modo in cui Monitoring determina il valore di sostituzione per i dati mancanti, utilizza il campo Valutazione di dati mancanti che hai impostato nel passaggio Trigger condizione. Questo campo è disabilitato quando la finestra di nuovo test è impostata su Nessun nuovo test.
Per configurare il tempo di attesa di Monitoring prima di chiudere un incidente aperto dopo l'arrivo dei dati, utilizza il campo Durata della chiusura automatica dell'incidente. Puoi impostare la durata della chiusura automatica nel passaggio Notifica. La durata predefinita della chiusura automatica è sette giorni.
Di seguito sono descritte le diverse opzioni per il campo dei dati mancanti:
| Console Google Cloud Campo "Valutazione di dati mancanti" |
Riepilogo | Dettagli |
|---|---|---|
| Dati mancanti vuoti | Gli incidenti aperti rimangono aperti. I nuovi incidenti non vengono aperti. |
Per condizioni che sono soddisfatte, la condizione continua a essere soddisfatta all'interruzione dei dati. Se un incidente è aperto per questa condizione, rimane aperto. Se un incidente è aperto e non arrivano dati, il timer per la chiusura automatica si avvia dopo un ritardo di almeno 15 minuti. Se il timer scade, l'incidente viene chiuso. Per condizioni che non sono soddisfatte, la condizione continua a non essere soddisfatta all'interruzione dei dati. |
| Punti dati mancanti trattati come valori che violano la condizione delle norme | Gli incidenti aperti rimangono aperti. È possibile aprire nuovi incidenti. |
Per condizioni che sono soddisfatte, la condizione continua a essere soddisfatta all'interruzione dei dati. Se un incidente è aperto per questa condizione, rimane aperto. Quando un incidente è aperto e non arrivano dati per la durata della chiusura automatica più 24 ore, l'incidente viene chiuso. Per condizioni che non sono soddisfatte, questa impostazione fa sì che la condizione di soglia di metrica si comporti come un |
| Punti dati mancanti trattati come valori che non violano la condizione delle norme | Gli incidenti aperti sono chiusi. I nuovi incidenti non vengono aperti. |
Per condizioni che sono soddisfatte, la condizione si interrompe all'arrivo dei dati. Se un incidente è aperto per questa condizione, viene chiuso. Per condizioni che non sono soddisfatte, la condizione continua a non essere soddisfatta all'interruzione dei dati. |
API
Puoi configurare il modo in cui Monitoring valuta una condizione di soglia di metrica all'arrivo dei dati. Ad esempio, se un incidente è aperto e non arriva una misurazione prevista, vuoi che Monitoring lasci l'incidente aperto o lo chiuda immediatamente? Analogamente, se i dati smettono di arrivare e non si è verificato alcun incidente, vuoi che si apra? Infine, per quanto tempo un incidente deve rimanere aperto quando i dati smettono di arrivare?
Sono disponibili due campi configurabili che specificano in che modo Monitoring valuta le condizioni di soglia di metriche all'interruzione dei dati:
Per configurare il modo in cui Monitoring determina il valore sostitutivo per i dati mancanti, utilizza il campo
evaluationMissingDatadella strutturaMetricThreshold. Questo campo viene ignorato quando il campodurationè pari a zero.Per configurare il tempo di attesa di Monitoring prima di chiudere un incidente aperto dopo l'arresto dei dati, utilizza il campo
autoClosenella strutturaAlertStrategy.
Di seguito sono descritte le diverse opzioni per il campo dei dati mancanti:
Campo APIevaluationMissingData |
Riepilogo | Dettagli |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Gli incidenti aperti rimangono aperti. I nuovi incidenti non vengono aperti. |
Per condizioni che sono soddisfatte, la condizione continua a essere soddisfatta all'interruzione dei dati. Se un incidente è aperto per questa condizione, rimane aperto. Se un incidente è aperto e non arrivano dati, il timer per la chiusura automatica si avvia dopo un ritardo di almeno 15 minuti. Se il timer scade, l'incidente viene chiuso. Per condizioni che non sono soddisfatte, la condizione continua a non essere soddisfatta all'interruzione dei dati. |
EVALUATION_MISSING_DATA_ACTIVE |
Gli incidenti aperti rimangono aperti. È possibile aprire nuovi incidenti. |
Per condizioni che sono soddisfatte, la condizione continua a essere soddisfatta all'interruzione dei dati. Se un incidente è aperto per questa condizione, rimane aperto. Quando un incidente è aperto e non arrivano dati per la durata della chiusura automatica più 24 ore, l'incidente viene chiuso. Per condizioni che non sono soddisfatte, questa impostazione fa sì che la condizione di soglia di metrica si comporti come un |
EVALUATION_MISSING_DATA_INACTIVE |
Gli incidenti aperti sono chiusi. I nuovi incidenti non vengono aperti. |
Per condizioni che sono soddisfatte, la condizione si interrompe all'arrivo dei dati. Se un incidente è aperto per questa condizione, viene chiuso. Per condizioni che non sono soddisfatte, la condizione continua a non essere soddisfatta all'interruzione dei dati. |
Per ridurre al minimo i problemi dovuti a dati mancanti, procedi in uno dei seguenti modi:
- Contatta il tuo cloud provider di terze parti per identificare modi per ridurre la latenza di raccolta delle metriche.
- Utilizza finestre di durata più lunga nelle tue condizioni. L'utilizzo di una finestra di durata più lunga ha lo svantaggio di rendere i criteri di avviso meno reattivi.
Scegli le metriche con un ritardo di raccolta inferiore:
- Monitoraggio delle metriche dell'agente, in particolare quando l'agente è in esecuzione su istanze VM in cloud di terze parti.
- Metriche personalizzate, quando scrivi i dati direttamente in Monitoring.
- Metriche basate su log, se la raccolta delle voci di log non subisce ritardi.
Per ulteriori informazioni, consulta Panoramica dell'agente Monitoring, Panoramica delle metriche definite dall'utente e Metriche basate su log.
Quando Monitoring invia notifiche e crea incidenti
Cloud Monitoring invia una notifica quando una serie temporale fa sì che una condizione sia soddisfatta. La notifica viene inviata a tutti i canali di notifica. Non puoi limitare una notifica a un canale specifico o a un sottoinsieme di canali del tuo criterio.
Se configuri le notifiche ripetute, la stessa notifica viene inviata nuovamente a canali di notifica specifici per il tuo criterio di avviso.
Potresti ricevere più notifiche univoche relative a un criterio di avviso quando si verifica una delle seguenti condizioni:
Una condizione sta monitorando più serie temporali.
Un criterio contiene più condizioni. In questo caso, le notifiche che ricevi dipendono dal valore dell'attivatore multicondizioni del criterio di avviso:
Tutte le condizioni sono soddisfatte: quando tutte le condizioni sono soddisfatte, per ogni serie temporale in cui una condizione è soddisfatta, il criterio di avviso invia una notifica e crea un incidente.
Non puoi configurare Cloud Monitoring in modo da creare un solo incidente e inviare una sola notifica quando il criterio di avviso contiene più condizioni.
Qualsiasi condizione è soddisfatta: il criterio di avviso invia una notifica quando una serie temporale fa sì che la condizione sia soddisfatta.
Per maggiori informazioni, consulta la sezione Norme con più condizioni.
I criteri di avviso creati utilizzando l'API Cloud Monitoring inviano anche una notifica quando la condizione è soddisfatta e quando la condizione smette di esserlo. I criteri di avviso creati utilizzando la console Google Cloud non inviano una notifica quando la condizione non viene soddisfatta, a meno che tu non abbia abilitato tale comportamento.
Casi in cui Monitoring non invia notifiche o crea incidenti
Nelle situazioni seguenti, Monitoring non crea incidenti né invia notifiche quando vengono soddisfatte le condizioni di un criterio di avviso:
- Il criterio di avviso è disabilitato.
- Il criterio di avviso è stato posticipato.
- Il monitoraggio ha raggiunto il limite per il numero massimo di incidenti aperti.
Criteri di avviso disabilitati
Monitoring non invia incidenti di creazione né notifiche per criteri di avviso disabilitati. Tuttavia, Monitoring continua a valutare le condizioni di un criterio di avviso disabilitato.
Quando attivi un criterio disattivato, Monitoring valuta i valori di tutte le condizioni nella finestra di durata più recente. La durata più recente potrebbe includere i dati acquisiti prima, durante e dopo l'attivazione del criterio. Le condizioni di un criterio disattivato possono essere soddisfatte subito dopo il suo ripristino, anche con finestre di durata estesa.
Ad esempio, supponi di avere un criterio di avviso che monitora un processo specifico e di disabilitare questo criterio. La settimana successiva, il processo non sarà più disponibile e, poiché il criterio di avviso è disabilitato, non riceverai alcuna notifica. Se riavvii il processo e abiliti immediatamente il criterio di avviso, Monitoring riconosce che il processo non è stato attivo negli ultimi cinque minuti e apre un incidente.
Gli incidenti relativi a un criterio di avviso disattivato rimangono aperti fino alla scadenza della durata di chiusura automatica del criterio.
Criteri di avviso posticipati
Monitoring non invia notifiche né crea incidenti per un criterio di avviso posticipato. Ti consigliamo di posticipare i criteri di avviso quando vuoi impedire a un criterio di avviso di inviare notifiche solo per brevi intervalli. Ad esempio, prima di eseguire la manutenzione su una macchina virtuale (VM), potresti creare una posticipazione e aggiungere ai criteri di posticipazione i criteri di avviso che monitorano l'istanza.
Quando posticipi un criterio di avviso, Monitoring chiude tutti gli incidenti aperti correlati al criterio. Monitoring può aprire nuovi incidenti dopo la scadenza del periodo di posticipazione. Per informazioni, vedi Posticipare notifiche e avvisi.
Limiti delle notifiche e degli incidenti aperti
Un criterio di avviso può essere applicato a molte risorse e un problema che riguarda tutte le risorse può causare l'apertura di incidenti per ogni risorsa nel criterio di avviso. Viene aperto un incidente per ogni serie temporale in cui viene soddisfatta una condizione.
Per evitare il sovraccarico del sistema, il numero di incidenti che un singolo criterio può aprire contemporaneamente è limitato a 1000.
Ad esempio, considera un criterio che si applica a 2000 istanze di Compute Engine, e ogni istanza fa sì che vengano soddisfatte le condizioni di avviso. Monitoring limita a 1000 il numero di incidenti aperti. Eventuali condizioni rimanenti soddisfatte vengono ignorate fino alla chiusura di alcuni degli incidenti aperti per quel criterio.
Di conseguenza, un singolo canale di notifica può ricevere fino a 1000 notifiche alla volta. Se il criterio di avviso ha più canali di notifica, questo limite si applica a ogni canale di notifica indipendente.
Latenza
La latenza si riferisce al ritardo tra il momento in cui Monitoring campiona una metrica e il momento in cui il punto dati della metrica diventa visibile come dati di una serie temporale. La latenza influisce sul momento dell'invio delle notifiche. Ad esempio, se una metrica monitorata ha una latenza fino a 180 secondi, Monitoring non creerà un incidente per un massimo di 180 secondi dopo che la condizione del criterio di avviso avrà valore true. Per ulteriori informazioni, consulta Latenza dei dati delle metriche.
I seguenti eventi e impostazioni contribuiscono alla latenza:
Ritardo nella raccolta delle metriche: il tempo necessario a Monitoring per raccogliere i valori delle metriche. Per i valori di Google Cloud, la maggior parte delle metriche non è visibile per 60 secondi dopo la raccolta; tuttavia, il ritardo dipende dalla metrica. I calcoli dei criteri di avviso richiedono un ulteriore ritardo compreso tra 60 e 90 secondi. Per le metriche di AWS CloudWatch, il ritardo di visibilità può essere di diversi minuti. Per i controlli di uptime, può essere una media di due minuti (dalla fine della finestra di durata).
Finestra di durata: la finestra configurata per la condizione. Le condizioni vengono soddisfatte solo quando una condizione è vera per tutta la durata della durata. Ad esempio, l'impostazione di una finestra di durata pari a cinque minuti causa un ritardo nella notifica di almeno cinque minuti dal momento in cui si verifica per la prima volta l'evento.
Ora di arrivo della notifica: i canali di notifica, ad esempio email e SMS, potrebbero riscontrare latenze di rete o altre latenze (non correlate a ciò che viene recapitato) e a volte avvicinarsi ai minuti. Alcuni canali, come SMS e Slack, non garantiscono che i messaggi vengano recapitati.
Passaggi successivi
Per informazioni su come creare un criterio di avviso, consulta i seguenti documenti:
Per una serie di criteri di avviso, consulta Criteri di esempio.