Risolvere i problemi relativi ai monitoraggi sintetici e ai controlli di uptime

Quando riscontri problemi durante la creazione, l'esecuzione o l'eliminazione di un monitor sintetico o di un controllo di uptime oppure quando non ricevi le notifiche di avviso previste, puoi diagnosticare la causa esaminando i log di esecuzione, le metriche e le tracce. Puoi anche risolvere errori di configurazione comuni che riguardano le autorizzazioni IAM, i perimetri dei Controlli di servizio VPC e le destinazioni di rete privata.

Trovare i log

Per aiutarti a correlare le richieste ai tuoi log, le richieste HTTP e HTTPS inviate da Cloud Monitoring includono un'intestazione Check-Id che memorizza l'identificatore del monitor sintetico o del controllo di uptime associato. Per trovare i log per i tuoi monitor sintetici e controlli di uptime:

1. Nella console Google Cloud , vai alla pagina segmento Esplora log:

   Vai a Esplora log

   Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo progetto Google Cloud . Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione.

3. Esegui una delle seguenti operazioni:

   • Per trovare tutti i log associati ai monitor sintetici o ai controlli di uptime, esegui una query per tipo di risorsa. Puoi utilizzare il menu Risorsa o inserire una query.

     Per i controlli di uptime, nel menu Risorsa, seleziona URL controllo di uptime oppure inserisci la seguente query nell'editor di query e poi fai clic su Esegui query:

     resource.type="uptime_url"
     

     Per i monitor sintetici, nel menu Risorsa, seleziona Revisione Cloud Run oppure inserisci la seguente query nell'editor di query e poi fai clic su Esegui query:

     resource.type="cloud_run_revision"
     

   • Per trovare i log che contengono informazioni sulla risposta ricevuta durante l'esecuzione di un monitor sintetico o di un controllo di uptime, esegui una delle seguenti operazioni:

     • Per eseguire query utilizzando l'ID del monitor sintetico o del controllo dell'uptime, utilizza il seguente formato quando inserisci l'ID nell'editor di query, quindi fai clic su Esegui query:

       labels.check_id="my-check-id"
       

     • Per eseguire query per i log che contengono dati di risposta per le richieste emesse da monitor sintetici e controlli di uptime, inserisci la seguente query nell'editor di query, quindi fai clic su Esegui query:

       "UptimeCheckResult"
       

       La query precedente corrisponde a tutte le voci di log che includono la stringa "UptimeCheckResult".

     Questi log includono:

     • L'ID del monitoraggio sintetico o del controllo di uptime, archiviato nel campo labels.check_id.

     • Per i monitor sintetici, il nome della funzione Cloud Run, memorizzato nel campo resource.labels.service_name.

     • Quando vengono raccolti i dati di traccia, l'ID di una traccia associata, che viene memorizzato nel campo trace.

   • Per verificare che il servizio abbia ricevuto richieste dai server Google Cloud , copia la seguente query nell'editor di query e poi fai clic su Esegui query:

     "GoogleStackdriverMonitoring-UptimeChecks"
     

     Il campo protoPayload.ip contiene uno degli indirizzi utilizzati dai server di controllo dell'uptime. Per informazioni su come elencare tutti gli indirizzi IP, consulta Elenca indirizzi IP.

Risolvere i problemi relativi alle notifiche

Questa sezione descrive alcuni errori che potresti riscontrare durante la configurazione dei criteri di avviso e fornisce informazioni per risolverli.

Un controllo non è riuscito, ma gli altri sì

Stai esaminando le metriche del controllo di uptime e noti che un controllo ha segnalato un errore mentre tutti gli altri hanno segnalato un esito positivo.

Non è richiesta alcuna azione per risolvere questa situazione.

Quando un solo controllo segnala un errore, questo potrebbe essere il risultato del timeout del comando del controllo dovuto a un problema di rete. ovvero, anziché non riuscire, il comando non viene completato entro il timeout specificato.

Le policy di avviso che utilizzano la configurazione predefinita richiedono errori da almeno due controlli prima di creare un avviso e inviare una notifica. Un errore segnalato da un singolo controllo non comporta una notifica.

Hai ricevuto una notifica e vuoi eseguire il debug dell'errore

