Comportamento dei criteri di avviso basati su metriche

Questo documento descrive come i periodi di allineamento e le finestre di test determinare quando una condizione è soddisfatta e in che modo i criteri di avviso combinano e il modo in cui 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 del nuovo test nel determinare se la condizione di un criterio di avviso è stata soddisfatta.

Periodo allineamento

Prima di essere monitorati da un criterio di avviso, i dati delle serie temporali devono essere regolarizzati in modo che il criterio di avviso abbia distanziati regolarmente dati da valutare. Il processo di regolarizzazione è chiamato allineamento.

L'allineamento prevede due passaggi:

  • Dividere le serie temporali in intervalli di tempo regolari (chiamato anche bucketing) i 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 o calcolare la loro media o utilizza il massimo. La funzione che combina i punti dati è chiamato 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 allineamento è di cinque minuti, alle 13:00, il 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 ricevuto tra le 12:56 e le 13:01.

Monitoring configura un periodo allineamento nel seguente modo:

Console Google Cloud

Per configurare il periodo di allineamento devi 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 su il rendimento nella finestra dei punti dati.

Per ulteriori informazioni sulle funzioni disponibili, consulta Aligner nel riferimento delle API. Alcuni allineatori allineano i dati e convertirla da un tipo o tipo di metrica a un altro. Per una panoramica consulta la sezione Tipi, tipi e conversioni.

API

Per configurare il periodo di allineamento si imposta aggregations.alignmentPeriod e aggregations.perSeriesAligner campi in MetricThreshold e strutture di MetricAbsence.

Per ulteriori informazioni sulle funzioni disponibili, consulta Aligner nel riferimento delle API. Alcuni allineatori allineano i dati e convertirla da un tipo o tipo di metrica a un altro. Per una panoramica consulta la sezione Tipi, tipi e conversioni.

per illustrare l'effetto del periodo allineamento su una condizione in un avviso specifico, considera una condizione di soglia di metrica che sia monitorare 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 è impostato su sum. Inoltre, supponiamo che la condizione sia soddisfatta quando il valore allineato della serie temporale è maggiore di due per in 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, descritto nella prossima sezione, è di tre minuti. La figura seguente illustra diverse valutazioni sequenziali del condizione:

Figura che mostra l'effetto del periodo di allineamento sulla finestra/durata del test.

Ogni riga nella figura illustra una singola valutazione della condizione. La vengono mostrati i dati delle serie temporali. I punti del periodo allineamento sono indicati con punti blu; i puntini più vecchi sono neri. Ogni riga mostra il valore allineato se questo valore è superiore alla 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 è tre e poiché questo valore è rispetto alla soglia, viene avviato un timer per la finestra di ripetizione del test.

Ripeti il test delle finestre

La condizione di un criterio di avviso ha una finestra di riesecuzione del test, che impedisce non 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 soglia metrica sono soddisfatte quando, per un singole serie temporali, 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 viene generata ogni previsione durante una finestra di 15 minuti prevede che la serie temporale violerà la soglia all'interno della finestra di previsione.

Per i criteri con una condizione, viene aperto un incidente e le notifiche vengono inviate quando la condizione è soddisfatta. Questi incidenti rimangono aperti mentre la condizione continua a essere soddisfatta.

Console Google Cloud

Per configurare la finestra del nuovo test, utilizza il campo Finestra di nuovo test nel Passaggio Configura il trigger di avviso.

API

Configuri la finestra di test impostando il campo denominato duration in MetricThreshold e strutture di MetricAbsence.

La figura precedente illustrava tre valutazioni di una soglia metrica . Al tempo start + 2 minutes, il valore allineato è maggiore della soglia; ma la condizione non è soddisfatta perché la finestra di nuovo test è impostata su tre minuti. La figura seguente illustra i risultati per la valutazioni della condizione:

Figura che mostra l'effetto della finestra del nuovo test.

Anche se il valore allineato è maggiore della soglia a volta start + 2 minutes, la condizione non è soddisfatta finché il valore allineato è superiore alla soglia per tre minuti. L'evento si verifica alle ore start + 5 minutes.

