Questa pagina è stata tradotta dall'API Cloud Translation.

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.

La variabile per un'etichetta di metrica è nulla

Crei un criterio di avviso e aggiungi una variabile per un'etichetta di metrica alla sezione della documentazione. Prevedi che le notifiche mostrino il valore della variabile; tuttavia, il valore è impostato su null.

Per risolvere questo problema, prova a procedere nel seguente modo:

Assicurati che le impostazioni di aggregazione per il criterio di avviso conservino l'etichetta che vuoi visualizzare.

Ad esempio, supponiamo che tu crei un criterio di avviso che monitora i byte del disco scritti dalle istanze VM. Se vuoi che la documentazione elenchi il dispositivo che causa la notifica, aggiungi quanto segue al campo della documentazione: device: ${metric.label.device}.

Devi inoltre assicurarti che le impostazioni di aggregazione conservino il valore dell'etichetta device. Per mantenere questa etichetta, imposta la funzione di aggregazione su none o assicurati che le selezioni di raggruppamento includano device.
Verifica la sintassi e l'applicabilità della variabile. Per informazioni sulla sintassi, consulta Annotare 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 come null quando un criterio di avviso monitora una metrica, anche una basata su log.

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. Dovresti 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 di loop. Se un disco virtuale viene creato in modo che l'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, è necessario configurare un criterio di avviso relativo all'utilizzo del disco in modo da filtrare le serie temporali dei dispositivi di loopback /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 invia le notifiche previste

Vuoi ricevere una notifica se una macchina virtuale (VM) si riavvia o si arresta, perciò crei un criterio di avviso per monitorare la metrica compute.googleapis.com/instance/uptime. Puoi creare e configurare la condizione per generare un incidente in assenza di dati delle metriche. Non è necessario definire la condizione utilizzando Monitoring Query Language (MQL)¹. Non riceverai notifiche quando la macchina virtuale (VM) si riavvia o si arresta.

Questo criterio di avviso monitora le serie temporali solo 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 della valutazione della condizione. A causa di questo comportamento, non puoi utilizzare un criterio di avviso con una condizione di avviso per 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 è l'uso di criteri di avviso che monitorano l'assenza di dati. Consigliamo vivamente di generare avvisi sui controlli di uptime anziché sull'assenza di dati: i criteri di avviso per l'assenza di metriche 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 che ti comunichi 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 agli stati delle VM, puoi utilizzarlo per rilevare l'assenza di dati nelle 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 le notifiche. Il valore absent_for deve essere di almeno tre minuti.

Per saperne di più su MQL, consulta Criteri di avviso con MQL.

¹ 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 invia le notifiche previste

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 riceverai notifiche quando il numero di richieste supera la soglia configurata.

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 massimo per questa metrica, riduci il periodo di allineamento in modo che non superi le 7 ore e 30 minuti.

Cause comuni degli incidenti anomali

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

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

Se esiste una lacuna nei dati, in particolare per i criteri di avviso con assenza di metriche o condizioni di soglia "inferiore a", è possibile creare un incidente che sembri anomalo. A volte l'incidente non mostra la carenza di dati, mentre a volte questa viene corretta automaticamente:
- Nei grafici, ad esempio, gli intervalli potrebbero non apparire perché i valori dei dati mancanti sono interpolati. Anche se mancano diversi minuti di dati, il grafico connette i punti mancanti per una continuità visiva. Una 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 ed essere sottoposti a backfill, per un massimo di 10 minuti prima. Il comportamento di backfill corregge efficacemente 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 "inferiore a" 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 diventa visibile in Monitoring.
Le condizioni configurate per creare un incidente su una singola misura possono causare incidenti che sembrano essere prematuri o errati. Per evitare questa situazione, assicurati che siano necessarie più misurazioni prima che venga creato un incidente, impostando il campo della durata di una condizione in modo che superi il 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 su un valore equivalente a 0 secondi, è possibile che una singola misurazione possa 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 notifiche relative agli 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 i dati vengano propagati nell'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 possibilità che questo accada, utilizza un periodo di allineamento di almeno cinque minuti.

L'incidente non viene chiuso all'interruzione dei dati in arrivo

Segui le indicazioni in Dati delle metriche parziali e configurerai un criterio di avviso per chiudere gli incidenti quando i dati smettono di arrivare. 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 il 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 smettono di arrivare 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 le hai unite 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.

Monitoring invia una notifica e crea un incidente per ogni serie temporale che fa sì che una condizione sia soddisfatta. Di conseguenza, quando disponi di criteri di avviso con più condizioni, puoi potenzialmente ricevere una notifica e un incidente per ogni serie temporale che fa sì che le condizioni unite vengano soddisfatte.

Ad esempio, hai un criterio di avviso con due condizioni, in cui ogni condizione monitora tre serie temporali. Il criterio invia una notifica solo quando entrambe le condizioni sono soddisfatte. Quando le condizioni del criterio sono soddisfatte, potresti ricevere da 2 notifiche e incidenti (una serie temporale è soddisfatta in ogni condizione) a 6 (tutte le serie temporali sono soddisfatte in ogni condizione).

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

Per saperne di più, 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. La pagina dei dettagli dovrebbe essere aperta. Tuttavia, la pagina dei dettagli non si apre e viene visualizzato il messaggio "Autorizzazione negata".

Per visualizzare tutti i dettagli degli incidenti tranne i dati delle metriche, assicurati di disporre dei ruoli IAM (Identity and Access Management) di Monitoring Cloud Console Visualizzatore incidenti (roles/monitoring.cloudConsoleIncidentViewer) e Visualizzatore account Stackdriver (roles/stackdriver.accounts.viewer).

Per visualizzare tutti i dettagli degli incidenti, compresi i dati delle metriche, e per essere in grado di riconoscere o chiudere gli incidenti, assicurati di disporre dei ruoli IAM Visualizzatore Monitoring (roles/monitoring.viewer) ed Editor incidenti console Cloud Monitoring (roles/monitoring.cloudConsoleIncidentEditor).

I ruoli personalizzati non possono concedere l'autorizzazione richiesta 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 è vero dopo aver soddisfatto la condizione del criterio di avviso, 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. Il monitoraggio può determinare lo stato di una risorsa se 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 nell'elenco dei dettagli dell'incidente

Ricevi una notifica e nel riepilogo della condizione viene indicato il progetto Google Cloud in cui è stato creato l'incidente, ovvero il progetto di definizione dell'ambito. Tuttavia, ti aspetti che nell'incidente venga elencato il nome del progetto Google Cloud che archivia le serie temporali che hanno portato alla creazione dell'incidente da parte di Monitoring.

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 memorizza l'ID progetto viene rimossa.
Quando le opzioni di aggregazione conservano l'etichetta in cui è archiviato l'ID progetto, le notifiche degli incidenti includono il nome del progetto Google Cloud in cui è archiviata la serie temporale in cui si verifica l'incidente. Per mantenere l'etichetta ID progetto, includi 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 relativo al tuo sistema. Vai alla pagina dei dettagli dell'incidente e fai clic su Chiudi incidente. Prevedi che l'incidente venga chiuso, 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, viene 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.

Quando non è possibile chiudere un incidente a causa di un errore interno, si verifica il seguente errore:

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 consentire a Monitoring di chiudere automaticamente l'incidente.

Per ulteriori informazioni, consulta Gestione degli incidenti.

Le notifiche non vengono ricevute

Configuri i canali di notifica e prevedi di ricevere notifiche 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:

Mancata ricezione delle notifiche webhook
Le notifiche Pub/Sub non vengono ricevute

Per raccogliere informazioni sulla causa dell'errore:

Nella console Google Cloud, vai alla pagina Esplora log:
Vai a Esplora log

Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato il cui sottotitolo è Logging.
Seleziona il progetto Google Cloud appropriato.
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
```
In genere le informazioni sull'errore sono 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 "errore non riuscito con gateway non valido 502".

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

Configuri un canale di notifica webhook in Monitoring e poi configuri il webhook per l'invio 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 Monitoring, quindi configura un servizio Cloud Run per convertire i messaggi Pub/Sub nel formato previsto da Chat, quindi recapitare 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

Configuri un canale di notifica webhook e prevedi di ricevere notifiche 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 in combinazione con una sottoscrizione pull per quell'argomento di notifica.

Quando configuri un canale di notifica Pub/Sub, le notifiche degli incidenti vengono inviate a una coda Pub/Sub dotata di controlli di Identity and Access Management. Qualsiasi servizio in grado di eseguire query per 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 che attende l'arrivo di un messaggio. Questi abbonamenti richiedono l'accesso a Google, ma non richiedono regole per i firewall o per 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"

Le notifiche Pub/Sub non vengono ricevute

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

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 che l'account di servizio esista:
1. Nella console Google Cloud, vai alla pagina IAM:
  Vai a IAM
  
  Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato il cui sottotitolo è IAM e amministrazione.
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 è in elenco, seleziona Includi concessioni di ruoli fornite da Google.
Se l'account di servizio delle notifiche non esiste, devi iniziare il processo di creazione del canale di notifica Pub/Sub affinché Monitoring possa creare l'account di servizio:
1. Nella console Google Cloud, vai alla pagina Avvisi di :
  Vai ad Avvisi
  
  Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato il cui sottotitolo è Monitoring.
2. Fai clic su Modifica canali di notifica.
3. Nella sezione Pub/Sub, fai clic su Aggiungi nuovo.
  
  Se non esiste, Monitoring crea l'account di servizio di notifica. La finestra di dialogo Crea canale Pub/Sub mostra il nome dell'account di servizio delle notifiche.
  
  Nota: non è necessario completare la creazione del canale di notifica Pub/Sub per Monitoring per creare l'account di servizio di notifica.
4. Se non vuoi aggiungere un canale di notifica, fai clic su Annulla. In caso contrario, completa la creazione del canale di notifica e fai clic su Aggiungi canale.
5. Concedi all'account di servizio le autorizzazioni per pubblicare i tuoi argomenti Pub/Sub:
  1. In una nuova scheda del browser, apri il documento Crea un canale di notifica.
  2. Seleziona la scheda Pub/Sub, quindi segui i passaggi nella sezione Autorizza account di servizio della pagina.
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 la console Google Cloud o il comando Google Cloud CLI:
- Nella pagina IAM nella console Google Cloud sono elencati i ruoli di ciascun account di servizio.
- Nella pagina Argomenti di Pub/Sub nella console Google Cloud 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 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 è 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 di notifica, vedi Autorizzare l'account di servizio.