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

Se você enviou uma chave de API na solicitação, uma mensagem de erro como "API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project" indica que a chave de API foi criada em um projeto Google Cloud diferente da API. Para corrigir esse problema, crie uma chave de API no mesmo projeto Google Cloud a que ela está associada ou ative a API no projeto 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 Explorador de registros

  2. Na parte de cima da página, selecione o projeto 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: