Solução de problemas em erros de resposta

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.

  • A porta de endereço IP correta do serviço de back-end foi especificada:
    • No GKE, verifique o valor da sinalização --backend do ESP no arquivo de manifesto da implantação, também conhecido como deployment.yaml. A menor opção é -a.
    • No Compute Engine, verifique o valor da sinalização --backend do ESP no comando docker run. A menor opção é -a.

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 ser grpc://.
  • Para o ESPv2 implantado no Cloud Run, o esquema do endereço de back-end precisa ser https:// ou grpcs://. O s 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.

  1. 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.

  2. 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:

  1. No console do Google Cloud, acesse a página Serviços do Endpoints do seu projeto.

    Ir para a página Serviços do Endpoints

  2. Caso tenha mais de uma API, selecione aquela para a qual a solicitação foi enviada.

  3. Clique na guia Histórico de implantação.

  4. 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:

  1. No Console do Google Cloud, acesse a página Logging.

    Acessar a página Análise de registros

  2. Na parte superior da página, selecione o projeto do Google Cloud.

  3. Usando o menu suspenso à esquerda, selecione API produzida> [YOUR_SERVICE_NAME].

  4. Ajuste o intervalo de tempo até ver uma linha que mostre seu erro de resposta.

  5. Expanda o payload JSON e procure por error_cause.

    • Se error_cause estiver definido como application, 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.

Para saber mais, consulte os seguintes artigos: