Questo documento descrive in che modo i periodi di allineamento e le finestre di nuovo test determinano quando viene soddisfatta una condizione, in che modo i criteri di avviso combinano più condizioni e in che modo sostituiscono i punti dati mancanti. Descrive inoltre il numero massimo di incidenti aperti per un criterio, il numero di notifiche per incidente e le cause dei 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 Monitorare i log.
Periodi di allineamento e finestre di nuovo test
Cloud Monitoring valuta il periodo di allineamento e la finestra di nuovo test per determinare se la condizione di un criterio di avviso è stata soddisfatta.
Periodo allineamento
Prima che i dati delle serie temporali vengano monitorati da un criterio di avviso, devono essere regolarizzati in modo che il criterio di avviso abbia dati con spaziatura regolare da valutare. Il processo di regolarizzazione è chiamato allineamento.
L'allineamento prevede due passaggi:
Suddivisione della serie temporale in intervalli di tempo regolari, chiamata anche raggruppamento in bucket dei dati. L'intervallo è il periodo di allineamento.
Calcolo di un singolo valore per i punti nel periodo di allineamento. Puoi scegliere come viene calcolato il 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 è chiamato valore allineato.
Per ulteriori informazioni 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 avanza 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
Per configurare il periodo di allineamento, scegli un valore per i seguenti campi nella pagina Condizioni di avviso:
- Finestra mobile: specifica l'intervallo di tempo da valutare.
- Funzione finestra temporale continua: specifica la funzione matematica da eseguire sulla finestra dei punti dati.
Per ulteriori informazioni sulle funzioni disponibili, consulta Aligner nella documentazione di riferimento dell'API. Alcune funzioni di allineamento consentono di allineare i dati e di convertirli da un tipo o tipo di metrica a un altro. Per una spiegazione dettagliata, consulta Tipi, conversioni e tipi di conversione.
API
Per configurare il periodo di allineamento, imposta i campi aggregations.alignmentPeriod e aggregations.perSeriesAligner nelle strutture MetricThreshold e MetricAbsence.
Per ulteriori informazioni sulle funzioni disponibili, consulta Aligner nella documentazione di riferimento dell'API. Alcune funzioni di allineamento consentono di allineare i dati e di convertirli da un tipo o tipo di metrica a un altro. Per una spiegazione dettagliata, consulta Tipi, conversioni e tipi di conversione.
Per illustrare l'effetto del periodo di allineamento su una condizione in un criterio 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. 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.
In questo esempio, il periodo di allineamento è di due minuti e la finestra di nuovo test,
descritta nella sezione successiva, è di tre minuti.
La figura seguente illustra diverse valutazioni sequenziali della condizione:
Ogni riga della figura illustra una singola valutazione della condizione. Vengono mostrati i dati della serie temporale. I punti nel periodo di allineamento sono mostrati con puntini blu; i punti precedenti 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.
Alla valutazione successiva, la somma dei campioni nel periodo di allineamento è pari a due.
Alla terza valutazione, la somma è pari a tre e, poiché questo valore è superiore alla soglia, viene avviato un timer per la finestra di esecuzione del nuovo test.
Finestre di ripetizione test
La condizione di un criterio di avviso ha una finestra di riesami, che impedisce la soddisfazione della condizione a causa di una singola misurazione o previsione. Ad esempio, supponiamo che la finestra di ripetizione del 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 metrica sono 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 vengono soddisfatte quando non arrivano dati per una serie temporale in un intervallo di 15 minuti.
- Le condizioni di previsione sono soddisfatte quando ogni previsione prodotta durante un intervallo di 15 minuti prevede che la serie temporale violerà la soglia all'interno dell'intervallo di previsione.
Per i criteri con una 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
Configura la finestra di nuovo test utilizzando il campo Finestra di nuovo test nel passaggio Configura l'attivatore di avvisi.
API
La finestra di nuovo test viene configurata impostando il campo chiamato
duration nelle strutture MetricThreshold e
MetricAbsence.
La figura precedente illustra tre valutazioni di una condizione di soglia metrica. Al
momento start + 2 minutes, il valore allineato è superiore alla soglia;
tuttavia, la condizione non è soddisfatta perché la finestra di nuovo 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 è soddisfatta finché il valore allineato
non è superiore alla soglia per tre minuti. Questo evento si verifica alle ore
start + 5 minutes.
Una condizione reimposta la finestra di nuovo test ogni volta che una misurazione o una previsione non soddisfa la condizione. Questo comportamento è illustrato nell'esempio seguente:
Esempio: questo criterio di avviso contiene una condizione di soglia metrica che specifica un intervallo di tempo per il nuovo test di cinque minuti.
Se la latenza della risposta HTTP è superiore a due secondi
e se la latenza è superiore alla soglia per cinque minuti,
apri un incidente e invia un'email al team di assistenza.La sequenza seguente illustra in che modo la finestra di nuovo test 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 nuovo test.
Per i cinque minuti consecutivi successivi, la latenza HTTP è superiore a due secondi, quindi la condizione è soddisfatta.
Poiché il criterio di avviso ha una condizione, il monitoraggio invia notifiche quando la condizione è soddisfatta.
Imposta la finestra di nuovo test in modo che sia sufficientemente lunga da ridurre al minimo i falsi positivi, ma sufficientemente breve da garantire che gli incidenti vengano aperti in modo tempestivo.
Best practice per l'impostazione del periodo di allineamento e della finestra di nuovo test
Il periodo di allineamento determina il numero di campioni combinati con l'allineatore:
Il valore minimo del periodo di allineamento per un tipo di metrica è il periodo di campionamento del 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 sec o 1500 secondi.
Il valore massimo del periodo di allineamento è 24 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 18 ore.
Utilizza la finestra di ripetizione del test per specificare la reattività dell'avviso. Ad esempio, se imposti la finestra di riattivazione del test su 20 minuti per una condizione di assenza di metriche, 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 inferiore. Per le condizioni di soglia metrica, per avere il criterio di avviso più reattivo, imposta la finestra di nuovo test su zero. Un singolo valore allineato consente di 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 nuovo test non determinano la frequenza con cui viene valutata la condizione.
Norme con più condizioni
Un criterio di avviso può contenere fino a 6 condizioni.
Se utilizzi l'API Cloud Monitoring o se il tuo criterio di avviso ha più condizioni, devi specificare quando viene aperto un incidente. Per configurare la combinazione di più condizioni, svolgi una delle seguenti operazioni:
Console Google Cloud
Configura le opzioni dell'operatore di combinazione nel passaggio Trigger per più condizioni.
API
Le opzioni dell'operatore di combinazione vengono configurate 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 ogni impostazione:
| Console Google Cloud Valore degli attivatori dei criteri |
Valore combiner dell'API Cloud Monitoring |
Significato |
|---|---|---|
| Qualsiasi condizione è soddisfatta | OR |
Viene aperto un incidente se una risorsa causa la soddisfazione di una delle condizioni. |
| Tutte le condizioni sono soddisfatte anche per risorse diverse per ogni condizione (valore predefinito) |
AND |
Viene aperto un incidente se ogni condizione è soddisfatta, anche se una risorsa diversa causa il verificarsi di queste condizioni. |
| Tutte le condizioni sono soddisfatte | AND_WITH_MATCHING_RESOURCE |
Viene aperto un incidente se la stessa risorsa causa la soddisfazione di ogni condizione. Questa impostazione è la scelta di combinazione più rigorosa. |
In questo contesto, il termine soddisfatta significa che la configurazione della condizione restituisce true. Per
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 contenente due VM, vm1 e vm2. Inoltre, supponiamo che tu crei un criterio di avviso con due condizioni:
- La condizione denominata
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 denominata
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 restituiscano false.
Supponiamo inoltre che l'utilizzo della CPU di vm1 superi 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 incidente perché è soddisfatta una condizione. 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 incidente. Queste scelte di combinazioni richiedono che entrambe le condizioni siano soddisfatte.
Supponiamo inoltre 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 che cosa accade in base alla combinazione delle condizioni:
Qualsiasi condizione è soddisfatta: un incidente viene creato quando una risorsa fa sì che venga soddisfatta una condizione. In questo esempio, vm2 fa sì che la condizione
Excessive utilizationvenga soddisfatta.Se vm2 causa la condizione
CPU usage is too high, viene anche creato un incidente. Viene creato un incidente perché vm1 e vm2 che causano il verificarsi della 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 causi la soddisfazione di tutte le condizioni. In questo esempio non viene creato alcun incidente perché la VM1 consente di soddisfare
CPU usage is too high, mentre la VM2 consente di soddisfareExcessive utilization.
Dati delle metriche parziali
Quando i dati delle serie temporali non arrivano o sono in ritardo, il monitoraggio li classifica come mancanti. La mancanza di dati può impedire la chiusura degli incidenti. I ritardi nei dati in arrivo da fornitori di cloud di terze parti possono arrivare fino a 30 minuti, con ritardi di 5-15 minuti più comuni. Un ritardo prolungato, più lungo del periodo di tempo per il nuovo test, può causare l'ingresso delle condizioni in uno stato "sconosciuto". Quando i dati arrivano, il 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 c'è alcuna evidenza di ritardi una volta che i dati arrivano.
Console Google Cloud
Puoi configurare il modo in cui Monitoring valuta una condizione di soglia metrica quando i dati non arrivano più. Ad esempio, quando è aperto un incidente e non arriva una misurazione prevista, vuoi che il monitoraggio lasci aperto l'incidente o lo chiuda immediatamente? Analogamente, quando i dati non arrivano più e non è aperto alcun incidente, vuoi che venga aperto un incidente? Infine, per quanto tempo deve rimanere aperto un incidente dopo l'interruzione dell'arrivo dei dati?
Esistono due campi configurabili che specificano in che modo il monitoraggio valuterà le condizioni di soglia delle metriche quando i dati non arrivano più:
Per configurare la modalità di determinazione del valore di sostituzione da parte del monitoraggio per i dati mancanti, utilizza il campo Valutazione dei dati mancanti impostato nel passaggio Attivazione della condizione. Questo campo è disattivato quando il periodo di ripetizione del test è impostato su Nessun nuovo test.
La finestra di nuovo test è il campo denominato durata nell'API Cloud Monitoring.
Per configurare il tempo di attesa di Monitoring prima di chiudere un incidente aperto dopo l'interruzione dell'arrivo dei dati, utilizza il campo Durata chiusura automatica incidenti. La durata della chiusura automatica viene impostata nel passaggio Notifica. La durata predefinita della chiusura automatica è di sette giorni.
Di seguito sono descritte le diverse opzioni per il campo dei dati mancanti:
| Console Google Cloud Campo "Valutazione dei dati mancanti" |
Riepilogo | Dettagli |
|---|---|---|
| Dati mancanti vuoti | Gli incidenti aperti rimangono aperti. Non vengono aperti nuovi incidenti. |
Per le condizioni soddisfatte, la condizione continua a essere soddisfatta quando i dati non arrivano più. Se un incidente è aperto per questa condizione, l'incidente rimane aperto. Quando un incidente è aperto e non arrivano dati, il timer di chiusura automatica si avvia dopo un ritardo di almeno 15 minuti. Se il timer scade, l'incidente viene chiuso. Per le condizioni che non sono soddisfatte, la condizione continua a non essere soddisfatta quando i dati non arrivano più. |
| Punti dati mancanti trattati come valori che violano la condizione del criterio | Gli incidenti aperti rimangono aperti. È possibile aprire nuovi incidenti. |
Per le condizioni soddisfatte, la condizione continua a essere soddisfatta quando i dati non arrivano più. Se un incidente è aperto per questa condizione, l'incidente rimane aperto. Quando un incidente è aperto e non arrivano dati per la durata della chiusura automatica più 24 ore, l'incidente viene chiuso. Per le condizioni non soddisfatte, questa impostazione fa sì che la condizione di soglia metrica si comporti come un |
| Punti dati mancanti trattati come valori che non violano la condizione delle norme | Gli incidenti aperti vengono chiusi. Non vengono aperti nuovi incidenti. |
Per le condizioni soddisfatte, la condizione non è più soddisfatta quando i dati non arrivano più. Se è aperto un incidente per questa condizione, l'incidente è chiuso. Per le condizioni che non sono soddisfatte, la condizione continua a non essere soddisfatta quando i dati non arrivano più. |
API
Puoi configurare la modalità di valutazione da parte di Monitoring di una condizione di soglia metrica quando i dati non arrivano più. Ad esempio, quando è aperto un incidente e non arriva una misurazione prevista, vuoi che il monitoraggio lasci aperto l'incidente o lo chiuda immediatamente? Analogamente, quando i dati non arrivano più e non è aperto alcun incidente, vuoi che venga aperto un incidente? Infine, per quanto tempo deve rimanere aperto un incidente dopo l'interruzione dell'arrivo dei dati?
Esistono due campi configurabili che specificano in che modo il monitoraggio valuterà le condizioni di soglia delle metriche quando i dati non arrivano più:
Per configurare il modo in cui il monitoraggio 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 Monitoraggio prima di chiudere un incidente 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:
CampoevaluationMissingData dell'API |
Riepilogo | Dettagli |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Gli incidenti aperti rimangono aperti. Non vengono aperti nuovi incidenti. |
Per le condizioni soddisfatte, la condizione continua a essere soddisfatta quando i dati non arrivano più. Se un incidente è aperto per questa condizione, l'incidente rimane aperto. Quando un incidente è aperto e non arrivano dati, il timer di chiusura automatica si avvia dopo un ritardo di almeno 15 minuti. Se il timer scade, l'incidente viene chiuso. Per le condizioni che non sono soddisfatte, la condizione continua a non essere soddisfatta quando i dati non arrivano più. |
EVALUATION_MISSING_DATA_ACTIVE |
Gli incidenti aperti rimangono aperti. È possibile aprire nuovi incidenti. |
Per le condizioni soddisfatte, la condizione continua a essere soddisfatta quando i dati non arrivano più. Se un incidente è aperto per questa condizione, l'incidente rimane aperto. Quando un incidente è aperto e non vengono ricevuti dati per la durata della chiusura automatica più 24 ore, l'incidente viene chiuso. Per le condizioni non soddisfatte, questa impostazione fa sì che la condizione di soglia metrica si comporti come un |
EVALUATION_MISSING_DATA_INACTIVE |
Gli incidenti aperti vengono chiusi. Non vengono aperti nuovi incidenti. |
Per le condizioni soddisfatte, la condizione non è più soddisfatta quando i dati non arrivano più. Se è aperto un incidente per questa condizione, l'incidente è chiuso. Per le condizioni che non sono soddisfatte, la condizione continua a non essere soddisfatta quando i dati non arrivano più. |
Puoi ridurre al minimo i problemi dovuti ai dati mancanti effettuando una delle seguenti operazioni:
- Contatta il tuo provider cloud di terze parti per identificare i modi per ridurre la latenza della raccolta delle metriche.
- Utilizza finestre di riesami più lunghe nelle condizioni. L'utilizzo di una finestra di retest più lunga ha lo svantaggio di rendere i criteri di avviso meno sensibili.
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 relativi dati direttamente in monitoraggio.
- Metriche basate su log, se la raccolta delle voci di log non è in ritardo.
Per ulteriori informazioni, consulta la panoramica dell'agente di monitoraggio, la panoramica delle metriche definite dall'utente e le metriche basate su log.
Quando il monitoraggio invia notifiche e crea incidenti
Cloud Monitoring invia una notifica quando una serie temporale fa sì che venga soddisfatta 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 di canali previsti dalle tue norme.
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 univoche relative a un criterio di avviso quando una delle seguenti condizioni è vera:
Una condizione monitora più serie temporali.
Un criterio contiene più condizioni. In questo caso, le notifiche che ricevi dipendono dal valore dell'attivatore con più condizioni del criterio di avviso:
Tutte le condizioni sono soddisfatte: quando tutte le condizioni sono soddisfatte, per ogni serie temporale che determina la soddisfazione di una condizione, il criterio di avviso invia una notifica e crea un incidente.
Non puoi configurare Cloud Monitoring per 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 causa la soddisfazione della condizione.
Per ulteriori informazioni, consulta Criteri con più condizioni.
I criteri di avviso creati utilizzando l'API Cloud Monitoring ti avvisano anche quando la condizione è soddisfatta e quando non è più soddisfatta. I criteri di avviso creati utilizzando la console Google Cloud non inviano una notifica quando la condizione non è più soddisfatta, a meno che non sia stato attivato questo comportamento.
Quando il monitoraggio non invia notifiche o non crea incidenti
Nelle seguenti situazioni, Monitoring non crea incidenti o invia notifiche quando vengono soddisfatte le condizioni di un criterio di avviso:
- Il criterio di avviso è disabilitato.
- Il criterio di avviso è in posticipazione.
- Il monitoraggio ha raggiunto il limite per il numero massimo di incidenti aperti.
Criteri di avviso disattivati
Il monitoraggio non crea incidenti o invia notifiche per i criteri di avviso disattivati. Tuttavia, Monitoraggio continua a valutare le condizioni di un criterio di avviso disattivato.
Quando attivi un criterio disattivato, il monitoraggio valuta i valori di tutte le condizioni nell'ultima finestra di nuovo test. La finestra di riesami più recente potrebbe includere i dati acquisiti prima, durante e dopo l'attivazione del criterio. Le condizioni di un criterio disattivato possono essere soddisfatte immediatamente dopo la ripresa del criterio, anche con finestre di riesami molto lunghe.
Ad esempio, supponiamo che tu abbia un criterio di avviso che monitora un processo specifico e che lo disattivi. La settimana successiva, il processo si interrompe e, poiché il criterio di avviso è disattivato, non ricevi alcuna notifica. Se riavvii il processo e attivi immediatamente il criterio di avviso, il monitoraggio riconosce che il processo non è attivo da cinque minuti e apre un incidente.
Gli incidenti relativi a un criterio di avviso disattivato rimangono aperti fino alla scadenza della durata della chiusura automatica del criterio.
Criteri di avviso posticipati
Il monitoraggio non invia notifiche o crea incidenti per una criterio di avviso posticipata. 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 di una macchina virtuale (VM), puoi 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. Il monitoraggio può aprire nuovi incidenti dopo la scadenza della posticipazione. Per informazioni, consulta Posticipare notifiche e avvisi.
Limiti di notifiche e incidenti aperti
Un criterio di avviso può essere applicato a molte risorse e un problema che interessa tutte le risorse può causare l'apertura di incidenti per ciascuna risorsa. Viene aperto un incidente per ogni serie temporale che comporta il verificarsi di una condizione.
Per evitare il sovraccarico del sistema, il numero di incidenti che un singolo piano può aprire contemporaneamente è limitato a 1000.
Ad esempio, considera un criterio che si applica a 2000 istanze Compute Engine e ogni istanza causa il verificarsi delle condizioni di avviso. Il monitoraggio limita il numero di incidenti aperti a 1000. Eventuali altre condizioni soddisfatte vengono ignorate fino alla chiusura di alcuni degli incidenti aperti per il criterio in questione.
A causa di questo limite, un singolo canale di notifica può ricevere fino a 1000 notifiche contemporaneamente. Se il tuo criterio di avviso prevede più canali di notifica, questo limite si applica a ciascun canale di notifica in modo indipendente.
Latenza
Per latenza si intende il ritardo tra il momento in cui il monitoraggio campiona una metrica e il momento 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 massima di 180 secondi, il monitoraggio non creerà un incidente per un massimo di 180 secondi dopo che la condizione del criterio di avviso è stata valutata come vera. Per ulteriori informazioni, consulta la pagina 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 ritardo aggiuntivo di 60-90 secondi. Per le metriche AWS CloudWatch, il ritardo della visibilità può essere di diversi minuti. Per i controlli di uptime, può essere in media di due minuti (dalla fine della finestra di riesami).
Finestra di ripetizione test: la finestra configurata per la condizione. Le condizioni sono soddisfatte solo quando una condizione è vera per l'intera finestra di retest. Ad esempio, un'impostazione della finestra di ripetizione del test di cinque minuti causa ritardi nella notifica di almeno cinque minuti dal primo verificarsi dell'evento.
Tempo di ricezione della notifica: i canali di notifica, come email e SMS, potrebbero presentare latenze di rete o di altro tipo (non correlate al contenuto inviato), a volte anche di alcuni 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 una serie di criteri di avviso, consulta Criteri di esempio.