Resolução de problemas de erros de resposta

Esta página descreve como resolver problemas de erros que recebe numa resposta de um pedido à sua API.

BAD_GATEWAY

Se receber o código de erro 13 e a mensagem BAD_GATEWAY, isto indica que o proxy de serviço extensível (ESP) não consegue alcançar o back-end do serviço. Verifique o seguinte:

  • Certifique-se de que o serviço de back-end está em execução. A forma como o faz depende do back-end.

  • A porta do endereço IP correta do serviço de back-end está especificada:
    • Para o GKE, verifique o valor da flag --backend do ESP (a opção abreviada é -a) no ficheiro de manifesto de implementação (frequentemente denominado deployment.yaml).
    • Para o Compute Engine, verifique o valor da flag --backend ESP (a opção abreviada é -a) no comando docker run.

reset reason: connection failure

Se 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, isto indica que o ESPv2 não consegue aceder ao back-end do serviço.

Para resolver problemas, verifique novamente os itens abaixo.

Endereço de back-end

O ESPv2 deve ser configurado com o endereço do back-end correto. Os problemas comuns incluem:

  • O esquema do endereço de back-end deve corresponder ao tipo de aplicação de back-end. Os back-ends da OpenAPI devem ser http:// e os back-ends da gRPC devem ser grpc://.
  • Para o ESPv2 implementado no Cloud Run, o esquema do endereço de back-end deve ser https:// ou grpcs://. O elemento s indica ao ESPv2 para configurar o TLS com o back-end.

Procura de DNS

Por predefinição, o ESPv2 tenta resolver nomes de domínios para endereços IPv6. Se a resolução IPv6 falhar, o ESPv2 recorre a endereços IPv4.

Para algumas redes, o mecanismo de alternativa pode não funcionar como esperado. Em alternativa, pode forçar o ESPv2 a usar endereços IPv4 através da flag --backend_dns_lookup_family.

Este erro é comum se configurar um conetor de VPC sem servidor para o ESPv2 implementado no Cloud Run. As VPCs não suportam tráfego IPv6.

API is not enabled for the project

Se enviou uma chave da API no pedido, uma mensagem de erro como "A API my-api.endpoints.example-project-12345.cloud.goog não está ativada para o projeto" indica que a chave da API foi criada num projeto Google Cloud diferente do da API. Para corrigir este problema, pode criar a chave da API no Google Cloud mesmo Google Cloud projeto ao qual a API está associada ou ativar a API no Google Cloud projeto no qual a chave da API foi criada.

Service control request failed with HTTP response code 403

Se receber o código de erro 14 e a mensagem Service control request failed with HTTP response code 403, isto indica que a API Service Control (servicecontrol.googleapis.com) não está ativada no projeto.

  1. Consulte o artigo Verificar os serviços necessários para se certificar de que todos os serviços que o Endpoints e o ESP requerem estão ativados no seu projeto.

  2. Consulte o artigo Verificar autorizações necessárias para se certificar de que tem todas as autorizaçõ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 especifica uma chave da API na secção security do seu documento OpenAPI, mas o pedido à sua API não tem uma chave da API atribuída a um parâmetro de consulta denominado key.

Se precisar de gerar uma chave da API para fazer chamadas para a sua API, consulte o artigo Criar uma chave da 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 resolver problemas, compare a configuração do serviço que implementou para se certificar de que o nome do método e o caminho do URL que está a enviar no pedido correspondem:

  1. Na Google Cloud consola, aceda à página Serviços de pontos finais do seu projeto.

    Aceda à página Serviços de pontos finais

  2. Se tiver mais do que uma API, selecione a API para a qual enviou o pedido.

  3. Clique no separador Histórico de implementação.

  4. Selecione a implementação mais recente para ver a configuração do serviço.

Se não vir o método que está a chamar especificado na secção paths do seu documento OpenAPI, adicione o método ou a flag x-google-allow ao nível superior do ficheiro:

x-google-allow: all

Esta flag significa que pode evitar listar todos os métodos suportados no seu back-end no documento OpenAPI. Quando all é usado, todas as chamadas, com ou sem uma chave de API ou autenticação do utilizador, passam pelo ESP para a sua API. Consulte x-google-allow para mais informações.

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

Esta secção descreve as respostas de erro das APIs implementadas no ambiente flexível do App Engine.

Código de erro 502 ou 503

O App Engine pode demorar alguns minutos a responder com êxito aos pedidos. Se enviar um pedido e receber um HTTP 502, 503 ou algum outro erro do servidor, aguarde um minuto e tente novamente.

Mensagem de erro BAD_GATEWAY

Um código de erro 502 com BAD_GATEWAY na mensagem indica normalmente que o App Engine terminou a aplicação porque ficou sem memória. A VM flexível do App Engine predefinida só tem 1 GB de memória, com apenas 600 MB disponíveis para o contentor da aplicação.

Para resolver problemas do código de erro 502:

  1. Na Google Cloud consola, aceda à página Registo:

    Aceda à página do Explorador de registos

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

  3. Selecione Google App Engine Application e abra vm.syslog.

  4. Procure uma entrada de registo semelhante à seguinte:

    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 vir uma entrada Out of memory no registo:

    1. Adicione o seguinte ao ficheiro app.yaml para aumentar o tamanho da VM predefinida:

      resources:
  memory_gb: 4

    2. Volte a implementar a API:

      gcloud app deploy

Se tiver a opção rollout_strategy: managed especificada na secção endpoints_api_service do ficheiro app.yaml, use o seguinte comando para voltar a implementar a sua API:

  gcloud app deploy

Consulte o artigo Implementar a sua API e ESP para mais informações.

Verificar os registos do Cloud Logging

Para usar os registos do Cloud Logging para ajudar a resolver problemas de erros de resposta:

  1. Na Google Cloud consola, aceda à página Registo.

    Aceda à página do Explorador de registos

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

  3. No menu pendente do lado esquerdo, selecione API produzida > [YOUR_SERVICE_NAME].

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

  5. Expanda o payload JSON e procure error_cause.

    • Se o valor error_cause estiver definido como application, isto indica um problema no seu código.

    • Se o error cause for qualquer outra coisa e não conseguir corrigir o problema, exporte o registo e inclua-o em qualquer comunicação que tenha com a Google.

Consulte o seguinte para mais informações:

Problemas com o exemplo Invoke-WebRequest

Em algumas versões do Windows PowerShell, o exemplo Invoke-WebRequest nos tutoriais falha. Também recebemos uma denúncia de que a resposta continha uma lista de bytes não assinados que tiveram de ser convertidos em carateres. Se o exemplo Invoke-WebRequest não devolveu o resultado esperado, experimente enviar o pedido com outra aplicação. Seguem-se algumas sugestões:

  • Inicie o Cloud Shell e siga os passos do Linux no tutorial que estava a usar para enviar o pedido.

  • Instale uma aplicação de terceiros, como a extensão do navegador Chrome Postman (oferecida por www.getpostman.com). Quando criar o pedido no Postman:

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

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

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

  • Transfira e instale o curl, que executa na linha de comandos. Uma vez que o Windows não processa as aspas duplas aninhadas dentro de aspas simples, tem de alterar a opção no exemplo para:--data

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