Risoluzione dei problemi relativi ai criteri di avviso

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, ad esempio tramite la scelta della finestra di durata, 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 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 che hai impostato 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 è costruito in modo che il suo utilizzo sia al 100%, si verificherebbe un incidente per la creazione del criterio.

Ad esempio, considera 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 per l'utilizzo del disco in modo da escludere le serie temporali relative ai dispositivi di loop /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.*.

Il criterio di uptime non crea avvisi previsti

Vuoi ricevere una notifica se una macchina virtuale (VM) si riavvia o si arresta, quindi crei un criterio di avviso per monitorare la metrica compute.googleapis.com/instance/uptime. Puoi creare e configurare la condizione per generare un incidente quando non sono disponibili dati della metrica. Non devi definire la condizione utilizzando MQL (Monitoring Query Language)1. Non ricevi notifiche quando la macchina virtuale (VM) si riavvia o si arresta.

Questo criterio di avviso monitora solo le serie temporali per le istanze VM di Compute Engine che si trovano nello stato RUNNING. Le serie temporali per le VM che si trovano in qualsiasi altro stato, ad esempio STOPPED o DELETED, vengono filtrate prima di valutare la condizione. A causa di questo comportamento, non puoi utilizzare un criterio di avviso con una condizione di avviso di assenza di metriche per determinare se un'istanza VM è in esecuzione. Per informazioni sugli stati delle istanze VM, consulta Ciclo di vita delle istanze VM.

Per risolvere questo problema, crea un criterio di avviso per monitorare un controllo di uptime. Per gli endpoint privati, utilizza i controlli di uptime privati.

Una possibile alternativa agli avvisi sui controlli di uptime è utilizzare criteri di avviso che monitorano l'assenza di dati. Consigliamo vivamente di generare avvisi sui controlli di uptime anziché sull'assenza di dati: gli avvisi di assenza possono generare falsi positivi in caso di problemi temporanei con la disponibilità dei dati di Monitoring.

Tuttavia, se non è possibile utilizzare i controlli di uptime, puoi creare un criterio di avviso con MQL per informarti che la VM è stata arrestata. Le condizioni definite da MQL non prefiltrano i dati delle serie temporali in base allo stato dell'istanza VM. Poiché MQL non filtra i dati in base allo stato della VM, puoi utilizzarlo per rilevare l'assenza di dati nelle VM che sono state arrestate.

Considera la seguente condizione MQL che monitora la metrica compute.googleapis.com/instance/cpu/utilization:

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
|absent_for 3m

Se una VM monitorata da questa condizione viene arrestata, tre minuti dopo viene generato un incidente e vengono inviate le notifiche. Il valore absent_for deve essere di almeno tre minuti.

Per ulteriori informazioni su MQL, consulta Criteri di avviso con MQL.

1: MQL è un linguaggio espressivo basato su testo che può essere utilizzato con le chiamate API Cloud Monitoring e nella console Google Cloud. Per configurare una condizione con MQL quando utilizzi la console Google Cloud, devi utilizzare l'editor di codice.

Il criterio di conteggio delle richieste non crea avvisi previsti

Vuoi monitorare il numero di richieste completate. Hai creato un criterio di avviso per monitorare la metrica serviceruntime.googleapis.com/api/request_count, ma non ricevi notifiche quando il numero di richieste supera la soglia che hai configurato.

Il periodo di allineamento massimo per la metrica di conteggio delle richieste è 7 ore e 30 minuti.

Per risolvere il problema, controlla il valore del periodo di allineamento nel criterio di avviso. Se il valore è più lungo del valore massimo per questa metrica, riduci il periodo di allineamento in modo che non sia superiore a 7 ore e 30 minuti.

Cause comuni degli incidenti anomali

Hai creato un criterio di avviso e sembra creare incidenti prematuramente o in modo errato.

Esistono diversi motivi per cui potresti ricevere una notifica di incidenti che sembrano errati:

  • Se è presente una lacuna nei dati, in particolare per i criteri di avviso con assenza di metriche o condizioni di soglia "minore di", è possibile creare un incidente che sembra essere anomalo. Determinare se esiste una lacuna nei dati potrebbe non essere facile. A volte il divario è oscurato e a volte viene corretto automaticamente:

    • Nei grafici, ad esempio, le lacune potrebbero essere oscurate perché i valori dei dati mancanti vengono interpolati. Anche se mancano diversi minuti di dati, il grafico collega i punti mancanti per la continuità visiva. Una tale lacuna nei dati sottostanti potrebbe essere sufficiente a creare un incidente con un criterio di avviso.

    • I punti nelle metriche basate su log possono arrivare in ritardo ed essere sottoposti a backfill, fino a un massimo di 10 minuti prima. Il comportamento di backfill corregge in modo efficace il divario, che viene colmato quando finalmente arrivano i dati. Pertanto, una lacuna in una metrica basata su log che non può più essere rilevata potrebbe aver causato la creazione di un incidente da parte di un criterio di avviso.

  • Le condizioni di assenza di metriche 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 in una singola misura possono causare incidenti che sembrano prematuri o errati. Per evitare questa situazione, assicurati che siano necessarie più misurazioni prima di creare un incidente impostando il campo della durata di una condizione in modo che sia superiore al doppio della frequenza di campionamento della metrica.

    Ad esempio, se una metrica viene campionata ogni 60 secondi, imposta la durata su almeno 3 minuti. Se imposti il campo della durata 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, potrebbero essere necessari diversi minuti prima che la modifica si propaghi nell'infrastruttura degli avvisi. Durante questo periodo di tempo, potresti ricevere una notifica degli incidenti che soddisfano le condizioni originali criterio di avviso.

  • Quando arrivano i dati delle serie temporali, può essere necessario fino a un minuto prima che vengano distribuiti attraverso l'intera infrastruttura di avviso. Quando il periodo di allineamento è impostato su un minuto o sul campione più recente, la latenza di propagazione potrebbe far sembrare che il criterio di avviso si attivi in modo errato. Per ridurre le probabilità che questa situazione si verifichi, utilizza un periodo di allineamento di almeno cinque minuti.

