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

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

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

Latência de publicação alta

A latência de publicação é o tempo necessário para concluir uma solicitação de publicação emitida por um cliente editor. A latência de publicação é diferente da latência de entrega de ponta a ponta, que é o tempo necessário para que uma mensagem publicada no Pub/Sub seja entregue a um cliente assinante. É possível observar latência de publicação ou de ponta a ponta alta, mesmo quando o valor do outro tipo de latência é baixo. A latência de publicação alta 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 incorrida no back-end do Pub/Sub usando a topic/send_request_latencies métrica. A latência de publicação alta 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 tópico 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, ela poderá afetar a latência geral das solicitações para o tópico e a assinatura. Confira as implicações de desempenho e disponibilidade do uso dessa configuração.

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

  • Verifique se você não está criando um novo editor para cada publicação. Recomendamos usar um único cliente editor por tópico 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 funções do Cloud Run para publicar mensagens, observe que as invocações também podem afetar a latência de publicação.

  • Se você descobrir que as configurações de repetição 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 são muito altos. Saiba como configurar as solicitações de repetição.

A latência de publicação alta 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 ocorrer devido a 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 topic/send_request_count métrica, 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 Google Cloud console. Se a taxa de erros for muito baixa, isso poderá ser um problema intermitente.

Se as solicitações estiverem chegando ao Pub/Sub, estas serão algumas causas possíveis 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 de linha de execução ruim ou congestionamento de rede na VM que hospeda o cliente editor. Se uma chamada Publish retornar DEADLINE_EXCEEDED, é possível que as chamadas Publish assíncronas estejam sendo enfileiradas mais rapidamente 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 sistema:

  • Verifique se você está publicando mensagens mais rápido do que o cliente pode enviá-las. Normalmente, cada chamada assíncrona Publish retorna um Future objeto. Para rastrear 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 retorno de chamada 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 Google Cloud. As redes Wi-Fi de desenvolvimento normalmente têm largura de banda de 1 a 10 MBps ou 1.000 a 10.000 mensagens típicas por segundo. A publicação de 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, é possível executar o editor em uma máquina dentroou reduzir a taxa de publicação das mensagens para corresponder à largura de banda disponível. Google Cloud

  • Verifique se há latência muito alta entre o host e Google Cloud 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 VM com um número cada vez maior de CPUs. Google Cloud Por exemplo, é possível atingir 500 MBps a 700 MBps 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 para chamadas de publicação, verifique se você tem um tempo limite suficientemente longo definido nas configurações de repetição do cliente editor. Para as configurações de repetição, 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á levar a mais erros.

Problemas da biblioteca de cliente

É possível que você esteja executando uma versão da biblioteca de cliente com um problema conhecido. A lista a seguir inclui os rastreadores de problemas para 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 da biblioteca de cliente. 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 tenha atualizado o tópico para mudar o esquema associado ao esquema, excluído o esquema ou excluído as revisões de 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 que estão sendo publicadas ou ajuste o formato da mensagem para corresponder ao esquema atual.

Problemas de criptografia de mensagens

Se você configurou o 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 poderá 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 de transformação de mensagem única (SMT)

Se você configurou SMTs no tópico do Pub/Sub, a publicação poderá falhar com INVALID_ARGUMENT erros quando as transformações não forem aplicadas às mensagens. Se alguma mensagem em um lote de publicação falhar na transformação, 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 o desempenho e o impacto das SMTs em um tópico, use as seguintes métricas de monitoramento:

A métrica topic/message_transform_latencies mede o tempo necessário para que as SMTs sejam aplicadas a uma mensagem. A métrica mede apenas a latência da 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 encontrou um problema.

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

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

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

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

A seguir

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