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

Questo documento fornisce informazioni su come trovare i dati di log e Risolvi gli errori del monitoraggio sintetico e del controllo di uptime:

Trovare i log

Questa sezione fornisce informazioni su come trovare i log per monitor sintetici e controlli di uptime:

  1. 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 con il sottotitolo Logging.

  2. Esegui una delle seguenti operazioni:

    • Per trovare tutti i log associati ai monitoraggi sintetici o ai controlli di uptime, 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"

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

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

        labels.check_id="my-check-id"

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

        "UptimeCheckResult"

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

      Questi log includono quanto segue:

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

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

      • Quando vengono raccolti i dati di traccia, l'ID di una traccia associata, 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, vedi Elenco indirizzi IP.

Risolvere i problemi relativi alle notifiche

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

Un controllo non è riuscito, altri no

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

Non è richiesta alcuna azione per risolvere la situazione.

Quando un solo controllo segnala un errore, quest'ultimo potrebbe essere il risultato della timeout del comando di controllo di sicurezza a causa di un problema di rete. Cioè, invece che non riesce, il comando non viene completato entro il timeout specificato.

I criteri di avviso che utilizzano la configurazione predefinita richiedono errori di almeno due controllori prima di creare un incidente e inviare una notifica. Un errore segnalato da un singolo ispettore non genera 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 sull'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. Trova e seleziona il controllo di uptime.

        Il grafico Controlli superati mostra la cronologia dei controlli. Per identificare la prima volta che il controllo di uptime non è andato a buon fine, potrebbe essere necessario modificare l'intervallo di tempo del grafico. Il selettore dell'intervallo di tempo che 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 sul tempo di attività:

      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. Trova e seleziona il monitor sintetico.

  2. Per informazioni su come trovare i dati dei log associati, consulta la sezione Trovare i log di questa pagina.

Non ti viene comunicato che un controllo di uptime non è riuscito

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

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

Puoi modificare la condizione del criterio di avviso in modo da ricevere una notifica quando una singola regione non riceve una risposta. Tuttavia, ti invitiamo a 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, segui questi passaggi:

  1. Nella console Google Cloud, 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. Fai clic su Visualizza tutti i criteri nel riquadro Criteri.

  3. Trova la norma che vuoi visualizzare o modificare e fai clic sul suo nome.

    Puoi visualizzare e modificare il criterio dalla pagina Dettagli criterio.

Risolvere i problemi relativi ai controlli di uptime pubblici

In questa sezione vengono descritti alcuni errori che potresti riscontrare durante l'utilizzo di uptime pubblici e fornisce informazioni per risolverli.

I tuoi controlli di uptime pubblici non vanno a buon fine

Configura un controllo di uptime pubblico, ma ricevi un errore quando svolgi 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 avere installato un server web che risponda alle richieste HTTP. Può verificarsi un errore di connessione su una nuova istanza se non hai installato un server web; vedi il Guida rapida per Compute Engine. Se utilizzi un tipo di connessione HTTPS, potrebbe essere necessario eseguire passaggi di configurazione aggiuntivi. Per i problemi relativi al firewall, consulta Elenco degli indirizzi IP dei server di controllo dell'uptime.
  • Nome o servizio non trovato: il nome host potrebbe non essere corretto.
  • 403 Accesso negato: il servizio restituisce un codice di errore all'uptime controllo. Ad esempio, la configurazione predefinita del server web Apache restituisce questo codice in Amazon Linux, ma restituisce il codice 200 (Successo) 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 (Timeout della richiesta 408) o nessuna risposta: il numero di porta potrebbe essere scorretto, il servizio potrebbe non essere in esecuzione, il servizio potrebbe essere inaccessibile o il timeout potrebbe essere troppo basso. Verifica che il firewall consente il traffico dai server di uptime, vedi Elenca gli indirizzi IP dei server per il controllo di uptime. Il limite di timeout viene specificato nell'ambito del modulo Response Validation le opzioni di CPU e memoria disponibili.

Per aiutarti a risolvere i problemi relativi a controlli di uptime pubblici non riusciti, puoi configurare dei controlli di uptime per inviare emette un ping da ICMP durante la verifica. I ping possono aiutarti a distinguere tra causati, ad esempio, da problemi di connettività di rete e i timeout nella tua applicazione. Per ulteriori informazioni, vedi Utilizza ping ICMP.

