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 un criterio di avviso, scegliendo la finestra di nuovo test, ad esempio, 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.
Prevedi 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 di loopback. Se un disco virtuale viene creato in modo che il suo utilizzo sia al 100%, ciò causerebbe un incidente per la creazione del criterio.
Considera ad esempio il seguente output del comando df di Linux, che mostra lo spazio su disco disponibile nei 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 per
filtrare le serie temporali per i
dispositivi di 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 prematuramente o in modo errato.
Esistono diversi motivi per cui potresti ricevere notifiche di incidenti che sembrano non corretti:
Se c'è una lacuna nei dati, in particolare per i criteri di avviso con condizioni di assenza della metrica o di soglia "inferiore a", può essere creato un incidente che sembra anomalo. A volte l'incidente non mostra la carenza di dati, mentre altre volte la lacuna viene corretta automaticamente:
Nei grafici, ad esempio, gli spazi vuoti potrebbero non essere visualizzati perché i valori per i dati mancanti vengono interpolati. Anche se mancano diversi minuti di dati, il grafico collega i punti mancanti per garantire la continuità visiva. Una tale lacuna nei dati sottostanti potrebbe essere sufficiente affinché un criterio di avviso crei un incidente.
I punti nelle metriche basate su log possono arrivare in ritardo ed essere sottoposti a backfill fino a 10 minuti prima. Il comportamento del backfill corregge in modo efficace il vuoto, che viene colmato quando finalmente arrivano i dati. Pertanto, una lacuna in una metrica basata su log che non può più essere visualizzata potrebbe aver causato un criterio di avviso per creare un incidente.
Le condizioni di assenza di metrica e di soglia "minore di" vengono valutate in tempo reale, con un piccolo 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 Monitoring.
Le condizioni configurate per creare un incidente su una singola misura possono generare incidenti che sembrano essere prematuri o errati. Per evitare questa situazione, assicurati che siano necessarie più misurazioni prima che venga creato un incidente impostando la finestra di ripetizione 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 su almeno 3 minuti. Se imposti la finestra del test sul 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, la propagazione della modifica nell'infrastruttura di avviso può richiedere diversi minuti. Durante questo periodo di tempo, potresti ricevere la notifica di incidenti che hanno soddisfatto le condizioni originali criterio di avviso.
Quando arrivano i dati delle serie temporali, la propagazione dei dati nell'intera infrastruttura di avviso può richiedere fino a un minuto. Durante questo processo, un criterio di avviso potrebbe valutare una condizione come soddisfatta anche se i dati delle serie temporali non si sono propagati nel grafico delle serie temporali. Di conseguenza, potresti ricevere una notifica anche se il grafico non indica che la condizione è soddisfatta. Per ridurre la possibilità che si verifichi questa situazione, utilizza un periodo allineato di almeno cinque minuti.
L'incidente non è chiuso quando i dati non arrivano più
Segui le indicazioni in Dati delle metriche parziali e configuri 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 sottostante monitorata da un criterio di avviso contiene l'etichetta metadata.system_labels.state e se il criterio non è scritto con Monitoring Query Language, Monitoring può determinare lo stato della risorsa. Se è noto che lo stato di una risorsa è disabilitato, Monitoring non chiude automaticamente gli incidenti all'arrivo
dei dati. Tuttavia, puoi chiudere questi incidenti manualmente.
Impossibile visualizzare i dettagli dell'incidente a causa di un errore di autorizzazione
Puoi accedere alla pagina degli incidenti nella console Google Cloud e selezionare un incidente da visualizzare. Prevedi che la pagina dei dettagli sia aperta. Tuttavia, la pagina dei dettagli non si apre e viene visualizzato il messaggio "Autorizzazione negata".
Per visualizzare tutti i dettagli degli incidenti, ad eccezione dei dati delle metriche, assicurati di disporre dei ruoli IAM (Identity and Access Management) di Visualizzatore incidenti di Cloud Console di 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, assicurati di disporre dei ruoli IAM 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 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 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 monitorato dal criterio di avviso è noto per essere disabilitato. Monitoring può determinare lo stato di una risorsa quando quest'ultima contiene l'etichetta
metadata.system_labels.statee quando il criterio di avviso non è scritto con Monitoring Query Language.
Elenco dei dettagli dell'incidente: progetto errato
Ricevi una notifica e il riepilogo della condizione elenca il progetto Google Cloud in cui è stato creato l'incidente, ovvero il progetto di ambito. Tuttavia, ti aspetti che l'incidente elenca il nome del progetto Google Cloud in cui è archiviata la serie temporale in base alla quale Monitoringing ha creato l'incidente.
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 archivia 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 archivia l'ID progetto viene rimossa.
Quando le opzioni di aggregazione conservano l'etichetta che archivia l'ID progetto, le notifiche degli incidenti includono il nome del progetto Google Cloud in cui è archiviata la serie temporale in cui si verifica l'incidente. Per mantenere l'etichetta dell'ID progetto, includi l'etichetta
project_idnel campo di raggruppamento oppure non raggruppare le serie temporali.
Impossibile chiudere manualmente un incidente
Hai ricevuto una notifica relativa a un incidente sul tuo sistema. Vai alla pagina dei dettagli dell'incidente e fai clic su Chiudi incidente. Prevedi che l'incidente verrà chiuso, ma riceverai il messaggio di errore:
Unable to close incident with active conditions.
Puoi chiudere un incidente solo se 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 entro il 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 viene visualizzato il messaggio di errore precedente, puoi riprovare l'operazione di chiusura o consentire a Monitoring di chiudere automaticamente l'incidente.
Per saperne di più, vedi Gestione degli incidenti.
Il criterio per più condizioni crea più notifiche
Hai creato un criterio di avviso che contiene più condizioni e hai unito queste condizioni con un AND logico. Dovresti ricevere una notifica e creare un incidente quando tutte le condizioni sono soddisfatte. Tuttavia, ricevi più notifiche e noti che vengono creati più incidenti.
Monitoring invia una notifica e crea un incidente per ogni serie temporale che fa sì che venga soddisfatta una condizione. Di conseguenza, quando disponi di criteri di avviso con più condizioni, potresti potenzialmente ricevere una notifica e un incidente per ogni serie temporale che determina il soddisfamento delle condizioni unite.
Ad esempio, se hai un criterio di avviso con due condizioni, ogni condizione monitora tre serie temporali. Il criterio invia una notifica solo quando entrambe le condizioni sono soddisfatte. Quando le condizioni del criterio sono soddisfatte, potresti ricevere da 2 notifiche e incidenti (è soddisfatta una serie temporale per ogni condizione) e 6 (tutte le serie temporali sono soddisfatte per ogni condizione).
Non puoi configurare Monitoring per creare un singolo incidente e inviare una singola notifica.
Per saperne di più, vedi Notifiche per incidente.
La variabile per un'etichetta di metrica è nulla
Crei un criterio di avviso e aggiungi una variabile per un'etichetta di metrica alla sezione della documentazione.
Dovresti che le notifiche mostreranno 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 del criterio di avviso conservino l'etichetta che vuoi visualizzare.
Ad esempio, supponiamo di creare un criterio di avviso per monitorare i byte del disco scritti dalle istanze VM. Vuoi che la documentazione indichi il dispositivo che genera la notifica, quindi aggiungi quanto segue al campo della documentazione:
device: ${metric.label.device}.Devi inoltre assicurarti che le impostazioni di aggregazione conservino il valore dell'etichetta
device. Per conservare questa etichetta, imposta la funzione di aggregazione sunoneo assicurandoti che le selezioni di raggruppamento includanodevice.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 comenullquando un criterio di avviso monitora una metrica, anche una basata su log.
Nessun nuovo dato dopo le modifiche alle definizioni delle metriche
Puoi cambiare la definizione di una metrica definita dall'utente, ad esempio modificando il filtro utilizzato in una metrica basata su log. 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.