Questa pagina spiega perché alcuni criteri di avviso potrebbero comportarsi in modo diverso del previsto e offre possibili rimedi 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 lo "usato" dei dischi permanenti
nel tuo sistema. Questo criterio monitora la metrica
agent.googleapis.com/disk/percent_used
.
Prevedi di ricevere una notifica solo quando viene utilizzato qualsiasi disco fisico
superi la soglia impostata nella condizione. Tuttavia, questo
crea incidenti quando l'utilizzo del disco da parte di
se il 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 quelli virtuali, dispositivi di loopback. Se un disco virtuale è creato in modo il suo utilizzo è del 100%, questo causerebbe un incidente per il criterio da creare.
Considera ad esempio il seguente output del comando Linux df
:
che mostra lo spazio su disco disponibile sui file system montati, per una
di 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, potresti
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 prematuramente o creare incidenti in modo errato.
I motivi per cui potresti ricevere notifiche di incidenti sono diversi che sembrano non essere corretti:
Se c'è una lacuna nei dati, in particolare per i criteri di avviso assenza di metrica o condizioni di soglia "minore di", viene generato un valore 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, gli spazi vuoti potrebbero non essere visualizzati perché i valori per i dati mancanti vengono interpolati. Anche quando vengono utilizzati diversi minuti di dati mancante, 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 del può cambiare tra il momento in cui viene valutata e il momento in cui l'incidente corrispondente è visibile in Monitoring.
Condizioni configurate per creare un incidente su una singola misura possono causare incidenti che sembrano essere prematuri o errati. A per evitare questa situazione, è necessario verificare che siano necessarie più misurazioni prima che l'incidente viene creato impostando la finestra di ripetizione di una condizione più del 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 la notifica di incidenti che soddisfacessero le condizioni originali criterio di avviso.
Quando arrivano i dati delle serie temporali, può essere necessario fino a un minuto si propagano nell'intera infrastruttura di avviso. Durante questo processo, un criterio di avviso potrebbe valutare una condizione come soddisfatta anche 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 indicano 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 fornite in Dati metriche parziali e configurare 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 è disabilitato,
Il monitoraggio non chiude automaticamente gli incidenti quando i dati
non arriva 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. 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 dell'incidente, ad eccezione dei dati delle metriche, assicurati di avere
i ruoli IAM (Identity and Access Management)
Visualizzatore incidenti console Cloud Monitoring
(roles/monitoring.cloudConsoleIncidentViewer
) e
Visualizzatore 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 è disabilitato.
- Il criterio di avviso ha raggiunto numero massimo di incidenti che può aprire contemporaneamente.
È noto che lo stato della risorsa monitorato dal criterio di avviso disattivata. 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.
Elenco dei dettagli dell'incidente: progetto errato
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 venga indicato il nome del in un progetto Google Cloud che archivia le serie temporali che hanno causato Monitoraggio per creare l'incidente.
Le opzioni di aggregazione specificate nella condizione di un criterio di avviso determina 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 indicano 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 conservano l'etichetta che memorizza l'ID progetto, le notifiche degli incidenti includono il nome del progetto Google Cloud che archivia la serie temporale che causa il verificarsi dell'incidente. Per mantenere l'etichetta dell'ID progetto, includi il parametro l'etichetta
project_id
nel 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 sezione dei dettagli dell'incidente e fai clic su Chiudi incidente. Prevedi che l'incidente chiuso; Tuttavia, viene visualizzato 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 è 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 viene visualizzato il messaggio di errore precedente, puoi riprovare a eseguire l'operazione di chiusura oppure permetti 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 aderito
queste condizioni con un AND
logico. Dovresti ricevere una notifica e
creare un incidente quando tutte le condizioni sono soddisfatte. Tuttavia,
ricevere più notifiche e vedere che vengono 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, dove ciascuna condizione monitora tre serie temporali. Il criterio invia una notifica solo quando entrambe le condizioni sono soddisfatte. 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 di metrica è nulla
Crei un criterio di avviso
aggiungi una variabile per un'etichetta di metrica alla sezione della documentazione.
Prevedi 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 per il criterio di avviso conservino il valore dell'etichetta da visualizzare.
Ad esempio, supponiamo che tu crei un criterio di avviso per monitorare byte su disco scritti da istanze VM. Vuoi che la documentazione elenca dispositivo che causa la notifica, quindi aggiungila alla documentazione nel campo seguente:
device: ${metric.label.device}
.Devi inoltre assicurarti che le impostazioni di aggregazione conservino il valore dell'etichetta
device
. Puoi mantenere questa etichetta impostando il parametro funzione di aggregazione sunone
o assicurandoti che il raggruppamento selezioni includidevice
.Verifica la sintassi e l'applicabilità della variabile. Per informazioni sulla sintassi, consulta Annota 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 comenull
quando 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 e il criterio di avviso che riflette la modifica apportata alla definizione della metrica.
Per risolvere il problema, forza l'aggiornamento del criterio di avviso modificando il valore il nome visualizzato del criterio.