Neste documento, fornecemos algumas dicas de solução de problemas comuns para assinaturas de pull do Pub/Sub. Leia mais sobre assinaturas de pull no guia de assinantes de pull.
Para monitorar com eficiência sua assinatura do Pub/Sub, recomendamos primeiro analisar a pontuação de integridade da latência de entrega (subscription/delivery_latency_health_score) e verificar quais fatores podem contribuir para um aumento ou aumento da latência inesperada.
O tempo para mensagens não confirmadas mais antigas 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 das mensagens garante um processamento de mensagens rápido e eficiente. Ao acompanhar a idade da mensagem mais antiga não confirmada, você pode identificar proativamente situações em que os consumidores estão ficando para trás. Essa prática permite intervenções antecipadas para resolver possíveis problemas relacionados à queda no desempenho.
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, é possível que os assinantes não estejam acompanhando o volume de mensagens. Nesta 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 do assinante, como CPU, memória e largura de banda de rede. Procure pontos de pressão que possam impedir a eficiência do processamento.
Código do cliente: revisar as alterações recentes no código e analisar 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 simultaneamente a mesma linha em um banco de dados. Esse comportamento pode levar a contenção e alta latência.
Limitações de cota: verifique se você não excedeu as cotas ou limitações do Pub/Sub impostas pelo serviço de hospedagem. Se os assinantes estiverem hospedados no Google Cloud, revise as cotas de recursos do Compute Engine ou do GKE para evitar possíveis gargalos.
O assinante confirmou as mensagens de maneira negativa.
Quando um assinante reconhece uma mensagem negativamente (transmite), ele informa ao Pub/Sub que não foi possível processar a mensagem. Em seguida, o Pub/Sub tenta reenviar a mesma mensagem. Erros repetidos para uma mensagem geram mensagens duplicadas e possivelmente um grande atraso na entrega de mensagens.
A captura de uma mensagem não garante que o próximo pull vai buscar uma mensagem diferente. A política de reenvio do Pub/Sub pode continuar reenviando mensagens não entregues antes das novas. Portanto, não use o Nacks como método de filtragem ou pulo de mensagens específicas. Em vez disso, defina uma política de nova tentativa, de preferência uma espera exponencial, como uma maneira de recuar mensagens individuais que provavelmente serão processadas mais tarde, mas que precisam de um pouco mais de tempo antes do 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 as mensagens sem confirmação, seja intencionalmente ou não, cria problemas de backlog e entregas duplicadas.
Alta latência de entrega
A latência de entrega no Pub/Sub é o tempo que 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, para alcançar uma latência consistentemente baixa, mantenha várias conexões StreamingPull abertas com sua assinatura. Sem conexões ativas do assinante, o Pub/Sub não pode entregar mensagens imediatamente. Um único stream pode ser um ponto único de falha, o que aumenta o risco de atrasos. A métrica subscription/open_streaming_pulls fornece visibilidade do número de conexões de streaming ativas. Use essa opção para garantir que você tenha sempre streams suficientes para lidar com as mensagens recebidas.
Para clientes que usam pull unário, para ter uma latência consistentemente baixa, mantenha várias solicitações de envio pendentes na sua assinatura. Solicitações não frequentes podem potencialmente 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 custos operacionais e de processamento mínimos. Por padrão, a biblioteca de cliente de alto nível usa a API StreamingPull, já que ela tende a ser uma opção melhor 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 da latência, formatação de mensagens e outros recursos.
Problemas de configuração do cliente
Consulte Problemas de configuração do cliente.
Backlog alto
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.
Como solicitar chaves e exatamente uma vez para a entrega
Pedir chaves e "entrega única" são recursos valiosos, mas exigem coordenação extra 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 na taxa de erro. Se a ordem 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 atrasos no processamento de mensagens.
Aumento do 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.
Se você notar um aumento na latência de entrega, verifique os tamanhos das mensagens usando a métrica topic/message_sizes, agrupando por topic_id. Correlacione os picos no tamanho da mensagem com os problemas de desempenho observados.
Mensagens ausentes
Se você suspeitar que as mensagens não estão sendo entregues ao assinante, um dos seguintes motivos pode ser o fator de contribuição.
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. Isso 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.
É possível que as mensagens já estejam pendentes para os clientes, e um backlog de mensagens não confirmadas não significa necessariamente que você receberá essas mensagens na sua próxima solicitação de envio. Um consumidor pode ser alguém que esteja usando pull no console do Google Cloud ou no Google Cloud CLI, ou executando um assinante personalizado localmente para verificar as mensagens.
Para clientes de pull unários, algumas solicitações de envio não retornam mensagens. Como discutido na seção assinantes insuficientes, é recomendável manter várias solicitações de pull pendentes, já que algumas podem retornar menos 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 anexados simultaneamente à assinatura e inspecione-os.
Filtrar na assinatura
Verifique se a assinatura tem um filtro anexado a ela. Nesse caso, você recebe apenas 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 verdadeiro. 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 solicitações de envio retornem 0 mensagens mesmo quando houver um backlog.
Como lidar com duplicatas
A duplicação de mensagens no Pub/Sub geralmente ocorre quando os assinantes não confirmam as mensagens dentro do prazo de confirmação. Isso faz com que as mensagens sejam reenviadas, criando a impressão de duplicatas. É possível medir a taxa de perda do prazo de confirmação dos assinantes 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, estenda os prazos das mensagens.
- As bibliotecas de cliente lidam com a extensão de prazo automaticamente, mas há limites padrão para o 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 extraídas do assinante mais rapidamente do que podem ser processadas e confirmadas, algumas mensagens poderão expirar e exigir extensões de prazo. No entanto, se o assinante continuar sobrecarregado, as várias extensões de prazo vão falhar. Na pior das hipóteses, isso pode levar a um excesso de assinantes duplicados, exacerbando o backlog. Cópias expiradas e geração de novas cópias.
Para evitar sobrecarregar o assinante, reduza o número de mensagens que ele recebe por pull de cada vez. Dessa forma, o assinante terá 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 recebe por vez, reduza o número máximo de mensagens pendentes na configuração de controle de fluxo do assinante. Não existe um valor único para todos os casos, portanto, você precisa ajustar o limite máximo de mensagens pendentes com base na sua capacidade de processamento e de assinantes. Considere que cada aplicativo processa as mensagens de maneira diferente e leva um tempo diferente para confirmar uma mensagem.
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.
Chaves de ordenação
Quando o Pub/Sub reenvia uma mensagem com uma chave de ordem, ela também reenvia todas as mensagens com a mesma chave de ordem, mesmo que tenham sido confirmadas anteriormente. Isso é feito para preservar a ordem da sequência. No entanto, não há uma política garantir que as mensagens dependentes sejam enviadas somente após o envio de mensagens anteriores na sequência.
O assinante está recebendo as mensagens
Consulte O assinante está recebendo as mensagens.
Solução de problemas de uma assinatura 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 a transmissão está desconectada. As solicitações não estão falhando. Portanto, embora o A API StreamingPull pode ter uma taxa de erro surpreendente de 100%. Esse comportamento do projeto.
Como os streams do StreamingPull sempre fecham com um erro, não é útil
Examinar métricas de encerramento de stream e diagnosticarem erros. Em vez disso, concentre-se
a métrica de resposta StreamingPull
subscription/streaming_pull_response_count,
agrupadas por response_code ou response_class.
Procure por estes erros:
Erros de precondição com falha podem ocorrer se houver mensagens no um backlog de assinatura criptografado com uma chave do Cloud KMS desativada. Para retomar a extração, restaurar o acesso à chave.
Erros indisponíveis podem ocorrer quando o Pub/Sub não consegue processar uma solicitação. Provavelmente, essa é uma condição transitória, e o cliente a biblioteca repete as solicitações. Nenhuma ação da sua parte é necessária se você estiver usando uma biblioteca de cliente.
Erros "Não encontrado" podem ocorrer quando a assinatura é excluída ou nunca eles existiam. O último caso acontece se você forneceu um valor inválido caminho de assinatura.