Annota gli incidenti con le etichette

Questo documento descrive come organizzare e assegnare priorità ai tuoi 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 elencati in determinate notifiche.

Informazioni sulle etichette

Le etichette, che sono coppie chiave/valore, vengono utilizzate per collegare informazioni una serie temporale, un criterio di avviso, un incidente o una notifica. Ad esempio, le etichette su una serie temporale potrebbero identificare di macchina virtuale (VM) da cui sono stati raccolti i dati. Le etichette possono essere definite dall'utente o predefinite.

Etichette definite dall'utente

Le etichette definite dall'utente contengono le informazioni specificate da te. Queste etichette possono avere valori statici o dinamici:

Le chiavi delle etichette devono iniziare con una lettera minuscola. Entrambe le chiavi di etichetta ed etichetta i valori possono contenere solo lettere minuscole, numeri, trattini bassi e trattini bassi.

Etichette predefinite

Le etichette predefinite sono incluse nei descrittori delle risorse. queste etichette devono essere vengono compilate quando vengono scritti i dati delle serie temporali. Queste etichette mostrano informazioni sulla metrica raccolta o sulla risorsa rispetto alla quale viene scritto. 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. Etichette dinamiche definite dall'utente ed etichette predefinite non sono visibili.
  • Incidenti: le etichette statiche definite dall'utente sono elencate nella sezione Etichette dei criteri mentre le etichette dinamiche definite dall'utente sono elencate nella sezione Etichette delle metriche . Le etichette predefinite sono elencate in Etichette delle risorse monitorate ed Etichette metriche.

  • Notifiche: sono elencate le etichette predefinite e le etichette definite dall'utente nei seguenti tipi di notifiche:

    • Email
    • 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 come i criteri di avviso che utilizzano Le query MQL elaborano i dati delle serie temporali monitorate:

Illustrazione di come i criteri di avviso elaborano le serie temporali monitorate.

Il gestore dei criteri elabora i dati sull'utilizzo della CPU e restituisce un 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 al 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 all'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 di "BUONO" serie temporali più un'etichetta di gravità con il valore "INFO".

I dati delle serie temporali generati dal gestore dei criteri costituiscono l'input della gestore degli incidenti, che determina quando gli incidenti vengono creati e chiusi. Per determinare quando chiudere un incidente, il gestore degli incidenti utilizza valori di duration, evaluationMissingData, e autoClose.

Best practice

Per garantire che al massimo un incidente sia aperto alla volta quando crei etichette. i cui valori sono impostati in modo dinamico, procedi nel seguente modo:

  • 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 da chiudere gli incidenti quando termina l'arrivo dei dati. Quando utilizzi l'API Cloud Monitoring, imposta questo campo su EVALUATION_MISSING_DATA_INACTIVE. Quando utilizzi nella console Google Cloud, imposta il campo su "Punti dati mancanti trattati come valori che non violano la condizione delle norme".

  • Nell'oggetto AlertStrategy, imposta autoClose sul valore minimo di 30 minuti. Quando utilizzi l'API Cloud Monitoring, imposta questo campo su 30m.

Per saperne di più, consulta la sezione Dati delle metriche parziali.

Flusso degli incidenti

Supponiamo che le misurazioni dell'utilizzo della CPU siano inferiori al 70% quando viene creato un criterio di avviso. La seguente sequenza illustra il modo in cui gli incidenti sono aperti e chiusi:

  1. 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.

  2. 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.

    Il gestore degli incidenti vede un nuovo "CRITICO" serie temporale che soddisfa i e apre un incidente. La notifica include l'etichetta di gravità con il valore CRITICAL.

  3. 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" serie temporale che soddisfa i e 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é è configurato per chiudere gli incidenti quando i dati non arrivano più, il gestore degli incidenti chiude incidente associato al "CRITICAL" serie temporali. Pertanto, rimane aperto solo l'incidente la cui etichetta di gravità ha il valore INFO.

  4. Infine, supponiamo che l'utilizzo della CPU scenda al 45%. Questo valore è inferiore di tutte le soglie, quindi il gestore dei criteri smette di generare "INFO" serie temporali e inizia a generare il "BUONO" serie temporali.

    Il gestore incidenti vede che non sono arrivati dati per "INFO" serie temporale e che per quella serie temporale sia aperto un incidente. Poiché utilizza le impostazioni consigliate, l'incidente è 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 saperne di più, consulta la sezione Dati delle metriche parziali.

Passaggi successivi