Risolvere i problemi relativi ai controlli di uptime privati

In questa sezione vengono descritti alcuni errori che potresti riscontrare durante l'utilizzo controlli di uptime privati e fornisce informazioni per risolverli.

La creazione del controllo di uptime non va a buon fine

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

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

Console Google Cloud

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

Per informazioni su come concedere ruoli a un account di servizio, consulta Autorizzare l'account di servizio.

API: progetto di definizione dell'ambito

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

  • La creazione del primo controllo di uptime riesce se il tuo progetto lo consente le concessioni automatiche di ruoli per gli account di servizio. Viene creato un account di servizio per te a cui vengono concessi i ruoli necessari.

  • La prima creazione del controllo dell'uptime non va a buon fine se il progetto non consente la concessione automatica dei ruoli per gli account di servizio. Un account di servizio è ma non sono stati concessi ruoli.

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

  1. Autorizza l'account di servizio.
  2. Attendi alcuni minuti per la propagazione delle autorizzazioni.
  3. Prova a creare di nuovo il controllo di uptime privato.

API: progetto monitorato

La prima volta che crei un controllo dell'uptime privato che ha come target un servizio Service Directory in un progetto monitorato o risorse private in un altro progetto Google Cloud, la richiesta non va a buon fine e si traduce nella creazione di un account di servizio di monitoraggio.

La modalità di autorizzazione dell'account di servizio dipende dal numero di I progetti Google Cloud che stai utilizzando e le relative relazioni. Puoi coinvolgere fino a quattro progetti:

  • Il progetto in cui hai definito il controllo di uptime privato.
  • Il progetto monitorato in cui hai configurato 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 ruolo nell'autorizzazione dell'account di servizio di cui parleremo qui.

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

  1. Autorizza l'account di servizio.
  2. Attendi qualche minuto per la propagazione delle autorizzazioni.
  3. Prova a creare di nuovo il controllo di uptime privato.

Accesso negato

I controlli di uptime non superano i risultati di VPC_ACCESS_DENIED. Questo risultato significa che alcuni aspetti della configurazione della rete o dell'autorizzazione dell'account servizio non sono corretti.

Verifica se l'autorizzazione dell'account di servizio utilizza una definizione dell'ambito un progetto monitorato o un progetto monitorato, come descritto La creazione del controllo di uptime non va a buon fine.

Per ulteriori informazioni sull'accesso a reti private, vedi Configura 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 chiudi una delle VM, il controllo di uptime indica ancora il successo.

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 dell'uptime va a buon fine anche se una delle VM non è in funzione.

Intestazioni predefinite

I controlli di uptime restituiscono errori o risultati imprevisti. Questo potrebbe accadere se hai sostituito i valori predefiniti delle intestazioni.

Quando viene inviata una richiesta per un controllo dell'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 di Service Directory
HTTP_ACCEPT_ENCODING gzip, deflate, br
CONTENT_LENGTH Calcolata in base ai dati dei post sull'uptime

Se provi a sostituire questi valori, potrebbero verificarsi i seguenti casi:

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

Nessun dato visibile

Non visualizzi alcun dato nella dashboard del controllo dell'uptime quando il controllo dell'uptime si trova in un progetto Google Cloud diverso da quello del servizio Directory dei servizi.

Assicurati che il progetto Google Cloud contenente il controllo dell'uptime monitori il progetto Google Cloud contenente il servizio Service Directory.

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

Risolvere i problemi relativi ai monitoraggi sintetici

Questa sezione fornisce informazioni che possono aiutarti a risolvere i problemi i tuoi monitor sintetici.

Messaggio di errore dopo l'abilitazione delle API

Apri il flusso di creazione per un monitoraggio sintetico e ti viene chiesto di abilitarlo almeno un'API. Dopo aver attivato 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 ti consiglia di attendere e riprovare l'azione.

Per verificare che l'API sia abilitata, vai alla scheda API e Servizi per il tuo progetto:

Vai ad API e Servizi

Dopo aver verificato che l'API sia abilitata, puoi continuare con il flusso di creazione. La condizione si risolve automaticamente dopo che l'API l'abilitazione si propaga attraverso il backend.

Le richieste HTTP in uscita non vengono monitorate

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

