Solução de problemas de um tópico padrão

Este documento oferece algumas dicas comuns para solucionar problemas ao publicar mensagens em um tópico padrão do Pub/Sub.

Saiba como publicar mensagens em tópicos e conhecer os diferentes recursos.

Alta latência de publicação

A latência de publicação é o tempo necessário para concluir uma solicitação de publicação emitida por um cliente publisher. A latência de publicação é diferente da latência de entrega de ponta a ponta, que é a quantidade de tempo que leva para uma mensagem publicada no Pub/Sub ser entregue a um cliente assinante. Você pode observar alta latência de publicação ou de ponta a ponta, mesmo quando o valor do outro tipo de latência é baixo. A alta latência de publicação pode ocorrer no cliente editor do Pub/Sub, em trânsito entre o cliente e o back-end do Pub/Sub ou no back-end do Pub/Sub. É possível inspecionar a latência de publicação no back-end do Pub/Sub usando a métrica topic/send_request_latencies. A alta latência de publicação do back-end pode estar relacionada aos seguintes fatores:

  • O Pub/Sub foi projetado para entrega de baixa latência e alta capacidade de processamento. Se o tema tiver baixa capacidade de processamento, os recursos associados a ele poderão levar mais tempo para serem inicializados.

  • Se você estiver usando uma política de armazenamento de mensagens, isso poderá afetar a latência geral das solicitações para o tópico e a assinatura. Confira as consequências de desempenho e disponibilidade de usar essa configuração.

Se o cliente editor estiver observando uma latência de publicação significativamente maior do que a refletida na métrica, isso pode ser um sinal de um destes fatores do lado do cliente:

  • Não crie um publisher novo para cada publicação. Recomendamos usar um único cliente editor por tópico e por aplicativo para publicar todas as mensagens. A criação de novos objetos de editor e a adição de novas linhas de execução têm um custo de latência. Se você estiver usando o Cloud Run functions para publicar mensagens, observe que as invocações também podem afetar a latência de publicação.

  • Se você achar que as configurações de nova tentativa padrão não são suficientes para seu caso de uso, faça os ajustes correspondentes. No entanto, verifique se os novos valores não estão muito altos. Saiba como configurar as solicitações de nova tentativa.

A alta latência de publicação pode levar a erros DEADLINE_EXCEEDED, que são discutidos na próxima seção.

As operações de publicação falham com DEADLINE_EXCEEDED

Um erro DEADLINE_EXCEEDED durante uma solicitação de publicação indica que a solicitação não foi concluída dentro do tempo alocado. Isso pode acontecer por vários fatores, como as solicitações não chegarem ao serviço do Pub/Sub ou problemas de desempenho que afetam as solicitações.

Para verificar se as solicitações de publicação estão chegando ao serviço do Pub/Sub, monitore o tópico usando a métrica topic/send_request_count, agrupada por response_code. Essa métrica ajuda a determinar se as solicitações falham antes de chegar ao tópico do Pub/Sub. Se a métrica estiver vazia, há um fator externo que impede que as mensagens cheguem ao serviço do Pub/Sub. Além disso, para descartar a possibilidade de um problema intermitente, verifique a taxa de erros usando o gráfico de métricas topic/send_request_count mencionado anteriormente ou a página APIs e serviços no console do Cloud de Confiance . Se a taxa de erro for muito baixa, pode ser um problema intermitente.

Se as solicitações estiverem chegando ao Pub/Sub, estas serão algumas possíveis causas de falha nas operações de publicação com um erro DEADLINE_EXCEEDED:

Gargalo do lado do cliente

As falhas de publicação provavelmente são causadas por um gargalo do lado do cliente, como memória insuficiente, pressão da CPU, integridade da linha de execução ruim ou congestionamento da rede na VM que hospeda o cliente publisher. Se uma chamada Publish retornar DEADLINE_EXCEEDED, talvez as chamadas Publish assíncronas estejam sendo enfileiradas mais rápido do que são enviadas ao serviço, o que aumenta progressivamente a latência da solicitação. Além disso, verifique se alguma das opções a seguir ajuda a determinar um possível gargalo no seu sistema:

  • Verifique se você está publicando mensagens mais rapidamente do que o cliente pode enviá-las. Normalmente, cada chamada Publish assíncrona retorna um objeto Future. Para monitorar o número de mensagens que estão aguardando o envio, armazene o número de mensagens a serem enviadas com cada chamada Publish e exclua-as somente no callback do objeto Future.

  • Verifique se você tem largura de banda de upload suficiente entre a máquina em que o editor está sendo executado e Cloud de Confiance by S3NS. As redes Wi-Fi de desenvolvimento geralmente têm largura de banda de 1 a 10 MBps ou de 1.000 a 10.000 mensagens típicas por segundo. Publicar mensagens em um loop sem qualquer limitação de taxa pode criar um pequeno burst de alta largura de banda em um curto período. Para evitar isso, execute o editor em uma máquina no Cloud de Confiance by S3NS ou reduza a taxa de publicação das mensagens para corresponder à largura de banda disponível.

  • Verifique se há latência muito alta entre o host e Cloud de Confiance by S3NS por algum motivo, como congestionamento da rede de inicialização ou firewalls. O cálculo da capacidade de processamento de rede tem ponteiros para descobrir sua largura de banda e latência para diferentes cenários.

  • Por fim, há limites para a quantidade de dados que uma única máquina pode publicar. Talvez seja necessário tentar escalonar horizontalmente ou executar várias instâncias do cliente do editor em várias máquinas. O teste de clientes do Cloud Pub/Sub para maximizar o desempenho do streaming demonstra como o Pub/Sub é escalonado em uma única VM Cloud de Confiance com um número cada vez maior de CPUs. Por exemplo, é possível atingir 500 MB/s a 700 MB/s para mensagens de 1 KB em uma instância do Compute Engine de 16 núcleos.

