Este documento oferece algumas dicas comuns de solução de problemas ao publicar mensagens em um tópico padrão do Pub/Sub.
Saiba como publicar mensagens em tópicos e os diferentes recursos.
Latência de publicação alta
A latência de publicação é o tempo que leva para concluir uma solicitação de publicação emitida por um cliente do editor. A latência de publicação é diferente da latência de entrega de ponta a ponta, que é o tempo que uma mensagem publicada no Pub/Sub leva para ser entregue a um cliente assinante. Você pode observar latência de publicação ou de ponta a ponta alta, mesmo quando o valor do outro tipo de latência é baixo. A alta latência de publicação pode ocorrer no cliente do editor do Pub/Sub, em trânsito entre o cliente e o back-end do Pub/Sub ou no back-end do Pub/Sub. É possível inspecionar a latência de publicação incorrida no back-end do Pub/Sub usando a métrica topic/send_request_latencies. Uma alta latência de publicação do back-end pode estar relacionada aos seguintes fatores:
O Pub/Sub foi projetado para entrega de baixa latência e alta capacidade de processamento. Se o tópico tiver baixa capacidade de processamento, os recursos associados a ele poderão levar mais tempo para serem inicializados.
Se você estiver usando uma política de armazenamento de mensagens, ela poderá afetar a latência geral das solicitações ao tópico e à assinatura. Confira as consequências de desempenho e disponibilidade do uso dessa configuração.
Se o cliente do editor estiver observando uma latência de publicação significativamente maior do que a refletida na métrica, isso pode ser um sinal de um destes fatores do lado do cliente:
Não crie um editor novo para cada publicação. É recomendável usar um único cliente de editor por tópico e aplicativo para publicar todas as mensagens. A criação de novos objetos de editor e a adição de novas linhas de execução têm um custo de latência. Se você estiver usando funções do Cloud Run para publicar mensagens, saiba que as invocações também podem afetar a latência de publicação.
Se você achar que as configurações padrão de nova tentativa não são suficientes para seu caso de uso, faça os ajustes necessários. No entanto, verifique se os novos valores não são muito altos. Saiba como configurar as solicitações de nova tentativa.
Uma alta latência de publicação pode levar a erros DEADLINE_EXCEEDED, que são discutidos na próxima seção.
As operações de publicação falham com DEADLINE_EXCEEDED
Um erro DEADLINE_EXCEEDED durante uma solicitação de publicação indica que a solicitação não foi concluída no tempo alocado. Isso pode acontecer por vários motivos, como as solicitações não alcançarem o serviço do Pub/Sub ou problemas de desempenho que afetam as solicitações.
Para verificar se as solicitações de publicação estão chegando ao serviço do Pub/Sub, monitore o tópico usando a métrica topic/send_request_count, agrupada por response_code. Essa métrica ajuda a determinar se as solicitações falham antes de chegar ao tópico do Pub/Sub. Se a métrica estiver vazia, há um fator externo impedindo que as mensagens cheguem ao serviço do Pub/Sub. Além disso, para descartar a possibilidade de um problema intermitente, verifique a taxa de erros usando o gráfico de métricas topic/send_request_count mencionado anteriormente ou a página APIs e serviços no console Google Cloud . Se a taxa de erro for muito baixa, pode ser um problema intermitente.
Se as solicitações estiverem chegando ao Pub/Sub, confira algumas causas possíveis de falhas nas operações de publicação com um erro DEADLINE_EXCEEDED:
Engasta do lado do cliente
As falhas de publicação provavelmente são causadas por um gargalo do lado do cliente, como memória insuficiente, pressão da CPU, integridade da linha de execução ruim ou congestionamento de rede na VM que hospeda o cliente do editor. Se uma chamada Publish retornar DEADLINE_EXCEEDED, pode ser que as chamadas Publish assíncronas estejam sendo enfileiradas mais rapidamente do que são enviadas ao serviço, o que aumenta progressivamente a latência da solicitação. Além disso, verifique se alguma das opções a seguir ajuda a determinar um possível gargalo no sistema:
Verifique se você está publicando mensagens mais rapidamente do que o cliente pode enviá-las. Normalmente, cada chamada
Publishassíncrona retorna um objetoFuture. Para rastrear o número de mensagens que estão aguardando o envio, armazene o número de mensagens a serem enviadas com cada chamadaPublishe exclua-as somente no callback do objetoFuture.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. As redes Wi-Fi de desenvolvimento geralmente têm largura de banda de 1 a 10 MBps ou 1.000 a 10.000 mensagens típicas por segundo. Publicar mensagens em um loop sem limitação de taxa pode criar um pequeno burst de alta largura de banda em um curto período. Para evitar isso, execute o editor em uma máquina no Google Cloud ou reduza a taxa em que as mensagens são publicadas para corresponder à largura de banda disponível.
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. Como calcular a capacidade da rede tem orientações para descobrir sua largura de banda e latência para diferentes cenários.
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 única VM do Google Cloud com um número cada vez maior de CPUs. Por exemplo, é possível atingir 500 MBps a 700 MBps para mensagens de 1 KB em uma instância do Compute Engine de 16 núcleos.
Tempo limite de publicação inadequado
Para reduzir a taxa de tempo limite das chamadas de publicação, verifique se você tem um tempo limite longo o suficiente definido nas configurações de repetição do cliente do editor. Para as configurações de nova tentativa, defina o prazo inicial como 10 segundos e o tempo limite total como 600 segundos. Mesmo que você não esteja acumulando uma grande lista de mensagens não enviadas, picos ocasionais na latência da solicitação podem fazer com que as chamadas de publicação tenham um tempo limite. No entanto, se os problemas forem causados por um gargalo persistente, em vez de tempos limite ocasionais, tentar novamente mais vezes poderá resultar em mais erros.
Problemas com a biblioteca de cliente
Você pode estar executando uma versão da biblioteca de cliente com um problema conhecido. A lista a seguir inclui os rastreadores de problemas de todas as bibliotecas de cliente. Se você encontrar um problema conhecido que afete a versão da biblioteca de cliente que está usando, faça upgrade para a versão mais recente. Isso garante que você tenha recebido todas as atualizações relevantes, incluindo correções e melhorias de desempenho.
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Problemas com o esquema
Se as publicações começarem a retornar INVALID_ARGUMENT, é possível que alguém tenha atualizado o tópico para mudar o esquema associado, excluído o esquema ou excluído as revisões do esquema associadas ao tópico. Nesse caso, atualize as configurações do esquema do tópico para um esquema e um conjunto de revisões que correspondam às mensagens publicadas ou ajuste o formato da mensagem para corresponder ao esquema atual.
Problemas com a criptografia de mensagens
Se você configurou o tópico do Pub/Sub para criptografar as mensagens publicadas usando uma chave de criptografia gerenciada pelo cliente, a publicação pode falhar com um erro FAILED_PRECONDITION. Esse erro pode ocorrer se a chave do Cloud KMS estiver desativada ou se as chaves gerenciadas externamente pelo Cloud EKM não estiverem mais acessíveis. Para retomar a publicação, restaure o acesso à chave.