Este documento oferece algumas dicas comuns de solução de problemas para assinaturas de pull do Pub/Sub. Leia mais sobre as assinaturas de pull no guia do assinante de pull.
Para monitorar sua assinatura do Pub/Sub de maneira eficaz, recomendamos que você primeiro analise 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 maior.
A idade da 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. Ele 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 no processamento.
O monitoramento do backlog de mensagens garante o processamento rápido e eficiente das mensagens. Ao acompanhar a idade da mensagem não confirmada mais antiga, você pode identificar de forma proativa situações em que os consumidores estão atrasados. Essa prática permite a intervenção precoce para resolver possíveis problemas relacionados ao desempenho degradado.
Alguns dos problemas comuns de pendências que você pode investigar incluem:
Problemas de configuração do cliente
Quando as métricas oldest_unacked_message_age e num_undelivered_messages aumentam ao mesmo tempo, isso pode significar que os assinantes não estão acompanhando o volume de mensagens. Nesse caso, concentre sua investigação nos componentes do assinante:
Integridade do cliente: analise a utilização de recursos em máquinas que hospedam clientes de assinantes, 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: analise as mudanças 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çã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 negativamente as mensagens
Quando um assinante confirma negativamente (NACK) uma mensagem, ele sinaliza ao Pub/Sub que a mensagem não foi processada. O Pub/Sub tenta reenviar a mesma mensagem. Os nacks repetidos de uma mensagem levam a duplicações e, possivelmente, a um grande atraso na entrega da mensagem.
O bloqueio de uma mensagem não garante que a próxima busca retorne uma mensagem diferente. A política de reenvio do Pub/Sub pode continuar a reenviar mensagens com erro antes das novas. Portanto, não confie em nacks como um método de filtragem ou omissão de mensagens específicas. Em vez disso, defina uma política de nova tentativa, de preferência uma espera exponencial, como uma maneira de aguardar mensagens individuais que provavelmente serão processadas mais tarde, mas que precisam de um tempo maior antes da nova entrega.
Se você precisar pular intencionalmente algumas mensagens, a abordagem recomendada é confirmar a leitura delas, mesmo que não as processe. Isso remove os usuários da assinatura, evita reentregas desnecessárias e reduz o consumo de recursos. Deixar mensagens não confirmadas, intencionalmente ou não, cria problemas de acúmulo e entregas duplicadas.
Latência alta de envio
A latência de envio no Pub/Sub é o tempo que uma mensagem de um editor leva para chegar a um assinante. Algumas possíveis causas de alta latência de envio são descritas nas próximas seções.
Não há assinantes suficientes
Para alcançar uma latência consistentemente baixa, mantenha várias conexões StreamingPull abertas para sua assinatura. Sem conexões ativas de assinantes, o Pub/Sub não pode entregar mensagens imediatamente. Um único stream pode ser um ponto único de falha, aumentando o risco de atrasos. A métrica subscription/open_streaming_pulls mostra o número de conexões de streaming ativas. Use essa opção para garantir que você tenha fluxos suficientes para processar as mensagens recebidas.
Para clientes que usam o pull unário, mantenha várias solicitações de pull pendentes na sua assinatura para alcançar uma latência consistentemente baixa. Solicitações pouco frequentes podem acumular mensagens no backlog e aumentar a latência. Essa abordagem ajuda a minimizar as lacunas de 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 um custo operacional e de processamento mínimo. Por padrão, a biblioteca de cliente de alto nível usa a API StreamingPull, já que ela tende a ser uma escolha melhor para minimizar a latência. As bibliotecas de cliente de alto nível contêm funções e classes predefinidas que processam as chamadas de API subjacentes para autenticação, otimização de taxa de transferência 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
Um acúmulo de mensagens não confirmadas em uma assinatura do Pub/Sub aumenta a latência de ponta a ponta porque as mensagens não são processadas imediatamente pelos assinantes.
Chaves de ordenação e entrega exatamente uma vez
As chaves de ordenação e a entrega exatamente uma vez são recursos valiosos, mas exigem mais coordenação 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, as etapas de coordenação necessárias podem 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 ordenação não poderão ser entregues até que as anteriores com a mesma chave de ordenação sejam confirmadas.
Considere se a ordenação de 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 pode ajudar a reduzir os atrasos no processamento de mensagens.
Aumento no tamanho da mensagem
Um aumento repentino no tamanho da mensagem pode aumentar o tempo de transferência entre o Pub/Sub e o cliente e diminuir o tempo de processamento das mensagens no lado do cliente.
Se você notar um aumento na latência de entrega, verifique o tamanho 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 motivos a seguir pode ser o fator que contribui para isso.
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.
As mensagens podem estar pendentes para os clientes, e um backlog de mensagens não confirmadas não significa necessariamente que você vai receber essas mensagens na próxima solicitação de envio. Um consumidor pode ser alguém que usa o pull no console do Google Cloud ou na Google Cloud CLI ou que executa um assinante personalizado localmente para verificar mensagens.
Para clientes de extração unária, algumas solicitações de envio podem retornar zero mensagens. Como discutido na seção não há assinantes suficientes, é recomendável manter várias solicitações de pull pendentes, já que algumas solicitações podem retornar menos do que o número máximo de mensagens configurado ou até mesmo nenhuma mensagem.
Se você suspeitar de algum desses comportamentos, investigue se há vários consumidores conectados à assinatura ao mesmo tempo e inspecione-os.
Filtrar pela assinatura
Verifique se a assinatura tem um filtro associado. Nesse caso, você só vai receber 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.
Como usar a opção returnImmediately
Se o cliente estiver usando o pull unário, verifique se o campo returnImmediately está definido como verdadeiro. Este é um campo descontinuado que informa ao serviço do Pub/Sub para responder à solicitação de envio imediatamente, mesmo que ela retorne sem mensagens. Isso pode resultar em solicitações de pull retornando com 0 mensagens, mesmo quando há um atraso.
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 reenviadas, criando a impressão de duplicações. É possível medir a taxa de perda do prazo de confirmação dos assinantes usando a métrica subscription/expired_ack_deadlines_count. Saiba como monitorar a expiração do prazo de confirmação.
Para reduzir a taxa de duplicação, prolongue o prazo das mensagens.
- As bibliotecas de cliente processam a extensão do prazo automaticamente, mas há limites padrão de configuração de quanto o prazo pode ser prolongado.
- 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 rápido 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 extensões repetidas do prazo vão falhar. No pior cenário, isso pode levar a um assinante com muitas cópias, o que agrava o backlog. A expiração de duplicatas gera novas duplicatas.
Para evitar sobrecarregar o assinante, reduza o número de mensagens que ele puxa por vez. Dessa forma, o assinante tem menos mensagens para processar dentro do prazo. Menos mensagens expiram e são reenviadas.
Para reduzir o número de mensagens que o assinante extrai por vez, é necessário reduzir a configuração de número máximo de mensagens pendentes no controle de fluxo do assinante. Não há um valor único, então você precisa ajustar o limite máximo de mensagens pendentes com base na 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.
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.
Chaves de ordenação
Quando o Pub/Sub reenvia uma mensagem com uma chave de ordenação, ele também reenvia todas as mensagens subsequentes com a mesma chave de ordenação, mesmo que tenham sido confirmadas anteriormente. Isso é feito para preservar a ordem da sequência. No entanto, não há garantia rígida de que as mensagens dependentes sejam enviadas somente após o acionamento bem-sucedido das mensagens anteriores na sequência.
O assinante está encerrando as mensagens
Consulte O assinante está interrompendo as mensagens.
Solução de problemas de uma assinatura do StreamingPull
Relação entre a métrica de latência da solicitação e a latência de entrega de ponta a ponta
Para o StreamingPull, a métrica serviceruntime.googleapis.com/api/request_latencies representa o tempo em que o fluxo está aberto. A métrica não é útil para determinar a latência de envio de ponta a ponta.
Em vez de usar a métrica de latência de solicitação, use a pontuação de integridade da latência de entrega para verificar quais fatores estão contribuindo para um aumento na latência de entrega de ponta a ponta.
As conexões do StreamingPull são encerradas com um status não OK
Os streams do StreamingPull sempre fecham com um status não OK. Ao contrário de um status de erro para RPCs unárias, 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 possa ter uma taxa de erro surpreendente de 100%, esse comportamento é projetado.
Como os streams do StreamingPull sempre fecham com um erro, não é útil
examinar as métricas de encerramento de stream enquanto diagnostica 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 condição prévia com falha podem ocorrer se houver mensagens no backlog da assinatura criptografadas com uma chave do Cloud KMS desativada. 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, trata-se de uma condição temporária, e a biblioteca de cliente tenta novamente as solicitações. Não é necessário fazer nada se você estiver usando uma biblioteca de cliente.
Erros de não encontrado podem ocorrer quando a assinatura é excluída ou se ela nunca existiu. O último caso acontece se você forneceu um caminho de assinatura inválido.