Comportamento dei criteri di avviso basati su metriche

Le policy di avviso basate su metriche in Cloud Monitoring ti consentono di monitorare i dati delle serie temporali, creare avvisi e inviare notifiche. Puoi controllare quando le policy di avviso creano avvisi e inviano notifiche configurando periodi di allineamento, finestre di nuovo test e regole con più condizioni. Comprendere come le policy di avviso gestiscono i dati mancanti, i limiti per gli avvisi e le notifiche e i ritardi delle notifiche ti aiuta a ridurre al minimo i falsi positivi e a ottimizzare la reattività degli avvisi.

Questi contenuti non si applicano alle policy di avviso basate su log. Per informazioni sulle policy di avviso basate 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 nuovo test per determinare se la condizione di una criterio di avviso è 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 distanziati regolarmente da valutare. Il processo di regolarizzazione è chiamato allineamento.

L'allineamento prevede due passaggi:

  • Suddivisione della serie temporale in intervalli di tempo regolari, chiamata anche suddivisione dei dati in bucket. L'intervallo è il periodo di allineamento.

  • Calcolo di un singolo valore per i punti nel periodo di allineamento. Sei tu a scegliere 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 cosiddetto valore allineato.

    Per saperne di più sull'allineamento, consulta Allineamento: regolarizzazione all'interno delle serie.

Ad esempio, se 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 di 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: 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 dell'allineatore allineano i dati e li convertono da un tipo di metrica a un altro. Per una spiegazione dettagliata, consulta Kind, 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 nel riferimento API. Alcune funzioni dell'allineatore allineano i dati e li convertono da un tipo di metrica a un altro. Per una spiegazione dettagliata, consulta Kind, tipi e conversioni.

Per illustrare l'effetto del periodo di allineamento su una condizione in una policy di avviso, considera 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. Supponiamo inoltre 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, la finestra di nuovo test, descritta nella sezione successiva, è di tre minuti. La seguente figura illustra diverse valutazioni sequenziali della condizione:

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

Ogni riga della figura illustra una singola valutazione della condizione. Vengono visualizzati 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 con etichetta start, il valore allineato viene calcolato su uno, che è inferiore alla soglia. Alla valutazione successiva, la somma dei campioni nel periodo di allineamento è due. Alla terza valutazione, la somma è tre e, poiché questo valore è maggiore della soglia, viene avviato un timer per la finestra di nuovo test.

Finestre di ripetizione test

La condizione di una criterio di avviso ha una finestra di nuovo 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 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 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 una finestra di 15 minuti prevede che la serie temporale violerà la soglia entro la finestra di previsione.

Per le policy con una condizione, viene aperto un avviso e vengono inviate notifiche quando la condizione è soddisfatta. Questi avvisi rimangono aperti finché la condizione continua a essere soddisfatta.

Console Google Cloud

Puoi configurare la finestra di nuovo test utilizzando il campo Finestra di nuovo test nel passaggio Configura trigger di avviso.

API

Puoi configurare la finestra di nuovo test impostando il campo denominato duration nelle strutture MetricThreshold e MetricAbsence.

La figura precedente illustra tre valutazioni di una condizione di soglia della metrica. 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 delle valutazioni successive della condizione:

Figura che illustra l'effetto della finestra di nuovo test.

Anche se il valore allineato è maggiore della soglia al momento start + 2 minutes, la condizione non viene soddisfatta finché il valore allineato non è maggiore della soglia per tre minuti. Questo evento si verifica al momento 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 nuovo 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 una finestra di 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 avviso 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:

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

  4. Per i 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 l'impostazione del periodo di allineamento e della finestra di nuovo test

Per configurare una criterio di avviso che esegua valutazioni affidabili senza falsi avvisi, configura il periodo di allineamento e la finestra di nuovo test in base al tuo caso d'uso.

Imposta il periodo di allineamento

