Questa pagina descrive come risolvere i problemi relativi agli errori che ricevi in una risposta a una richiesta alla tua API.
BAD_GATEWAY
Se ricevi il codice di errore 13 e il messaggio BAD_GATEWAY, significa
che Extensible Service Proxy (ESP) non riesce a raggiungere il backend del servizio.
Verifica quanto segue:
- Assicurati che il servizio di backend sia in esecuzione. Il modo in cui farlo dipende dal
backend.
-
Per l'ambiente flessibile di App Engine, il codice di errore per il messaggio
BAD_GATEWAYpotrebbe essere502. Per saperne di più, consulta la sezione Errori specifici dell'ambiente flessibile di App Engine. - Per Compute Engine, consulta la pagina Risoluzione dei problemi di Cloud Endpoints su Compute Engine per i dettagli.
-
Per GKE, devi utilizzare SSH per accedere al pod e utilizzare
curl. Per i dettagli, consulta Risoluzione dei problemi degli endpoint in Google Kubernetes Engine.
-
Per l'ambiente flessibile di App Engine, il codice di errore per il messaggio
- È specificata la porta dell'indirizzo IP corretta del servizio di backend:
-
Per GKE, controlla il valore del flag ESP
--backend(l'opzione breve è-a) nel file manifest del deployment (spesso chiamatodeployment.yaml). -
Per Compute Engine, controlla il valore del flag ESP
--backend(l'opzione breve è-a) nel comandodocker run.
-
Per GKE, controlla il valore del flag ESP
reset reason: connection failure
Se ricevi il codice HTTP 503 o il codice gRPC 14 e il messaggio upstream connect error or disconnect/reset before headers. reset reason: connection failure, significa
che ESPv2 non riesce a raggiungere il backend del servizio.
Per risolvere il problema, controlla i seguenti elementi.
Indirizzo backend
ESPv2 deve essere configurato con l'indirizzo backend corretto. I problemi più comuni includono:
- Lo schema dell'indirizzo di backend deve corrispondere al tipo di applicazione di backend.
I backend OpenAPI devono essere
http://e i backend gRPC devono esseregrpc://. - Per ESPv2 di cui è stato eseguito il deployment su Cloud Run, lo schema dell'indirizzo backend deve essere
https://ogrpcs://.sindica a ESPv2 di configurare TLS con il backend.
Ricerca DNS
Per impostazione predefinita, ESPv2 tenta di risolvere i nomi di dominio in indirizzi IPv6. Se la risoluzione IPv6 non va a buon fine, ESPv2 esegue il failover sugli indirizzi IPv4.
Per alcune emittenti, il meccanismo di fallback potrebbe non funzionare come previsto.
In alternativa, puoi forzare ESPv2 a utilizzare indirizzi IPv4 tramite il
flag --backend_dns_lookup_family.
Questo errore è comune se configuri un connettore VPC serverless per ESPv2 di cui è stato eseguito il deployment su Cloud Run. I VPC non supportano il traffico IPv6.
API is not enabled for the project
Se hai inviato una chiave API nella richiesta, un messaggio di errore come "API my-api.endpoints.example-project-12345.cloud.goog non è abilitata per il progetto" indica che la chiave API è stata creata in un progetto Google Cloud diverso da quello dell'API. Per risolvere il problema, puoi creare la chiave API nello stesso progetto Google Cloud a cui è associata l'API oppure puoi attivare l'API nel progetto Google Cloud in cui è stata creata la chiave API.
Service control request failed with HTTP response code 403
Se ricevi il codice di errore 14 e il messaggio Service control request failed
with HTTP response code 403, significa che l'API Service Control (servicecontrol.googleapis.com) non è abilitata nel progetto.
Consulta la sezione Controllo dei servizi richiesti per assicurarti che tutti i servizi richiesti da Endpoints e ESP siano abilitati nel tuo progetto.
Consulta la sezione Controllo delle autorizzazioni richieste per assicurarti che il account di servizio associato all'istanza che esegue ESP disponga di tutte le autorizzazioni richieste.
Method doesn't allow unregistered callers
ESP risponde con l'errore
Method doesn't allow unregistered callers quando hai specificato una chiave API
nella sezione security del documento OpenAPI, ma la richiesta alla tua API
non ha una chiave API assegnata a un parametro di query denominato key.
Se devi generare una chiave API per effettuare chiamate alla tua API, consulta Crea una chiave API.
Method does not exist
La risposta, Method does not exist, indica che il metodo HTTP
(GET, POST o altro) nel percorso URL specificato non è stato trovato. Per
risolvere il problema, confronta la configurazione del servizio che hai eseguito il deployment per assicurarti che il nome del metodo e il percorso dell'URL che invii nella richiesta
corrispondano:
Nella console Google Cloud , vai alla pagina Servizi endpoint per il tuo progetto.
Se hai più di un'API, seleziona quella a cui hai inviato la richiesta.
Fai clic sulla scheda Cronologia deployment.
Seleziona l'ultimo deployment per visualizzare la configurazione del servizio.
Se non vedi il metodo che stai chiamando specificato nella sezione paths
del documento OpenAPI, aggiungi il metodo o il flag x-google-allow
al livello superiore del file:
x-google-allow: all
Questo flag indica che puoi evitare di elencare tutti i metodi supportati nel backend
nel documento OpenAPI. Quando viene utilizzato all, tutte le chiamate, con o senza
autenticazione utente o chiave API, passano attraverso ESP alla tua
API. Per saperne di più, consulta
x-google-allow.
Errori specifici dell'ambiente flessibile di App Engine
Questa sezione descrive le risposte di errore delle API di cui è stato eseguito il deployment nell'ambiente flessibile di App Engine.
Codice di errore 502 o 503
Potrebbero essere necessari alcuni minuti prima che App Engine risponda correttamente alle richieste.
Se invii una richiesta e ricevi un errore HTTP 502, 503 o un altro errore del server, attendi un minuto e riprova.
Messaggio di errore BAD_GATEWAY
Un codice di errore 502 con BAD_GATEWAY nel messaggio indica in genere che
App Engine ha terminato l'applicazione perché la memoria è esaurita.
La VM flessibile App Engine predefinita ha solo 1 GB di memoria, con solo
600 MB disponibili per il container dell'applicazione.
Per risolvere il problema relativo al codice di errore 502:
Nella console Google Cloud , vai alla pagina Logging:
Seleziona il progetto Google Cloud applicabile nella parte superiore della pagina.
Seleziona Applicazione Google App Engine e apri
vm.syslog.Cerca una voce di log simile alla seguente:
kernel: [ 133.706951] Out of memory: Kill process 4490 (java) score 878 or sacrifice child kernel: [ 133.714468] Killed process 4306 (java) total-vm:5332376kB, anon-rss:2712108kB, file-rss:0kBSe nel log vedi una voce
Out of memory:Aggiungi quanto segue al tuo file
app.yamlper aumentare le dimensioni della VM predefinita:resources: memory_gb: 4Esegui di nuovo il deployment dell'API:
gcloud app deploy
Se hai specificato l'opzione rollout_strategy: managed nella
sezione endpoints_api_service del file app.yaml, utilizza il seguente comando
per eseguire nuovamente il deployment dell'API:
gcloud app deploy
Per saperne di più, consulta Deployment dell'API e dell'ESP.
Controllare i log di Cloud Logging
Per utilizzare i log di Cloud Logging per risolvere i problemi relativi agli errori di risposta:
Nella console Google Cloud , vai alla pagina Logging.
Nella parte superiore della pagina, seleziona il Google Cloud progetto.
Utilizzando il menu a discesa a sinistra, seleziona API prodotta > [YOUR_SERVICE_NAME].
Regola l'intervallo di tempo finché non vedi una riga che mostra l'errore di risposta.
Espandi il payload JSON e cerca
error_cause.Se
error_causeè impostato suapplication, significa che c'è un problema nel tuo codice.Se il
error causeè diverso e non riesci a risolvere il problema, esporta il log e includilo in qualsiasi comunicazione con Google.
Vai ai seguenti argomenti per ulteriori informazioni:
Per informazioni dettagliate sulla struttura dei log in Esplora log, consulta il riferimento ai log degli endpoint.
Inizia a utilizzare Esplora log.
Utilizza le query avanzate sui log per il filtraggio avanzato, ad esempio per ottenere tutte le richieste con una latenza superiore a 300 millisecondi.
Problemi con l'esempio Invoke-WebRequest
In alcune versioni di Windows PowerShell, l'esempio Invoke-WebRequest nei
tutorial
non va a buon fine. Abbiamo anche ricevuto una segnalazione secondo cui la risposta conteneva un elenco di
byte non firmati che dovevano essere convertiti in caratteri. Se l'esempio
Invoke-WebRequest non ha restituito il risultato previsto, prova a inviare la richiesta
utilizzando un'altra applicazione. Ecco alcuni suggerimenti:
- Avvia Cloud Shell e segui i passaggi per Linux nel tutorial che stavi utilizzando per inviare la richiesta.
Installa un'applicazione di terze parti, ad esempio l'estensione del browser Chrome Postman (offerta da
www.getpostman.com). Quando crei la richiesta in Postman:- Seleziona
POSTcome verbo HTTP. - Per l'intestazione, seleziona la chiave
content-typee il valoreapplication/json. - Per il corpo, inserisci:
{"message":"hello world"} Nell'URL, utilizza la chiave API effettiva anziché la variabile di ambiente. Ad esempio:
- Nell'ambiente flessibile di App Engine:
https://example-project-12345.appspot.com/echo?key=AIza... - Su altri backend:
http://192.0.2.0:80/echo?key=AIza...
- Nell'ambiente flessibile di App Engine:
- Seleziona
Scarica e installa
curl, che esegui nel prompt dei comandi. Poiché Windows non gestisce le virgolette doppie nidificate all'interno delle virgolette singole, devi modificare l'opzione--datanell'esempio in:--data "{\"message\":\"hello world\"}"