Neste documento, fornecemos algumas dicas de solução de problemas comuns ao publicar mensagens em um tópico padrão do Pub/Sub.
Saiba mais sobre como Publicar mensagens em tópicos e 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 que uma mensagem publicada no Pub/Sub leva para ser entregue a um cliente assinante. Talvez você observe alta latência de publicação ou latência de ponta a ponta, mesmo quando o valor do outro tipo de latência é baixo. A alta latência de publicação pode ocorrer no cliente 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 no 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 estiver observando uma latência de publicação significativamente maior do que a refletida na métrica, pode ser um sinal de um destes fatores:
Não crie um novo editor para cada publicação. Recomendamos usar um único cliente editor por tópico e por aplicativo para publicar todas as mensagens. A ativação de novos objetos do editor e a adição de novas linhas de execução têm um custo de latência. Se você estiver usando o Cloud Functions 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 correspondentes. No entanto, verifique se os novos valores não são muito altos. Veja como configurar Repetir solicitações.
A alta latência de publicação pode resultar em 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 ela não foi concluída no tempo alocado. Isso pode ocorrer devido a vários fatores, como 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, 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 erro. Se a taxa de erro for muito baixa, isso pode ser um problema intermitente.
Se as solicitações estiverem chegando ao Pub/Sub, estas são algumas das possíveis causas de falha 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 afunilamento do lado do cliente, como memória insuficiente, pressão da CPU, integridade ruim da linha de execução ou congestionamento da 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 enviadas ao serviço, o que aumenta progressivamente a latência da solicitação. Além disso, verifique se alguma das seguintes opções 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 aguardando envio, armazene esse número em cada chamadaPublishe exclua-o 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 de 1.000 a 10.000 mensagens típicas por segundo. A publicação de mensagens em loop sem qualquer limitação de taxa pode criar um burst rápido 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 correspondam à largura de banda disponível.
Verifique se a latência entre o host e o Google Cloud é muito alta por um dos motivos, como congestionamento da rede na inicialização ou firewalls. O cálculo da capacidade da rede aponta para a descoberta da largura de banda e da 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 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 cada vez maior 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 inadequada do tempo limite de publicação
Para reduzir a taxa de tempo limite das chamadas de publicação, defina um tempo limite suficiente nas configurações de repetição 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 acumule 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 persistente, em vez de tempos limite ocasionais, tentar mais vezes pode causar mais erros.
Problemas com a biblioteca de cliente
Talvez você esteja 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 afeta a versão da biblioteca de cliente que está usando, faça upgrade para a versão mais recente dela. 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 com o 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 de esquema do tópico para um esquema e um conjunto de revisões que correspondam às mensagens que estão sendo publicadas ou ajuste o formato da mensagem para corresponder ao esquema atual.
Problemas de criptografia de mensagens
Se você tiver configurado o 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.