Nesta página, descrevemos como solucionar erros recebidos na resposta da solicitação para uma API.
Upstream backend unavailable
Receber o código de erro 14
e a mensagem upstream backend unavailable
indica que o Extensible Service Proxy (ESP) não consegue acessar o back-end do serviço. Verifique se:
- Se o serviço do back-end está em execução. A maneira de fazer isso depende do back-end.
- Para o Compute Engine, veja detalhes em Como solucionar problemas do Cloud Endpoints no Compute Engine.
-
No GKE, use SSH para acessar o pod e usar o
curl
. Para mais detalhes, consulte Como solucionar problemas do Endpoints no Google Kubernetes Engine.
- A porta de endereço IP correta do serviço de back-end foi especificada:
-
Para o GKE, verifique o valor da sinalização
--backend
do ESP (a opção menor é-a
) no arquivo de manifesto de implantação, geralmente chamado dedeployment.yaml
. -
No Compute Engine, verifique o valor da sinalização
--backend
do ESP no comandodocker run
. A menor opção é-a
.
-
Para o GKE, verifique o valor da sinalização
reset reason: connection failure
Se você receber o código HTTP 503
ou o código gRPC 14
e a mensagem upstream connect error or disconnect/reset before headers. reset reason: connection failure
, isso significa
que o ESPv2 não consegue alcançar o back-end do serviço.
Para resolver esse problema, veja os itens abaixo.
Endereço de back-end
Ao configurar o ESPv2, o endereço de back-end precisa estar correto. Problemas comuns incluem:
- O esquema do endereço de back-end deve corresponder ao tipo de aplicativo de back-end.
Os back-ends da OpenAPI precisam ser
http://
, e os back-ends do gRPC devem sergrpc://
. - Para o ESPv2 implantado no Cloud Run, o esquema do endereço de back-end precisa ser
https://
ougrpcs://
. Os
solicita que o ESPv2 configure o TLS com o back-end.
Busca DNS
Por padrão, o ESPv2 tenta resolver nomes de domínio para endereços IPv6. Quando a resolução IPv6 falha, o ESPv2 recorre aos endereços IPv4.
Em algumas redes, o mecanismo substituto pode não funcionar como esperado.
Em vez disso, é possível forçar o ESPv2 a usar endereços IPv4 com a
sinalização --backend_dns_lookup_family
.
Esse erro é comum se você configurar um conector de VPC sem servidor para o ESPv2 implantado no Cloud Run. As VPCs não têm suporte para o tráfego IPv6.
API is not enabled for the project
Ao enviar uma chave de API na solicitação, uma mensagem de erro do tipo "API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project" indica que essa chave foi criada em um projeto do Google Cloud diferente da API. Para corrigir esse problema, crie uma chave de API no mesmo projeto do Google Cloud a que ela está associada ou ative a API no projeto do Google Cloud em que a chave de API foi criada.
Service control request failed with HTTP response code 403
Receber o código de erro 14
e a mensagem Service control request failed
with HTTP response code 403
indica que a API Service Control (servicecontrol.googleapis.com
) não está ativada no projeto.
Consulte Como verificar os serviços obrigatórios para garantir que todos os serviços exigidos pelo Endpoints e o ESP estejam ativados no projeto.
Consulte Como verificar as permissões necessárias para garantir que todas as permissões necessárias para a conta de serviço associada à instância que executa o ESP.
Method doesn't allow unregistered callers
O ESP responde com o erro Method doesn't allow unregistered callers
quando você especifica allow_unregistered_calls: false
no arquivo de configuração da API gRPC, mas a solicitação para sua API não tem uma chave de API atribuída a um parâmetro de consulta chamado key
.
Caso precise gerar uma chave de API para chamar sua API, consulte Como criar uma chave de API.
Method does not exist
A resposta Method does not exist
significa que o método HTTP (GET
, POST
ou outro) no caminho do URL especificado não foi encontrado. Para solucionar isso, compare a configuração do serviço que você implantou para garantir a correspondência entre o nome do método e o caminho do URL enviados na solicitação:
No console do Google Cloud, acesse a página Serviços do Endpoints do seu projeto.
Caso tenha mais de uma API, selecione aquela para a qual a solicitação foi enviada.
Clique na guia Histórico de implantação.
Selecione a implantação mais recente para ver a configuração do serviço.
Transport is closing
Receber o código de erro 13
e a mensagem transport is closing
indica que o ESP está inacessível.
Verifique os registros de erros do ESP. A maneira de fazer isso depende do back-end. Para saber mais, consulte os seguintes artigos:
Respostas inesperadas
Se a resposta HTTP parecer binária, isso pode indicar que a solicitação está acessando a API por meio da porta HTTP2
quando você pretendia usar a porta HTTP1
.
Verifique as opções de configuração de porta para o ESP. Como as sinalizações abreviadas, -p
(para HTTP1
) e -P
(para HTTP2
), são muito parecidas, recomendamos usar as sinalizações de formato longo: --http_port
paraHTTP1
e --http2_port
para HTTP2
.
Uma configuração errada do back-end do ESP também pode causar respostas inesperadas. Verifique se a sinalização de back-end (-a
ou --backend
) está definida como um URL gRPC, como --backend=grpc://127.0.0.1:8081
.
Para mais detalhes sobre as sinalizações do ESP, consulte Opções de inicialização do ESP.
Como verificar os registros do Cloud Logging
Para usar os registros do Cloud Logging para ajudar a solucionar erros de resposta:
No Console do Google Cloud, acesse a página Logging.
Na parte superior da página, selecione o projeto do Google Cloud.
Usando o menu suspenso à esquerda, selecione API produzida> [YOUR_SERVICE_NAME].
Ajuste o intervalo de tempo até ver uma linha que mostre seu erro de resposta.
Expanda o payload JSON e procure por
error_cause
.Se
error_cause
estiver definido comoapplication
, significa que seu código está com problema.Se
error cause
estiver definido de qualquer outra maneira e você não conseguir corrigir o problema, exporte o registro e inclua-o em qualquer comunicação com o Google.
Consulte os seguintes tópicos para saber mais:
Para ver mais detalhes sobre a estrutura dos registros no Explorador de registros, consulte a Referência de registros do Endpoints
Comece a usar o Explorador de registros.
Use Consultas avançadas de registros para realizar filtragem avançada. Por exemplo, buscar todas as solicitações com latência maior que 300 milissegundos.