Risoluzione dei problemi relativi ai criteri di avviso

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa pagina spiega perché alcuni criteri di avviso potrebbero comportarsi in modo diverso dal previsto e offre possibili soluzioni in questi casi.

Per informazioni sulle variabili che possono influire su un criterio di avviso, scegli la finestra della durata, ad esempio vedi Comportamento dei criteri di avviso basati sulle metriche.

Il criterio di utilizzo del disco crea incidenti imprevisti

Hai creato un criterio di avviso per monitorare la "funzionalità" utilizzata dei dischi nel tuo sistema. Questo criterio monitora la metrica agent.googleapis.com/disk/percent_used. Dovresti ricevere una notifica solo quando l'utilizzo di qualsiasi 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 loop. Se un disco virtuale viene creato in modo che il suo utilizzo sia pari al 100%, verrà creato un incidente per il criterio.

Ad esempio, considera il seguente output del comando df di Linux, che mostra lo spazio su disco disponibile sui 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, è necessario configurare un criterio di avviso per l'utilizzo del disco per filtrare le serie temporali per i 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, per cui crei un criterio di avviso che monitora la metrica compute.googleapis.com/instance/uptime. Puoi creare e configurare la condizione per generare un incidente quando non sono disponibili dati delle metriche. Non definisci la condizione utilizzando Monitoring Query Language (MQL)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 in stato RUNNING. Le serie temporali per le VM in qualsiasi altro stato, ad esempio STOPPED o DELETED, vengono filtrate prima che la condizione venga valutata. A causa di questo comportamento, non puoi utilizzare un criterio di avviso con una condizione di avviso di assenza di metrica per determinare se un'istanza VM è in esecuzione. Per informazioni sugli stati delle istanze VM, consulta il 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 monitorino 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 nella disponibilità dei dati di Monitoring.

Tuttavia, se non è possibile utilizzare i controlli di uptime, puoi creare un criterio di avviso con MQL che ti avvisa che la VM è stata arrestata. Le condizioni definite da MQL non filtrano i dati delle serie temporali in base allo stato dell'istanza VM. Poiché MQL non filtra i dati per stato VM, puoi utilizzarlo per rilevare l'assenza di dati da VM 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 notifiche. Il valore absent_for deve essere almeno di tre minuti.

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

1: MQL è un linguaggio basato su testo espressivo che può essere utilizzato con le chiamate API Cloud Monitoring e nella console Google Cloud. Per configurare una condizione con MQL quando utilizzi Google Cloud Console, devi selezionare Query Editor.

Cause comuni degli incidenti anomali

Hai creato un criterio di avviso e sembra che venga creato prematuramente o crea erroneamente incidenti.

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

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

    • Nei grafici, ad esempio, le lacune potrebbero essere oscurate perché i valori per i dati mancanti sono interpolati. Anche quando mancano diversi minuti di dati, il grafico connette i punti mancanti per la continuità visiva. Tale lacuna nei dati sottostanti potrebbe essere sufficiente per consentire a un criterio di avviso di creare un incidente.

    • I punti nelle metriche basate su log possono arrivare in ritardo e ricevere il backfill, per un massimo di dieci minuti nel passato. Il comportamento di backfill corregge effettivamente il divario; il divario viene colmato quando arriva finalmente i dati. Pertanto, un divario in una metrica basata su log che non può più essere visualizzato potrebbe aver causato una norma di avviso per creare un incidente.

  • Le condizioni di assenza di metriche e di soglia "minore di" vengono valutate in tempo reale, con un piccolo ritardo nella query. Lo stato della condizione può cambiare tra il momento in cui viene valutato e il momento in cui l'incidente corrispondente è visibile in Monitoring.

  • Le condizioni configurate per creare un incidente in una singola misura possono provocare incidenti che sembrano essere prematuri o errati. Per evitare questa situazione, assicurati che siano richieste più misurazioni prima che venga creato un incidente impostando il campo Durata 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 durata di almeno 3 minuti. Se imposti il campo della durata su 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 una notifica relativa agli incidenti che soddisfano le condizioni originali del criterio di avviso.

  • Quando arrivano i dati della serie temporale, può essere necessario fino a un minuto prima che i dati si propaghino attraverso l'intera infrastruttura di avviso. Quando il periodo di allineamento è impostato su un minuto o sull'esempio più recente, la latenza di propagazione potrebbe far sembrare che il criterio di avviso venga attivato in modo errato. Per ridurre la possibilità di questa situazione, utilizza un periodo di allineamento di almeno cinque minuti.

Il criterio multicondizione crea più notifiche

Hai creato un criterio di avviso contenente più condizioni e hai unito queste condizioni con un AND logico. Dovresti ricevere una notifica e un incidente creato quando tutte le condizioni sono soddisfatte. Tuttavia, ricevi più notifiche e ti accorgi che vengono creati più incidenti.

Quando un criterio di avviso contiene più condizioni unite da un elemento AND logico, se il criterio viene attivato, per ogni serie temporale che restituisce una condizione soddisfatta, 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 scoprire di più, vedi Notifiche per incidente.

Impossibile visualizzare i dettagli dell'incidente a causa di un errore di autorizzazione