1. Per identificare quando è iniziato l'errore, esegui una delle seguenti operazioni:

   • Per i controlli di uptime, per determinare quando si è verificato l'errore, visualizza la pagina Dettagli uptime:

     1. Nella console Google Cloud , vai alla pagina  Controlli di uptime:

        Vai a Controlli di uptime

        Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

     2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo progetto Google Cloud . Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione.

     3. Trova e seleziona il controllo di uptime.

        Il grafico Controlli superati mostra la cronologia dei controlli. Per identificare quando il controllo di uptime ha avuto esito negativo per la prima volta, potrebbe essere necessario modificare l'intervallo di tempo per il grafico. Il selettore dell'intervallo di tempo si trova nella barra degli strumenti della pagina Dettagli uptime.

   • Per i monitoraggi sintetici, per determinare quando si è verificato l'errore, visualizza la pagina Dettagli uptime:

     1. Nella console Google Cloud , vai alla pagina  Monitoraggio sintetico:

        Vai a Monitoraggio sintetico

        Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

     2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo progetto Google Cloud . Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione.
     3. Trova e seleziona il monitoraggio sintetico.

2. Per informazioni su come trovare i dati di log associati, vedi Trovare i log.

Non ricevi una notifica che ti informa che un controllo di uptime non è riuscito

Hai configurato un controllo di uptime e stai visualizzando la pagina Dettagli uptime per questo controllo. Noti che il grafico Controlli superati mostra che almeno un controllo non è andato a buon fine. Tuttavia, non hai ricevuto una notifica.

Per impostazione predefinita, la criterio di avviso è configurata per creare un avviso e inviare una notifica quando i controlli in almeno due regioni non ricevono una risposta a un controllo di uptime. Questi errori devono verificarsi contemporaneamente.

Puoi modificare la condizione della criterio di avviso in modo da ricevere una notifica quando una singola regione non riceve una risposta. Tuttavia, ti consigliamo di utilizzare la configurazione predefinita, che riduce il numero di notifiche che potresti ricevere a causa di errori temporanei.

Per visualizzare o modificare un criterio di avviso:

1. Nella Google Cloud console, vai alla pagina  Avvisi:

   Vai ad Avvisi

   Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo progetto Google Cloud . Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione.
3. Fai clic su Visualizza tutti i criteri nel riquadro Criteri.

4. Trova la norma che vuoi visualizzare o modificare, quindi fai clic sul nome della norma.

   Puoi visualizzare e modificare la policy dalla pagina Dettagli policy.

Risolvi i problemi relativi ai controlli di uptime pubblici

Questa sezione descrive alcuni errori che potresti riscontrare durante l'utilizzo dei controlli di uptime pubblici e fornisce informazioni per risolverli.

I controlli di uptime pubblici non funzionano

Configuri un controllo di uptime pubblico, ma ricevi un errore quando esegui il passaggio di verifica.

Di seguito sono riportate alcune possibili cause di un errore di controllo dell'uptime:

• Errore di connessione - Rifiutato: se utilizzi il tipo di connessione HTTP predefinito, verifica di aver installato un server web che risponda alle richieste HTTP. Un errore di connessione può verificarsi su una nuova istanza se non hai installato un server web. Consulta la Guida rapida per Compute Engine. Se utilizzi un tipo di connessione HTTPS, potresti dover eseguire passaggi di configurazione aggiuntivi. Per problemi relativi al firewall, consulta Elenco degli indirizzi IP del server di controllo dell'uptime.
• Nome o servizio non trovato: il nome host potrebbe non essere corretto.
• 403 Forbidden: il servizio restituisce un codice di errore al controllo dell'uptime. Ad esempio, la configurazione predefinita del server web Apache restituisce questo codice in Amazon Linux, ma restituisce il codice 200 (Operazione riuscita) in alcune altre versioni di Linux. Consulta il tutorial LAMP per Amazon Linux o la documentazione del tuo server web.
• 404 - Non trovato: il percorso potrebbe non essere corretto.
• 408 Request timeout o nessuna risposta: il numero di porta potrebbe essere errato, il servizio potrebbe non essere in esecuzione, potrebbe essere inaccessibile o il timeout potrebbe essere troppo basso. Verifica che il firewall consenta il traffico dai server di uptime. Consulta Elenco degli indirizzi IP dei server di controllo dell'uptime. Il limite di timeout è specificato nelle opzioni di convalida della risposta.

Per aiutarti a risolvere i problemi relativi ai controlli di uptime pubblici non riusciti, puoi configurare i controlli di uptime in modo che inviino fino a 3 ping ICMP durante il controllo. I ping possono aiutarti a distinguere tra errori causati, ad esempio, da problemi di connettività di rete e da timeout nell'applicazione. Per saperne di più, consulta Utilizzare i ping ICMP.

