Risolvere i problemi relativi ai criteri di avviso

Questa pagina spiega perché alcuni criteri di avviso potrebbero comportarsi in modo diverso rispetto a quanto previsto e offre possibili soluzioni per queste situazioni.

Per informazioni sulle variabili che possono influire su un criterio di avviso, scegliendo la finestra di test, ad esempio vedi Comportamento dei criteri di avviso basati su metriche.

Il criterio di utilizzo del disco crea incidenti imprevisti

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

Una causa nota di incidenti imprevisti per questi criteri è che le condizioni non si limitano al monitoraggio dei dischi fisici. Questi criteri monitorano invece tutti i dischi, inclusi i dischi virtuali come i dispositivi loopback. Se un disco virtuale viene creato in modo che il suo utilizzo sia pari al 100%, verrà generato un incidente per la norma.

Ad esempio, considera il seguente output del comando df di Linux, 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, deve essere configurato un criterio di avviso di utilizzo del disco filtra le serie temporali per dispositivi di loopback /dev/loop0 e /dev/loop1. Ad esempio, aggiungi 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 che sembra creare incidenti in modo prematuro o errato.

Esistono diversi motivi per cui potresti ricevere notifiche di incidenti apparentemente errati:

• Se c'è una lacuna nei dati, in particolare per i criteri di avviso assenza di metrica o condizioni di soglia "minore di", viene incidente che appare anomalo. A volte l'incidente non mostra la lacuna nei dati, mentre a volte la lacuna nei dati viene corretto automaticamente:

  • Nei grafici, ad esempio, le lacune potrebbero non essere visualizzate perché i valori dei dati mancanti vengono interpolati. Anche se mancano diversi minuti di dati, il grafico collega i punti mancanti per garantire la continuità visiva. Tale una lacuna nei dati sottostanti potrebbe essere sufficiente perché un criterio di avviso creare un incidente.

  • I punti nelle metriche basate su log possono arrivare in ritardo ed essere sottoposti a backfill. fino a 10 minuti prima della data corrente. Il comportamento del backfill efficace corregge il divario; la lacuna viene colmata quando finalmente arrivano i dati. Pertanto, una lacuna in una metrica basata su log che non può più essere visualizzata potrebbe avere ha causato la creazione di un incidente da parte di un criterio di avviso.

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

• Le condizioni configurate per creare un incidente su una singola misura possono comportare incidenti che sembrano prematuri o errati. Per evitare questa situazione, assicurati che siano necessarie più misurazioni prima che venga creato un evento impostando la finestra di riesami di una condizione su un valore superiore al doppio della frequenza di campionamento della metrica.

  Ad esempio, se una metrica viene campionata ogni 60 secondi, quindi imposta la finestra per il nuovo test su almeno 3 minuti. Se imposti la finestra di test con il valore più recente o equivalente a 0 secondi, una singola misurazione può causare la creazione di un incidente.

• Quando la condizione di un criterio di avviso viene modificata, possono essere necessari minuti per consentire la propagazione della modifica nell'infrastruttura di avviso. Durante questo periodo di tempo, potresti ricevere una notifica di incidenti che hanno soddisfatto le condizioni dei criteri di avviso originali.

• Quando arrivano i dati delle serie temporali, può essere necessario fino a un minuto si propagano nell'intera infrastruttura di avviso. Durante questo procedura, un 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à in questa situazione, utilizza un periodo allineato di almeno cinque minuti.

L'incidente non è chiuso quando i dati non arrivano più

Segui le indicazioni riportate in Dati delle metriche parziali e configura un criterio di avviso per chiudere gli incidenti quando i dati non arrivano più. In alcuni casi, i dati non arrivano, ma non si verifica un incidente aperto chiuso automaticamente.