Duração inadequada do tempo limite de publicação

Para reduzir a taxa de tempo limite das chamadas de publicação, verifique se você tem um tempo limite longo o suficiente definido nas configurações de repetição do cliente editor. Nas configurações de nova tentativa, defina o prazo inicial como 10 segundos e o tempo limite total como 600 segundos. Mesmo que você não esteja acumulando um grande backlog de mensagens não enviadas, picos ocasionais na latência da solicitação podem causar o tempo limite das chamadas de publicação. No entanto, se os problemas forem causados por um gargalo persistente, em vez de tempos limite ocasionais, tentar novamente mais vezes poderá resultar em mais erros.

Problemas com a biblioteca de cliente

Você pode estar executando uma versão da biblioteca de cliente com um problema conhecido. A lista a seguir inclui os rastreadores de problemas de todas as bibliotecas de cliente. Se você encontrar um problema conhecido que afeta a versão da biblioteca de cliente que está usando, faça upgrade para a versão mais recente. Isso garante que você tenha recebido todas as atualizações relevantes, incluindo correções e melhorias de desempenho.

Problemas de esquema

Se as publicações começarem a retornar INVALID_ARGUMENT, é possível que alguém atualizou o tópico para mudar o esquema associado, excluiu o esquema ou excluiu as revisões do esquema associadas ao tópico. Nesse caso, atualize as configurações de esquema do tópico para um esquema e um conjunto de revisões que correspondam às mensagens publicadas ou ajuste o formato da mensagem para corresponder ao esquema atual.

Problemas com a criptografia de mensagens

Se você configurou seu tópico do Pub/Sub para criptografar mensagens publicadas usando uma chave de criptografia gerenciada pelo cliente, a publicação poderá falhar com um erro FAILED_PRECONDITION. Esse erro pode ocorrer se a chave do Cloud KMS estiver desativada ou se as chaves gerenciadas externamente pelo Cloud EKM não estiverem mais acessíveis. Para retomar a publicação, restaure o acesso à chave.

Problemas com a transformação de mensagens únicas (SMT)

Se você tiver configurado SMTs no tópico do Pub/Sub, a publicação poderá falhar com erros INVALID_ARGUMENT quando as transformações não forem aplicadas às mensagens. Se uma mensagem em um lote de publicação não for transformada, todo o lote não será publicado. O erro retornado indica o motivo da falha, por exemplo:

INVALID_ARGUMENT: Pub/Sub failed to apply a message transformation to one or
more messages in the publish request. Error: Failed to execute JavaScript UDF:
`my_function`. Return value is not an object.

Monitorar SMTs

Para entender a performance e o impacto das SMTs em um tema, use as seguintes métricas de monitoramento:

A métrica topic/message_transform_latencies mede quanto tempo leva para as SMTs serem aplicadas a uma mensagem. A métrica mede apenas a latência do SMT e não inclui outras partes do tempo de entrega da mensagem.

A métrica fornece dois rótulos principais:

  • status: informa se a transformação foi bem-sucedida ou se ocorreu um problema.

  • filtered: indica se a SMT fez com que a mensagem fosse filtrada. Quando um SMT filtra uma mensagem em um tópico, o Pub/Sub descarta a mensagem, e ela nunca é enviada aos assinantes. O rótulo filtered é verdadeiro apenas quando um SMT realiza a filtragem. As mensagens filtradas usando as capacidades de filtragem integradas do Pub/Sub não são refletidas nessa métrica específica.

A métrica topic/byte_cost é usada para identificar mensagens filtradas por SMTs ou em que os SMTs falharam. Procure estes valores específicos:

  • Quando um SMT filtra uma mensagem, o operation_type é smt_publish_filter_drop.

  • Se uma SMT não transformar uma mensagem, você vai ver um response_code que não é OK.

A seguir

Conheça o rastreamento do OpenTelemetry para ajudar você a depurar a latência de publicação.