Il periodo di allineamento determina il numero di campioni che l'allineatore combina in una misurazione aggregata. Quando imposti il periodo di allineamento, tieni conto dell'intervallo di campionamento e del ritardo di importazione della metrica:

  • Periodo di allineamento minimo: il periodo di allineamento deve essere di almeno 60 secondi (1 minuto) e deve essere un multiplo intero di 60 secondi. Per assicurarti che ogni finestra di allineamento acquisisca dati rappresentativi, imposta il periodo di allineamento almeno sull'intervallo di campionamento della metrica, arrotondato per eccesso a un multiplo di 60 secondi. Ad esempio, per una metrica che esegue il campionamento ogni 30 secondi, imposta il periodo di allineamento su almeno 60 secondi.

  • Ritardo di importazione: i dati delle metriche subiscono una latenza di raccolta e importazione prima di raggiungere Monitoring. Quando valuta le policy di avviso, Monitoring sposta i tempi di valutazione nel passato per tenere conto del ritardo di importazione previsto per ogni metrica, in genere almeno 60 secondi, con ritardi più brevi per metriche come i controlli di uptime e ritardi più lunghi per metriche con latenza più elevata, come le metriche basate su log definite dall'utente o le metriche cloud di terze parti. Tuttavia, se una metrica esterna o di terze parti presenta un ritardo di importazione variabile che supera il ritardo integrato, scegli un periodo di allineamento abbastanza ampio da acquisire più intervalli di campionamento, in modo che i campioni ritardati non producano finestre di allineamento vuote.

  • Periodo di allineamento massimo: per le condizioni di soglia della metrica, il periodo di allineamento può essere al massimo di 25 ore. Per le condizioni di assenza di metriche, la somma del periodo di allineamento e della finestra di nuovo test non deve superare le 25 ore. Se devi valutare le tendenze storiche su finestre temporali superiori a 25 ore (fino a 2 anni), utilizza PromQL. Le regole di avviso PromQL che analizzano un periodo di tempo superiore a 25 ore richiedono che la finestra di nuovo test (duration) sia pari a zero, non supportano metriche personalizzate o basate su log e applicano intervalli di valutazione minimi che aumentano con la durata del periodo di analisi:

    • Da 25 ore e 10 minuti a 8 giorni: 5 minuti
    • Da 8 a 16 giorni: 1 ora
    • Da 16 a 32 giorni: 2 ore
    • Da 32 a 93 giorni: 6 ore
    • Da 93 giorni a 2 anni: 12 ore

    Per saperne di più, consulta Utilizza PromQL per creare policy di avviso.

Imposta la finestra di ripetizione test

La finestra di riapprovazione (duration) specifica per quanto tempo una serie temporale deve violare continuamente la soglia della condizione prima che Monitoring apra un avviso:

  • Tempo di risposta: per le condizioni di soglia delle metriche, l'impostazione della finestra di nuovo test su zero (visualizzata nella console Google Cloud come Nessun nuovo test) causa l'apertura di un avviso quando una singola misurazione allineata viola la soglia. Per le condizioni di assenza di metriche, i dati devono essere assenti per l'intera finestra di nuovo test prima che la condizione venga soddisfatta.

  • Evita falsi allarmi: per evitare falsi allarmi causati da picchi temporanei, jitter di valutazione o variazione della raccolta delle metriche, imposta la finestra di ripetizione del test su almeno 180 secondi (3 minuti). Se imposti la finestra di nuovo test su zero, viene attivato un avviso su un singolo punto anomalo.

Le condizioni delle policy di avviso vengono valutate a una frequenza fissa, tranne quando utilizzi PromQL. Per PromQL, la frequenza di valutazione può variare in base alla durata del lookback della query.

Policy con più condizioni

Una criterio di avviso può contenere fino a 6 condizioni.

Se utilizzi l'API Cloud Monitoring o se la criterio di avviso ha più condizioni, devi specificare quando viene aperto un avviso. Per configurare il modo in cui vengono combinate più condizioni, esegui una delle seguenti operazioni:

Console Google Cloud

Puoi configurare le opzioni del combinatore nel passaggio Trigger per più condizioni.

API

Puoi configurare le opzioni del combinatore con il campo combiner della struttura AlertPolicy.

Questa tabella elenca le impostazioni nella console Google Cloud , il valore equivalente nell'API Cloud Monitoring e una descrizione di ogni impostazione:

Google Cloud console
Valore trigger della policy		 Valore del combinatore dell'API Cloud Monitoring
 Significato
Qualsiasi condizione è soddisfatta OR Viene aperto un avviso se una risorsa causa la soddisfazione di 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 siano 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 sia soddisfatta. Questa impostazione è la scelta di 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 true, la condizione è soddisfatta.

Esempio

