Solução de problemas

Saiba mais sobre as etapas de solução de problemas que podem ser úteis ao usar o Pub/Sub.

Não é possível criar uma assinatura

Verifique se você realizou estas ações:

  • Especificou um nome para a assinatura no campo name. Para as versões v1beta2 e posteriores, o nome da assinatura precisa ter o seguinte formato: projects/project-identifier/subscriptions/subscription-name.
  • Especificou no campo topic o nome de um tópico atual que você quer assinar. Para as versões v1beta2 e posteriores, o nome do tópico precisa ter o seguinte formato: projects/project-identifier/topics/topic-name.
  • Especificou https:// no campo pushEndpoint como o protocolo para o URL de recebimento em letras minúsculas, não http:// ou HTTPS://.

Assinante de push não recebe mensagens

Faça estas verificações:

  • Procure no Cloud Monitoring se há algum erro relacionado à assinatura em questão.
  • No App Engine, recomenda-se o uso do prefixo /_ah/push-handlers/ no caminho do URL dos endpoints, conforme descrito em Como registrar endpoints do App Engine. Esse código permite que o endpoint receba mensagens de push da API Pub/Sub.
  • Em outros ambientes, certifique-se de que o URL do seu endpoint possa ser acessado da Internet sem a necessidade de um login. Para verificar se o URL não é restrito, acesse-o com uma ferramenta de diagnóstico, como cURL.
  • Para domínios que não sejam appspot.com, registre o domínio no Console do Google Cloud. Consulte Como registrar outros endpoints para mais detalhes.

A entrega de mensagens por push está com horas de atraso

Uma mensagem de push não confirmada pode atrasar a entrega de novas mensagens. Uma mensagem é considerada não confirmada se o endpoint de push falhar ou retornar um código de status diferente de 200, 201, 202, 204 ou 102. Para se livrar do atraso, atualize o código do endpoint para processar as mensagens que falham ou solicite-as manualmente e, em seguida, confirme-as. Consulte a Visão geral do Monitoring para mais informações sobre como detectar mensagens não confirmadas e criar alertas.

Erro 403 (Forbidden)

Se você receber esse erro, faça o seguinte:

  • Verifique se você ativou a API Pub/Sub no Console do Cloud.
  • Confira se quem fez a solicitação tem as permissões necessárias para os recursos relevantes da API Pub/Sub, especialmente se ela estiver sendo usada para a comunicação entre projetos.
  • Se você usa o Cloud Dataflow, certifique-se de que o <projectId>@cloudservices.gserviceaccount.com e a conta de serviço do Compute Engine <projectId>-compute@developer.gserviceaccount.com tenham as permissões necessárias no recurso da API Pub/Sub correspondente. Consulte Segurança e permissões do Dataflow para mais informações.
  • Se você está usando o App Engine, verifique a página Permissões do seu projeto para ver se uma conta de serviço do App Engine está listada como um Editor. Se não houver, adicione sua conta de serviço do App Engine como Editor. Normalmente, a conta de serviço do App Engine está no formato <project-id>@appspot.gserviceaccount.com.

Como lidar com duplicatas e forçar novas tentativas

Quando você não confirma uma mensagem antes do vencimento do prazo de confirmação, o Pub/Sub reenvia a mensagem. Como resultado, o Pub/Sub pode enviar mensagens duplicadas. Use o pacote de operações do Google Cloud para monitorar as operações de confirmação com o código de resposta expired para detectar essa condição. Para conseguir esses dados, selecione a métrica Confirmar operações de mensagens e agrupe ou filtre pelo rótulo response_code. Observe que response_code é um rótulo do sistema em uma métrica. Ele não é uma métrica.

Use o Stackdriver para pesquisar prazos de confirmação de mensagens vencidos

Para reduzir a taxa de duplicação, prolongue o prazo da mensagem.

  • As bibliotecas de cliente prolongam o prazo automaticamente, mas há limites padrão de quanto o prazo pode ser prolongado.
  • Use o método modifyAckDeadline para estender o prazo de confirmação se você estiver criando sua própria biblioteca de cliente.

Como alternativa, para forçar o Pub/Suba repetir uma mensagem, defina modifyAckDeadline para 0.

As operações de publicação falham com DEADLINE_EXCEEDED

