Neste documento, você verá algumas dicas comuns de solução de problemas durante a publicação de mensagens em um tópico padrão do Pub/Sub.
Saiba mais sobre como Publicar mensagens em tópicos e conheça os diferentes recursos.
Alta latência de publicação
A latência de publicação é o tempo necessário para concluir uma solicitação de publicação emitida por um cliente editor. A latência de publicação é diferente da latência de entrega de ponta a ponta, que é o tempo necessário para que uma mensagem publicada no Pub/Sub seja entregue a um cliente assinante. Talvez você note uma alta latência de publicação ou latência de ponta a ponta, mesmo quando o valor do outro tipo de latência for baixo. Pode haver alta latência de publicação 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. Use a métrica topic/send_request_latencies para inspecionar a latência de publicação incorrida no back-end do Pub/Sub. A alta latência de publicação de back-end pode estar relacionada aos seguintes fatores:
O Pub/Sub foi projetado para entrega de baixa latência e alta capacidade. Se o tópico tiver baixa capacidade, 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 para o tópico e a assinatura. Verifique as implicações de desempenho e disponibilidade do uso dessa configuração.
Se o cliente editor observar uma latência de publicação significativamente maior do que a indicada na métrica, pode ser um sinal de um destes fatores no lado do cliente:
Não crie um novo editor para cada publicação. Recomendamos usar um único cliente editor por tópico por aplicativo para publicar todas as mensagens. Ativar novos objetos de editor e adicionar novas linhas de execução tem um custo de latência. Se você estiver usando o Cloud Functions para publicar mensagens, 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 correspondentes. No entanto, verifique se os novos valores não são muito altos. Veja como configurar a opção Solicitações de repetição.
A alta latência de publicação pode levar a erros DEADLINE_EXCEEDED, que serã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 dentro do tempo alocado. Isso pode ocorrer por vários fatores, como as solicitações que não chegam ao serviço do Pub/Sub ou problemas de desempenho que as afetam.
Para verificar se as solicitações de publicação estão chegando ao serviço 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, um fator externo impede 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. Se a taxa de erro for muito baixa, pode ser um problema intermitente.
Se as solicitações estiverem chegando ao Pub/Sub, estas são algumas das possíveis causas de falhas nas operações de publicação com um erro DEADLINE_EXCEEDED:
Gargalo 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 da rede na VM que hospeda o cliente do editor. Se uma chamada Publish retornar DEADLINE_EXCEEDED, talvez 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 acompanhar o número de mensagens que aguardam o envio, armazene o número de mensagens a serem enviadas com cada chamadaPublishe o exclua apenas 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 normalmente têm largura de banda de 1 a 10 MB/s, ou 1.000 a 10.000 mensagens típicas por segundo. A publicação de mensagens em loop sem limitação de taxa pode criar um breve 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 de publicação das mensagens para que ela corresponda à largura de banda disponível.
Verifique se há uma latência muito alta entre o host e o Google Cloud por algum dos motivos, como congestionamento da rede na inicialização ou firewalls. O cálculo da capacidade de rede tem ponteiros para descobrir a largura de banda e a latência em diferentes cenários.
Por fim, há limites para a quantidade de dados que uma única máquina pode publicar. Talvez seja necessário fazer o escalonamento horizontal ou executar várias instâncias do cliente do editor em diversas máquinas. Como testar clientes do Cloud Pub/Sub para maximizar o desempenho de streaming demonstra como o Pub/Sub é escalonado em uma única VM do Google Cloud com um número crescente de CPUs. Por exemplo, é possível atingir de 500 MB/s a 700 MB/s para mensagens de 1 KB em uma instância de 16 núcleos do Compute Engine.
Duração do tempo limite de publicação inadequada
Para reduzir o tempo limite das chamadas de publicação, defina um tempo limite longo o suficiente nas configurações de nova tentativa do cliente do editor. Nas 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 um grande backlog de mensagens não enviadas, picos ocasionais na latência da solicitação podem fazer com que as chamadas de publicação atinjam o tempo limite. No entanto, se os problemas forem causados por um gargalo permanente, em vez de tempos limite esporádicos, novas tentativas podem gerar 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 Issue Trackers de todas as bibliotecas de cliente. Se você encontrar um problema conhecido que afeta a versão da biblioteca de cliente que está usando, faça upgrade para a versão mais recente. Isso garante que você recebeu todas as atualizações relevantes, incluindo correções e melhorias de desempenho.
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Problemas de esquema
Se as publicações começarem a retornar INVALID_ARGUMENT, é possível que alguém tenha atualizado o tópico para alterar o esquema associado, excluído o esquema ou excluído as revisões de 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 de criptografia de mensagens
Se você tiver configurado seu tópico do Pub/Sub para criptografar mensagens publicadas usando uma chave de criptografia gerenciada pelo cliente, a publicação poderá falhar com um erro FAILED_PRECONDITION. Esse erro poderá 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.