Solução de problemas de erros de respostas

Nesta página, descrevemos como solucionar erros recebidos na resposta da solicitação para uma API.

BAD_GATEWAY

Receber o código de erro 13 e a mensagem BAD_GATEWAY indica que o Extensible Service Proxy (ESP) não consegue alcançar o back-end do serviço. Verifique se:

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 uma chave de API na seção security do documento da OpenAPI, 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 para 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.

Se você não vir o método que está chamando especificado na seção paths do documento da OpenAPI, adicione o método ou a sinalização x-google-allow no nível superior do arquivo:

x-google-allow: all

Esta sinalização significa que é possível impedir a listagem de todos os métodos compatíveis com seu back-end no documento da OpenAPI. Ao usar all, todas as chamadas com ou sem uma chave de API ou autenticação de usuário passarão pelo ESP para a API. Consulte x-google-allow para mais informações.

Erros específicos do ambiente flexível do App Engine

Nesta seção, você verá as respostas de erros das APIs implementadas no ambiente flexível do App Engine.

Código de erro 502 ou 503

O App Engine pode levar alguns minutos para responder às solicitações. Ao enviar uma solicitação e receber um erro HTTP 502, 503 ou algum outro erro de servidor, aguarde um minuto e envie a solicitação novamente.

Mensagem de erro BAD_GATEWAY

Um código de erro 502 com BAD_GATEWAY na mensagem geralmente indica que o App Engine encerrou o aplicativo porque ele ficou sem memória. A VM flexível padrão do App Engine tem apenas 1GB de memória com apenas 600MB disponíveis para o contêiner do aplicativo.

Para solucionar problemas do código de erro 502:

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

    Acessar a página Análise de registros

  2. Selecione o projeto do Google Cloud aplicável na parte superior da página.

  3. Selecione Aplicativo do Google App Engine e abra vm.syslog.

  4. Procure uma entrada de registro semelhante a esta:

    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:0kB

    Se você vir uma entrada Out of memory no registro:

    1. Adicione o seguinte ao arquivo app.yaml para aumentar o tamanho da VM padrão:

      resources:
  memory_gb: 4

    2. Implante a API novamente.

      gcloud app deploy

Se você tiver a opção rollout_strategy: managed especificada na seção endpoints_api_service do arquivo app.yaml, use o seguinte comando para reimplantar a API:

  gcloud app deploy

Consulte Como implantar a API e o ESP para mais informações.

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 relacionado a qualquer outra coisa e você não conseguir corrigir o problema, exportar o registro e incluí-lo em todas as comunicações com o Google.

Para saber mais, consulte os seguintes artigos:

Problemas com o exemplo Invoke-WebRequest

Em algumas versões do Windows PowerShell, o exemplo Invoke-WebRequest nos tutoriais apresenta falha. Também foi recebido um relatório informando que a resposta continha uma lista de bytes não assinados que precisavam ser convertidos em caracteres. Se o exemplo Invoke-WebRequest não retornou o resultado esperado, tente enviar a solicitação usando outro aplicativo. A seguir, algumas sugestões:

  • Inicie o Cloud Shell e siga as etapas do Linux no tutorial que estava usando para enviar a solicitação.

  • Instale um aplicativo de terceiros, como a extensão do navegador Google Chrome Postman, oferecido por www.getpostman.com. Ao criar a solicitação no Postman:

    • Selecione POST como o verbo HTTP.
    • Para o cabeçalho, selecione a chave content-type e o valor application/json.
    • Para o corpo, digite: {"message":"hello world"}

    • No URL, use a chave de API real em vez da variável de ambiente. Exemplo:

      • No ambiente flexível do App Engine: https://example-project-12345.appspot.com/echo?key=AIza...
      • Em outros back-ends: http://192.0.2.0:80/echo?key=AIza...

  • Faça o download e instale o curl, que você executa no prompt de comando. Como o Windows não processa aspas duplas aninhadas entre aspas simples, é necessário alterar a opção --data no exemplo para: 

    --data "{\"message\":\"hello world\"}"