Cloud Trace che mostra una sola traccia.

Per risolvere la situazione, assicurati che al tuo account di servizio sia stato concesso il ruolo Agente Cloud Trace (roles/cloudtrace.agent). È sufficiente anche un ruolo 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 Console di amministrazione.

  2. Seleziona Includi concessioni dei ruoli fornite da Google.

  3. Se l'account di servizio utilizzato dal monitor sintetico non è elencato o se non gli è stato concesso un ruolo che includa le autorizzazioni del ruolo Agente Cloud Trace (roles/cloudtrace.agent), concedi questo ruolo all'account di servizio.

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

Stato In corso

Nella pagina Monitoraggi sintetici è elencato un monitoraggio sintetico con stato In progress. Uno stato In progress indica che il monitoraggio sintetico è stato creato di recente e non ci sono dati da visualizzare oppure che il deployment della funzione non è riuscito.

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

  • Assicurati che il nome della funzione Cloud Run non sia contiene un trattino basso. Se è presente un'underscore, rimuovila e esegui nuovamente il deployment della funzione Cloud Run.

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

    Se viene visualizzato il seguente messaggio, elimina il monitoraggio 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, di conseguenza, il monitoraggio sintetico non è in grado di eseguire la funzione.

  • Apri la pagina delle funzioni di Cloud Run per la funzione. Per aprire questa pagina Dalla pagina Dettagli monitoraggio sintetico, fai clic su Codice e poi fai clic sul nome della funzione.

    Se viene visualizzato un messaggio simile al seguente, la funzione non è riuscita. di cui eseguire il deployment.

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

    Per risolvere l'errore, esamina il codice della funzione e correggi gli errori che impediscono la creazione o il deployment della funzione.

Quando crei un monitor sintetico, il deployment e l'esecuzione della funzione potrebbero richiedere diversi minuti.

Stato di avviso

Monitor sintetici elenca un monitoraggio sintetico con stato Warning. Lo stato Warning indica che l'esecuzione i risultati non sono coerenti. Questo potrebbe indicare un problema di progettazione test o potrebbe indicare che ciò che viene testato ha un comportamento incoerente.

Stato di errore

Monitor sintetici elenca un monitoraggio sintetico con lo stato Failing. Per ulteriori informazioni 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 il problema in caso di errore, devi modificare la destinazione del monitoraggio sintetico.

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

  • Se l'errore restituisce un tempo di esecuzione pari a 0ms, l'errore È possibile che la funzione Cloud Run stia esaurendo 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 riesce per un monitoraggio sintetico

Puoi utilizzare l'API Cloud Monitoring per eliminare un monitoraggio sintetico, ma l'API non riesce 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 i criteri di avviso che monitorano i risultati del monitoraggio sintetico, quindi elimina il monitoraggio sintetico.

Impossibile modificare la configurazione di uno strumento di verifica dei link inaccessibili

Hai creato un programma di verifica dei link inaccessibili utilizzando la console Google Cloud e vuoi per cambiare gli elementi HTML testati o se desideri modificare il timeout dell'URI, i nuovi tentativi, l'attesa del selettore e le opzioni per link. Tuttavia, quando modifichi il controllo dei link inaccessibili, la console Google Cloud vengono visualizzati i campi di configurazione.

Per risolvere l'errore:

  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. Individua il monitor sintetico che vuoi modificare. fai clic su Altre opzioni, poi seleziona Modifica.
  3. Fai clic su Modifica funzione.

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

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

  5. Fai clic su Salva.

La console Google Cloud indica che i salvataggi degli screenshot non vanno a buon fine

Hai creato uno strumento di verifica dei link inaccessibili e l'hai configurato in modo da salvare gli screenshot. Tuttavia, nella console Google Cloud viene visualizzato uno dei seguenti avvisi messaggi insieme a informazioni più dettagliate:

  • InvalidStorageLocation
  • StorageValidationError
  • BucketCreationError
  • ScreenshotFileUploadError

Per risolvere questi errori, prova a procedere nel seguente modo:

  • Se vedi il messaggio InvalidStorageLocation, verifica che esista del bucket Cloud Storage specificato nel campo denominato options.screenshot_options.storage_location.

  • Visualizza i log relativi alla funzione Cloud Run. Per ulteriori informazioni, consulta Trovare i log.

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