Este documento fornece algumas dicas de solução de problemas comuns para assinaturas de pull do Pub/Sub. Leia mais sobre assinaturas de pull no Guia do assinante de pull.
Para monitorar efetivamente sua assinatura do Pub/Sub, recomendamos que você consulte primeiro a pontuação de integridade da latência de entrega (subscription/delivery_latency_health_score) para verificar quais fatores podem contribuir para uma latência inesperada ou aumentada.
O tempo de mensagem não confirmada mais antiga continua aumentando
O oldest_unacked_message_age é uma métrica essencial para monitorar a integridade das assinaturas do Pub/Sub. Ela mede a idade, em segundos, da mensagem mais antiga no backlog de uma assinatura que ainda não foi confirmada (confirmada) por um assinante. Essa métrica oferece insights valiosos sobre possíveis atrasos ou gargalos de processamento.
O monitoramento do backlog de mensagens garante o processamento de mensagens oportuno e eficiente. Ao monitorar a idade da mensagem não confirmada mais antiga, você pode identificar proativamente situações em que os consumidores estão ficando para trás. Essa prática permite uma intervenção precoce para resolver possíveis problemas relacionados a uma performance prejudicada.
Alguns dos problemas comuns de backlog que você pode investigar incluem:
Problemas de configuração do cliente
Quando as métricas oldest_unacked_message_age e num_undelivered_messages aumentam simultaneamente, isso pode significar que os assinantes não estão acompanhando o volume de mensagens. Nessa situação, concentre sua investigação nos componentes do assinante:
Integridade do cliente: analise a utilização de recursos em máquinas que hospedam clientes assinantes, como CPU, memória e largura de banda da rede. Procure pontos de pressão que possam impedir a eficiência do processamento.
Código do cliente: revise as alterações recentes no código e examine os registros de erros. Bugs ou ineficiências no código do assinante podem afetar significativamente as taxas de processamento de mensagens. Pode haver problemas em mensagens específicas. Por exemplo, várias mensagens podem precisar acessar a mesma linha em um banco de dados simultaneamente. Esse comportamento pode levar a contenções e alta latência.
Limitações de cota: verifique se você não excedeu as cotas ou limitações do Pub/Sub impostas pelo seu serviço de hospedagem. Se os assinantes estiverem hospedados no Google Cloud, analise as cotas de recursos do Compute Engine ou do GKE para evitar gargalos.
O assinante reconheceu as mensagens negativamente
Quando um assinante confirma negativamente uma mensagem, ele sinaliza ao Pub/Sub que a mensagem não foi processada. Em seguida, o Pub/Sub tenta reenviar a mesma mensagem. A repetição de uma mensagem gera duplicatas e pode resultar em um grande atraso na entrega da mensagem.
A inclusão de uma mensagem não garante que o próximo pull busque outra mensagem. A política de reenvio do Pub/Sub pode continuar reenviando mensagens não entregues antes de novas. Portanto, não confie nos NACKs como método de filtragem ou para pular mensagens específicas. Em vez disso, defina uma política de nova tentativa, de preferência uma espera exponencial, como uma forma de recuar mensagens individuais que provavelmente serão processadas mais tarde, mas precisam de um pouco mais de tempo para o reenvio.
Se você precisar pular intencionalmente certas mensagens, a abordagem recomendada é confirmá-las, mesmo que não as processe. Isso os remove da assinatura, evita reenvios desnecessários e reduz o consumo de recursos. Deixar mensagens não confirmadas, intencionalmente ou não, cria problemas de backlog e duplica entregas.
Alta latência de entrega
A latência de entrega no Pub/Sub é o tempo que uma mensagem de um editor leva para chegar a um assinante. Algumas possíveis causas de uma alta latência de entrega são descritas nas próximas seções.
Não há inscritos suficientes
Para clientes que usam o StreamingPull, mantenha várias conexões StreamingPull abertas com sua assinatura para ter uma latência consistentemente baixa. Sem conexões de assinante ativas, o Pub/Sub não pode entregar mensagens de imediato. Um único stream pode ser um ponto único de falha, aumentando o risco de atrasos. A métrica subscription/open_streaming_pulls fornece visibilidade sobre o número de conexões de streaming ativas. Use esse recurso para garantir que você tenha streams suficientes para processar as mensagens recebidas.
Para clientes que usam pull unário, para alcançar uma latência consistentemente baixa, mantenha várias solicitações de pull pendentes na sua assinatura. Solicitações não frequentes podem acumular mensagens no backlog e aumentar a latência. Essa abordagem ajuda a minimizar lacunas na conectividade e melhorar a latência de entrega.
A biblioteca de cliente de alto nível é recomendada para casos em que você precisa de alta capacidade de processamento e baixa latência com o mínimo de sobrecarga operacional e custo de processamento. Por padrão, a biblioteca de cliente de alto nível usa a API StreamingPull, já que ela tende a ser a melhor escolha para minimizar a latência. As bibliotecas de cliente de alto nível contêm funções e classes predefinidas que lidam com as chamadas de API subjacentes para autenticação, otimização da capacidade de processamento e latência, formatação de mensagens e outros recursos.
Problemas de configuração do cliente
Consulte Problemas de configuração do cliente.
Backlog alto
Observe que um backlog de mensagens não confirmadas em uma assinatura do Pub/Sub aumenta inerentemente a latência de ponta a ponta, porque as mensagens não são processadas imediatamente pelos assinantes.
Pedidos de chaves e entrega única
O pedido de chaves e o envio único são recursos valiosos, mas exigem coordenação adicional no Pub/Sub para garantir a entrega correta. Essa coordenação pode reduzir a disponibilidade e aumentar a latência. Embora a diferença seja mínima no estado estável, qualquer etapa de coordenação necessária pode resultar em aumentos temporários na latência ou em uma taxa de erros maior. Se a ordenação estiver ativada, as mensagens com uma chave de ordem não poderão ser entregues até que as anteriores com a mesma chave de ordem sejam reconhecidas.
Considere se a ordem das mensagens ou a entrega exatamente uma vez são absolutamente essenciais para seu aplicativo. Se a baixa latência for sua prioridade, minimizar o uso desses recursos poderá ajudar a reduzir os atrasos no processamento de mensagens.
de aumento no tamanho da mensagem
Um aumento repentino no tamanho da mensagem pode aumentar o tempo de transferência entre o Pub/Sub e seu cliente, além de atrasar o tempo de processamento das mensagens no lado do cliente.
Caso você note um aumento na latência de entrega, verifique o tamanho das mensagens usando a métrica topic/message_sizes, agrupando por topic_id. Relacione os picos no tamanho das mensagens com os problemas de desempenho observados.
Mensagens ausentes
Se você suspeita que as mensagens não estão sendo entregues ao assinante, um dos motivos a seguir pode ser o fator contribuinte.
Distribuição de mensagens em assinaturas do Pub/Sub com vários consumidores
No Pub/Sub, as mensagens podem ser distribuídas de maneira desigual entre os consumidores. Esse comportamento ocorre porque o Pub/Sub distribui mensagens entre consumidores ativos para aumentar a eficiência. Às vezes, um único consumidor pode receber menos mensagens do que o esperado ou um subconjunto diferente de mensagens do que outros consumidores.
Observe que as mensagens podem estar pendentes para os clientes, e um backlog de mensagens não confirmadas não significa necessariamente que você receberá essas mensagens em sua próxima solicitação de envio. Um consumidor pode ser alguém usando pull no console do Google Cloud ou na Google Cloud CLI ou executando um assinante personalizado localmente para verificar mensagens.
Para clientes Pull unários, talvez algumas solicitações pull não retornem mensagens. Conforme discutido na seção não há inscritos suficientes, é recomendável manter várias solicitações de envio pendentes, já que algumas podem retornar menos do que o número máximo de mensagens configuradas ou até mesmo nenhuma mensagem.
Se você suspeitar de algum desses comportamentos, investigue se há vários consumidores conectados simultaneamente à assinatura e inspecione-os.
Filtrar a assinatura
Verifique se a assinatura tem um filtro anexado a ela. Nesse caso, você só recebe as mensagens que correspondem ao filtro. O serviço Pub/Sub reconhece automaticamente as mensagens que não correspondem ao filtro. Considere como os filtros afetam as métricas do backlog.
Usando a opção returnImmediately
Se o cliente estiver usando Pull unário, verifique se o campo returnImmediately está definido como "true". Este é um campo descontinuado que diz ao serviço Pub/Sub para responder à solicitação de envio imediatamente, mesmo que ela retorne sem mensagens. Isso pode fazer com que as solicitações de envio retornem 0 mensagens, mesmo quando há um backlog.
Como lidar com duplicatas
A duplicação de mensagens no Pub/Sub geralmente ocorre quando os assinantes não conseguem confirmar as mensagens dentro do prazo de confirmação. Isso faz com que as mensagens sejam entregues novamente, criando a impressão de duplicatas. É possível medir a taxa em que os assinantes perdem o prazo de confirmação usando a métrica subscription/expired_ack_deadlines_count. Saiba mais sobre como monitorar a expiração do prazo de confirmação.
Para reduzir a taxa de duplicação, prolongue os prazos das mensagens.
- As bibliotecas de cliente lidam com a extensão do prazo automaticamente, mas há limites padrão no prazo máximo de extensão que você pode configurar.
- Se você estiver criando sua própria biblioteca de cliente, use o método
modifyAckDeadlinepara estender o prazo de confirmação.
Se as mensagens forem enviadas ao assinante mais rapidamente do que podem ser processadas e confirmadas, algumas podem expirar e exigir prorrogações de prazo. No entanto, se o assinante permanecer sobrecarregado, as extensões de prazo repetidas acabarão falhando. Na pior das hipóteses, isso pode fazer com que os assinantes lotem as cópias, agravando o backlog. Duplicações prestes a expirar, em seguida, gerar novas cópias.
Para evitar sobrecarregar o assinante, reduza o número de mensagens que ele recebe por pull. Dessa forma, o assinante tem menos mensagens para processar dentro do prazo. Menos mensagens expiram e menos são reenviadas.
Para reduzir o número de mensagens que o assinante extrai por vez, é preciso reduzir o número máximo de mensagens pendentes na configuração de controle de fluxo do assinante. Não existe um valor único. Por isso, é preciso ajustar o limite máximo de mensagens pendentes com base na sua transferência e na capacidade do assinante. Considere que cada aplicativo processa mensagens de forma diferente e leva um tempo diferente para confirmar uma mensagem.
Como forçar novas tentativas
Para forçar o Pub/Sub a repetir uma mensagem, envie uma solicitação nack. Se você não estiver usando as bibliotecas de cliente de alto nível, envie uma solicitação modifyAckDeadline com um ackDeadlineSeconds definido como 0.
Ordenar chaves
Quando o Pub/Sub reenvia uma mensagem com uma chave de ordem, ele também reenvia todas as mensagens subsequentes com a mesma chave de ordem, mesmo que elas tenham sido confirmadas anteriormente. Isso é feito para preservar a ordem da sequência. No entanto, não há garantia estrita de que as mensagens dependentes só serão enviadas após a confirmação bem-sucedida de mensagens anteriores na sequência.
O assinante está acompanhando as mensagens
Consulte o assinante está preenchendo as mensagens.
Solução de problemas de uma assinatura do StreamingPull
Os streams do StreamingPull sempre fecham com um status não OK. Ao contrário de um status de erro para RPCs unários, esse status para StreamingPull é apenas uma indicação de que o stream está desconectado. As solicitações não estão falhando. Portanto, embora a API StreamingPull tenha uma taxa de erro surpreendente de 100%, esse comportamento é projetado.
Como os streams do StreamingPull sempre são fechados com um erro, não é útil
examinar as métricas de encerramento de stream ao diagnosticar erros. Em vez disso, concentre-se
na métrica de resposta do StreamingPull
subscription/streaming_pull_response_count,
agrupada por response_code ou response_class.
Procure por estes erros:
Erros de pré-condição com falha podem ocorrer se houver mensagens no backlog da assinatura criptografadas com uma chave desativada do Cloud KMS. Para retomar a extração, restaure o acesso à chave.
Erros indisponíveis podem ocorrer quando o Pub/Sub não consegue processar uma solicitação. Provavelmente, essa é uma condição temporária, e a biblioteca de cliente tenta realizar as solicitações novamente. Se você estiver usando uma biblioteca de cliente, nenhuma ação será necessária.
Os erros "Não encontrado" podem ocorrer quando a assinatura é excluída ou se nunca existiu. O último caso acontece quando você fornece um caminho de assinatura inválido.