Non puoi creare un controllo di uptime pubblico

Provi a creare un controllo di uptime pubblico, ma l'azione non va a buon fine e viene visualizzato un messaggio simile al seguente:

Public uptime checks cannot be configured in a VPC Service Controls perimeter.

Questo messaggio di errore indica che il tuo progetto Google Cloud si trova in un perimetro dei Controlli di servizio VPC abilitato. Non puoi creare controlli di uptime pubblici per queste configurazioni.

Per risolvere il problema, crea un controllo di uptime privato.

Risolvere i problemi relativi ai controlli di uptime privati

Questa sezione descrive alcuni errori che potresti riscontrare quando utilizzi controlli di uptime privati e fornisce informazioni per risolverli.

Creazione del controllo di uptime non riuscita

Le impostazioni del progetto Google Cloud potrebbero impedire la modifica dei ruoli assegnati al account di servizio utilizzato dai controlli di uptime per gestire le interazioni con il servizio Service Directory. In questa situazione, la creazione del controllo di uptime non va a buon fine.

Questa sezione descrive come concedere i ruoli richiesti dal account di servizio:

Console

Quando utilizzi la console Google Cloud per creare il controllo di uptime privato, la console Google Cloud emette i comandi per concedere i ruoli Service Directory al account di servizio.

Per informazioni su come concedere ruoli a un account di servizio, consulta Autorizzare il service account.

gcloud: progetto di definizione dell'ambito

La prima volta che crei un controllo di uptime privato per un servizio Service Directory e risorse private in un singolo progetto Google Cloud , la richiesta potrebbe riuscire o non riuscire. Il risultato dipende dal fatto che tu abbia disattivato la concessione automatica dei ruoli per i service account nel tuo progetto:

• La prima creazione del controllo di uptime ha esito positivo se il progetto consente la concessione automatica dei ruoli per i service account. Viene creato un account di servizio per te e gli vengono concessi i ruoli necessari.

• La prima creazione del controllo di uptime non va a buon fine se il tuo progetto non consente la concessione automatica dei ruoli per i service account. Viene creato un account di servizio, ma non vengono concessi ruoli.

Se la creazione del controllo di uptime non va a buon fine, procedi nel seguente modo:

1. Autorizza il service account.
2. Attendi qualche minuto affinché le autorizzazioni vengano propagate.
3. Prova a creare di nuovo il controllo di uptime privato.

gcloud: progetto monitorato

La prima volta che crei un controllo di uptime privato che ha come target un servizio Service Directory in un progetto monitorato o risorse private in un progetto Google Cloud diverso, la richiesta non va a buon fine e viene creato un account di servizio Monitoring.

La modalità di autorizzazione del account di servizio dipende dal numero di progettiGoogle Cloud che utilizzi e dalle loro relazioni. Potresti avere fino a quattro progetti coinvolti:

• Il progetto in cui hai definito il controllo di uptime privato.
• Il progetto monitorato in cui hai configurato il servizio Service Directory.
• Il progetto in cui hai configurato la rete VPC.
• Il progetto in cui sono configurate le risorse di rete come VM o bilanciatori del carico. Questo progetto non ha alcun ruolo nell'autorizzazione del service account descritta qui.

Se la creazione del primo controllo di uptime non va a buon fine:

1. Autorizza il service account.
2. Attendi qualche minuto affinché le autorizzazioni vengano propagate.
3. Prova a creare di nuovo il controllo di uptime privato.

Impossibile scegliere come target un servizio Cloud Run

Vuoi scegliere come target un servizio Cloud Run con un controllo di uptime privato, ma un servizio Cloud Run non ha un indirizzo IPv4 in una rete VPC del cliente che puoi registrare come endpoint Service Directory.

Per scegliere come target un servizio Cloud Run con un controllo di uptime privato, configura un bilanciatore del carico delle applicazioni interno con un backend NEG serverless e registra l'indirizzo IP interno del bilanciatore del carico in Service Directory. Per un esempio di come configurare il bilanciatore del carico, consulta Configurare un bilanciatore del carico delle applicazioni interno regionale con Cloud Run.

Accesso negato

I controlli di uptime non vanno a buon fine e restituiscono risultati VPC_ACCESS_DENIED. Questo risultato indica che alcuni aspetti della configurazione di rete o dell'autorizzazione del service account non sono corretti.