L'incidente non viene chiuso quando smette di arrivare i dati

Segui le indicazioni 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 smettono di arrivare, 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 tale 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 quando non arrivano i dati. Tuttavia, puoi chiudere questi incidenti manualmente.

Il criterio a 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 vedi che vengono creati più incidenti.

Quando un criterio di avviso contiene più condizioni che vengono unite da un elemento logico AND, se questo criterio si attiva, per ogni serie temporale che comporta il raggiungimento di una condizione, il criterio invia una notifica e crea un incidente. Ad esempio, se hai un criterio con due condizioni e ogni condizione monitora una serie temporale, vengono aperti due incidenti e ricevi due notifiche.

Non puoi configurare Cloud Monitoring per creare un singolo incidente e inviare una singola notifica.

Per ulteriori informazioni, vedi Notifiche per incidente.

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 avere la pagina dei dettagli aperta. Tuttavia, non è possibile aprire la pagina dei dettagli e viene visualizzato il messaggio "Autorizzazione negata".

Per visualizzare tutti i dettagli dell'incidente, tranne i dati delle metriche, assicurati di disporre dei ruoli Identity and Access Management (IAM) di Monitoraggio incidenti console Cloud 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 essere in grado di 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 degli avvisi mostra che i dati monitorati violano la condizione, ma non hai ricevuto una notifica e non è stato creato un incidente.

Se uno qualsiasi dei seguenti criteri è true dopo l'attivazione della condizione del criterio di avviso, Cloud 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 monitorata dal criterio di avviso è noto per essere disabilitato. Monitoring può determinare lo stato di una risorsa quando questa contiene l'etichetta metadata.system_labels.state e quando il criterio di avviso non è scritto con il linguaggio di query di Monitoring.

Progetto errato con elenco dei dettagli dell'incidente

Quando ricevi la notifica di un avviso, il riepilogo della condizione indica il progetto Google Cloud in cui è stato creato, ovvero il progetto con ambito. Tuttavia, ci si aspetta che l'incidente elenchi il nome del progetto Google Cloud che archivia la serie temporale che causa l'attivazione dell'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 memorizza 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 memorizza l'ID progetto, le notifiche di incidenti includono il nome del progetto Google Cloud che archivia la serie temporale che causa l'attivazione dell'incidente. Per mantenere l'etichetta ID progetto, non raggruppare le serie temporali e non includere l'etichetta project_id nel campo di raggruppamento.

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 la chiusura dell'incidente, ma riceverai il messaggio di errore:

Unable to close incident with active conditions.

Puoi chiudere un incidente solo se non arriva alcuna osservazione 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 visualizzi 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 Gestire gli incidenti.

Le notifiche non vengono ricevute

Configura i canali di notifica e prevedi di ricevere una notifica quando si verificano incidenti. Non ricevi alcuna notifica.

Per informazioni su come risolvere i problemi relativi alle notifiche webhook e Pub/Sub, consulta le seguenti sezioni di questo documento:

Per raccogliere informazioni sulla causa dell'errore:

  1. Nel pannello di navigazione della console Google Cloud, seleziona Logging e poi Esplora log:

    Vai a Esplora log

  2. Seleziona il progetto Google Cloud appropriato.
  3. Esegui una query nei log per gli eventi del canale di notifica:

    1. Espandi il menu Nome log e seleziona notification_channel_events.
    2. Espandi il menu Gravità e seleziona Errore.
    3. (Facoltativo) Per selezionare un intervallo di tempo personalizzato, utilizza il selettore dell'intervallo di tempo.
    4. Fai clic su Esegui query.

    I passaggi precedenti creano la seguente query:

    logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
    severity=ERROR
    

    Le informazioni sull'errore sono in genere incluse nella riga di riepilogo e nel campo jsonPayload.

    La riga di riepilogo e il campo jsonPayload in genere contengono informazioni sull'errore. Ad esempio, quando si verifica un errore del gateway, la riga di riepilogo include "Non riuscito con gateway non valido 502".

Nessun nuovo dato dopo le modifiche alle definizioni delle metriche

