Este documento fornece algumas dicas comuns de solução de problemas para assinaturas por pull do Pub/Sub. Leia mais sobre assinaturas por pull no Guia do assinante por pull.
Para monitorar de forma eficaz sua assinatura do Pub/Sub, 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. Ela mede a idade, em segundos, da mensagem mais antiga no backlog de uma assinatura que ainda não foi confirmada (acked) por um assinante. Essa métrica oferece insights valiosos sobre possíveis atrasos ou gargalos de processamento.
Monitorar o backlog de mensagens garante um processamento de mensagens rápido e eficiente. Ao monitorar o tempo da mensagem não confirmada mais antiga, é possível 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 à degradação do 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, 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 de 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 analise 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 à 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 pôde ser processada. O Pub/Sub tenta reenviar a mesma mensagem. Nacks repetidas para uma mensagem levam a duplicatas e, possivelmente, a um grande atraso na entrega da mensagem.
A confirmação negativa de uma mensagem não garante que a próxima extração vai buscar uma mensagem diferente. A política de reenvio do Pub/Sub pode continuar reenviando mensagens nacked antes das novas. Portanto, não use nacks como um método de filtragem ou para pular mensagens específicas. Em vez disso, defina uma política de repetição, de preferência uma espera exponencial, como uma forma de adiar mensagens individuais que provavelmente serão processadas mais tarde, mas precisam de um pouco mais de tempo antes de serem reenviadas.
Se você precisar pular intencionalmente determinadas mensagens, a abordagem recomendada é confirmá-las, mesmo que não as processe. Isso as 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 backlog 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 uma alta latência de entrega são descritas nas próximas seções.
Não há inscritos suficientes
Para clientes que usam StreamingPull, para alcançar uma latência consistentemente baixa, mantenha várias conexões StreamingPull abertas com sua assinatura. 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 mostra o número de conexões de streaming ativas. Use isso para garantir que você sempre tenha streams suficientes para lidar com 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 para sua assinatura. Solicitações pouco frequentes podem acumular mensagens no backlog e aumentar a latência. Essa abordagem ajuda a minimizar as 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 costuma 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 a latência de ponta a ponta porque as mensagens não são processadas imediatamente pelos assinantes.
Chaves de ordenação e entrega única
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 erro 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, além de desacelerar o tempo de processamento das mensagens no lado do cliente.
Se você observar 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 motivos a seguir pode ser o fator determinante.
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 capacidade 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 confirmam 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. Portanto, a menos que a ordenação de 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 já 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 pull no console do Google Cloud ou na Google Cloud CLI, ou que executa um assinante personalizado localmente para verificar mensagens.
Para clientes de pull unário, algumas solicitações de pull podem retornar zero mensagens. Como discutido na seção assinantes insuficientes, é 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 configuradas ou até mesmo zero mensagens, mesmo que haja um backlog. Isso ocorre porque outros consumidores podem estar mantendo as concessões das mensagens disponíveis.
Se um consumidor não confirmar uma mensagem dentro do prazo de confirmação ou se ele enviar uma confirmação negativa (NACK), o Pub/Sub vai tentar reenviá-la. Essa tentativa de reenvio pode ser feita para qualquer consumidor ativo na assinatura, não necessariamente para aquele que a recebeu inicialmente. Portanto, um ID de mensagem específico pode ser entregue e ter o processamento tentado por vários consumidores diferentes conectados à assinatura durante o ciclo de vida dela, até que um deles o confirme.
Se você suspeitar de comportamentos inesperados na distribuição de mensagens, investigue se há vários consumidores conectados simultaneamente à assinatura e inspecione as métricas de performance e as configurações individuais deles.
Filtrar na assinatura
Verifique se a assinatura tem um filtro anexado. 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 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 verdadeiro. Este é um campo descontinuado que instrui o serviço do Pub/Sub a responder à solicitação de envio imediatamente, mesmo que ela não retorne mensagens. Isso pode fazer com que as solicitações de pull retornem com 0 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 (correspondente 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 definir essa configuração são
InstantiatingGrpcChannelProvider.Builder.setMaxInboundMessageSize()
e
ManagedChannelBuilder.maxInboundMessageSize().
Como lidar com duplicatas
Um assinante pode receber mensagens duplicadas nos seguintes casos:
Reenviar. Um cliente confirmou negativamente uma mensagem ou o prazo de confirmação expirou. Esse comportamento é esperado.
Entrega duplicada. Uma mensagem é reenviada após uma confirmação bem-sucedida ou antes que o prazo de confirmação expire. As assinaturas com a entrega exatamente uma vez ativada não recebem entregas duplicadas.
Mensagens duplicadas do editor. O editor envia uma mensagem duas vezes devido à lógica do aplicativo do editor. O serviço do Pub/Sub trata essas mensagens como mensagens distintas do Pub/Sub e atribui a elas IDs de mensagem exclusivos.
Se os IDs forem iguais, isso significa que o Pub/Sub reenviou ou reentregou a mensagem. Se os IDs de mensagem forem diferentes, isso significa que a duplicação ocorreu no upstream do editor.
Prazos de confirmação expirados
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 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 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 no assinante mais rápido do que podem ser processadas e confirmadas, algumas delas podem expirar e exigir extensões de prazo. No entanto, se o assinante continuar sobrecarregado, as extensões de prazo repetidas vão falhar. Na pior das hipóteses, isso pode fazer com que um assinante fique sobrecarregado com duplicatas, o que aumenta o backlog. As duplicatas que expiram geram novas duplicatas.
Para evitar sobrecarregar o assinante, reduza o número de mensagens que ele recebe por vez. Dessa forma, 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, reduza 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 que sirva para todos os casos. Por isso, é preciso ajustar o limite máximo de mensagens pendentes com base na capacidade de processamento e do assinante. Considere que cada aplicativo processa 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 ordem
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 sejam enviadas somente após a confirmação das mensagens anteriores na sequência.
O assinante está enviando nacks para as mensagens
Consulte O assinante está enviando nacks para as mensagens.
Operações de busca
Quando você realiza uma operação de busca em um carimbo de data/hora ou snapshot, o Pub/Sub reenvia as mensagens que foram publicadas após o carimbo de data/hora ou incluídas no snapshot. Esse reenvio é um comportamento esperado e ocorre mesmo que a entrega exatamente uma vez esteja ativada na assinatura. Para mais informações, consulte Buscar com entrega exatamente uma vez.
Eliminação de duplicação downstream
Os assinantes e outros sistemas downstream podem eliminar a duplicação de mensagens. Por exemplo, o Dataflow é compatível com a entrega única. Se você notar mensagens duplicadas aparecendo inesperadamente no downstream, a causa pode estar no assinante, e não no Pub/Sub.
Solução de problemas de uma assinatura 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 stream 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, embora a API StreamingPull possa ter uma taxa de erro surpreendente de 100%, esse comportamento é intencional.
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 StreamingPull
subscription/streaming_pull_response_count,
agrupada por response_code ou response_class.
Procure por estes erros:
Os erros de condição prévia com falha podem ocorrer se houver mensagens no backlog da assinatura que estejam criptografadas com uma chave do Cloud KMS desativada. Para retomar a extração, 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 tentará as solicitações novamente. Não é necessário fazer nada se você estiver usando uma biblioteca de cliente.
Os erros de não encontrado podem ocorrer quando a assinatura é excluída ou se ela nunca existiu. O último caso acontece se você fornecer um caminho de assinatura inválido.