Questo documento descrive come organizzare e dare la priorità ai incidenti assegnando loro etichette definite dall'utente. Queste etichette sono configurate criteri di avviso ed è elencata nei criteri di avviso e i relativi incidenti. A seconda della configurazione, le etichette vengono elencate anche in determinate notifiche.
Informazioni sulle etichette
Le etichette, che sono coppie chiave-valore, vengono utilizzate per associare informazioni a una serie temporale, a un criterio di avviso, a un incidente o a una notifica. Ad esempio, le etichette di una serie temporale potrebbero identificare l'istanza specifica della macchina virtuale (VM) da cui sono stati raccolti i dati. Le etichette sono definite dall'utente o predefinite.
Etichette definite dall'utente
Le etichette definite dall'utente contengono le informazioni specificate. Queste etichette possono avere valori statici o dinamici:
Le etichette statiche definite dall'utente hanno valori che non possono essere modificati. Puoi creare etichette statiche definite dall'utente quando configuri un criterio di avviso utilizzando la console Google Cloud o l'API Cloud Monitoring. Per ulteriori informazioni, consulta i seguenti documenti:
Le etichette dinamiche definite dall'utente hanno valori che possono variare in base ai valori di i dati delle serie temporali. Puoi creare etichette dinamiche definite dall'utente quando configurare la condizione di un criterio di avviso con MQL. Per un esempio, consulta Esempio: aggiungere etichette definite dall'utente con valori dinamici.
Le chiavi delle etichette devono iniziare con una lettera minuscola. Sia le chiavi di etichetta sia i valori dell'etichetta possono contenere solo lettere minuscole, cifre, trattini bassi e trattini.
Etichette predefinite
Le etichette predefinite sono incluse nei descrittori delle risorse; queste etichette devono essere compilate quando vengono scritti i dati delle serie temporali. Queste etichette mostrano informazioni sulla metrica raccolta o sulla risorsa in base alla quale viene scritta. Ad esempio, le etichette su una serie temporale potrebbero identificare macchina virtuale (VM), una zona, un progetto Google Cloud e un tipo di dispositivo. Quando Monitoring crea un incidente sulla base di quella serie temporale, l'incidente eredita queste etichette.
Come visualizzare le etichette
Puoi visualizzare le etichette di un criterio di avviso o di un incidente nella pagina dei dettagli di un incidente, la pagina dei dettagli di un criterio di avviso, e in alcune notifiche.
- Criteri di avviso: le etichette statiche definite dall'utente sono elencate nella Etichette utente. Le etichette predefinite e quelle dinamiche definite dall'utente non sono visibili.
- Incidenti: le etichette definite dall'utente statiche sono elencate nella sezione Etichette dei criteri, mentre le etichette definite dall'utente dinamiche sono elencate nella sezione Etichette delle metriche. Le etichette predefinite sono elencate nelle sezioni Etichette delle risorse monitorate e Etichette delle metriche.
Notifiche: sono elencate le etichette predefinite e le etichette definite dall'utente nei seguenti tipi di notifiche:
- Google Chat
- PagerDuty
- Pub/Sub
- Webhook
Esempio: aggiungere etichette definite dall'utente con valori dinamici
Puoi utilizzare MQL per configurare un'etichetta in modo che il suo valore
cambia dinamicamente in base ai dati delle serie temporali. Ad esempio, vuoi
gli incidenti in modo che abbiano un'etichetta criticality
il cui valore cambia
a seconda del valore della metrica di utilizzo della CPU monitorata:
fetch gce_instance
| metric 'compute.googleapis.com/instance/cpu/utilization'
| group_by sliding(5m), [value_utilization_mean: mean(value.utilization)]
| map
add[
criticality:
if(val() >= 90 '%', 'CRITICAL',
if(val() >= 80 '%', 'WARNING',
if(val() >= 70 '%', 'INFO', 'GOOD')))
]
| condition val() >= 70 '%'
La figura seguente illustra in che modo i criteri di avviso che utilizzano query MQL elaborano i dati delle serie temporali monitorati:
Il gestore dei criteri elabora i dati sull'utilizzo della CPU e genera una serie temporale che indica quando la condizione è soddisfatta. Nella precedente Ad esempio, la condizione è soddisfatta quando l'utilizzo della CPU è almeno il 70%. Per ogni serie temporale di input, il gestore dei criteri può generare una di quattro serie temporali:
Nome serie temporale di output | Condizione soddisfatta | Descrizione |
---|---|---|
"BUONO" | No | Questa serie temporale ha le stesse etichette della serie temporale di input. Non ha un'etichetta di gravità. |
"CRITICO" | Sì | L'utilizzo della CPU è almeno del 90%. La serie temporale di output ha le stesse etichette di "BUONO" serie temporali più un'etichetta di gravità con il valore "CRITICAL". |
"AVVISO" | Sì | L'utilizzo della CPU è almeno dell'80%, ma inferiore al 90%. La serie temporale di output ha le stesse etichette di "BUONO" serie temporali più un'etichetta di gravità con il valore "WARNING". |
"INFO" | Sì | L'utilizzo della CPU è almeno il 70%, ma inferiore all'80%. La serie temporale di output ha le stesse etichette della serie temporale "BUONO", oltre a un'etichetta di gravità con il valore "INFO". |
I dati delle serie temporali generati dal gestore dei criteri vengono inseriti nell'incident manager, che determina quando vengono creati e chiusi gli incidenti.
Per determinare quando chiudere un incidente, l'amministratore degli incidenti utilizza i valori dei campi duration
, evaluationMissingData
e autoClose
.
Best practice
Per assicurarti che sia aperto al massimo un incidente alla volta quando crei etichette cuyos valori vengono impostati dinamicamente:
Nell'oggetto
MetricThreshold
, sostituisci il valore valori predefiniti per i seguenti campi:- Campo
duration
: impostato su un valore diverso da zero. - Campo
evaluationMissingData
: impostato in modo che gli incidenti vengano chiusi quando i dati non arrivano più. Quando utilizzi l'API Cloud Monitoring, imposta questo campo suEVALUATION_MISSING_DATA_INACTIVE
. Quando utilizzi la console Google Cloud, imposta il campo su "Punti dati mancanti trattati come valori che non violano la condizione del criterio".
- Campo
Nell'oggetto
AlertStrategy
, imposta il campoautoClose
sul valore minimo di 30 minuti. Quando utilizzi l'API Cloud Monitoring, imposta questo campo su30m
.
Per ulteriori informazioni, consulta Dati delle metriche parziali.
Flusso degli incidenti
Supponiamo che le misurazioni dell'utilizzo della CPU siano inferiori al 70% quando viene creato il criterio di avviso. La seguente sequenza illustra il modo in cui gli incidenti sono aperti e chiusi:
Poiché le misurazioni dell'utilizzo della CPU sono inferiori al 70%, il gestore di criteri genera il "BUONO" serie temporali non ci sono incidenti aperti.
Supponiamo quindi che l'utilizzo della CPU aumenti al 93%. Il gestore dei criteri non genera più il "BUONO" i dati delle serie temporali e inizierà a generare dati per il "CRITICO" serie temporali.
L'incident manager vede una nuova serie temporale "CRITICA" che soddisfa la condizione e apre un incidente. La notifica include l'etichetta di gravità con il valore
CRITICAL
.Supponiamo che l'utilizzo della CPU scenda al 75%. Il gestore dei criteri non genera più il comando "CRITICAL" serie temporale e inizia a generare le "INFO" serie temporali.
Il gestore incidenti visualizza una nuova "INFO" che soddisfa i requisiti di addestramento e poi apre un incidente. La include l'etichetta di gravità con il valore
INFO
.Il gestore degli incidenti vede che non sono arrivati dati per l'evento "CRITICO" serie temporale e che per quella serie temporale sia aperto un incidente. Poiché il criterio è configurato per chiudere gli incidenti quando i dati non arrivano più, il gestore degli incidenti chiude l'incidente associato alla serie temporale "CRITICO". Pertanto, rimane aperto solo l'incidente la cui etichetta di gravità ha il valore
INFO
.Infine, supponiamo che l'utilizzo della CPU scenda al 45%. Questo valore è inferiore a tutte le soglie, quindi il gestore dei criteri smette di generare la serie temporale "INFO" e inizia a generare la serie temporale "BUONO".
Il gestore incidenti vede che non sono arrivati dati per "INFO" serie temporale e che per quella serie temporale sia aperto un incidente. Poiché il regolamento utilizza le impostazioni consigliate, l'incidente è stato chiuso.
Se non utilizzi il valore consigliato per il campo evaluationMissingData
,
quando i dati non arrivano più, gli incidenti aperti non vengono chiusi immediatamente.
Il risultato è che potresti vedere più incidenti aperti per lo stesso input
serie temporali. Per ulteriori informazioni, consulta Dati delle metriche parziali.
Passaggi successivi
- Crea criteri di avviso utilizzando l'API Monitoring
- Criteri di avviso con MQL
- Gestione dei dati delle metriche parziali