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, ad esempio in base alla scelta della finestra di riesami, consulta 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 sono limitate 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 relativo all'utilizzo del disco per filtrare le serie temporali per i dispositivi loopback /dev/loop0 e /dev/loop1. Ad esempio, potresti 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 che sembra creare incidenti in modo prematuro o errato.

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

  • Se esiste una lacuna nei dati, in particolare per i criteri di avviso con condizioni di assenza di metrica o "meno di", è possibile creare un incidente che sembra anomalo. A volte l'incidente non mostra la lacuna nei dati e a volte la lacuna viene corretta 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. Un simile vuoto nei dati sottostanti potrebbe essere sufficiente per un criterio di avviso per creare un incidente.

    • I punti nelle metriche basate su log possono arrivare in ritardo e essere sottoposti a backfill, fino a 10 minuti nel passato. Il comportamento di completamento a ritroso corregge efficacemente la lacuna, che viene riempita quando i dati arrivano finalmente. Pertanto, un'interruzione in una metrica basata su log che non può più essere visualizzata potrebbe aver causato la creazione di un incidente da parte di un criterio di avviso.

  • Le condizioni di assenza di metriche e di soglia "meno di" vengono valutate in tempo reale, con un piccolo ritardo nella 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, imposta la finestra di riesami su almeno 3 minuti. Se imposti la finestra di nuovo test su valore più recente o, in modo equivalente, su 0 secondi, una singola misurazione può causare la creazione di un incidente.

  • Quando la condizione di un criterio di avviso viene modificata, possono trascorrere diversi minuti prima che la modifica venga propagata nell'infrastruttura di avviso. Durante questo periodo di tempo, potresti ricevere una notifica di incidenti che hanno soddisfatto le condizioni criterio di avviso originali.

  • Quando arrivano i dati delle serie temporali, può essere necessario fino a un minuto prima che si propaghino 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à di questa situazione, utilizza un periodo di allineamento di almeno cinque minuti.

L'incidente non viene 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 più, ma un incidente aperto non viene chiuso automaticamente.

Se la risorsa di base monitorata da un criterio di avviso contiene l'etichetta metadata.system_labels.state e se questo criterio non è scritto con il Monitoring Query Language, il monitoraggio 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

Vai alla pagina degli incidenti nella console Google Cloud e seleziona un 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, inclusi i dati delle metriche, e per poter confermare o chiudere gli incidenti, assicurati di disporre dei ruoli IAM di Visualizzatore monitoraggio (roles/monitoring.viewer) e Editor incidenti Monitoring Cloud Console (roles/monitoring.cloudConsoleIncidentEditor).

I ruoli personalizzati non possono concedere l'autorizzazione richiesta per visualizzare i dettagli degli incidenti.

L'incidente non viene creato quando la condizione è soddisfatta

Hai creato un criterio di avviso con una condizione. Il grafico per il 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 è stata soddisfatta la condizione del criterio di avviso, 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 la risorsa contiene l'etichetta metadata.system_labels.state e quando il criterio di avviso non è scritto con il Monitoring Query Language.

I dettagli dell'incidente elencano il progetto sbagliato

Riceverai una notifica e il riepilogo delle condizioni elenca il progetto Google Cloud in cui è stato creato l'incidente, ovvero il progetto di 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, al termine del raggruppamento l'etichetta che memorizza 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 nel 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 vengono registrate 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 entro il periodo di avviso.

Quando non è possibile chiudere un incidente a causa di un errore interno, si verifica il seguente errore:

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

Quando viene visualizzato 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 contenente più condizioni e le hai unite 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 la soddisfazione di una condizione. Di conseguenza, se hai criteri di avviso con più condizioni, puoi potenzialmente ricevere una notifica e un incidente per ogni serie temporale che determina il verificarsi 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 le condizioni del criterio sono soddisfatte, puoi 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 il monitoraggio per creare un singolo incidente e inviare una singola notifica.

Per ulteriori informazioni, consulta 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 quanto segue:

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

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

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

La creazione del criterio di avviso non riesce nell'API a causa di una metrica mancante

Di recente hai creato una metrica e poi hai fatto riferimento a questa metrica quando hai provato a 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.