Considera un progetto Google Cloud che contiene due istanze VM, vm1 e vm2. Supponiamo inoltre di creare una policy di avviso con due condizioni:

  • La condizione denominata CPU usage is too high monitora l'utilizzo della CPU delle istanze. Questa condizione è soddisfatta quando l'utilizzo della CPU di un'istanza è superiore a 100 ms/s per 1 minuto.
  • La condizione denominata Excessive utilization monitora l'utilizzo della CPU delle istanze. Questa condizione viene soddisfatta quando l'utilizzo della CPU di un'istanza è superiore al 60% per 1 minuto.

Inizialmente, supponiamo che entrambe le condizioni restituiscano il valore false.

Supponiamo ora 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 sono 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 ora 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 fa sì che una condizione venga soddisfatta. In questo esempio, vm2 fa sì che la condizione Excessive utilization venga soddisfatta.

    Se vm2 fa sì che la condizione CPU usage is too high venga soddisfatta, viene creato un avviso anche in questo caso. Viene creato un avviso perché vm1 e vm2 che causano il soddisfacimento della condizione CPU usage is too high sono 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 fa sì che venga soddisfatta la condizione CPU usage is too high, mentre vm2 fa sì che venga soddisfatta la condizione Excessive utilization.

Dati delle metriche parziali

Quando i dati delle serie temporali smettono di arrivare o quando i dati sono in ritardo, Monitoring li classifica come mancanti. I dati mancanti possono impedire la chiusura degli avvisi. I ritardi nell'arrivo dei dati dai provider cloud di terze parti possono arrivare fino a 30 minuti, anche se i ritardi più comuni sono di 5-15 minuti. Un ritardo prolungato, più lungo della finestra di riapprovazione, può far sì che le condizioni entrino in uno stato "sconosciuto". Quando i dati arrivano, Monitoring 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 arrivati i dati.

Console Google Cloud

Puoi configurare il modo in cui Monitoring valuta una condizione di soglia della metrica 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 un avviso deve rimanere aperto dopo che i dati smettono di arrivare?

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 sostitutivo per i dati mancanti, utilizza il campo Valutazione dei dati mancanti che imposti nel passaggio Trigger della condizione. Questo campo è disattivato quando la finestra di riapprovazione è impostata su Nessuna riapprovazione.

    La finestra di riapprovazione è il campo denominato duration nell'API Cloud Monitoring.

  • Per configurare il tempo di attesa di Monitoring prima di chiudere un avviso aperto dopo che i dati non arrivano più, utilizza il campo Durata chiusura automatica avviso. 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:

CampoGoogle Cloud console
"Valutazione dei dati mancanti"		 Riepilogo Dettagli
Dati mancanti vuoti Gli avvisi aperti rimangono aperti.
Non vengono aperti nuovi avvisi.

Le condizioni soddisfatte continuano a essere soddisfatte 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.

Le condizioni non soddisfatte continuano a non essere soddisfatte 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.

Le condizioni soddisfatte continuano a essere soddisfatte 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 non soddisfatte, questa impostazione fa sì che la condizione di soglia della metrica si comporti come un metric-absence condition. Se i dati non arrivano entro il tempo specificato dalla finestra di nuovo test, la condizione viene valutata come soddisfatta. Per una criterio di avviso con una condizione, se la condizione viene soddisfatta, viene aperto un avviso.
Punti dati mancanti considerati come valori che non violano la condizione della policy Gli avvisi aperti vengono chiusi.
Non vengono aperti nuovi avvisi.

Le condizioni soddisfatte non vengono più soddisfatte quando i dati smettono di arrivare. Se è aperto un avviso per questa condizione, l'avviso viene chiuso.

Le condizioni non soddisfatte continuano a non essere soddisfatte quando i dati smettono di arrivare.

API

Puoi configurare il modo in cui Monitoring valuta una condizione di soglia della metrica 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 un avviso deve rimanere aperto dopo che i dati smettono di arrivare?

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 sostitutivo per i dati mancanti, utilizza il campo evaluationMissingData della struttura MetricThreshold. Questo campo viene ignorato quando il campo duration è pari a zero.

  • Per configurare il tempo di attesa di Monitoring prima di chiudere un avviso aperto dopo che i dati non arrivano più, utilizza il campo autoClose nella struttura AlertStrategy.

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

Campo API
evaluationMissingData		 Riepilogo Dettagli
EVALUATION_MISSING_DATA_UNSPECIFIED Gli avvisi aperti rimangono aperti.
Non vengono aperti nuovi avvisi.

Le condizioni soddisfatte continuano a essere soddisfatte 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.