Se la risorsa sottostante monitorata da un criterio di avviso contiene l'etichetta metadata.system_labels.state e se questo criterio non viene scritto con Monitoring Query Language, Monitoring può determinare lo stato della risorsa. Se è noto che lo stato di una risorsa è disattivato, il monitoraggio non chiude automaticamente gli incidenti quando i dati non arrivano più. Tuttavia, puoi chiudere questi incidenti manualmente.

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

Accedi alla pagina degli incidenti nella console Google Cloud e seleziona un l'incidente da visualizzare. Dovresti vedere la pagina dei dettagli aperta. 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, assicurati di disporre dei ruoli IAM di visualizzatore degli incidenti della console Cloud Monitoring (roles/monitoring.cloudConsoleIncidentViewer) e visualizzatore degli account Stackdriver (roles/stackdriver.accounts.viewer).

Per visualizzare tutti i dettagli degli incidenti, compresi i dati delle metriche, e poter conferma o chiudi gli incidenti, assicurati di avere il ruolo IAM ruoli di Visualizzatore Monitoring (roles/monitoring.viewer) e Editor incidenti console Cloud Monitoring (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 relativo il criterio di avviso mostra che i dati monitorati violano la condizione, ma non hai ricevuto notifica e non è stato creato un incidente.

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

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

• È noto che lo stato della risorsa monitorata dal criterio di avviso è disabilitato. Il monitoraggio può determinare lo stato di una risorsa quando questa contiene metadata.system_labels.state e quando il criterio di avviso non è scritte con Monitoring Query Language.

I dettagli dell'incidente elencano il progetto sbagliato

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

Le opzioni di aggregazione specificate nella condizione di un criterio di avviso determinano il progetto Google Cloud 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 in cui è archiviato l'ID progetto viene rimossa.

• Quando le opzioni di aggregazione mantengono l'etichetta che memorizza l'ID progetto, le notifiche degli incidenti includono il nome del progetto Google Cloud che memorizza le serie temporali che causano l'incidente. Per preservare l'etichetta dell'ID progetto, includi l'etichetta project_id nel campo di raggruppamento o 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 nell’ultimo durante il periodo di avviso. 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 ricevute durante il periodo di avviso.

Il seguente errore si verifica quando non è possibile chiudere un incidente a causa di 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 sia il monitoraggio a chiudere automaticamente l'incidente.

Per saperne di più, consulta Gestire gli incidenti.

Il criterio con più condizioni crea più notifiche

Hai creato un criterio di avviso che contiene più condizioni e hai aderito queste condizioni con un AND logico. Dovresti ricevere una notifica e avere un incidente creato quando tutte le condizioni sono soddisfatte. Tuttavia, ricevi più notifiche e noti che sono stati creati più incidenti.

Il monitoraggio invia una notifica e crea un incidente per ogni serie temporale che causa il rispetto di una condizione. Di conseguenza, quando esistono criteri di avviso con più condizioni, potresti ricevere una notifica e un incidente per ogni serie temporale che causa da soddisfare.

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 le condizioni delle norme sono soddisfatte, che potresti ricevere da 2 (una serie temporale è soddisfatta in ogni condizione) e 6 (tutte le serie temporali sono soddisfatte per ogni condizione) notifiche e incidenti.

Non puoi configurare Monitoring per creare un singolo incidente invia una singola notifica.

Per saperne di più, vedi Notifiche per incidente.

La variabile per un'etichetta 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 la situazione, prova a procedere nel seguente modo:

• Assicurati che le impostazioni di aggregazione per il criterio di avviso conservino il valore dell'etichetta da visualizzare.

  Ad esempio, supponiamo che tu crei un criterio di avviso che monitori i byte del disco scritti dalle istanze VM. Vuoi che nella documentazione sia elencato il dispositivo che causa la notifica, quindi aggiungi al campo della documentazione quanto segue: device: ${metric.label.device}.

  Devi anche assicurarti che le impostazioni di aggregazione conservino il valore dell'etichetta device. Puoi mantenere questa etichetta impostando il parametro funzione di aggregazione su none o assicurandoti che il raggruppamento selezioni includi 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 su 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 il 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.