Risolvere i problemi relativi ai criteri di avviso

Questa pagina spiega perché alcuni criteri di avviso potrebbero comportarsi in modo diverso dal previsto e offre possibili rimedi per queste situazioni.

Per informazioni sulle variabili che possono influire su una criterio di avviso, ad esempio la scelta della finestra di nuovo test, consulta Comportamento delle policy di avviso basate su metriche.

I criteri di utilizzo del disco creano incidenti imprevisti

Hai creato un criterio di avviso per monitorare la capacità "utilizzata" dei dischi nel tuo sistema. Questa policy monitora la metrica agent.googleapis.com/disk/percent_used. Prevedi di ricevere una notifica solo quando l'utilizzo di un disco fisico supera la soglia impostata nella condizione. Tuttavia, questa norma crea incidenti quando l'utilizzo del disco di ogni disco fisico è inferiore alla soglia.

Una causa nota di incidenti imprevisti per queste norme è che le condizioni non sono limitate al monitoraggio dei dischi fisici. Questi criteri monitorano invece tutti i dischi, inclusi quelli virtuali come i dispositivi di loopback. Se un disco virtuale è costruito in modo che il suo utilizzo sia del 100%, verrà creato un incidente per la norma.

Ad esempio, considera il seguente output del comando Linux df, che mostra lo spazio su disco disponibile sui file system montati per un sistema:

$ df
/dev/root     9983232  2337708  7629140   24%  /
devtmpfs      2524080        0  2524080    0%  /dev
tmpfs         2528080        0  2528080    0%  /dev/shm
...
/dev/sda15     106858     3934   102924    4%  /boot/efi
/dev/loop0      56704    56704        0  100%  /snap/core18/1885
/dev/loop1     129536   129536        0  100%  /snap/google-cloud-sdk/150
...

Per questo sistema, un criterio di avviso di utilizzo del disco deve essere configurato per filtrare le serie temporali per i dispositivi di loopback /dev/loop0 e /dev/loop1. Ad esempio, puoi aggiungere il filtro device !=~ ^/dev/loop.*, che esclude tutte le serie temporali la cui etichetta device non corrisponde all'espressione regolare ^/dev/loop.*.

Cause comuni di incidenti anomali

Hai creato un criterio di avviso e sembra che crei incidenti in modo prematuro o errato.

Esistono diversi motivi per cui potresti ricevere una notifica di incidenti che sembrano errati:

• Se si verifica una lacuna nei dati, in particolare per i criteri di avviso con condizioni di assenza di metriche o di soglia "inferiore a", è possibile creare un incidente che sembra anomalo. A volte l'incidente non mostra il gap di dati e a volte il gap di dati viene corretto automaticamente:

  • Nei grafici, ad esempio, le lacune potrebbero non essere visualizzate perché i valori per i dati mancanti vengono interpolati. Anche quando mancano diversi minuti di dati, il grafico collega i punti mancanti per garantire la continuità visiva. Un divario di questo tipo nei dati sottostanti potrebbe essere sufficiente per unacriterio di avvisoo per creare un incidente.

  • I punti nelle metriche basate sui log possono arrivare in ritardo ed essere riempiti, fino a 10 minuti nel passato. Il comportamento di backfill corregge in modo efficace la lacuna, che viene colmata quando i dati arrivano. Pertanto, un intervallo in una metrica basata su log che non è più visibile potrebbe aver indotto un criterio di avviso a creare un incidente.

• Le condizioni di assenza di metriche e di soglia "minore di" vengono valutate in tempo reale, con un piccolo ritardo della query. Lo stato della condizione può cambiare tra il momento in cui viene valutata e il momento in cui l'incidente corrispondente è visibile in Monitoring.

• Le condizioni configurate per creare un incidente su una singola misura possono generare incidenti che sembrano prematuri o errati. Per evitare questa situazione, verifica che siano necessarie più misurazioni prima che venga creato un incidente impostando la finestra di ripetizione del test di una condizione in modo che sia più del doppio della frequenza di campionamento della metrica.

  Ad esempio, se una metrica viene campionata ogni 60 secondi, imposta la finestra di test di nuovo su almeno 3 minuti. Se imposti la finestra di ripetizione del test sul valore più recente o, in modo equivalente, su 0 secondi, una singola misurazione può causare la creazione di un incidente.

• Quando viene modificata la condizione di un criterio di avviso, possono trascorrere diversi minuti prima che la modifica venga propagata nell'infrastruttura di avviso. Durante questo periodo di tempo, potresti ricevere notifiche di incidenti che soddisfano le condizioni originalicriterio di avvisoo.

• Quando arrivano i dati delle serie temporali, può essere necessario fino a un minuto prima che i dati si propaghino nell'intera infrastruttura di avvisi. Durante questo processo, una criterio di avviso potrebbe valutare una condizione come soddisfatta anche se i dati delle serie temporali non sono stati propagati al grafico delle serie temporali. Di conseguenza, potresti ricevere una notifica anche se il grafico non indica che la condizione è soddisfatta. Per ridurre la possibilità di questa situazione, utilizza un periodo di allineamento di almeno cinque minuti.