Le condizioni non soddisfatte continuano a non essere soddisfatte quando i dati smettono di arrivare.
EVALUATION_MISSING_DATA_ACTIVE Gli avvisi aperti rimangono aperti.
È possibile aprire nuovi avvisi.

Le condizioni soddisfatte continuano a essere soddisfatte 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 non soddisfatte, questa impostazione fa sì che la condizione di soglia della metrica si comporti come un metric-absence condition. Se i dati non arrivano nel tempo specificato dal campo "duration", la condizione viene valutata come soddisfatta. Per una criterio di avviso con una condizione, se la condizione viene soddisfatta, viene aperto un avviso.
EVALUATION_MISSING_DATA_INACTIVE Gli avvisi aperti vengono chiusi.
Non vengono aperti nuovi avvisi.

Le condizioni soddisfatte non vengono più soddisfatte quando i dati smettono di arrivare. Se è aperto un avviso per questa condizione, l'avviso viene chiuso.

Le condizioni non soddisfatte continuano a non essere soddisfatte quando i dati smettono di arrivare.

Valutazione dei dati mancanti nei cicli di vita dei workload

Nelle condizioni di soglia delle metriche e di Monitoring Query Language, puoi configurare il modo in cui Monitoring valuta i dati mancanti quando le serie temporali interrompono i report. Per configurare la valutazione dei dati mancanti, la condizione deve avere una finestra di riapprovazione diversa da zero (duration). Le condizioni PromQL non supportano le impostazioni di valutazione dei dati mancanti; Monitoring chiude un avviso PromQL aperto dopo che i dati non sono presenti per due intervalli di valutazione più un periodo di tolleranza.

Quando una condizione valuta i dati mancanti con l'impostazione predefinita Dati mancanti vuoti (EVALUATION_MISSING_DATA_NO_OP o EVALUATION_MISSING_DATA_UNSPECIFIED), un avviso già aperto rimane aperto quando i dati delle metriche smettono di arrivare. Ad esempio, se un job o un container temporaneo subisce un picco prolungato che attiva un avviso e poi il workload termina, l'avviso rimane aperto fino alla scadenza della durata della chiusura automatica (7 giorni per impostazione predefinita) perché non arrivano punti dati successivi che dimostrano che la metrica è stata recuperata al di sotto della soglia.

Per allineare il comportamento criterio di avviso al ciclo di vita dell'applicazione, seleziona un'impostazione di valutazione dei dati mancanti e una durata della chiusura automatica in base ai seguenti tipi di workload:

Tipo di workload Impostazione consigliata per i dati mancanti Durata di chiusura automatica consigliata Comportamento e logica del ciclo di vita
Daemon e infrastruttura continui
(VM di Compute Engine, istanze Cloud SQL, nodi GKE)		 Dati mancanti vuoti (EVALUATION_MISSING_DATA_NO_OP) o Valori che violano la condizione (EVALUATION_MISSING_DATA_ACTIVE) Predefinita (7 giorni) o 24 ore L'infrastruttura continua deve emettere dati di telemetria delle metriche senza interruzioni. Se la telemetria si interrompe mentre un avviso è aperto, mantenere l'avviso aperto garantisce che le partizioni di rete, gli arresti anomali delle VM o gli errori dei daemon ricevano l'attenzione dell'operatore anziché chiudersi automaticamente.
Workload temporanei e servizi di scalabilità automatica
(pod GKE, job e revisioni Cloud Run, Cloud Tasks, worker batch)		 Valori che non violano la condizione (EVALUATION_MISSING_DATA_INACTIVE) Da 30 minuti a 2 ore I pod temporanei e i container serverless terminano o scalano fino a zero dopo aver completato il lavoro. Se imposti i dati mancanti su Inattivo, quando un container temporaneo scompare, la condizione smette di essere valutata come violata e l'avviso viene chiuso. La riduzione della durata della chiusura automatica impedisce che gli incidenti temporanei si protraggano per giorni.
Workload periodici e pianificati
(query batch giornaliere, cron job orari, analisi dei giorni di calendario)		 Valori che non violano la condizione (EVALUATION_MISSING_DATA_INACTIVE) Da 30 minuti a 2 ore I workload batch periodici generano report sulle metriche solo durante le esecuzioni attive. Poiché la durata della chiusura automatica viene misurata dal momento in cui la telemetria smette di arrivare, l'utilizzo di EVALUATION_MISSING_DATA_INACTIVE e di una durata della chiusura automatica ridotta (almeno 30 minuti) impedisce che gli avvisi di singola esecuzione persistano per più giorni di calendario.