Controlla l'autorizzazione del service account per l'utilizzo di un progetto di ambito o di un progetto monitorato, come descritto in Creazione del controllo di uptime non riuscita.

Per saperne di più sull'accesso alle reti private, consulta Configurare il progetto di rete.

Risultati anomali dei controlli di uptime privati

Hai un servizio Service Directory con più VM e la configurazione del servizio contiene più endpoint. Quando spegni una delle VM, il controllo di uptime indica comunque esito positivo.

Quando la configurazione del servizio contiene più endpoint, ne viene scelto uno in modo casuale. Se la VM associata all'endpoint scelto è in esecuzione, il controllo di uptime va a buon fine anche se una delle VM non è attiva.

Intestazioni predefinite

I controlli di uptime restituiscono errori o risultati imprevisti. Ciò potrebbe verificarsi se hai sostituito i valori predefiniti dell'intestazione.

Quando viene inviata una richiesta per un controllo di uptime privato a un endpoint di destinazione, la richiesta include le seguenti intestazioni e valori:

Intestazione	Valore
HTTP_USER_AGENT	GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)
HTTP_CONNECTION	keep-alive
HTTP_HOST	IP dell'endpoint Service Directory
HTTP_ACCEPT_ENCODING	gzip, deflate, br
CONTENT_LENGTH	Calcolato in base ai dati di uptime POST

Se provi a ignorare questi valori, potrebbe verificarsi quanto segue:

• Il controllo di uptime segnala errori.
• I valori di override vengono eliminati e sostituiti con i valori della tabella.

Nessun dato visibile

Non vengono visualizzati dati nella dashboard dei controlli di uptime quando il controllo di uptime si trova in un progetto Google Cloud diverso dal servizio Service Directory.

Assicurati che il progetto Google Cloud che contiene il controllo di uptime monitori il progetto Google Cloud che contiene il servizio Service Directory.

Per ulteriori informazioni su come elencare i progetti monitorati e aggiungerne altri, consulta Configurare un ambito delle metriche per più progetti.

Risolvere i problemi relativi ai monitoraggi sintetici

Questa sezione fornisce informazioni che puoi utilizzare per risolvere i problemi relativi ai monitor sintetici.

Messaggio di errore dopo l'abilitazione delle API

Apri il flusso di creazione per un monitoraggio sintetico e ti viene chiesto di abilitare almeno un'API. Dopo aver abilitato le API, viene visualizzato un messaggio simile al seguente:

An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

Il messaggio di errore consiglia di verificare che l'API sia abilitata e poi di attendere e riprovare l'azione.

Per verificare che l'API sia abilitata, vai alla pagina API e servizi del tuo progetto:

Vai ad API e servizi

Dopo aver verificato che l'API sia abilitata, puoi continuare con il flusso di creazione. La condizione viene risolta automaticamente dopo che l'attivazione dell'API si propaga tramite il backend.

Le richieste HTTP in uscita non vengono monitorate

Configura il monitor sintetico per raccogliere i dati di traccia per le richieste HTTP in uscita. I dati di traccia mostrano un solo intervallo, simile allo screenshot seguente:

Per risolvere il problema, assicurati che al tuo account di servizio sia stato concesso il ruolo di Cloud Trace Agent (roles/cloudtrace.agent). È sufficiente anche un ruolo di Editor (roles/editor).

Per visualizzare i ruoli concessi al tuo account di servizio:

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 con il sottotitolo IAM e amministrazione.

2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo progetto Google Cloud . Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione.
3. Seleziona Includi concessioni di ruoli fornite da Google.

4. Se il account di servizio utilizzato dal monitor sintetico non è elencato o se non gli è stato concesso un ruolo che include le autorizzazioni del ruolo Agente Cloud Trace (roles/cloudtrace.agent), concedi questo ruolo al tuo account di servizio.

   Se non conosci il nome del tuo account di servizio, seleziona Service account nel menu di navigazione.

Stato In corso

La pagina Monitor sintetici elenca un monitor sintetico con lo stato In progress. Lo stato In progress indica che il monitor sintetico è stato creato di recente e non ci sono dati da visualizzare o che il deployment della funzione non è riuscito.

Per determinare se il deployment della funzione non è riuscito, prova a:

• Assicurati che il nome della funzione Cloud Run non contenga un carattere di sottolineatura. Se è presente un carattere di sottolineatura, rimuovilo e riesegui il deployment della funzione Cloud Run.