Accedi alla pagina Incidenti in Google Cloud Console e seleziona un incidente da visualizzare. La pagina dei dettagli dovrebbe essere aperta. Tuttavia, la pagina dei dettagli non si apre e viene visualizzato il messaggio "Autorizzazione negata".

Per risolvere questa situazione, assicurati che il tuo ruolo IAM (Gestione di identità e accessi) sia roles/monitoring.viewer o che includa tutte le autorizzazioni di quel ruolo. Ad esempio, i ruoli roles/monitoring.editor e roles/monitoring.admin includono tutte le autorizzazioni del ruolo Visualizzatore.

I ruoli personalizzati non possono concedere l'autorizzazione necessaria per visualizzare i dettagli dell'incidente.

Progetto con elenco dei dettagli dell'incidente errato

Ricevi una notifica di un avviso e il riepilogo della condizione elenca il progetto Google Cloud in cui è stato creato l'avviso, ovvero elenca il progetto di definizione dell'ambito. Tuttavia, ti aspetti che l'incidente elenchi il nome del progetto Google Cloud che archivia la serie temporale che sta causando l'attivazione dell'incidente.

Le opzioni di aggregazione specificate nella condizione di un criterio di avviso determinano il progetto Google Cloud a cui si fa 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 memorizza l'ID progetto verrà rimossa.

  • Quando le opzioni di aggregazione mantengono l'etichetta che archivia l'ID progetto, le notifiche degli incidenti includono il nome del progetto Google Cloud che memorizza la serie temporale che sta causando l'attivazione dell'incidente. Per mantenere l'etichetta dell'ID progetto, non raggruppare la serie temporale o includi 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 che l'incidente verrà chiuso, ma riceverai il messaggio di errore:

Unable to close incident with active conditions.

Puoi chiudere un incidente solo quando 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 a eseguire l'operazione di chiusura o lasciare che Monitoring chiuda automaticamente l'incidente.

Per saperne di più, vedi Gestire gli incidenti.

Le notifiche non vengono ricevute

Configuri canali di notifica e ti informi 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, procedi nel seguente modo:

  1. In Google Cloud Console, vai alla pagina Explorer log:

    Vai a Esplora log

  2. Seleziona il progetto Cloud appropriato.

  3. Esegui una query sui 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. Utilizza il menu Intervallo di tempo per selezionare un intervallo di tempo.
    4. Fai clic su Esegui query.

    I passaggi precedenti creano la query seguente:

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

    Le informazioni sugli errori vengono solitamente 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 riuscita con Gateway 502 non valido".

Notifiche inviate a Google Chat tramite webhook non riusciti

Configuri un canale di notifica webhook in Cloud Monitoring, quindi configuri Google Chat con tale webhook. Tuttavia, non ricevi notifiche o visualizzi 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 elaborare i messaggi Pub/Sub e consegnare la notifica a Google Chat. Per un esempio di questa configurazione, consulta Creazione di notifiche personalizzate con Cloud Monitoring e Cloud Run.

Le notifiche webhook non vengono ricevute

Configura un canale di notifica webhook e riceverai 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 questa situazione, utilizza le notifiche Pub/Sub combinate con un abbonamento pull a quell'argomento di notifica.

Quando configuri un canale di notifica Pub/Sub, le notifiche degli incidenti vengono inviate a una coda Pub/Sub con controlli di Identity and Access Management. Qualsiasi servizio in grado di eseguire query su un argomento Pub/Sub o di 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 un abbonamento pull, viene inviata una richiesta a Google in attesa che arrivi il messaggio. Questi abbonamenti richiedono l'accesso a Google, ma non richiedono regole per i firewall o l'accesso in entrata.

Endpoint pubblico

Per identificare i motivi della mancata distribuzione, esamina le voci di log di Cloud Logging per trovare informazioni sugli errori.

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"

Le notifiche Pub/Sub non vengono ricevute

Configura un canale di notifica Pub/Sub ma non ricevi notifiche 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 quando l'account di servizio è stato eliminato.

    Per verificare l'esistenza dell'account di servizio:

    1. In Google Cloud Console, vai alla pagina IAM:

      Vai a IAM

    2. Cerca un account di servizio che abbia 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 nel seguente screenshot:

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

    Per creare un account di servizio di notifica:

    1. In Google Cloud Console, seleziona Monitoring

      Vai a Monitoring

    2. Fai clic su Avvisi, quindi 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 le autorizzazioni all'account di servizio per pubblicare gli argomenti Pub/Sub come descritto in Autorizza account di servizio.

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

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

    • Nella pagina IAM della console Google Cloud sono elencati i ruoli per ogni account di servizio.
    • Nella pagina Argomenti di Pub/Sub in Google Cloud Console, sono elencati tutti gli argomenti. 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 il seguente comando dell'interfaccia a riga di comando di Google Cloud:

      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 di comando include solo i ruoli, non include l'autorizzazione per argomento.

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

      gcloud pubsub topics get-iam-policy TOPIC
      

      Di seguito è riportata una risposta di esempio 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 delle notifiche, consulta Autorizzare l'account di servizio.