Este documento fornece algumas sugestões de resolução de problemas comuns para subscrições de obtenção do Pub/Sub. Leia mais sobre as subscrições de obtenção no guia de subscrição de obtenção.
Para monitorizar eficazmente a sua subscrição do Pub/Sub, recomendamos que analise primeiro a pontuação de estado da latência de entrega (subscription/delivery_latency_health_score) para verificar que fatores podem contribuir para uma latência inesperada ou aumentada.
A idade da mensagem mais antiga não confirmada continua a aumentar
O oldest_unacked_message_age é uma métrica fundamental para monitorizar o estado das subscrições do Pub/Sub. Mede a antiguidade, em segundos, da mensagem mais antiga na fila de espera de uma subscrição que ainda não foi confirmada por um subscritor. Esta métrica oferece estatísticas valiosas sobre potenciais atrasos ou gargalos no processamento.
A monitorização do atraso de mensagens garante o processamento de mensagens atempado e eficiente. Ao acompanhar a antiguidade da mensagem não confirmada mais antiga, pode identificar proativamente situações em que os consumidores estão a ficar para trás. Esta prática permite uma intervenção precoce para resolver potenciais problemas relacionados com a degradação do desempenho.
Seguem-se alguns dos problemas comuns de pendências que pode investigar:
Problemas de configuração do cliente
Quando as métricas oldest_unacked_message_age e num_undelivered_messages aumentam em simultâneo, pode significar que os subscritores não estão a acompanhar o volume de mensagens. Nesta situação, concentre a sua investigação nos componentes de subscrição:
Estado de funcionamento do cliente: analise a utilização de recursos em máquinas que alojam clientes subscritores, como a CPU, a memória e a largura de banda da rede. Procure pontos de pressão que possam impedir a eficiência do processamento.
Código do cliente: reveja as alterações recentes ao código e examine os registos de erros. Os erros ou as ineficiências no código do subscritor podem afetar significativamente as taxas de processamento de mensagens. Tenha em atenção que podem existir problemas em mensagens específicas. Por exemplo, várias mensagens podem ter de aceder à mesma linha numa base de dados em simultâneo. Este comportamento pode levar a contestações e a uma latência elevada.
Limitações de quota: verifique se não excedeu nenhuma quota ou limitação do Pub/Sub imposta pelo seu serviço de alojamento. Se os subscritores estiverem alojados no Google Cloud, reveja as quotas de recursos do Compute Engine ou do GKE para evitar potenciais estrangulamentos.
O subscritor acusou negativamente a receção das mensagens
Quando um subscritor envia uma confirmação negativa (NACK) de uma mensagem, indica ao Pub/Sub que não foi possível processar a mensagem com êxito. Em seguida, o Pub/Sub tenta reenviar a mesma mensagem. Os NACKs repetidos para uma mensagem originam duplicados e, potencialmente, um atraso elevado na entrega de mensagens.
Tenha em atenção que o envio de um NACK para uma mensagem não garante que a obtenção seguinte obtenha uma mensagem diferente. A política de reenvio do Pub/Sub pode continuar a reenviar mensagens com NACK antes de novas mensagens. Por conseguinte, não confie nos nacks como um método de filtragem ou ignorar mensagens específicas. Em alternativa, defina uma política de repetição, de preferência um recuo exponencial, como forma de recuar em mensagens individuais que provavelmente podem ser processadas mais tarde, mas precisam de um pouco mais de tempo antes da reentrega.
Se precisar de ignorar intencionalmente determinadas mensagens, a abordagem recomendada é acusá-las, mesmo que não as processe. Isto remove-os da subscrição, evita reenvios desnecessários e reduz o consumo de recursos. Deixar mensagens sem confirmação, intencionalmente ou não, cria problemas de atraso e entregas duplicadas.
Latência de entrega elevada
A latência de entrega no Pub/Sub é o tempo que uma mensagem de um publicador demora a chegar a um subscritor. Algumas causas possíveis de uma latência de entrega elevada são descritas nas secções seguintes.
Não tem subscritores suficientes
Para clientes que usam o StreamingPull, para alcançar uma latência consistentemente baixa, mantenha várias ligações StreamingPull abertas à sua subscrição. Sem ligações de subscritores ativas, o Pub/Sub não pode entregar mensagens prontamente. Um único stream pode ser um ponto único de falha, o que aumenta o risco de atrasos. A métrica subscription/open_streaming_pulls oferece visibilidade sobre o número de ligações de streaming ativas. Use esta opção para se certificar de que tem sempre streams suficientes para processar as mensagens recebidas.
Para clientes que usam a obtenção unária, para alcançar uma latência consistentemente baixa, mantenha vários pedidos de obtenção pendentes para a sua subscrição. Os pedidos pouco frequentes podem acumular mensagens no backlog e aumentar a latência. Esta abordagem ajuda a minimizar as falhas de conetividade e a melhorar a latência de entrega.
A biblioteca de cliente de nível superior é recomendada para casos em que precisa de um elevado débito e uma baixa latência com custos operacionais e de processamento mínimos. Por predefinição, a biblioteca cliente de alto nível usa a API StreamingPull, uma vez que tende a ser uma melhor escolha para minimizar a latência. As bibliotecas de cliente de nível superior contêm funções e classes pré-criadas que processam as chamadas API subjacentes para autenticação, otimização da taxa de transferência e da latência, formatação de mensagens e outras funcionalidades.
Problemas de configuração do cliente
Consulte a secção Problemas de configuração do cliente.
Trabalho acumulado elevado
Tenha em atenção que um atraso de mensagens não confirmadas numa subscrição do Pub/Sub aumenta inerentemente a latência ponto a ponto, porque as mensagens não são processadas imediatamente pelos subscritores.
Chaves de ordenação e entrega exatamente uma vez
As chaves de ordenação e a entrega exatamente uma vez são funcionalidades valiosas. No entanto, requerem coordenação adicional no Pub/Sub para garantir a entrega correta. Esta coordenação pode reduzir a disponibilidade e aumentar a latência. Embora a diferença seja mínima no estado estável, quaisquer passos de coordenação necessários podem resultar em aumentos temporários na latência ou numa taxa de erro aumentada. Se a ordenação estiver ativada, as mensagens com uma chave de ordenação não podem ser entregues até que as anteriores com a mesma chave de ordenação sejam ACKed.
Considere se a ordenação de mensagens ou a entrega exatamente uma vez são absolutamente essenciais para a sua aplicação. Se a baixa latência for a sua principal prioridade, minimizar a utilização destas funcionalidades pode ajudar a reduzir os atrasos no processamento de mensagens.
Aumento do tamanho das mensagens
Um aumento repentino no tamanho da mensagem pode aumentar potencialmente o tempo de transferência entre o Pub/Sub e o seu cliente, e diminuir o tempo de processamento das mensagens no lado do cliente.
Se observar um aumento na latência de entrega, pode verificar os tamanhos das mensagens através da métrica topic/message_sizes, agrupando por topic_id. Correlacione os picos no tamanho das mensagens com os problemas de desempenho observados.
Mensagens em falta
Se suspeitar que as mensagens não estão a ser entregues com êxito ao seu subscritor, um dos seguintes motivos pode ser o fator contribuinte.
Distribuição de mensagens em subscrições do Pub/Sub com vários consumidores
No Pub/Sub, as mensagens podem ser distribuídas de forma desigual entre os consumidores. Este comportamento ocorre porque o Pub/Sub distribui mensagens entre consumidores ativos para maior eficiência. Por vezes, um único consumidor pode receber menos mensagens do que o esperado ou um subconjunto de mensagens diferente do de outros consumidores.
Tenha em atenção que podem existir mensagens pendentes para os clientes e que um atraso de mensagens não reconhecidas não significa necessariamente que vai receber essas mensagens no seu próximo pedido de obtenção. Tenha em atenção que um consumidor pode ser alguém que usa o comando pull na Google Cloud consola ou na CLI do Google Cloud, ou que executa um subscritor personalizado localmente para verificar as mensagens.
Para clientes de obtenção unários, pode observar alguns pedidos de obtenção a devolverem zero mensagens. Conforme abordado na secção Não tem subscritores suficientes, é recomendável manter vários pedidos de obtenção pendentes, uma vez que alguns pedidos podem devolver um número de mensagens inferior ao número máximo configurado ou mesmo zero mensagens.
Se suspeitar de algum destes comportamentos, investigue se existem vários consumidores anexados em simultâneo à subscrição e inspecione-os.
Filtrar na subscrição
Verifique se a subscrição tem um filtro associado. Se for o caso, só recebe as mensagens que correspondem ao filtro. O serviço Pub/Sub confirma automaticamente as mensagens que não correspondem ao filtro. Considere como os filtros afetam as métricas de pendências.
Usar a opção returnImmediately
Se o seu cliente estiver a usar o método Pull unário, verifique se o campo returnImmediately está definido como verdadeiro. Este é um campo descontinuado que indica ao serviço Pub/Sub para responder ao pedido de obtenção imediatamente, mesmo que não devolva mensagens. Isto pode fazer com que os pedidos de obtenção sejam devolvidos com 0 mensagens, mesmo quando existe um backlog.
Problemas de configuração do cliente
Se estiver a usar a biblioteca cliente Java e a inicializar o subscritor com um canal gRPC personalizado através do método setChannelProvider(), deve garantir que a definição maxInboundMessageSize é, pelo menos, de 20 MB (correspondendo ao valor predefinido da biblioteca) ao criar o TransportChannelProvider. Quando este valor é inferior a 10 MB, as mensagens com mais de maxInboundMessageSize não são recebidas corretamente. Alguns métodos comuns para configurar esta definição são InstantiatingGrpcChannelProvider.Builder.setMaxInboundMetadataSize() e ManagedChannelBuilder.maxInboundMetadataSize().
Lidar com duplicados
A duplicação de mensagens no Pub/Sub ocorre frequentemente quando os subscritores não conseguem confirmar as mensagens dentro do prazo de confirmação. Isto faz com que as mensagens sejam reenviadas, criando a impressão de duplicados. Pode medir a taxa à qual os subscritores não cumprem o prazo de confirmação através da métrica subscription/expired_ack_deadlines_count. Saiba como monitorizar a expiração do prazo de confirmação.
Para reduzir a taxa de duplicação, prolongue os prazos das mensagens.
- As bibliotecas de cliente processam a extensão do prazo automaticamente, mas existem limites predefinidos para o prazo máximo de extensão que pode configurar.
- Se estiver a criar a sua própria biblioteca de cliente, use o método
modifyAckDeadlinepara prolongar o prazo de confirmação.
Se as mensagens forem obtidas pelo subscritor mais rapidamente do que podem ser processadas e confirmadas, algumas mensagens podem expirar e exigir extensões de prazo. No entanto, se o subscritor continuar sobrecarregado, as extensões repetidas do prazo acabam por falhar. No pior cenário possível, isto pode levar a que um subscritor fique cheio de duplicados, o que agrava o atraso. A expiração dos duplicados gera novos duplicados.
Para evitar sobrecarregar o subscritor, reduza o número de mensagens que o subscritor extrai de cada vez. Desta forma, o subscritor 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 subscritor extrai de cada vez, tem de reduzir a definição do número máximo de mensagens pendentes na configuração do controlo de fluxo do subscritor. Não existe um valor único para todos os casos, pelo que tem de ajustar o limite máximo de mensagens pendentes com base no seu débito e capacidade de subscrição. Tenha em atenção que cada aplicação processa as mensagens de forma diferente e demora um período diferente a acusar a receção de uma mensagem.
Forçar novas tentativas
Para forçar o Pub/Sub a tentar novamente uma mensagem, envie um pedido nack. Se não estiver a usar as bibliotecas cliente de nível superior, envie um pedido modifyAckDeadline com um ackDeadlineSeconds definido como 0.
Encomendar chaves
Quando o Pub/Sub reenvia uma mensagem com uma chave de ordenação, também reenvia todas as mensagens subsequentes com a mesma chave de ordenação, mesmo que tenham sido confirmadas anteriormente. Isto é feito para preservar a ordem da sequência. No entanto, não existe uma garantia estrita de que as mensagens dependentes só sejam enviadas após a confirmação bem-sucedida das mensagens anteriores na sequência.
O subscritor está a enviar NACKs para as mensagens
Verifique se o subscritor está a rejeitar as mensagens.
Resolução de problemas de uma subscrição StreamingPull
Relação entre a métrica de latência do pedido e a latência de entrega ponto a ponto
Para StreamingPull, a métrica serviceruntime.googleapis.com/api/request_latencies representa o tempo durante o qual a stream está aberta. A métrica não é útil para determinar a latência de entrega integral.
Em vez de usar a métrica de latência do pedido, use a classificação de estado da latência de entrega para verificar que fatores estão a contribuir para um aumento da latência de entrega ponto a ponto.
As ligações StreamingPull são fechadas com um estado não OK
As streams StreamingPull são sempre fechadas com um estado não OK. Ao contrário de um estado de erro para RPCs unários, este estado para StreamingPull é apenas uma indicação de que a stream está desligada. Os pedidos não estão a falhar. Por conseguinte, embora a API StreamingPull possa ter uma taxa de erro surpreendente de 100%, este comportamento é intencional.
Uma vez que as streams StreamingPull fecham sempre com um erro, não é útil examinar as métricas de terminação de streams ao diagnosticar erros. Em vez disso, foque-se na métrica de resposta StreamingPull subscription/streaming_pull_response_count, agrupada por response_code ou response_class.
Procure estes erros:
Os erros de condição prévia falhada podem ocorrer se existirem mensagens no backlog da subscrição encriptadas com uma chave do Cloud KMS desativada. Para retomar a obtenção, restaure o acesso à chave.
Os erros de indisponibilidade podem ocorrer quando o Pub/Sub não consegue processar um pedido. Esta é provavelmente uma condição transitória e a biblioteca do cliente tenta novamente os pedidos. Não tem de fazer nada se estiver a usar uma biblioteca de cliente.
Os erros não encontrados podem ocorrer quando a subscrição é eliminada ou se nunca existiu. O último caso ocorre se tiver fornecido um caminho de subscrição inválido.