Puoi ridurre al minimo i problemi dovuti ai dati mancanti eseguendo 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 riapprovazione più lunghe nelle tue condizioni. L'utilizzo di una finestra di nuovo test più lunga ha lo svantaggio di rendere le policy di avviso meno reattive.

  • Scegli metriche con un ritardo di raccolta inferiore:

    • Metriche dell'agente Monitoring, in particolare 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 è in ritardo.

Per saperne di più, consulta la panoramica di Ops Agent, la panoramica delle metriche definite dall'utente e le metriche basate su log.

Quando Monitoring 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 della policy.

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

Potresti ricevere più notifiche univoche relative a una criterio di avviso se si verifica una delle seguenti condizioni:

  • Una condizione sta monitorando più serie temporali.

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

    • Tutte le condizioni sono soddisfatte: quando tutte le condizioni sono soddisfatte, per ogni serie temporale che comporta il rispetto di una condizione, la 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 avvisano anche quando la condizione viene soddisfatta e quando non lo è più. 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 Monitoring non invia notifiche o non crea avvisi

Nelle seguenti situazioni, Monitoring non crea avvisi né invia notifiche quando vengono soddisfatte le condizioni di una criterio di avviso:

  • La criterio di avviso è disattivata.
  • La criterio di avviso è posticipata.
  • Monitoring ha raggiunto il limite per il numero massimo di avvisi aperti.

Policy di avviso disattivate

Monitoring non crea avvisi né invia notifiche per le policy di avviso disattivate. Tuttavia, Monitoring continua a valutare le condizioni di una criterio di avviso disabilitata.

Quando attivi una policy disattivata, Monitoring valuta i valori di tutte le condizioni nell'ultima finestra di nuovo test. La finestra di riapprovazione più recente potrebbe includere dati acquisiti prima, durante e dopo l'attivazione della policy. Le condizioni di una policy disattivata possono essere soddisfatte immediatamente dopo la ripresa della policy, anche con finestre di riapprovazione ampie.

Ad esempio, supponiamo che tu abbia una criterio di avviso che monitora un processo specifico e che la disabiliti. La settimana successiva, il processo si interrompe e, poiché la criterio di avviso è disattivata, non ricevi alcuna notifica. Se riavvii il processo e attivi immediatamente la criterio di avviso, Monitoring riconosce che il processo non è stato attivo negli ultimi cinque minuti e genera un avviso.

Gli avvisi relativi a una criterio di avviso disattivata rimangono aperti fino alla scadenza della durata di chiusura automatica della policy.

Policy di avviso posticipate

Monitoring non invia notifiche né crea avvisi per una criterio di avviso posticipata. Ti consigliamo di posticipare le policy di avviso quando vuoi impedire l'invio di notifiche da parte di una criterio di avviso solo per brevi intervalli. 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 una criterio di avviso, Monitoring chiude tutti gli avvisi aperti correlati alla policy. Monitoring può aprire nuovi avvisi dopo la scadenza del posticipo. Per informazioni, consulta Posticipa 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 l'apertura di avvisi per ogni risorsa da parte della criterio di avviso. 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 policy può aprire contemporaneamente è limitato a 1000.

Ad esempio, considera una policy che si applica a 2000 istanze Compute Engine e ogni istanza fa sì che le condizioni di avviso siano soddisfatte. Monitoring limita il numero di avvisi aperti a 1000. Eventuali altre condizioni soddisfatte vengono ignorate finché non vengono chiusi alcuni degli avvisi aperti per la policy.

A causa di questo limite, un singolo canale di notifica può ricevere fino a 1000 notifiche alla volta. Se la policy di avviso ha più canali di notifica, questo limite si applica a ciascun canale di notifica in modo indipendente.

Latenza

La 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 massima di 180 secondi, Monitoring non creerà un avviso per un massimo di 180 secondi dopo che la condizione della criterio di avviso restituisce true. Per saperne di più, 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 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 di uptime, questo tempo può essere in media di due minuti (dalla fine della finestra di nuovo test).

  • Finestra di ripetizione test: la finestra configurata per la condizione. Le condizioni sono soddisfatte solo quando una condizione è vera per l'intera finestra di riapprovazione. Ad esempio, un'impostazione della finestra di nuovo 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 ai contenuti inviati), a volte di alcuni minuti. Su alcuni canali, come SMS e Slack, non è garantito che i messaggi vengano recapitati.

Passaggi successivi