Isso provavelmente é causado por um gargalo do lado do cliente, como CPUs de serviço insuficientes, integridade da linha de execução ruim ou congestionamento da rede. Se uma chamada Publish retorna DEADLINE_EXCEEDED, chamadas Publish assíncronas estão sendo enfileiradas mais rapidamente do que são enviadas ao serviço, o que aumenta progressivamente a latência da solicitação. Para determinar a capacidade de Publish com uma única VM para parâmetros diferentes (núcleos, workers, tamanho da mensagem), consulte Como testar clientes do Cloud Pub/Sub para maximizar o desempenho do streaming. Por outro lado, pode ser que você esteja executando uma versão da biblioteca de cliente com um problema conhecido. Verifique o rastreador de problemas da sua biblioteca de cliente na lista.

Por fim, você pode definir um prazo menor que o desempenho típico de latência de publicação do Pub/Sub. O recomendado é definir o prazo inicial como 10 segundos e o tempo limite total como 600 segundos.

Verifique se alguma das opções a seguir ajuda:

  • Verifique se você está publicando mensagens mais rapidamente do que o cliente pode enviá-las. Normalmente, cada chamada Publish assíncrona retorna um objeto Future. Para rastrear o número de mensagens que estão aguardando o envio, armazene o número de mensagens a serem enviadas com esta chamada de publicação e exclua-as somente no retorno de chamada do objeto Future. Quando você faz chamadas Publish mais rápido do que as solicitações correspondentes ao serviço Pub/Sub podem ser concluídas, a latência para uma chamada Publish individual feita posteriormente aumentará drasticamente.
  • Verifique se você tem largura de banda de upload suficiente entre a máquina em que o editor está sendo executado e o Google Cloud. É comum que redes Wi-Fi usadas para desenvolvimento tenham largura de banda de 1 a 10 MB/s ou de 1.000 a 10.000 mensagens típicas por segundo. Publicar essas mensagens em um loop, sem qualquer limitação de taxa, pode criar um pequeno burst de alta largura de banda em um curto período. Você pode obter mais largura de banda executando o editor em uma máquina no GCP ou reduzindo a taxa em que as mensagens são publicadas para corresponder à largura de banda disponível.
  • Verifique se você tem um tempo limite suficiente para a chamada definida nas configurações de repetição. Haverá casos em que os picos na latência da solicitação levarão a erros, mesmo se você não estiver acumulando uma grande backlog de mensagens não enviadas. Aumentar o prazo inicial para 10 segundos e o tempo limite total para 600 segundos leva a uma queda na taxa de tempo limite. Se os problemas forem causados por um gargalo persistente, em vez de tempos limite ocasionais, tentar novamente mais vezes resultará em mais erros.
  • Verifique se há latência muito alta entre o host e o Google Cloud por algum motivo, como congestionamento da rede de inicialização ou firewalls. O cálculo da capacidade de rede tem ponteiros para descobrir sua largura de banda e latência para diferentes cenários.
  • Faça upgrade para a versão mais recente da biblioteca de cliente. Verifique se você recebeu atualizações relevantes que podem incluir correções, como melhorias no desempenho.
  • Verifique se a VM que hospeda o cliente do editor está ficando sem recursos, incluindo CPU, RAM e linhas de execução. Pode ser que a chamada esteja aguardando muito tempo para ser agendada antes de realmente fazer uma solicitação ao serviço.
  • Por fim, há limites para a quantidade de dados que uma única máquina pode publicar. Talvez seja necessário tentar escalonar horizontalmente ou executar várias instâncias do cliente do editor em várias máquinas. O teste de clientes do Cloud Pub/Sub para maximizar o desempenho do streaming demonstra como o Pub/Sub é escalonado em uma VM do Google Cloud com um número cada vez maior de CPUs. Por exemplo, é possível atingir 500 MB/s a 700 MB/s para mensagens de 1 KB em uma instância do Compute Engine de 16 núcleos.

Operações administrativas excessivas

Se você perceber que está gastando muito da cota de operações administrativas, talvez seja necessário refatorar o código. Para ilustrar, considere este pseudo-código. Neste exemplo, uma operação administrativa (GET) está sendo usada para verificar a presença de uma assinatura antes de tentar consumir os recursos dela. As operações GET e CREATE são do administrador:


    if !GetSubscription my-sub {
     CreateSubscription my-sub
    }
    Consume from subscription my-sub
            

Um padrão mais eficiente é tentar consumir mensagens da assinatura (supondo que você esteja razoavelmente seguro do nome da assinatura). Nesse caso, você só recebe ou cria a assinatura em caso de erro. Veja este exemplo:

    try {
      Consume from subscription my-sub
    } catch NotFoundError {
      CreateSubscription my-sub
      Consume from subscription my-sub
    }