Una condizione reimposta la finestra di nuovo test ogni volta che viene eseguita una misurazione o una previsione non soddisfa la condizione. Questo comportamento è illustrato di seguito esempio:

Esempio: questo criterio di avviso contiene una condizione di soglia della metrica che specifica una finestra di ripetizione di cinque minuti.

Se la latenza della risposta HTTP è superiore a due secondi,
e se la latenza supera la 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 test influisce sulla valutazione della condizione:

  1. La latenza HTTP è inferiore a due secondi.
  2. Per i successivi tre minuti consecutivi, la latenza HTTP è maggiore per più di due secondi.
  3. Nella misurazione successiva, la latenza è inferiore a 2 secondi, quindi reimposta la finestra del nuovo test.

  4. Per i successivi cinque minuti consecutivi, la latenza HTTP sarà maggiore di da 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 è di campionamento di quel tipo di metrica. Ad esempio, se il tipo di metrica è campionato ogni 300 secondi, il periodo allineamento dovrebbe essere 300 secondi. Tuttavia, per combinare 5 campioni, imposta il valore periodo di allineamento a 5 * 300 secondi o 1500 secondi.

  • Il valore massimo del periodo allineamento è 24 ore meno l'importazione del tipo di metrica. Ad esempio, se il ritardo nell'importazione per una metrica è 6 ore, il valore massimo del periodo allineamento è 18 ore.

Utilizza la finestra del test per specificare la reattività dell'avviso. Ad esempio: se imposti la finestra per il nuovo test su 20 minuti per condizione di assenza metrica, non ci siano dati per 20 minuti prima che la condizione sia soddisfatta. Per un criterio di avviso più reattivo, imposta la finestra di test su un valore inferiore. Per avere le condizioni soglia metrica, per avere il criterio di avviso più reattivo, imposta la finestra di test su zero. Un singolo valore allineato causa questi tipi di le condizioni da soddisfare.

Le condizioni dei criteri di avviso vengono valutate con una frequenza fissa. Le scelte che per il periodo di allineamento e la finestra di test non stabiliscono 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 se il criterio di avviso è soggetto a più condizioni, devi specificare quando viene aperto un incidente. Per configurare come vengono combinate più condizioni, procedi in uno dei seguenti modi:

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 struttura di AlertPolicy.

Questa tabella elenca le impostazioni nella console Google Cloud, ovvero nell'API Cloud Monitoring e una descrizione di ciascuna impostazione:

Console Google Cloud
Il criterio attiva il valore		 Valore combinato dell'API
Cloud Monitoring		 Significato
Tutte le condizioni sono soddisfatte OR Viene aperto un incidente se una risorsa causa uno dei le condizioni da soddisfare.
Tutte le condizioni sono soddisfatte
anche per differenti
risorse per ogni condizione
(valore predefinito)		 AND Viene aperto un incidente se ciascuno sia soddisfatta anche se diversa fa sì che queste condizioni vengano soddisfatte.
Tutte le condizioni sono soddisfatte AND_WITH_MATCHING_RESOURCE Un incidente viene aperto se la stessa risorsa causa ogni condizione da soddisfare. Questa impostazione è la scelta di combinazione più rigorosa.

In questo contesto, il termine met indica che la configurazione della condizione ha come valore true. Per Ad esempio, se la configurazione è Any time series is greater than 10 for 5 minutes, quando questa istruzione restituisce true, la condizione è soddisfatta.

Esempio

Considera un progetto Google Cloud che contiene due VM vm1 e vm2. Inoltre, supponiamo che tu abbia creato una rete con 2 condizioni:

  • La condizione denominata CPU usage is too high monitora l'utilizzo della CPU dell'account di Compute Engine. 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 utilization monitora l'utilizzo della CPU di le istanze. Questa condizione è soddisfatta quando l'utilizzo della CPU da parte di 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 rispettata. Se combinate con Qualsiasi condizione è soddisfatta, un incidente perché è soddisfatta una condizione. 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 di combinazione richiedono che che le condizioni vengano soddisfatte.