• La ridenominazione dell'etichetta App Hub metadata.system_labels.apphub_host_project_id in metadata.system_labels.apphub_application_container potrebbe comportare la generazione di alcuni nuovi incidenti e la mancata chiusura di alcuni incidenti aperti.

  Non è richiesta alcuna azione. Gli avvisi si chiudono automaticamente quando i dati smettono di arrivare, dopo la scadenza della durata di chiusura automatica. Per maggiori informazioni, consulta la pagina Dati parziali delle metriche.

L'incidente non viene chiuso quando i dati smettono di arrivare

Segui le indicazioni riportate in Dati parziali delle metriche e configura una criterio di avviso per chiudere gli incidenti quando i dati smettono di arrivare. In alcuni casi, i dati smettono di arrivare, ma un incidente aperto non viene chiuso automaticamente.

Se la risorsa sottostante monitorata da un criterio di avviso contiene l'etichetta metadata.system_labels.state e se questo criterio non è scritto con il linguaggio di query di Monitoring, Monitoring può determinare lo stato della risorsa. Se lo stato di una risorsa è noto per essere disattivato, Monitoring non chiude automaticamente gli incidenti quando i dati smettono di arrivare. Tuttavia, puoi chiudere manualmente questi incidenti.

Impossibile visualizzare i dettagli dell'incidente a causa di un errore di autorizzazione

Vai alla pagina degli incidenti nella console Google Cloud e seleziona un incidente da visualizzare. Ti aspetti che si apra la pagina dei dettagli. Tuttavia, la pagina dei dettagli non si apre e viene visualizzato il messaggio "Autorizzazione negata".

Per visualizzare tutti i dettagli dell'incidente, ad eccezione dei dati delle metriche, verifica di disporre dei ruoli Identity and Access Management (IAM) di visualizzatore incidenti della console Google Cloud Monitoring (roles/monitoring.cloudConsoleIncidentViewer) e visualizzatore account Stackdriver (roles/stackdriver.accounts.viewer).

Per visualizzare tutti i dettagli degli incidenti, inclusi i dati delle metriche, e per poter confermare o chiudere gli incidenti, verifica di disporre dei ruoli IAM di Visualizzatore Monitoring (roles/monitoring.viewer) e Editor incidenti di Monitoring Cloud Console (roles/monitoring.cloudConsoleIncidentEditor).

I ruoli personalizzati non possono concedere l'autorizzazione necessaria per visualizzare i dettagli dell'incidente.

L'incidente non viene creato quando la condizione è soddisfatta

Hai creato un criterio di avviso con una condizione. Il grafico per la criterio di avviso mostra che i dati monitorati violano la condizione, ma non hai ricevuto una notifica e non è stato creato un incidente.

Se uno dei seguenti criteri è vero dopo che la condizione del criterio di avviso è soddisfatta, Monitoring non apre l'incidente.

• Il criterio di avviso è posticipato.
• Il criterio di avviso è disabilitato.
• Il criterio di avviso ha raggiunto il numero massimo di incidenti che può aprire contemporaneamente.

• Lo stato della risorsa monitorata dal criterio di avviso è noto per essere disattivato. Il monitoraggio può determinare lo stato di una risorsa quando la risorsa contiene l'etichetta metadata.system_labels.state e quando la criterio di avviso non è scritta con il linguaggio di query di Monitoring.

L'elenco dei dettagli dell'incidente mostra il progetto sbagliato

Ricevi una notifica e il riepilogo della condizione elenca il progettoGoogle Cloud in cui è stato creato l'incidente, ovvero il progetto di definizione dell'ambito. Tuttavia, ti aspetti che l'incidente elenchi il nome del progetto Google Cloud che archivia le serie temporali che hanno causato la creazione dell'incidente da parte di Monitoring.

Le opzioni di aggregazione specificate nella condizione di una criterio di avviso determinano il Google Cloud progetto a cui viene fatto riferimento in una notifica:

• Quando le opzioni di aggregazione eliminano l'etichetta che memorizza l'ID progetto, le informazioni sull'incidente elencano il progetto di definizione dell'ambito. Ad esempio, se raggruppi i dati solo per zona, dopo il raggruppamento l'etichetta che memorizza l'ID progetto viene rimossa.

• Quando le opzioni di aggregazione conservano l'etichetta che memorizza l'ID progetto, le notifiche relative agli incident includono il nome del progetto Google Cloud che memorizza la serie temporale che causa l'incidente. Per conservare l'etichetta ID progetto, includi l'etichetta project_id nel campo di raggruppamento oppure non raggruppare le serie temporali.

Impossibile chiudere manualmente un incidente

Hai ricevuto una notifica di un incidente sul tuo sistema. Vai alla pagina dei dettagli dell'incidente e fai clic su Chiudi incidente. Ti aspetti che l'incidente venga chiuso, ma ricevi il messaggio di errore:

Unable to close incident with active conditions.

Puoi chiudere un incidente solo quando non arrivano osservazioni nel periodo di avviso più recente. Il periodo di avviso, che in genere ha un valore predefinito di 5 minuti, è definito come parte della condizione del criterio di avviso ed è configurabile. Il messaggio di errore precedente indica che i dati sono stati ricevuti nel periodo di avviso.

Il seguente errore si verifica quando non è possibile chiudere un incidente a causa di un errore interno:

Unable to close incident. Please try again in a few minutes.

Quando visualizzi il messaggio di errore precedente, puoi riprovare l'operazione di chiusura o lasciare che Monitoring chiuda automaticamente l'incidente.

Per saperne di più, consulta Gestione degli incidenti.

I criteri con più condizioni creano più notifiche

Hai creato un criterio di avviso che contiene più condizioni e le hai unite con un AND logico. Ti aspetti di ricevere una notifica e che venga creato un incidente quando tutte le condizioni sono soddisfatte. Tuttavia, ricevi più notifiche e vedi che vengono creati più incidenti.

Monitoring invia una notifica e crea un incidente per ogni serie temporale che soddisfa una condizione. Di conseguenza, quando hai criteri di avviso con più condizioni, puoi potenzialmente ricevere una notifica e un incidente per ogni serie temporale che causa il soddisfacimento delle condizioni unite.

Ad esempio, hai un criterio di avviso con due condizioni, in cui ogni condizione monitora tre serie temporali. Il criterio invia una notifica solo quando sono soddisfatte entrambe le condizioni. Quando vengono soddisfatte le condizioni della norma, potresti ricevere da 2 (una serie temporale è soddisfatta in ogni condizione) a 6 (tutte le serie temporali sono soddisfatte in ogni condizione) notifiche e incidenti.

Non puoi configurare Monitoring in modo che crei un singolo incidente e invii una singola notifica.

Per maggiori informazioni, vedi Notifiche per incidente.

La variabile per un'etichetta della metrica è null

Crea un criterio di avviso e aggiungi una variabile per un'etichetta della metrica alla sezione della documentazione. Ti aspetti che le notifiche mostrino il valore della variabile, ma il valore è impostato su null.

Per risolvere il problema, prova quanto segue:

• Verifica che le impostazioni di aggregazione per il criterio di avviso conservino l'etichetta che vuoi visualizzare.

  Ad esempio, supponiamo di creare una criterio di avviso che monitori i byte scritti su disco dalle istanze VM. Vuoi che la documentazione elenchi il dispositivo che causa la notifica, quindi aggiungi al campo della documentazione quanto segue: device: ${metric.label.device}.

  Devi anche verificare che le impostazioni di aggregazione conservino il valore dell'etichetta device. Puoi conservare questa etichetta impostando la funzione di aggregazione su none o verificando che le selezioni di raggruppamento includano device.

• Verifica la sintassi e l'applicabilità della variabile. Per informazioni sulla sintassi, consulta Annotare le notifiche con la documentazione definita dall'utente.

  Ad esempio, la variabile log.extracted_label.KEY è supportata solo per i criteri di avviso basati su log. Questa variabile viene sempre visualizzata come null quando un criterio di avviso monitora una metrica, anche una metrica basata sui log.

Nessun nuovo dato dopo le modifiche alle definizioni delle metriche

Modifichi la definizione di una metrica definita dall'utente, ad esempio modificando il filtro utilizzato in una metrica basata su log, e la criterio di avviso non riflette la modifica apportata alla definizione della metrica.

Per risolvere il problema, forza l'aggiornamento del criterio di avviso modificando il nome visualizzato del criterio.

La creazione di criteri di avviso non riesce nell'API a causa della metrica mancante

Di recente hai creato una metrica e poi hai fatto riferimento a questa metrica quando hai tentato di creare un criterio di avviso nell'API Cloud Monitoring. Tuttavia, il comando API non va a buon fine e mostra il seguente errore:

Error 404: Cannot find metric(s) that match type = "METRIC_NAME".
If a metric was created recently, it could take up to 10 minutes to become
available. Please try again soon.

Per risolvere il problema, attendi almeno dieci minuti e poi invia di nuovo la richiesta API.

Il grafico della policy di avviso non mostra la violazione della soglia

Hai ricevuto una notifica che ti informa che è stato aperto un incidente per la tua norma di avviso. Tuttavia, quando vai alla pagina dei dettagli delle norme, il grafico non indica che la soglia è stata violata.

Per risolvere il problema, prova a ridurre l'intervallo di tempo del grafico. Puoi abbreviare l'intervallo di tempo utilizzando il selettore dell'intervallo di tempo nella barra degli strumenti o evidenziando gli intervalli di tempo nel grafico con il puntatore.

I grafici hanno una risoluzione limitata e potrebbero non mostrare tutte le misurazioni per alcuni intervalli di tempo.