Risolvere i problemi relativi all'API Monitoring

Questa guida illustra alcuni dei problemi che potrebbero verificarsi durante l'utilizzo dell'API Monitoring.

L'API Monitoring è una delle API Cloud. Queste API condividono un insieme comune di codici di errore. Per un elenco degli errori codici definiti dalle API Cloud e suggerimenti generali su per gestire gli errori, consulta Gestione degli errori.

Utilizzare Explorer API per il debug

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

Se riscontri problemi con la chiamata di un metodo, utilizza Explorer API (Prova questa API) nella pagina di riferimento di tale metodo per eseguire il debug del problema. Per ulteriori informazioni, vedi Explorer API.

Errori generali relativi all'API

Di seguito sono riportati alcuni degli errori e dei messaggi dell'API Monitoring che potresti visualizzare dalle chiamate API:

• 404 NOT_FOUND con "L'URL richiesto non è stato trovato su questo server": Una parte dell'URL non è corretta. Confronta l'URL con l'URL del metodo mostrato nella pagina di riferimento del metodo. Potrebbe indicare un errore ortografico, ad esempio "progetto" anziché "progetti" o un errore di lettere maiuscole, ad esempio "Serie temporali" anziché "timeSeries".

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

  Se non utilizzi Explorer API, prova a farlo. Quando l'API funziona in Explorer API, probabilmente è presente problema nell'ambiente in cui viene effettuata la chiamata API. Vai alla sezione Pagina del gestore API per eseguire la verifica che l'API Monitoring sia abilitata per il tuo progetto.

• 400 INVALID_ARGUMENT con "Il filtro del campo ha un valore non valido": verifica il l'ortografia e la formattazione del filtro di monitoraggio. Per ulteriori informazioni, vedi Filtri di Monitoring.

• 400 INVALID_ARGUMENT con "Nel campo della richiesta mancava intervallo.endTime": Visualizzi questo messaggio quando non c'è l'ora di fine o quando è presente, ma non è nel formato corretto. Se utilizzi l'Explorer API, non devi indicare il valore del campo time.

  Ecco alcuni esempi di specifiche di tempo 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, prendi in considerazione le seguenti:

• Quando la chiamata utilizza un filtro, quest'ultimo potrebbe non avere qualsiasi cosa. La corrispondenza del filtro è sensibile alle maiuscole. Per risolvere i problemi relativi ai filtri, inizia specificando un solo componente del filtro, ad esempio metric.type, e verifica di ottenere risultati. Aggiungi l'altro filtro uno alla volta per creare la tua richiesta.

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

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

• I dati potrebbero essere obsoleti. Per ulteriori informazioni, vedi Conservazione dei dati.

• I dati potrebbero non essere ancora stati propagati a Monitoraggio. 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 la dall'ora di inizio all'ora di fine. Per le metriche GAUGE, questo intervallo di tempo corrisponde solo ai punti le cui ore di inizio e di fine corrispondono esattamente all'ora di fine dell'intervallo. Per le metriche CUMULATIVE o DELTA, che misurano a intervalli di tempo, non viene assegnato alcun punto. Per saperne di più, consulta la sezione Intervalli di tempo.

Errori di ripetizione dell'API

Due dei codici di errore delle API Cloud indicano circostanze in cui potrebbe essere utile riprovare a inviare la richiesta:

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

Quando scrivi codice che potrebbe riprovare a effettuare richieste, assicurati innanzitutto che la richiesta puoi riprovare.

È sicuro riprovare a inviare la richiesta?

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

• La lettura di x è idempotente; il valore non cambia.
• L'impostazione di x su 10 è idempotente; questo potrebbe cambiare lo stato, non è già 10, ma non importa quale sia il valore corrente. Inoltre, non importa quante volte provi a impostare il valore.
• L'aumento di x non è idempotente; il nuovo valore dipende valore.

Effettua nuovi tentativi con backoff esponenziale

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

Utilizza invece un approccio con backoff esponenziale troncato. Quando le richieste non vanno a buon fine a causa di sovraccarichi temporanei invece che per true l'indisponibilità, la soluzione consiste nel ridurre il carico. Un backoff esponenziale troncato segue questo schema generale:

• Stabilisci per quanto tempo vuoi attendere durante i tentativi di ripetizione o quanti tentativi vuoi 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 troncato: a un certo punto smetti di riprovare.

• Riprovare la richiesta con pause sempre più lunghe per arretrare il la frequenza dei nuovi tentativi. Riprova finché la richiesta non va a buon fine o raggiunto il limite stabilito.

  L'intervallo viene tipicamente aumentato da una qualche funzione della potenza il numero di nuovi tentativi, creando un backoff esponenziale.

Esistono molti modi per implementare un backoff esponenziale. Di seguito è riportato un esempio che aggiunge 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 con ogni tentativo.

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

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

Riprova conteggio	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 interrompendolo dopo n tentativi o se il tempo speso supera un valore ragionevole per l'applicazione.

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