Puoi modificare 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.

Le notifiche webhook inviate a Google Chat non vengono ricevute

Devi configurare un canale di notifica webhook in Cloud Monitoring e poi configurare il webhook da inviare a Google Chat. Tuttavia, non ricevi notifiche o ricevi 400 Bad Request errori.

Per risolvere questo problema, configura un canale di notifica Pub/Sub in Cloud Monitoring, quindi configura un servizio Cloud Run per convertire i messaggi Pub/Sub nel formato previsto da Chat e quindi recapitare la notifica a Google Chat. Per un esempio di questa configurazione, consulta Creazione di notifiche personalizzate con Cloud Monitoring e Cloud Run.

Notifiche webhook non ricevute

Configuri un canale di notifica webhook e prevedi di ricevere una notifica quando si verificano incidenti. Non ricevi alcuna notifica.

Endpoint privato

Non puoi utilizzare i webhook per le notifiche, a meno che l'endpoint non sia pubblico.

Per risolvere questo problema, utilizza le notifiche Pub/Sub in combinazione con una sottoscrizione pull per quell'argomento di notifica.

Quando configuri un canale di notifica Pub/Sub, le notifiche relative agli incidenti vengono inviate a una coda Pub/Sub con controlli di Identity and Access Management. Qualsiasi servizio che può eseguire query su un argomento Pub/Sub o ascoltarlo può utilizzare queste notifiche. Ad esempio, le applicazioni in esecuzione su macchine virtuali App Engine, Cloud Run o Compute Engine possono utilizzare queste notifiche.

Se utilizzi una sottoscrizione pull, viene inviata una richiesta a Google in attesa dell'arrivo di un messaggio. Questi abbonamenti richiedono l'accesso a Google, ma non le regole per i firewall o l'accesso in entrata.

Endpoint pubblico

Per identificare il motivo per cui la consegna non è riuscita, esamina le voci di log di Cloud Logging per trovare informazioni sull'errore.

Ad esempio, puoi cercare le voci di log per la risorsa del canale di notifica utilizzando Esplora log, con un filtro come il seguente:

resource.type="stackdriver_notification_channel"

Mancata ricezione delle notifiche Pub/Sub

Configura un canale di notifica Pub/Sub, ma non ricevi alcuna notifica di avviso.

Per risolvere questa condizione, prova a procedere nel seguente modo:

  • Assicurati che l'account di servizio delle notifiche esista. Le notifiche non vengono inviate dopo l'eliminazione dell'account di servizio.

    Per verificare che l'account di servizio esista:

    1. Nel pannello di navigazione della console Google Cloud, seleziona IAM:

      Vai a IAM

    2. Cerca un account di servizio con la seguente convenzione di denominazione:

      service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com

      Se questo account di servizio non è presente nell'elenco, seleziona Includi concessioni di ruoli fornite da Google, come mostrato nello screenshot seguente:

      Seleziona l'opzione Includi concessioni di ruoli fornite da Google.

    Per creare un account di servizio di notifica:

    1. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring e poi  Avvisi:

      Vai ad Avvisi

    2. Fai clic su Modifica canali di notifica.
    3. Nella sezione Pub/Sub, fai clic su Aggiungi nuovo.

      La finestra di dialogo Canale Pub/Sub creato mostra il nome dell'account di servizio creato da Monitoring.

    4. Fai clic su Annulla.

    5. Concedi all'account di servizio le autorizzazioni per pubblicare gli argomenti Pub/Sub come descritto in Autorizzare account di servizio.

  • Assicurati che l'account di servizio delle notifiche sia stato autorizzato a inviare notifiche per gli argomenti Pub/Sub che ti interessano.

    Per visualizzare le autorizzazioni per un account di servizio, puoi utilizzare la console Google Cloud o il comando Google Cloud CLI:

    • Nella pagina IAM nella console Google Cloud sono elencati i ruoli per ciascun account di servizio.
    • Nella pagina Argomenti Pub/Sub nella console Google Cloud è elencato ogni argomento. Quando selezioni un argomento, nella scheda Autorizzazioni sono elencati i ruoli concessi agli account di servizio.
    • Per elencare tutti gli account di servizio e i relativi ruoli, esegui questo comando di Google Cloud CLI:

      gcloud projects get-iam-policy PROJECT_ID
      

      Di seguito è riportata una risposta parziale per questo comando:

          serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
             role: roles/monitoring.notificationServiceAgent
           - members:
             [...]
             role: roles/owner
           - members:
             - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
             role: roles/pubsub.publisher
      

      La risposta del comando include solo i ruoli e non include l'autorizzazione per argomento.

    • Per elencare le associazioni IAM per un argomento specifico, esegui questo comando:

      gcloud pubsub topics get-iam-policy TOPIC
      

      Di seguito è riportato un esempio di risposta per questo comando:

          bindings:
          - members:
            - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
            role: roles/pubsub.publisher
          etag: BwXPRb5WDPI=
          version: 1
      

    Per informazioni su come autorizzare l'account di servizio di notifica, consulta Autorizzare l'account di servizio.