Quindi, supponiamo che l'utilizzo della CPU di vm1 rimanga superiore a 100 ms/s che l'utilizzo della CPU di vm2 supera il 60% per 1 minuto. Il risultato è che sono soddisfatte entrambe le condizioni. Le seguenti descrive cosa accade in base alla combinazione delle condizioni:

  • Qualsiasi condizione è soddisfatta: viene creato un incidente quando una risorsa provoca una condizione da soddisfare. In questo esempio, vm2 causa la condizione Excessive utilization da soddisfare.

    Se vm2 fa in modo che la condizione CPU usage is too high venga soddisfatta, che comporta anche la creazione di un incidente. È stato creato un incidente perché vm1 e vm2 generano la condizione CPU usage is too high sono 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 tutte le condizioni siano soddisfatte dalla stessa risorsa. In questo esempio, non viene creato nessun incidente perché vm1 causa CPU usage is too high da soddisfare mentre vm2 fa sì che venga soddisfatto Excessive utilization.

Dati metriche parziali

Quando i dati delle serie temporali non arrivano più o quando i dati subiscono un ritardo, Il monitoraggio classifica i dati come mancanti. La mancanza di dati può impedire la chiusura degli incidenti. Ritardi nei dati in arrivo da con i cloud provider di terze parti possono richiedere anche 30 minuti, con ritardi di 5-15 minuti che sono i più comuni. Un lungo (più lungo della finestra di ripetizione del test) può causare l'inserimento di condizioni uno "sconosciuto" stato. 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 quando arrivano i dati.

Console Google Cloud

Puoi configurare il modo in cui Monitoring valuta condizione soglia metrica quando non arrivano più dati. Ad esempio, quando un incidente è aperto e una misurazione prevista non arriva, vuoi che Monitoring lasci l'incidente per aprirlo o chiuderlo immediatamente? Analogamente, quando i dati non arrivano più nessun incidente è aperto, vuoi che venga aperto? Infine, per quanto tempo un incidente deve rimanere aperto quando i dati non arrivano più?

Esistono due campi configurabili che specificano in che modo 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 quando il parametro finestra di ripetizione del test sia impostata su Nessun nuovo test.

    La finestra di nuovo test è il campo denominato "Durata" nell'API Cloud Monitoring.

  • Per configurare il tempo che deve trascorrere prima della chiusura di Monitoring un incidente aperto quando i dati non sono più disponibili, utilizza Campo Durata chiusura automatica incidente. Puoi impostare la durata della chiusura automatica nel Passaggio di notifica. La durata predefinita della chiusura automatica è per sette giorni.

Di seguito sono descritte le diverse opzioni disponibili per il campo dei dati mancanti:

Console Google Cloud
"Valutazione dei dati mancanti" campo		 Riepilogo Dettagli
Dati mancanti vuoti Gli incidenti aperti rimangono aperti.
I nuovi incidenti non vengono aperti.

Per le condizioni soddisfatte, la condizione continua a essere soddisfatti quando i dati non arrivano più. Se un incidente è aperto per questa condizione, l'incidente rimane aperto. Quando un incidente è aperto e non ci sono dati arriva, 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 non soddisfatte, la condizione continua a non vengano soddisfatti 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 le condizioni soddisfatte, la condizione continua a essere soddisfatti 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 è chiuso.

In caso di condizioni non soddisfatte, questa impostazione determina soglia metrica affinché si comporti come una metric-absence condition. Se i dati non arrivano nel tempo specificato dalla finestra di ripetizione, la condizione viene valutata come soddisfatta. Per un criterio di avviso con una condizione, la condizione è soddisfatta comporta l'apertura di un incidente.
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 soddisfatte, la condizione non viene più soddisfatta quando non arrivano più. Se un incidente è aperto per questa condizione, allora l'incidente è chiuso.

Per le condizioni non soddisfatte, la condizione continua a non vengano soddisfatti quando i dati non arrivano più.

API

Puoi configurare il modo in cui Monitoring valuta condizione soglia metrica quando non arrivano più dati. Ad esempio, quando un incidente è aperto e una misurazione prevista non arriva, vuoi che Monitoring lasci l'incidente per aprirlo o chiuderlo immediatamente? Analogamente, quando i dati non arrivano più nessun incidente è aperto, vuoi che venga aperto? Infine, per quanto tempo un incidente deve rimanere aperto quando i dati non sono più disponibili?

