Este documento oferece algumas dicas comuns de solução de problemas para assinaturas de pull do Pub/Sub. Leia mais sobre assinaturas de pull no guia do assinante de pull.
Para monitorar sua assinatura do Pub/Sub de maneira eficaz, recomendamos primeiro analisar 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 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. Ela mede a idade, em segundos, da mensagem mais antiga no backlog de uma assinatura que ainda não foi confirmada por um assinante. Essa métrica oferece insights valiosos sobre possíveis atrasos ou gargalos no processamento.
Monitorar o backlog de mensagens garante o processamento eficiente e oportuno das mensagens. Ao rastrear o tempo da mensagem descompactada mais antiga, você pode identificar de maneira proativa 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 à performance degradada.
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 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 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 causar contenção e alta latência.
Limitações de cota: verifique se você não excedeu nenhuma cota ou limitação do Pub/Sub imposta pelo seu serviço de hospedagem. Se os assinantes estiverem hospedados em Cloud de Confiance by S3NS, 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 envia uma confirmação negativa (nack) de uma mensagem, ele sinaliza ao Pub/Sub que a mensagem não pôde ser processada. Em seguida, o Pub/Sub tenta reenviar a mesma mensagem. Nacks repetidos para uma mensagem levam a duplicatas e podem causar um grande atraso na entrega.
Enviar um NACK para uma mensagem não garante que o próximo pull vai buscar uma mensagem diferente. A política de reentrega do Pub/Sub pode continuar reentregando mensagens com NACK antes das novas. Portanto, não confie em nacks como um método de filtragem ou de ignorar mensagens específicas. Em vez disso, defina uma política de nova tentativa, de preferência uma espera exponencial, como uma forma de reduzir mensagens individuais que provavelmente serão processadas mais tarde, mas precisam de um pouco mais de tempo antes da nova entrega.
Se você precisar ignorar intencionalmente algumas mensagens, a abordagem recomendada é confirmar o recebimento delas, mesmo que não as processe. Isso os remove da assinatura, evita novas entregas desnecessárias e reduz o consumo de recursos. Deixar mensagens sem confirmação, intencionalmente ou não, cria problemas de acúmulo e entregas duplicadas.
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 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 abertas com sua assinatura para ter uma latência consistentemente baixa. Sem conexões de assinantes ativas, 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 oferece visibilidade sobre o número de conexões de streaming ativas. Use isso para garantir que você sempre tenha fluxos suficientes para lidar com as mensagens recebidas.
Para clientes que usam pull unário, mantenha várias solicitações de pull pendentes na sua assinatura para conseguir 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 falhas 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 sobrecarga operacional e custo 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 pré-criadas que processam as chamadas de API subjacentes para autenticação, otimização de capacidade 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 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.
Chaves de pedido e entrega exatamente uma vez
As chaves de ordenação e a entrega exatamente uma vez 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, 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 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 principal prioridade, minimizar o uso desses recursos poderá 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 seu cliente, além de diminuir 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 das mensagens 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 a causa.
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 na mesma assinatura. O Pub/Sub faz o balanceamento de carga das mensagens em todos os clientes ativos, mas o objetivo principal é maximizar a taxa de transferência geral de processamento de mensagens e minimizar o backlog, em vez de garantir uma distribuição perfeitamente uniforme. O sistema direciona dinamicamente mais mensagens para os consumidores que demonstram maior capacidade, ou seja, aqueles que reconhecem as mensagens rapidamente e não são limitados pelas configurações de controle de fluxo. Os consumidores que processam mensagens em velocidades diferentes ou operam em condições diferentes (por exemplo, disponibilidade de recursos, latência de rede) provavelmente vão lidar com volumes diferentes de mensagens. Normalmente, os consumidores mais rápidos e responsivos recebem e processam uma parcela maior da carga de mensagens.
Esse método de distribuição entre vários consumidores significa que a ordem em que as mensagens são recebidas e processadas pode variar. Consequentemente, a menos que a ordem das mensagens esteja ativada para a assinatura e os editores incluam chaves de ordenação, não há garantia de que as mensagens serão processadas pelos consumidores na ordem em que foram publicadas.
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 Cloud de Confiance ou na Google Cloud CLI ou que executa um assinante personalizado localmente para verificar mensagens.
Para clientes de extração unários, talvez você observe algumas solicitações de extração retornando zero mensagens. Como discutido na seção não há assinantes suficientes, é recomendável manter várias solicitações de extração pendentes, já que algumas solicitações podem retornar menos do que o número máximo de mensagens configuradas ou até mesmo zero mensagens, mesmo que haja um backlog. Isso acontece porque outros consumidores podem estar mantendo concessões nas mensagens disponíveis.
Se um consumidor não confirmar uma mensagem dentro do prazo ou se ela for confirmada negativamente (NACKs), o Pub/Sub tentará reenviá-la. Essa nova tentativa de entrega pode ser feita para qualquer consumidor ativo na assinatura, não necessariamente para quem a recebeu inicialmente. Portanto, um ID de mensagem específico pode ser entregue a vários consumidores diferentes conectados à assinatura durante o ciclo de vida dela, e o processamento pode ser tentado por todos eles até que um deles confirme o recebimento.
Se você suspeitar de comportamentos inesperados de distribuição de mensagens, investigue se há vários consumidores conectados simultaneamente à assinatura e inspecione as métricas e configurações de performance individuais deles.
Filtrar a assinatura
Verifique se a assinatura tem um filtro anexado. Se for esse o 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 de backlog.
Como usar a opção returnImmediately
Se o cliente estiver usando o Pull unário, verifique se o campo returnImmediately está definido como "true". É 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 fazer com que as solicitações de pull retornem com zero mensagens, mesmo quando há um backlog.
Problemas de configuração do cliente
Se você estiver usando a biblioteca de cliente Java e inicializando o assinante com um canal gRPC personalizado usando o método setChannelProvider(), verifique se a configuração maxInboundMessageSize é de pelo menos 20 MB (correspondendo ao valor padrão da biblioteca) ao criar o TransportChannelProvider. Quando esse valor é menor que 10 MB, as mensagens maiores que maxInboundMessageSize não são recebidas corretamente. Alguns métodos comuns para configurar essa opção são InstantiatingGrpcChannelProvider.Builder.setMaxInboundMetadataSize() e ManagedChannelBuilder.maxInboundMetadataSize().
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. Isso faz com que as mensagens sejam entregues novamente, criando a impressão de duplicidade. É 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 os prazos das mensagens.
- As bibliotecas de cliente prolongam o prazo automaticamente, mas há limites padrã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 de prazo vão falhar. Na pior das hipóteses, isso pode levar a um assinante com excesso de duplicados, agravando o backlog. Os duplicados expirados geram novos duplicados.
Para evitar sobrecarregar o assinante, reduza o número de mensagens que ele extrai por vez. Assim, o assinante tem menos mensagens para processar dentro do prazo. Menos mensagens expiram e menos mensagens são reenviadas.
Para reduzir o número de mensagens que o assinante extrai por vez, diminua a configuração do número máximo de mensagens pendentes na configuração de controle de fluxo do assinante. Não há um valor único para todos os casos. Portanto, ajuste o limite máximo de mensagens pendentes com base na capacidade de transmissão e de assinantes. Considere que cada aplicativo processa mensagens de maneira diferente e leva um tempo diferente para confirmar o recebimento de 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 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 estrita de que as mensagens dependentes só serão enviadas após o recebimento das mensagens anteriores na sequência.
O assinante está enviando NACKs para as mensagens
Consulte o assinante está enviando NACKs para as mensagens.
Resolver problemas com uma assinatura do StreamingPull
Relação entre a métrica de latência de solicitação e a latência de entrega de ponta a ponta
Para StreamingPull, a métrica serviceruntime.googleapis.com/api/request_latencies representa o tempo em que o fluxo fica aberto. A métrica não é útil para determinar a latência de entrega 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 o aumento da latência de entrega de ponta a ponta.
As conexões StreamingPull são fechadas 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, ainda que a API StreamingPull tenha uma taxa de erro de 100% que pareça surpreendente, ela foi projetada dessa maneira.
Como os streams do StreamingPull sempre terminam 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 pré-condição não atendida podem ocorrer se houver mensagens no backlog da assinatura criptografadas com uma chave desativada do Cloud KMS. Para retomar o processo, restaure o acesso à chave.
Os erros de indisponibilidade podem ocorrer quando o Pub/Sub não consegue processar uma solicitação. Essa é provavelmente 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.