Questo documento descrive in che modo i periodi di allineamento e le finestre di ripetizione del test determinano quando una condizione viene soddisfatta, in che modo i criteri di avviso combinano più condizioni e in che modo i criteri di avviso sostituiscono i punti dati mancanti. Descrive anche il numero massimo di avvisi aperti per una policy, il numero di notifiche per avviso e le cause dei ritardi nelle notifiche.
Questi contenuti non si applicano ai criteri di avviso basati su log. Per informazioni sulle policy di avviso basate su log, vedi Monitoraggio dei log.
Periodi di allineamento e finestre di ritest
Cloud Monitoring valuta il periodo di allineamento e la finestra di nuovo test quando determina se la condizione di unacriterio di avvisoo è stata soddisfatta.
Periodo allineamento
Prima che i dati delle serie temporali vengano monitorati da una criterio di avviso, devono essere regolarizzati in modo che la criterio di avviso disponga di dati a intervalli regolari da valutare. Il processo di regolarizzazione è chiamato allineamento.
L'allineamento prevede due passaggi:
Dividere la serie temporale in intervalli di tempo regolari, operazione chiamata anche raggruppamento dei dati. L'intervallo è il periodo di allineamento.
Calcolo di un singolo valore per i punti nel periodo di allineamento. Scegli come viene calcolato questo singolo punto: puoi sommare tutti i valori, calcolarne la media o utilizzare il valore massimo. La funzione che combina i punti dati è chiamata allineatore. Il risultato della combinazione è il valore allineato.
Per saperne di più sull'allineamento, consulta Allineamento: regolarizzazione all'interno della serie.
Ad esempio, quando il periodo di allineamento è di cinque minuti, alle 13:00 il periodo di allineamento contiene i campioni ricevuti tra le 12:55 e le 13:00. Alle 13:01, il periodo di allineamento scorre di un minuto e contiene i campioni ricevuti tra le 12:56 e le 13:01.
Il monitoraggio configura un periodo di allineamento nel seguente modo:
Console Google Cloud
Configura il periodo di allineamento scegliendo un valore per i seguenti campi nella pagina Condizioni avviso:
- Finestra mobile: specifica l'intervallo di tempo da valutare.
- Funzione finestra temporale continua: specifica la funzione matematica da eseguire sulla finestra di punti dati.
Per saperne di più sulle funzioni disponibili,
consulta Aligner nel riferimento API. Alcune funzioni di allineamento
allineano i dati
e li convertono da un tipo o genere di metrica a un altro. Per una spiegazione
dettagliata, vedi Tipi, tipi e conversioni.
API
Configura il periodo di allineamento impostando i campi
aggregations.alignmentPeriod e aggregations.perSeriesAligner
nelle strutture MetricThreshold e
MetricAbsence.
Per saperne di più sulle funzioni disponibili,
consulta Aligner nel riferimento API. Alcune funzioni di allineamento
allineano i dati
e li convertono da un tipo o genere di metrica a un altro. Per una spiegazione
dettagliata, vedi Tipi, conversioni e generi.
Per illustrare l'effetto del periodo di allineamento su una condizione in una policy di avviso, considera una condizione di soglia 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. Supponi inoltre che la condizione sia soddisfatta quando il valore allineato della serie temporale è maggiore di 2 per almeno tre minuti e che la condizione venga valutata ogni minuto.
In questo esempio, la finestra di ritest, descritta nella sezione successiva, è di
tre minuti. La seguente figura illustra diverse valutazioni sequenziali
della condizione:
Ogni riga della figura illustra una singola valutazione della condizione. Vengono
mostrati i dati delle serie temporali. I punti nel periodo di allineamento sono mostrati con
punti blu; i punti più vecchi sono neri. Ogni riga mostra il valore allineato e
se questo valore è maggiore della soglia di due. Per la riga etichettata
start, il valore allineato è pari a 1, che è inferiore alla soglia.
Nella 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 finestra di ritest.
Finestre di ripetizione dei test
La condizione di un criterio di avviso ha una finestra di test, che impedisce che la condizione venga soddisfatta a causa di una singola misurazione o previsione. Ad esempio, supponiamo che la finestra di nuovo test di una condizione sia impostata su 15 minuti. Di seguito viene descritto il comportamento della condizione in base al suo tipo:
- Le condizioni di soglia della 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 metrica vengono 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 intervallo di 15 minuti prevede che la serie temporale supererà la soglia entro l'intervallo di previsione.
Per le policy con una condizione, viene aperto un avviso e vengono inviate notifiche quando la condizione viene soddisfatta. Questi avvisi rimangono aperti finché la condizione continua a essere soddisfatta.
Console Google Cloud
Configura la finestra di ripetizione del test utilizzando il campo Finestra di ripetizione del test nel passaggio Configura trigger di avviso.
API
Configura la finestra di ripetizione del test impostando il campo denominato
duration nelle strutture MetricThreshold e
MetricAbsence.
La figura precedente mostrava tre valutazioni di una condizione di soglia della metrica. Al momento start + 2 minutes, il valore allineato è superiore alla soglia; tuttavia, la condizione non è soddisfatta perché la finestra di test è impostata su tre minuti. La figura seguente illustra i risultati delle valutazioni successive della condizione:
Anche se il valore allineato è superiore alla soglia al
momento start + 2 minutes, la condizione non viene soddisfatta finché il valore allineato
non è superiore alla soglia per tre minuti. Questo evento si verifica all'ora
start + 5 minutes.
Una condizione reimposta la finestra di nuovo test ogni volta che una misurazione o una previsione non soddisfa la condizione. Pertanto, imposta la finestra di ripetizione del test in modo che sia abbastanza lunga da ridurre al minimo i falsi positivi, ma abbastanza breve da verificare che gli avvisi vengano aperti in modo tempestivo. Questo comportamento è illustrato nel seguente esempio:
Esempio
Questa criterio di avviso contiene una condizione di soglia della metrica che specifica un intervallo di tempo di cinque minuti per il nuovo test.
Se la latenza della risposta HTTP è superiore a due secondi
e se la latenza è superiore alla soglia per cinque minuti,
apri un avviso e invia un'email al tuo team di assistenza.
La seguente sequenza illustra in che modo la finestra di ritest influisce sulla valutazione della condizione:
- La latenza HTTP è inferiore a due secondi.
- Per i tre minuti consecutivi successivi, la latenza HTTP è superiore a due secondi.
- Nella misurazione successiva, la latenza è inferiore a due secondi, quindi la condizione reimposta la finestra di ritest.
Nei cinque minuti consecutivi successivi, la latenza HTTP è superiore a due secondi, quindi la condizione è soddisfatta.
Poiché la criterio di avviso ha una condizione, Monitoring invia notifiche quando la condizione viene soddisfatta.
Best practice per impostare il periodo di allineamento e la finestra di retest
Il periodo di allineamento determina il numero di campioni combinati dall'allineatore. L'intervallo di campionamento, il ritardo di importazione e il numero di campioni che vuoi combinare influiscono sulla modalità di impostazione del periodo di allineamento:
Il periodo di allineamento non deve superare le 24 ore meno il ritardo di importazione.
Ti consigliamo di impostare il periodo di allineamento in modo che sia almeno pari al ritardo di importazione. Tuttavia, il periodo di allineamento deve sempre essere almeno pari all'intervallo di campionamento.
Per le condizioni di soglia metrica, il valore massimo tipico del periodo di allineamento è 25 ore meno il ritardo di importazione del tipo di metrica. Ad esempio, se il ritardo di importazione per una metrica è di 6 ore, il valore massimo del periodo di allineamento è di 19 ore. Puoi utilizzare PromQL per inviare avvisi relativi a dati più vecchi di 25 ore. Per saperne di più, consulta Utilizzare PromQL per creare policy di avviso.
Ad esempio, se il ritardo di importazione per un tipo di metrica è di 6 ore, ti consigliamo di utilizzare un periodo di allineamento compreso tra 6 e 18 ore. Supponiamo che l'intervallo di campionamento sia di 60 secondi. Se imposti il periodo di allineamento su 6 ore e 5 minuti, l'allineatore combina in media 5 campioni.
Se un tipo di metrica ha un ritardo di importazione molto lungo, ad esempio 18 ore, imposta il periodo di allineamento in modo che sia almeno lungo quanto l'intervallo di campionamento, ma al massimo 24 ore meno il ritardo di importazione.
Utilizza la finestra di ripetizione del test per specificare la reattività dell'avviso. Ad esempio, se imposti la finestra di nuovo test su 20 minuti per una condizione di assenza metrica, non devono essere presenti dati per 20 minuti prima che la condizione venga soddisfatta. Per un criterio di avviso più reattivo, imposta la finestra di nuovo test su un valore più piccolo. Per le condizioni di soglia metrica, per avere la criterio di avviso più reattiva, imposta la finestra di nuovo test su zero. Un singolo valore allineato fa sì che questi tipi di condizioni vengano soddisfatte.
Se imposti la finestra di ripetizione del test, potresti dover ridurre il periodo di allineamento a causa dei limiti per i criteri di avviso.
Le condizioni delle policy di avviso vengono valutate a una frequenza fissa. Le scelte che fai per il periodo di allineamento e la finestra di ri-test non determinano la frequenza con cui viene valutata la condizione.
Norme con più condizioni
Una criterio di avviso può contenere fino a sei condizioni.
Se utilizzi l'API Cloud Monitoring o se la tua criterio di avviso ha più condizioni, devi specificare quando viene aperto un avviso. Per configurare la modalità di combinazione di più condizioni, esegui una delle seguenti operazioni:
Console Google Cloud
Configura le opzioni del combinatore nel passaggio Trigger per più condizioni.
API
Configura le opzioni del combinatore con il campo combiner della struttura
AlertPolicy.
Questa tabella elenca le impostazioni nella console Google Cloud , il valore equivalente nell'API Cloud Monitoring e una descrizione di ciascuna impostazione:
| Valore dei trigger delle norme dellaGoogle Cloud console |
API Cloud Monitoring combiner value |
Significato |
|---|---|---|
| Qualsiasi condizione è soddisfatta | OR |
Viene aperto un avviso se una risorsa soddisfa una delle condizioni. |
| Tutte le condizioni sono soddisfatte anche per risorse diverse per ogni condizione (impostazione predefinita) |
AND |
Viene aperto un avviso per ogni condizione soddisfatta quando tutte le condizioni sono soddisfatte, anche se una risorsa diversa fa sì che queste condizioni vengano soddisfatte. |
| Tutte le condizioni sono soddisfatte | AND_WITH_MATCHING_RESOURCE |
Viene aperto un avviso per ogni condizione soddisfatta quando tutte le condizioni sono soddisfatte, solo se la stessa risorsa fa sì che ogni condizione venga soddisfatta. Questa impostazione è la combinazione più rigorosa. |
In questo contesto, il termine soddisfatta
significa che la configurazione della condizione restituisce il valore true. Ad esempio, se la configurazione è Any time series is greater than 10 for 5 minutes, quando questa istruzione restituisce il valore true, la condizione è soddisfatta.
Esempio
Considera un progetto Google Cloud che contiene due istanze VM, vm1 e vm2. Supponiamo inoltre di creare un criterio di avviso con due condizioni:
- La condizione denominata
CPU usage is too highmonitora l'utilizzo della CPU delle istanze. Questa condizione viene soddisfatta quando l'utilizzo della CPU di qualsiasi istanza è superiore a 100 ms/s per 1 minuto. - La condizione denominata
Excessive utilizationmonitora l'utilizzo della CPU delle istanze. Questa condizione viene soddisfatta quando l'utilizzo della CPU di qualsiasi istanza è superiore al 60% per 1 minuto.
Inizialmente, supponi che entrambe le condizioni restituiscano il valore false.
Supponiamo poi 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, la condizione
CPU usage is too high è soddisfatta. Se le
condizioni vengono combinate con Qualsiasi condizione è soddisfatta, viene creato un avviso
perché una condizione è soddisfatta. Se le condizioni sono combinate con
Tutte le condizioni sono soddisfatte o
Tutte le condizioni sono soddisfatte anche per risorse diverse per ogni condizione,
non viene creato un avviso. Queste scelte di combinazione richiedono che entrambe le condizioni siano soddisfatte.
Supponiamo poi 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 alla combinazione delle condizioni:
Qualsiasi condizione è soddisfatta: viene creato un avviso quando una risorsa soddisfa una condizione. In questo esempio, vm2 fa sì che la condizione
Excessive utilizationvenga soddisfatta.Se vm2 soddisfa la condizione
CPU usage is too high, viene creato anche un avviso. Viene creato un avviso 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 avviso perché entrambe le condizioni sono soddisfatte.
Tutte le condizioni sono soddisfatte: non viene creato un avviso perché questo combinatore richiede che la stessa risorsa soddisfi tutte le condizioni. In questo esempio, non viene creato alcun avviso perché vm1 soddisfa
CPU usage is too highmentre vm2 soddisfaExcessive utilization.
Dati parziali delle metriche
Quando i dati delle serie temporali smettono di arrivare o quando i dati sono in ritardo, il monitoraggio li classifica come mancanti. I dati mancanti possono impedire la chiusura degli avvisi. I ritardi nell'arrivo dei dati dai cloud provider di terze parti possono arrivare fino a 30 minuti, con ritardi di 5-15 minuti più comuni. Un ritardo prolungato, superiore al periodo di ritest, può far sì che le condizioni entrino in uno stato "sconosciuto". Quando i dati arrivano, Monitoraggio potrebbe aver perso parte della cronologia recente delle condizioni. Un'ispezione successiva dei dati delle serie temporali potrebbe non rivelare questo problema perché non ci sono prove di ritardi una volta che i dati arrivano.
Console Google Cloud
Puoi configurare la modalità di valutazione di una condizione di soglia metrica da parte di Monitoring quando i dati smettono di arrivare. Ad esempio, quando un avviso è aperto e una misurazione prevista non arriva, vuoi che Monitoring lasci l'avviso aperto o lo chiuda immediatamente? Allo stesso modo, quando i dati smettono di arrivare e non è aperto alcun avviso, vuoi che venga aperto un avviso? Infine, per quanto tempo deve rimanere aperta una notifica dopo l'interruzione dell'arrivo dei dati?
Esistono due campi configurabili che specificano in che modo Monitoring valuta le condizioni di soglia delle metriche quando i dati smettono di arrivare:
Per configurare il modo in cui Monitoring determina il valore di sostituzione per i dati mancanti, utilizza il campo Valutazione dei dati mancanti, che hai impostato nel passaggio Trigger di condizione. Questo campo è disattivato quando la finestra di ripetizione del test è impostata su Nessun nuovo test.
La finestra di nuovo test è il campo denominato durata nell'API Cloud Monitoring.
Per configurare il periodo di attesa di Monitoring prima di chiudere un avviso aperto dopo l'interruzione dell'arrivo dei dati, utilizza il campo Durata chiusura automatica avviso. Hai impostato la durata della chiusura automatica nel passaggio Notifica. La durata di chiusura automatica predefinita è di sette giorni.
Di seguito sono descritte le diverse opzioni per il campo dati mancante:
| Google Cloud console Campo "Valutazione dei dati mancanti" |
Riepilogo | Dettagli |
|---|---|---|
| Dati mancanti vuoti | Gli avvisi aperti rimangono aperti. I nuovi avvisi non vengono aperti. |
Per le condizioni soddisfatte, la condizione continua a essere soddisfatta quando i dati smettono di arrivare. Se è aperto un avviso per questa condizione, l'avviso rimane aperto. Quando un avviso è aperto e non arrivano dati, il timer di chiusura automatica si avvia dopo un ritardo di almeno 15 minuti. Se il timer scade, l'avviso viene chiuso. Per le condizioni che non vengono soddisfatte, la condizione continua a non essere soddisfatta quando i dati smettono di arrivare. |
| Punti dati mancanti considerati come valori che violano la condizione della policy | Gli avvisi aperti rimangono aperti. È possibile aprire nuovi avvisi. |
Per le condizioni soddisfatte, la condizione continua a essere soddisfatta quando i dati smettono di arrivare. Se è aperto un avviso per questa condizione, l'avviso rimane aperto. Quando un avviso è aperto e non arrivano dati per la durata della chiusura automatica più 24 ore, l'avviso viene chiuso. Per le condizioni che non vengono soddisfatte, questa impostazione fa sì che la condizione di soglia della metrica si comporti come un |
| Punti dati mancanti considerati come valori che non violano la condizione della policy | Gli avvisi aperti vengono chiusi. I nuovi avvisi non vengono aperti. |
Per le condizioni soddisfatte, la condizione smette di essere soddisfatta quando i dati smettono di arrivare. Se è aperto un avviso per questa condizione, l'avviso viene chiuso. Per le condizioni che non vengono soddisfatte, la condizione continua a non essere soddisfatta quando i dati smettono di arrivare. |
API
Puoi configurare la modalità di valutazione di una condizione di soglia metrica da parte di Monitoring quando i dati smettono di arrivare. Ad esempio, quando un avviso è aperto e una misurazione prevista non arriva, vuoi che Monitoring lasci l'avviso aperto o lo chiuda immediatamente? Allo stesso modo, quando i dati smettono di arrivare e non è aperto alcun avviso, vuoi che venga aperto un avviso? Infine, per quanto tempo deve rimanere aperta una notifica dopo l'interruzione dell'arrivo dei dati?
Esistono due campi configurabili che specificano in che modo Monitoring valuta le condizioni di soglia delle metriche quando i dati smettono di arrivare:
Per configurare il modo in cui Monitoring determina il valore di sostituzione per i dati mancanti, utilizza il campo
evaluationMissingDatadella strutturaMetricThreshold. Questo campo viene ignorato quando il campodurationè zero.Per configurare il periodo di attesa del monitoraggio prima di chiudere un avviso aperto dopo l'interruzione dell'arrivo 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 avvisi aperti rimangono aperti. I nuovi avvisi non vengono aperti. |
Per le condizioni soddisfatte, la condizione continua a essere soddisfatta quando i dati smettono di arrivare. Se un avviso è aperto per questa condizione, l'avviso rimane aperto. Quando un avviso è aperto e non arrivano dati, il timer di chiusura automatica si avvia dopo un ritardo di almeno 15 minuti. Se il timer scade, l'avviso viene chiuso. Per le condizioni che non vengono soddisfatte, la condizione continua a non essere soddisfatta quando i dati smettono di arrivare. |
EVALUATION_MISSING_DATA_ACTIVE |
Gli avvisi aperti rimangono aperti. È possibile aprire nuovi avvisi. |
Per le condizioni soddisfatte, la condizione continua a essere soddisfatta quando i dati smettono di arrivare. Se un avviso è aperto per questa condizione, l'avviso rimane aperto. Quando un avviso è aperto e non arrivano dati per la durata della chiusura automatica più 24 ore, l'avviso viene chiuso. Per le condizioni che non vengono soddisfatte, questa impostazione fa sì che la
condizione di soglia della metrica si comporti come un
|
EVALUATION_MISSING_DATA_INACTIVE |
Gli avvisi aperti vengono chiusi. I nuovi avvisi non vengono aperti. |
Per le condizioni soddisfatte, la condizione smette di essere soddisfatta quando i dati smettono di arrivare. Se è aperto un avviso per questa condizione, l'avviso viene chiuso. Per le condizioni che non vengono soddisfatte, la condizione continua a non essere soddisfatta quando i dati smettono di arrivare. |
Puoi ridurre al minimo i problemi dovuti alla mancanza di dati effettuando una delle seguenti operazioni:
- Contatta il tuo cloud provider di terze parti per identificare i modi per ridurre la latenza di raccolta delle metriche.
- Utilizza finestre di ritest più lunghe nelle condizioni. L'utilizzo di una finestra di nuovo test più lunga ha lo svantaggio di rendere meno reattive le policy di avviso.
Scegli metriche con un ritardo di raccolta inferiore:
- Metriche dell'agente Monitoring, soprattutto quando l'agente è in esecuzione su istanze VM in cloud di terze parti.
- Metriche personalizzate, quando scrivi i relativi dati direttamente in Monitoring.
- Metriche basate su log, se la raccolta delle voci di log non è ritardata.
Per saperne di più, consulta la panoramica dell'agente Monitoring, la panoramica delle metriche definite dall'utente e le metriche basate su log.
Quando il monitoraggio invia notifiche e crea avvisi
Cloud Monitoring invia una notifica quando una serie temporale soddisfa una condizione. La notifica viene inviata a tutti i canali di notifica. Non puoi limitare una notifica a un canale specifico o a un sottoinsieme dei canali del tuo criterio.
Se configuri le notifiche ripetute, la stessa notifica viene inviata nuovamente a canali di notifica specifici per il criterio di avviso.
Potresti ricevere più notifiche uniche relative a un criterio di avviso quando si verifica una delle seguenti condizioni:
Una condizione monitora più serie temporali.
Un criterio contiene più condizioni. In questo caso, le notifiche che ricevi dipendono dal valore dell'attivazione multicondizione del criterio di avviso:
Tutte le condizioni sono soddisfatte: quando tutte le condizioni sono soddisfatte, per ogni serie temporale che soddisfa una condizione, il criterio di avviso invia una notifica e crea un avviso.
Non puoi configurare Cloud Monitoring in modo che crei un solo avviso e invii una sola notifica quando la criterio di avviso contiene più condizioni.
Qualsiasi condizione è soddisfatta: la criterio di avviso invia una notifica quando una serie temporale fa sì che la condizione venga soddisfatta.
Per saperne di più, consulta Policy con più condizioni.
Le policy di avviso create utilizzando l'API Cloud Monitoring ti inviano una notifica quando la condizione viene soddisfatta e quando non viene più soddisfatta. Le policy di avviso create utilizzando la console Google Cloud non inviano una notifica quando la condizione non viene più soddisfatta, a meno che tu non abbia attivato questo comportamento.
Quando il monitoraggio non invia notifiche o non crea avvisi
Nelle seguenti situazioni, Monitoring non crea avvisi né invia notifiche quando le condizioni di una criterio di avviso sono soddisfatte:
- La criterio di avviso è disabilitata.
- La criterio di avviso è posticipata.
- Il monitoraggio ha raggiunto il limite per il numero massimo di avvisi aperti.
Policy di avviso disattivate
Il monitoraggio non invia avvisi di creazione né notifiche per le policy di avviso disattivate. Tuttavia, Monitoring continua a valutare le condizioni di unacriterio di avvisoo disattivata.
Quando attivi una policy disattivata, Monitoring valuta i valori di tutte le condizioni nell'ultima finestra di riapprovazione. La finestra di nuovo test più recente potrebbe includere dati acquisiti prima, durante e dopo l'attivazione della norma. Le condizioni di un criterio disattivato possono essere soddisfatte immediatamente dopo la riattivazione del criterio, anche con finestre di test di grandi dimensioni.
Ad esempio, supponiamo di avere una criterio di avviso che monitora un processo specifico e di disattivarla. La settimana successiva, il processo non funziona e, poiché lacriterio di avvisoo è disattivata, non ricevi notifiche. Se riavvii il processo e attivi immediatamente la criterio di avviso, Monitoring riconosce che il processo non è attivo negli ultimi cinque minuti e apre un avviso.
Gli avvisi relativi a una criterio di avviso disattivata rimangono aperti fino alla scadenza della durata di chiusura automatica della policy.
Criteri di avviso posticipati
Il monitoraggio non invia notifiche né crea avvisi per unacriterio di avvisoo posticipata. Ti consigliamo di posticipare i criteri di avviso quando vuoi impedire che un criterio di avviso invii notifiche solo per intervalli brevi. Ad esempio, prima di eseguire la manutenzione di una macchina virtuale (VM), puoi creare un posticipo e aggiungere ai criteri di posticipo le policy di avviso che monitorano l'istanza.
Quando posticipi un criterio di avviso, Monitoring chiude tutti gli avvisi aperti correlati al criterio. Monitoring può aprire nuovi avvisi dopo la scadenza del posticipo. Per informazioni, vedi Posticipare notifiche e avvisi.
Limiti di notifiche e avvisi aperti
Una criterio di avviso può essere applicata a molte risorse e un problema che interessa tutte le risorse può causare criterio di avviso9;apertura di avvisi per ogni risorsa. Viene aperto un avviso per ogni serie temporale che soddisfa una condizione.
Per evitare di sovraccaricare il sistema, il numero di avvisi che una singola norma può aprire contemporaneamente è limitato a 1000.
Ad esempio, considera un criterio che si applica a 2000 istanze Compute Engine e ogni istanza fa sì che le condizioni di avviso vengano soddisfatte. Il monitoraggio limita il numero di avvisi aperti a 1000. Le condizioni rimanenti soddisfatte vengono ignorate finché non vengono chiusi alcuni degli avvisi aperti per quella policy.
A causa di questo limite, un singolo canale di notifica può ricevere fino a 1000 notifiche contemporaneamente. Se la tua policy di avviso ha più canali di notifica, questo limite si applica a ciascun canale di notifica in modo indipendente.
Latenza
Latenza si riferisce al ritardo tra il momento in cui Monitoring campiona una metrica e quello in cui il punto dati della metrica diventa visibile come dati delle serie temporali. La latenza influisce sul momento in cui vengono inviate le notifiche. Ad esempio, se una metrica monitorata ha una latenza fino a 180 secondi, allora Monitoring non creerà un avviso fino a 180 secondi dopo che la condizione del criterio di avviso restituisce true. Per maggiori informazioni, consulta la sezione 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 Google Cloud , la maggior parte delle metriche non è visibile per 60 secondi dopo la raccolta; tuttavia, il ritardo dipende dalla metrica. I calcoli delle policy di avviso richiedono un ritardo aggiuntivo fino a 5 minuti e 30 secondi. Per le metriche AWS CloudWatch, il ritardo di visibilità può essere di diversi minuti. Per i controlli dell'uptime, questo può essere una media di due minuti (dalla fine della finestra di nuovo test).
Finestra di ripetizione test: la finestra configurata per la condizione. Le condizioni vengono soddisfatte solo quando una condizione è vera durante l'intero periodo di ritest. Ad esempio, un'impostazione della finestra di ripetizione del test di cinque minuti causa ritardi nella notifica di almeno cinque minuti dal momento in cui si verifica l'evento.
Tempo di arrivo della notifica: i canali di notifica, come email e SMS, potrebbero subire latenze di rete o di altro tipo (non correlate a ciò che viene inviato), a volte anche di diversi minuti. Su alcuni canali, come SMS e Slack, non è garantita la consegna dei messaggi.
Passaggi successivi
Per informazioni su come creare un criterio di avviso, consulta i seguenti documenti:
Per un assortimento di policy di avviso, consulta Policy di esempio.