Esistono due campi configurabili che specificano in che modo 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 evaluationMissingData campo della struttura MetricThreshold. Questo campo viene ignorato quando il campo duration è pari a zero.

  • Per configurare il tempo che deve trascorrere prima della chiusura di Monitoring un incidente aperto dopo che i dati non arrivano più, usa il campo autoClose nella struttura AlertStrategy.

Di seguito sono descritte le diverse opzioni disponibili per il campo dei dati mancanti:

API
Campo evaluationMissingData		 Riepilogo Dettagli
EVALUATION_MISSING_DATA_UNSPECIFIED Gli incidenti aperti rimangono aperti.
I nuovi incidenti non vengono aperti.

Per le condizioni soddisfatte, la condizione continua a essere soddisfatti quando i dati non arrivano più. Se un incidente è aperto per questa condizione, l'incidente rimane aperto. Quando un incidente è aperto e non ci sono dati arriva, 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 non soddisfatte, la condizione continua a non vengano soddisfatti 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 soddisfatti quando i dati non arrivano più. Se un incidente è aperto per questa condizione, l'incidente rimane aperto. Quando un incidente è aperto e non ci sono dati arriva per la durata della chiusura automatica più 24 ore, l'incidente è chiuso.

In caso di condizioni non soddisfatte, questa impostazione determina soglia metrica affinché si comporti come una metric-absence condition. Se i dati non arrivano nel tempo specificato dal campo "duration", la condizione viene valutata come soddisfatta. Per un criterio di avviso con una condizione, la condizione è soddisfatta comporta l'apertura di un incidente.
EVALUATION_MISSING_DATA_INACTIVE Gli incidenti aperti sono chiusi.
I nuovi incidenti non vengono aperti.

Per condizioni soddisfatte, la condizione non viene più soddisfatta quando non arrivano più. Se un incidente è aperto per questa condizione, allora l'incidente è chiuso.

Per le condizioni non soddisfatte, la condizione continua a non vengano soddisfatti quando i dati non arrivano più.

Puoi ridurre al minimo i problemi dovuti alla mancanza di dati eseguendo una delle seguenti operazioni:

  • Contatta il tuo provider cloud di terze parti per conoscere modi per ridurre latenza di raccolta delle metriche.
  • Utilizza finestre di test più lunghe nelle tue condizioni. Utilizzo di una finestra di test più lunga ha lo svantaggio di ridurre i criteri di avviso adattabile.

  • Scegli le metriche con un ritardo di raccolta più basso:

    • Monitoraggio delle metriche dell'agente, soprattutto quando l'agente in esecuzione su istanze VM in cloud di terze parti.
    • Metriche personalizzate, quando scrivi i relativi dati direttamente monitoraggio.
    • Metriche basate su log, se la raccolta delle voci di log non viene ritardata.

Per ulteriori informazioni, vedi Panoramica dell'agente in monitoraggio 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 determina il soddisfacimento di una condizione. La notifica viene inviata a tutti canali di notifica. Non puoi limitare una notifica a un canale specifico o a un sottoinsieme delle tue norme canali.

Se configuri le notifiche ripetute: la stessa notifica viene inviata nuovamente a specifici canali di notifica per il criterio di avviso.

Potresti ricevere più notifiche univoche relative a un criterio di avviso quando uno qualsiasi sono vere:

  • Una condizione monitora più serie temporali.

  • Un criterio contiene più condizioni. In questo caso, le notifiche che ricevi dipendono dal valore della multicondizione del criterio di avviso Attivatore:

    • Tutte le condizioni sono soddisfatte: quando tutte le condizioni sono soddisfatte, per ogni serie temporale che genera una condizione, il criterio di avviso invia una notifica e crea un incidente.

      Non puoi configurare Cloud Monitoring per creare un solo incidente invia una sola notifica quando il criterio di avviso contiene più conditions.

    • Qualsiasi condizione è soddisfatta: il criterio di avviso invia una notifica quando la condizione è soddisfatta da una serie temporale.

    Per ulteriori informazioni, vedi Norme con più condizioni.