• Apri la pagina Dettagli del monitoraggio sintetico per il monitoraggio sintetico.

  Se visualizzi il seguente messaggio, elimina il monitor sintetico.

  Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
  

  Il messaggio di errore indica che la funzione è stata eliminata e pertanto il monitor sintetico non è in grado di eseguirla.

• Apri la pagina Cloud Run Functions per la funzione. Per aprire questa pagina dalla pagina Dettagli monitor sintetico, fai clic su Codice, quindi sul nome della funzione.

  Se visualizzi un messaggio simile al seguente, il deployment della funzione non è riuscito.

  This function has failed to deploy and will not work correctly. Please edit and redeploy
  

  Per risolvere questo errore, rivedi il codice della funzione e correggi gli errori che impediscono la creazione o il deployment della funzione.

Quando crei un monitor sintetico, potrebbero essere necessari diversi minuti prima che la funzione venga implementata ed eseguita.

Stato avviso

La pagina Monitor sintetici elenca un monitor sintetico con lo stato Warning. Uno stato Warning indica che i risultati dell'esecuzione non sono coerenti. Ciò potrebbe indicare un problema di progettazione del test oppure che ciò che viene testato ha un comportamento incoerente.

Stato non superato

La pagina Monitoraggi sintetici elenca un monitoraggio sintetico con stato Failing. Per saperne di più sul motivo dell'errore, visualizza la cronologia di esecuzione più recente.

• Se viene visualizzato il messaggio di errore Request failed with status code 429, la destinazione della richiesta HTTP ha rifiutato il comando. Per risolvere questo errore, devi modificare la destinazione del monitor sintetico.

  L'endpoint https://www.google.com rifiuta le richieste effettuate da monitor sintetici.

• Se l'errore restituisce un tempo di esecuzione di 0ms, la funzione Cloud Run potrebbe esaurire la memoria. Per risolvere questo errore, modifica la funzione Cloud Run, quindi aumenta la memoria ad almeno 2 GiB e imposta il campo CPU su 1.

L'eliminazione non va a buon fine per un monitoraggio sintetico

Utilizzi l'API Cloud Monitoring per eliminare un monitoraggio sintetico, ma la chiamata API non va a buon fine e restituisce una risposta simile alla seguente:

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

Per risolvere l'errore, elimina le policy di avviso che monitorano i risultati del monitoraggio sintetico, quindi elimina il monitoraggio sintetico.

Impossibile modificare la configurazione di un controllo dei link non funzionanti

Hai creato un controllo dei link non funzionanti utilizzando la console Google Cloud e vuoi modificare gli elementi HTML testati oppure vuoi modificare il timeout URI, i tentativi, l'attesa del selettore e le opzioni per link. Tuttavia, quando modifichi il controllo dei link non funzionanti, la console Google Cloud non mostra i campi di configurazione.

Per risolvere questo errore, segui questi passaggi:

1. Nella console Google Cloud , vai alla pagina  Monitoraggio sintetico:

   Vai a Monitoraggio sintetico

   Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo progetto Google Cloud . Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione.
3. Individua il monitor sintetico che vuoi modificare, fai clic su Altre opzioni e poi seleziona Modifica.
4. Fai clic su Modifica funzione.

5. Modifica l'oggetto options nel file index.js, poi fai clic su Applica funzione.

   Per informazioni sui campi e sulla sintassi di questo oggetto, vedi broken-links-ok/index.js.

6. Fai clic su Salva.

La consoleGoogle Cloud segnala che il salvataggio degli screenshot non è riuscito

Nota: un monitoraggio sintetico che non può salvare screenshot continua a testare i link contenuti in un URI.

Hai creato un controllo dei link non funzionanti e lo hai configurato per salvare gli screenshot. Tuttavia, la console Google Cloud mostra uno dei seguenti messaggi di avviso insieme a informazioni più dettagliate:

• InvalidStorageLocation
• StorageValidationError
• BucketCreationError
• ScreenshotFileUploadError

Per risolvere questi errori, prova quanto segue:

• Se visualizzi il messaggio InvalidStorageLocation, verifica l'esistenza del bucket Cloud Storage specificato nel campo denominato options.screenshot_options.storage_location.

• Visualizza i log relativi alla tua funzione Cloud Run. Per saperne di più, consulta Trovare i log.

• Verifica che il account di servizio utilizzato nella funzione Cloud Run corrispondente disponga di un ruolo Identity and Access Management che gli consenta di creare, accedere e scrivere nei bucket Cloud Storage.