Questo documento descrive in che modo i periodi di allineamento e le finestre di test determinano quando una condizione è 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 inoltre il numero massimo di incidenti aperti per un criterio, il numero di notifiche per incidente e le cause dei ritardi nelle notifiche.
Questo contenuto non si applica ai criteri di avviso basati su log. Per informazioni sui criteri di avviso basati su log, consulta Monitoraggio dei log.
Periodi di allineamento e finestre di nuovo test
Cloud Monitoring valuta il periodo di allineamento e la finestra di test per determinare se la condizione di un criterio di avviso è stata soddisfatta.
Periodo allineamento
Prima che i dati delle serie temporali siano monitorati da un criterio di avviso, devono essere regolarizzati in modo che il criterio di avviso disponga di dati distanziati regolarmente da valutare. Il processo di regolarizzazione è chiamato alignment.
L'allineamento prevede due passaggi:
Dividere le serie temporali in intervalli di tempo regolari, detto anche bucketing dei dati. L'intervallo è il periodo di allineamento.
È in corso il calcolo di un singolo valore per i punti nel periodo allineamento. Sei tu a scegliere come viene calcolato quel singolo punto; potresti sommare tutti i valori, calcolarne la media oppure utilizzare il massimo. La funzione che combina i punti dati è chiamata allineatore. Il risultato della combinazione è il valore allineato.
Per ulteriori informazioni sull'allineamento, vedi 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.
Monitoring configura un periodo allineamento nel seguente modo:
Console Google Cloud
Puoi configurare il periodo di allineamento scegliendo un valore per i seguenti campi nella pagina Condizioni di avviso:
- Finestra temporale continua: specifica l'intervallo di tempo da valutare.
- Funzione finestra temporale continua: specifica la funzione matematica da eseguire sulla finestra dei punti dati.
Per saperne di più sulle funzioni disponibili,
consulta Aligner in Riferimento API. Alcune funzioni di allineatore allineano i dati e li convertono da un tipo o tipo di metrica a un altro. Per una spiegazione dettagliata, consulta Tipi, tipi e conversioni.
API
Puoi configurare 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 in Riferimento API. Alcune funzioni di allineatore allineano i dati e li convertono da un tipo o tipo di metrica a un altro. Per una spiegazione dettagliata, consulta Tipi, tipi e conversioni.
Per illustrare l'effetto del periodo allineamento su una condizione in un criterio di avviso, consideriamo una condizione di soglia della 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 test, descritta nella prossima sezione, è di tre minuti.
La figura seguente illustra diverse valutazioni sequenziali della
condizione:
Ogni riga nella figura illustra una singola valutazione della condizione. Vengono mostrati i dati delle serie temporali. I punti del periodo di allineamento sono
indicati da punti blu, mentre quelli meno recenti sono neri. Ogni riga mostra il valore allineato e indica
se questo valore è maggiore della soglia di due. Per la riga con l'etichetta start, il valore allineato viene calcolato in uno, che è inferiore alla soglia.
Nella valutazione successiva, la somma dei campioni nel periodo di allineamento è pari a due.
Nella terza valutazione, la somma è 3 e, poiché questo valore è
superiore alla soglia, viene avviato un timer per la finestra di test.
Ripeti il test delle finestre
La condizione di un criterio di avviso ha una finestra di test che impedisce di soddisfare la condizione a causa di una singola misurazione o previsione. Ad esempio, supponiamo che la finestra per il nuovo test di una condizione sia impostata su 15 minuti. Di seguito viene descritto il comportamento della condizione in base al tipo:
- Le condizioni di soglia delle metriche 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 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 violi la soglia all'interno della finestra di previsione.
Per i criteri con una condizione, viene aperto un incidente e vengono inviate notifiche quando la condizione è soddisfatta. Questi incidenti rimangono aperti mentre la condizione continua a essere soddisfatta.
Console Google Cloud
Per configurare la finestra di nuovo test, utilizza il campo Finestra di nuovo test nel passaggio Configura trigger di avviso.
API
Per configurare la finestra di test del test, imposta il campo denominato
duration nelle strutture MetricThreshold e
MetricAbsence.
La figura precedente illustrava tre valutazioni di una condizione
metrica-soglia. Al momento start + 2 minutes, il valore allineato è maggiore della soglia; tuttavia, la condizione non è soddisfatta perché la finestra di nuovo test è impostata su tre minuti. La figura seguente illustra i risultati per le prossime
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. L'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 della metrica che specifica una finestra di test di cinque minuti.
Se la latenza della risposta HTTP è superiore a due secondi
e se è superiore alla soglia per cinque minuti,
apri un incidente e invia un'email al team di assistenza.La seguente sequenza illustra in che modo la finestra di nuovo test influisce sulla valutazione della condizione:
- La latenza HTTP è inferiore a due secondi.
- Per i successivi tre minuti consecutivi, la latenza HTTP sarà superiore a due secondi.
- Nella misurazione successiva, la latenza è inferiore a 2 secondi, quindi la condizione reimposta la finestra del nuovo test.
Per i successivi cinque minuti consecutivi, la latenza HTTP sarà superiore a due secondi, quindi la condizione è soddisfatta.
Poiché il criterio di avviso ha una condizione, Monitoring invia notifiche quando la condizione è soddisfatta.
Imposta la finestra di test in modo che sia abbastanza 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 per il nuovo test
Il periodo di allineamento determina il numero di campioni combinati con l'allineatore:
Il valore minimo del periodo 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 dovrebbe essere di almeno 300 secondi. Tuttavia, se desideri 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 per una metrica è 6 ore, il valore massimo del periodo di allineamento è 18 ore.
Utilizza la finestra del test per specificare la reattività dell'avviso. Ad esempio, se imposti la finestra di test su 20 minuti per una condizione di assenza di 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 inferiore. Per le condizioni soglia metrica, per avere il criterio di avviso più reattivo, imposta la finestra di nuovo test su zero. Un singolo valore allineato fa sì che questi tipi di condizioni vengano soddisfatti.
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 test non determinano la frequenza di valutazione della 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, esegui una delle seguenti operazioni:
Console Google Cloud
Puoi configurare le opzioni del combinatore nel passaggio Trigger per più condizioni.
API
Per configurare le opzioni del combinatore, utilizza 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 Il criterio attiva il valore |
Valore combinato dell'API Cloud Monitoring |
Significato |
|---|---|---|
| Tutte le condizioni sono soddisfatte | OR |
Un incidente viene aperto se una risorsa causa il rispetto di una qualsiasi delle condizioni. |
| 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 causa queste condizioni. |
| Tutte le condizioni sono soddisfatte | AND_WITH_MATCHING_RESOURCE |
Un incidente viene aperto se la stessa risorsa fa sì che ogni condizione venga soddisfatta. Questa impostazione rappresenta la scelta di combinazione più rigorosa. |
In questo contesto, il termine met indica che la configurazione della condizione è true. Ad esempio, se la configurazione è Any time series is greater than 10 for 5 minutes, quando questa istruzione restituisce true, la condizione è soddisfatta.
Esempio
Prendiamo ad esempio un progetto Google Cloud che contiene due istanze VM, vm1 e vm2. Inoltre, supponiamo di creare un criterio di avviso con due condizioni:
- La condizione denominata
CPU usage is too highmonitora l'utilizzo della CPU da parte delle istanze. Questa condizione è soddisfatta quando l'utilizzo della CPU da parte 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 per qualsiasi istanza è superiore al 60% per 1 minuto.
Supponiamo che entrambe le condizioni abbiano come valore false.
Quindi, supponiamo che l'utilizzo della CPU di vm1 superi 100 ms/s per 1 minuto. Poiché
l'utilizzo della CPU è maggiore della 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é 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 ciascuna condizione,
l'incidente non viene creato. Queste scelte devono essere soddisfatte
entrambe le condizioni.
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 descrive cosa accade in base alla combinazione delle condizioni:
Qualsiasi condizione è soddisfatta: viene creato un incidente quando una risorsa causa il rispetto di una condizione. In questo esempio, vm2 fa sì che la condizione
Excessive utilizationvenga soddisfatta.Se vm2 fa in modo che la condizione
CPU usage is too highvenga soddisfatta, viene creato anche un incidente. Viene creato un incidente perché vm1 e vm2 che causano il soddisfare la condizioneCPU usage is too highsono eventi distinti.Tutte le condizioni sono soddisfatte anche per risorse diverse per ciascuna 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 il rispetto di tutte le condizioni. In questo esempio, non viene creato alcun incidente perché vm1 fa sì che
CPU usage is too highvenga soddisfatto, mentre vm2 fa sì cheExcessive utilization.
Dati metriche parziali
Quando i dati delle serie temporali smettono di arrivare o quando i dati subiscono ritardi, Monitoring classifica i dati come mancanti. La mancanza di dati può impedire la chiusura degli incidenti. I ritardi nei dati in arrivo dai cloud provider di terze parti possono arrivare fino a 30 minuti, con ritardi di 5-15 minuti che sono i più comuni. Un ritardo lungo, più lungo della finestra di test, può causare l'ingresso delle condizioni in uno stato "sconosciuto". Quando finalmente i dati arrivano, Monitoring potrebbe aver perso parte della cronologia recente delle patologie. Un'ispezione successiva dei dati delle serie temporali potrebbe non rivelare questo problema perché non ci sono prove di ritardi una volta arrivati i dati.
Console Google Cloud
Puoi configurare il modo in cui Monitoring valuta una condizione di soglia di metrica quando i dati non arrivano. Ad esempio, quando un incidente è aperto e non arriva una misurazione prevista, vuoi che Monitoring lasci aperto l'incidente o lo chiuda immediatamente? Analogamente, se i dati non arrivano più e non è aperto nessun incidente, vuoi che venga aperto? Infine, per quanto tempo un incidente deve rimanere aperto dopo che i dati non sono più disponibili?
Esistono due campi configurabili che specificano in che modo Monitoring valuta le condizioni di soglia della metrica quando i dati non arrivano:
Per configurare il modo in cui Monitoring determina il valore sostitutivo per i dati mancanti, utilizza il campo Valutazione dei dati mancanti che hai impostato nel passaggio Trigger condizione. Questo campo è disabilitato se la finestra di ripetizione è impostata 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 il termine dell'arrivo di dati, utilizza il campo Durata della chiusura automatica degli incidenti. Puoi impostare la durata della chiusura automatica nel passaggio Notifica. La durata predefinita della chiusura automatica è di sette giorni.
Di seguito sono descritte le diverse opzioni disponibili per il campo dei dati mancanti:
| Console Google Cloud Campo "Valutazione dei dati mancanti" |
Riepilogo | Dettagli |
|---|---|---|
| Dati mancanti vuoti | Gli incidenti aperti rimangono aperti. I nuovi incidenti non vengono aperti. |
Per condizioni soddisfatte, continua a essere soddisfatta quando i dati non arrivano più. Se un incidente è aperto per questa condizione, 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 condizioni non soddisfatte, la condizione continua a non essere soddisfatta quando i dati non arrivano più. |
| Punti dati mancanti trattati come valori che violano la condizione delle norme | Gli incidenti aperti rimangono aperti. È possibile aprire nuovi incidenti. |
Per condizioni soddisfatte, continua a essere soddisfatta quando i dati non arrivano più. 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 non soddisfatte, questa impostazione fa sì che la
condizione soglia della 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. |
In caso di condizioni soddisfatte, la condizione non viene più soddisfatta quando i dati non arrivano. Se un incidente è aperto per questa condizione, viene chiuso. Per condizioni non soddisfatte, la condizione continua a non essere soddisfatta quando i dati non arrivano più. |
API
Puoi configurare il modo in cui Monitoring valuta una condizione di soglia di metrica quando i dati non arrivano. Ad esempio, quando un incidente è aperto e non arriva una misurazione prevista, vuoi che Monitoring lasci aperto l'incidente o lo chiuda immediatamente? Analogamente, se i dati non arrivano più e non è aperto nessun incidente, vuoi che venga aperto? Infine, per quanto tempo un incidente deve rimanere aperto dopo che i dati non sono più disponibili?
Esistono due campi configurabili che specificano in che modo Monitoring valuta le condizioni di soglia della metrica quando i dati non arrivano:
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 che i dati non arrivano più, utilizza il campo
autoClosenella strutturaAlertStrategy.
Di seguito sono descritte le diverse opzioni disponibili per il campo dei dati mancanti:
Campo evaluationMissingDataAPI |
Riepilogo | Dettagli |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Gli incidenti aperti rimangono aperti. I nuovi incidenti non vengono aperti. |
Per condizioni soddisfatte, continua a essere soddisfatta quando i dati non arrivano più. Se un incidente è aperto per questa condizione, 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 condizioni non 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 condizioni soddisfatte, continua a essere soddisfatta quando i dati non arrivano più. 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 non soddisfatte, questa impostazione fa sì che la
condizione soglia della metrica si comporti come un |
EVALUATION_MISSING_DATA_INACTIVE |
Gli incidenti aperti sono chiusi. I nuovi incidenti non vengono aperti. |
In caso di condizioni soddisfatte, la condizione non viene più soddisfatta quando i dati non arrivano. Se un incidente è aperto per questa condizione, viene chiuso. Per condizioni non soddisfatte, la condizione continua a non essere soddisfatta quando i dati non arrivano più. |
Puoi ridurre al minimo i problemi dovuti alla mancanza di dati eseguendo una delle seguenti operazioni:
- Contattare il provider cloud di terze parti per identificare modi per ridurre la latenza della raccolta delle metriche.
- Utilizza finestre di test più lunghe nelle tue condizioni. L'utilizzo di una finestra di nuovo test più lunga presenta lo svantaggio di rendere meno reattivi i criteri di avviso.
Scegli le metriche con un ritardo di raccolta più basso:
- le metriche dell'agente Monitoring, 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 viene ritardata.
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 causa il rispetto di 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 attuati dalle tue norme.
Se configuri 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 se 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'attivatore multicondizionale del criterio di avviso:
Tutte le condizioni sono soddisfatte: quando tutte le condizioni sono soddisfatte, per ogni serie temporale in cui una condizione viene 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 Norme con più condizioni.
I criteri di avviso creati utilizzando l'API Cloud Monitoring inviano una notifica anche quando la condizione è soddisfatta e quando la condizione non viene più soddisfatta. I criteri di avviso creati utilizzando la console Google Cloud non inviano una notifica quando la condizione smette di essere soddisfatta, a meno che tu non abbia attivato questo comportamento.
Quando Monitoring non invia notifiche o crea incidenti
Nelle situazioni seguenti, Monitoring non crea incidenti né invia notifiche quando le condizioni di un criterio di avviso sono soddisfatte:
- Il criterio di avviso è disabilitato.
- Il criterio di avviso è stato posticipato.
- Il monitoraggio ha raggiunto il limite massimo di incidenti aperti.
Criteri di avviso disabilitati
Monitoring non invia incidenti creati, né notifiche per criteri di avviso disattivati. Tuttavia, Monitoring continua a valutare le condizioni di un criterio di avviso disabilitato.
Quando abiliti un criterio disattivato, Monitoring valuta i valori di tutte le condizioni nella finestra di test più recente. La finestra di test più recente potrebbe includere i dati acquisiti prima, durante e dopo l'abilitazione del criterio. Le condizioni di un criterio disattivato possono essere soddisfatte immediatamente dopo il ripristino del criterio, anche con finestre di test di grandi dimensioni.
Ad esempio, supponiamo che tu abbia un criterio di avviso che monitora un processo specifico e che lo disabiliti. La settimana successiva, la procedura 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 della chiusura automatica del criterio.
Criteri di avviso posticipati
Il monitoraggio non invia notifiche né crea incidenti per un criterio di avviso posticipato. Ti consigliamo di posticipare i criteri di avviso se vuoi impedire che un criterio di avviso invii 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 relativi al criterio. Il monitoraggio può aprire nuovi incidenti dopo la scadenza della posticipazione. Per informazioni, vedi Posticipare notifiche e avvisi.
Limiti delle notifiche e incidenti aperti
Un criterio di avviso può essere applicato a molte risorse e un problema che interessa tutte le risorse può far sì che il criterio di avviso apra incidenti per ogni risorsa. Viene aperto un incidente per ogni serie temporale che determina il rispetto di 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 il numero di incidenti aperti a 1000. Eventuali condizioni rimanenti che vengono soddisfatte vengono ignorate fino alla chiusura di alcuni degli incidenti aperti per quel criterio.
Come risultato di questo limite, un singolo canale di notifica può ricevere fino a 1000 notifiche contemporaneamente. Se il criterio di avviso include più canali di notifica, questo limite si applica a ogni canale di notifica in modo indipendente.
Latenza
Per latenza si intende il 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 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, Monitoring non crea un incidente per un massimo di 180 secondi dopo la valutazione della condizione del criterio di avviso su true. Per maggiori 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. Il calcolo dei criteri di avviso richiede un ritardo aggiuntivo compreso tra 60 e 90 secondi. Per le metriche AWS CloudWatch, il ritardo della visibilità può essere di diversi minuti. Per i controlli di uptime, il valore può corrispondere a una media di 2 minuti (dalla fine della finestra di test).
Finestra di nuovo test: la finestra configurata per la condizione. Le condizioni vengono soddisfatte solo quando una condizione è vera nell'intera finestra di ripetizione. Ad esempio, un'impostazione della finestra per il nuovo test di cinque minuti provoca ritardi nella notifica di almeno cinque minuti dal momento in cui si verifica il primo evento.
Tempo di ricezione della notifica: i canali di notifica, come email e SMS, potrebbero riscontrare latenze di rete o altre latenze (non correlate ai contenuti inviati) che a volte stanno per raggiungere i minuti. Su alcuni canali, come SMS e Slack, non vi è alcuna garanzia 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.