Anche i criteri di avviso creati utilizzando l'API Cloud Monitoring ti informano quando la condizione è soddisfatta e quando la condizione smette di essere soddisfatta. I criteri di avviso creati utilizzando la console Google Cloud non inviano una notifica quando la condizione smette di essere soddisfatta se non hai abilitato tale comportamento.

Quando Monitoring non invia notifiche o crea incidenti

Nelle situazioni seguenti, 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 è stato posticipato.
  • Il monitoraggio ha raggiunto il limite per il numero massimo di contatti aperti e i relativi incidenti.

Criteri di avviso disabilitati

Il monitoraggio non invia incidenti, né invia delle notifiche per i criteri di avviso disabilitati. Tuttavia, il monitoraggio continua a valutare le condizioni di un criterio di avviso disattivato.

Quando abiliti un criterio disattivato, Monitoring valuta i valori di tutte le condizioni nella finestra di ripetizione più recente. La finestra di test più recente potrebbe includere dati acquisiti prima, durante e dopo il è stato attivato. 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 una specifica procedura e di disattivare il criterio. La settimana successiva, la procedura non è più disponibile e, poiché il criterio di avviso è disattivato, non riceverai alcuna notifica. Se riavvii il processo e abiliti immediatamente il criterio di avviso, Il monitoraggio riconosce che il processo non è stato completato ultimi cinque minuti e apre un incidente.

Gli incidenti relativi a un criterio di avviso per disabili rimangono aperti fino al scade la durata della chiusura automatica.

Criteri di avviso posticipati

Il monitoraggio non invia notifiche né crea incidenti per un criterio di avviso posticipato. Ti consigliamo di posticipare criteri di avviso se vuoi impedire che un criterio di avviso invii solo per brevi intervalli. Ad esempio, prima di eseguire di manutenzione di una macchina virtuale (VM), potresti creare una posticipazione e aggiungere per posticipare i criteri di avviso che monitorano l'istanza.

Quando posticipi un criterio di avviso, Monitoring si chiude tutti gli incidenti aperti relativi al criterio. Monitoraggio possono 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 si verifica un problema che tutte le risorse possono causare l'apertura di incidenti da parte del criterio di avviso risorsa. Viene aperto un incidente per ogni serie temporale che genera una condizione vengono soddisfatte.

Per evitare di sovraccaricare il sistema, il numero di incidenti che un singolo che è possibile aprire contemporaneamente è limitato a 1000.

Considera ad esempio un criterio che si applica a Compute Engine 2000 di istanze gestite e ciascuna istanza fa sì che vengano soddisfatte le condizioni di avviso. Il monitoraggio limita il numero di incidenti aperti 1000. Le eventuali condizioni rimanenti che vengono soddisfatte sono ignorati fino alla chiusura di alcuni degli incidenti aperti per quel criterio.

A causa di questo limite, un singolo canale di notifica può ricevere fino a 1000 notifiche alla volta. Se gli avvisi che la norma ha più canali di notifica, il limite si applica a ogni canale di notifica in modo indipendente.

Latenza

La latenza si riferisce al ritardo tra il momento in cui Monitoring campiona un e quando 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 un'istanza ha una latenza massima di 180 secondi, Il monitoraggio non creerà un incidente per un massimo di 180 secondi dopo la condizione del criterio di avviso è true. Per ulteriori informazioni, vedi Latenza dei dati delle metriche.

I seguenti eventi e impostazioni contribuiscono alla latenza:

  • Ritardo nella raccolta delle metriche: il tempo necessario a Monitoring raccolgono 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 in base alla metrica. I calcoli dei criteri di avviso richiedono un ulteriore ritardo di 60-90 secondi. Per le metriche AWS CloudWatch, il ritardo di visibilità può richiedere diversi minuti. Per i controlli di uptime, il valore può essere una media di due 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 durante il test finestra. Ad esempio, un'impostazione della finestra per il nuovo test di cinque minuti fa sì che ritardi nella notifica di almeno cinque minuti dal si verifica prima.

  • Ora di arrivo della notifica: canali di notifica, come l'email. e SMS, potrebbero presentare latenze di rete o altre latenze (non correlate a ciò che viene pubblicato), a volte ci si avvicina ai minuti. Su alcune come SMS e Slack, non vi è alcuna garanzia che il recapito dei messaggi.

Passaggi successivi