Risolvi i problemi dell'API Monitoring

Questa guida spiega alcuni dei problemi che potrebbero verificarsi quando utilizzi l'API Monitoring.

L'API Monitoring è una delle varie API Cloud. Queste API condividono un insieme comune di codici di errore. Per un elenco dei codici di errore definiti dalle API Cloud e suggerimenti generali sulla gestione degli errori, consulta Gestione degli errori.

Utilizza Explorer API per il debug

Explorer API è un widget integrato nelle pagine di riferimento per i metodi API. Ti consente di richiamare il metodo compilando i campi; non richiede di scrivere codice.

Se hai problemi con la chiamata di un metodo, utilizza il widget Explorer API (Prova questa API) nella pagina di riferimento del metodo in questione per eseguire il debug del problema. Per ulteriori informazioni, consulta Explorer API.

Errori generali relativi all'API

Ecco alcuni degli errori e dei messaggi dell'API Monitoring che potresti visualizzare dalle tue chiamate API:

• 404 NOT_FOUND con il messaggio "L'URL richiesto non è stato trovato su questo server": alcune parte dell'URL non sono corrette. Confronta l'URL con l'URL per il metodo mostrato nella pagina di riferimento del metodo. Questo errore potrebbe significare che è presente un errore ortografico, ad esempio "progetto" anziché "progetti", oppure un errore di utilizzo delle lettere maiuscole, ad esempio "TimeSeries" anziché "timeSeries".

• 401 UNAUTHENTICATED con "L'utente non è autorizzato ad accedere al progetto (o alla metrica)": questo codice di errore indica in genere un problema di autorizzazione, ma può indicare che è presente un errore nell'ID progetto o nel nome del tipo di metrica. Verifica l'ortografia e le lettere maiuscole.

  Se non usi Explorer API, prova a farlo. Quando la chiamata API funziona in Explorer API, probabilmente esiste un problema di autorizzazione nell'ambiente in cui esegui la chiamata API. Vai alla pagina del gestore API per verificare che l'API Monitoring sia abilitata per il tuo progetto.

• 400 INVALID_ARGUMENT con "Il filtro del campo aveva un valore non valido": verifica l'ortografia e la formattazione del filtro di monitoraggio. Per saperne di più, consulta la sezione Filtri di monitoraggio.

• 400 INVALID_ARGUMENT con "Richiesta campo intervallo.endTime mancante": viene visualizzato questo messaggio quando manca l'ora di fine o quando è presente ma non è formattata correttamente. Se utilizzi Explorer API, non indicare il valore del campo temporale.

  Di seguito sono riportati alcuni esempi di specifiche temporali valide:

  2024-05-11T01:23:45Z
  2024-05-11T01:23:45.678Z
  2024-05-11T01:23:45.678+05:00
  2024-05-11T01:23:45.678-04:30
  

Risultati mancanti

Quando una chiamata API restituisce il codice di stato 200 e una risposta vuota, considera quanto segue:

• Quando la chiamata utilizza un filtro, il filtro potrebbe non corrispondere a nulla. La corrispondenza del filtro è sensibile alle maiuscole. Per risolvere i problemi di filtro, inizia specificando un solo componente del filtro, come metric.type, e verifica di ottenere risultati. Aggiungi gli altri componenti del filtro uno alla volta per creare la tua richiesta.

• Quando lavori con una metrica personalizzata, verifica che sia specificato il progetto che la definisce.

Esistono diversi motivi per cui potrebbero mancare i punti dati quando utilizzi il metodo timeSeries.list:

• I dati potrebbero essere invecchiati. Per ulteriori informazioni, consulta Conservazione dei dati.

• I dati potrebbero non essere stati ancora propagati a Monitoring. Per saperne di più, consulta Latenza dei dati delle metriche.

• L'intervallo non è valido:

  • Verifica che l'ora di fine sia corretta.
  • Verifica che l'ora di inizio sia corretta e che sia precedente all'ora di fine. Se l'ora di inizio non è presente o è in un formato non corretto, l'API imposta l'ora di inizio sull'ora di fine. Per le metriche GAUGE, questo intervallo di tempo corrisponde solo ai punti i cui ora di inizio e fine corrispondono esattamente a quella di fine dell'intervallo. Per le metriche CUMULATIVE o DELTA, che misurano intervalli temporali, non viene trovata alcuna corrispondenza. Per saperne di più, consulta Intervalli di tempo.

Nuovo tentativo per errori relativi all'API

Due dei codici di errore delle API Cloud indicano le circostanze in cui potrebbe essere utile ritentare la richiesta:

• 503 UNAVAILABLE: i nuovi tentativi sono utili quando il problema è una condizione temporanea o di breve durata.
• 429 RESOURCE_EXHAUSTED: i nuovi tentativi sono utili, dopo un ritardo, per i job in background a lunga esecuzione con quota basata sul tempo, come n chiamate al t secondi. I nuovi tentativi non sono utili quando il problema è una condizione temporanea o di breve durata oppure quando hai esaurito una quota basata sul volume. In caso di condizioni temporanee, valuta la possibilità di tollerare l'errore. Per problemi relativi alla quota, valuta la possibilità di ridurre l'utilizzo della quota o di richiederne un aumento.

Quando scrivi codice che potrebbe riprovare a eseguire la richiesta, assicurati prima che sia possibile riprovare in sicurezza.

Puoi riprovare la richiesta?

Se la tua richiesta è idempotente, puoi riprovare in sicurezza. Un'azione idempotente è un'azione in cui qualsiasi modifica di stato non dipende dallo stato attuale. Ad esempio:

• La lettura di x è idempotente; il valore non è cambiato.
• Impostare x su 10 è idempotente; questo potrebbe cambiare lo stato, se il valore non è già 10, ma non importa qual è il valore corrente. Inoltre, il numero di volte che provi a impostarlo non è importante.
• L'incremento di x non è idempotente; il nuovo valore dipende dal valore corrente.

Riprova con backoff esponenziale

Quando implementi il codice per riprovare a eseguire le richieste, non vuoi inviare nuove richieste rapidamente e a tempo indeterminato. Se un sistema è sovraccarico, questo approccio contribuisce al problema.

Utilizza invece un approccio di backoff esponenziale troncato. Quando le richieste non vanno a buon fine a causa di sovraccarichi temporanei anziché per una vera indisponibilità, la soluzione è ridurre il carico. Un backoff esponenziale troncato segue questo schema generale:

• Stabilisci quanto tempo intendi attendere mentre riprovi o quanti tentativi intendi fare. Quando questo limite viene superato, considera il servizio non disponibile e gestisci questa condizione in modo appropriato per la tua applicazione. Questo è ciò che rende il backoff tronco: a un certo punto smetti di riprovare.

• Riprova a effettuare la richiesta con pause sempre più lunghe per arrestare la frequenza dei nuovi tentativi. Riprova finché la richiesta non viene completata o non viene raggiunto il limite stabilito.

  In genere, l'intervallo viene aumentato di una funzione della potenza del conteggio dei tentativi, rendendolo un backoff esponenziale.

Esistono molti modi per implementare un backoff esponenziale. Di seguito è riportato un esempio in cui viene aggiunto un ritardo di backoff crescente a un ritardo minimo di 1000 ms. Il ritardo di backoff iniziale è di 2 ms e aumenta a 2 ^retry_count ms a ogni tentativo.

La tabella seguente mostra gli intervalli tra i tentativi utilizzando i valori iniziali:

• Ritardo minimo = 1 s = 1000 ms
• Backoff iniziale = 2 ms

Conteggio nuovi tentativi	Ritardo aggiuntivo (ms)	Riprova tra (ms)
0	2^0 = 1	1001
1	2^1 = 2	1002
2	2^2 = 4	1004
3	2^3 = 8	1008
4	2^4 = 16	1016
...	...	...
n	2^n	1000 + 2^n

Puoi troncare il ciclo di nuovi tentativi interrompendo l'esecuzione dopo n tentativi o quando il tempo speso supera un valore ragionevole per la tua applicazione.

Per maggiori informazioni, consulta l'articolo di Wikipedia Backoff esponenziale.