Esta página foi traduzida pela API Cloud Translation.

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

Este documento fornece algumas dicas de resolução de problemas comuns quando publica mensagens num tópico padrão do Pub/Sub.

Saiba como publicar mensagens em tópicos e as diferentes funcionalidades.

Latência de publicação elevada

A latência de publicação é o tempo necessário para concluir um pedido de publicação emitido por um cliente editor. A latência de publicação é diferente da latência de entrega completa, que é o tempo que uma mensagem publicada no Pub/Sub demora a ser entregue a um cliente subscritor. Pode observar uma latência de publicação ou uma latência de ponta a ponta elevadas, mesmo quando o valor do outro tipo de latência é baixo. Pode incorrer numa latência de publicação elevada no cliente publicador do Pub/Sub, em trânsito entre o cliente e o back-end do Pub/Sub ou no back-end do Pub/Sub. Pode inspecionar a latência de publicação incorrida no back-end do Pub/Sub através da métrica topic/send_request_latencies. A elevada latência de publicação no back-end pode estar relacionada com os seguintes fatores:

O Pub/Sub foi concebido para uma entrega de latência baixa e débito elevado. Se o tópico tiver um débito baixo, os recursos associados ao tópico podem demorar mais tempo a inicializar.
Se estiver a usar uma política de armazenamento de mensagens, esta pode afetar a latência geral dos pedidos para o tópico e a subscrição. Verifique as implicações de desempenho e disponibilidade da utilização desta configuração.

Se o seu cliente publicador estiver a observar uma latência de publicação significativamente superior à refletida na métrica, pode ser um sinal de um destes fatores do lado do cliente:

Certifique-se de que não está a criar um novo editor para cada publicação. Recomendamos que use um único cliente publicador por tópico por aplicação para publicar todas as mensagens. A criação de novos objetos de publicador e a adição de novas discussões têm um custo de latência. Se estiver a usar funções do Cloud Run para publicar mensagens, tenha em atenção que as invocações também podem afetar a latência de publicação.
Se considerar que as predefinições de repetição não são suficientes para o seu exemplo de utilização, faça os ajustes correspondentes. No entanto, verifique se os novos valores não são demasiado elevados. Veja como configurar os pedidos de repetição.

Tenha em atenção que uma latência de publicação elevada pode originar erros DEADLINE_EXCEEDED, que são abordados na secção seguinte.

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

Um erro DEADLINE_EXCEEDED durante um pedido de publicação indica que o pedido não foi concluído dentro do tempo atribuído. Isto pode dever-se a vários fatores, como os pedidos não chegarem ao serviço Pub/Sub ou problemas de desempenho que afetam os pedidos.

Para verificar se os pedidos de publicação estão a chegar ao serviço Pub/Sub, monitorize o tópico através da métrica topic/send_request_count, agrupada por response_code. Esta métrica ajuda a determinar se os pedidos falham antes de chegarem ao tópico Pub/Sub. Se a métrica estiver vazia, existe um fator externo que impede que as mensagens cheguem ao serviço Pub/Sub. Além disso, para excluir a possibilidade de um problema intermitente, verifique a taxa de erros através do gráfico de métricas topic/send_request_count mencionado anteriormente ou da página APIs e serviços na Google Cloud consola. Se a taxa de erros for muito baixa, pode tratar-se de um problema intermitente.

Se os pedidos estiverem a chegar ao Pub/Sub, seguem-se algumas possíveis causas de falhas nas operações de publicação com um erro DEADLINE_EXCEEDED:

Restrição do lado do cliente

As falhas de publicação são provavelmente causadas por um gargalo do lado do cliente, como memória insuficiente, pressão da CPU, estado de funcionamento incorreto da thread ou congestionamento da rede na VM que aloja o cliente publicador. Se uma chamada Publish devolver DEADLINE_EXCEEDED, pode ser que as chamadas Publish assíncronas estejam a ser colocadas em fila mais rapidamente do que são enviadas para o serviço, o que aumenta progressivamente a latência do pedido. Além disso, verifique se alguma das seguintes opções ajuda a determinar um possível gargalo no seu sistema:

Verifique se está a publicar mensagens mais rapidamente do que o cliente as consegue enviar. Normalmente, cada chamada Publish assíncrona devolve um objeto Future. Para acompanhar o número de mensagens que aguardam envio, armazene o número de mensagens a enviar com cada chamada Publish e elimine-o apenas no callback do objeto Future.
Certifique-se de que tem largura de banda de carregamento suficiente entre a máquina onde o publicador está a ser executado e Google Cloud. As redes Wi-Fi de desenvolvimento têm normalmente uma largura de banda de 1 a 10 MBps ou 1000 a 10 000 mensagens típicas por segundo. A publicação de mensagens num ciclo sem qualquer limitação de taxa pode criar um breve pico de largura de banda elevada durante um curto período. Para evitar esta situação, pode executar o publicador numa máquina dentro do Google Cloud ou reduzir a taxa de publicação das mensagens para corresponder à sua largura de banda disponível.
Verifique se deteta uma latência muito elevada entre o anfitrião e Google Cloud por qualquer um dos motivos, como congestionamento da rede de arranque ou firewalls. Calcular o débito da rede tem sugestões sobre como descobrir a largura de banda e a latência para diferentes cenários.
Em última análise, existem limites para a quantidade de dados que uma única máquina pode publicar. Pode ter de tentar dimensionar horizontalmente ou executar várias instâncias do cliente do publicador em várias máquinas. O artigo Testar clientes do Cloud Pub/Sub para maximizar o desempenho do streaming demonstra como o Pub/Sub é dimensionado numa única Google Cloud VM com um número crescente de CPUs. Por exemplo, pode atingir 500 MBps a 700 MBps para mensagens de 1 KB numa instância do Compute Engine de 16 núcleos.

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

Para reduzir a taxa de limite de tempo para chamadas de publicação, certifique-se de que tem um limite de tempo suficientemente longo definido nas definições de repetição do cliente publicador. Para as definições de nova tentativa, defina o prazo inicial para 10 segundos e o limite de tempo total para 600 segundos. Mesmo que não esteja a acumular um grande número de mensagens não enviadas, os picos ocasionais na latência dos pedidos podem fazer com que as chamadas de publicação excedam o tempo limite. No entanto, se os seus problemas forem causados por um gargalo persistente, em vez de tempos limite ocasionais, tentar novamente mais vezes pode levar a mais erros.

Problemas com a biblioteca cliente

Pode estar a executar uma versão da biblioteca de cliente com um problema conhecido. A lista seguinte inclui os rastreadores de problemas para todas as bibliotecas de cliente. Se encontrar um problema conhecido que afete a versão da biblioteca cliente que está a usar, atualize para a versão mais recente da biblioteca cliente. Isto garante que recebeu todas as atualizações relevantes, incluindo correções e melhorias no desempenho.

Problemas de esquema

Se as suas publicações começarem a devolver INVALID_ARGUMENT, é possível que alguém tenha atualizado o tópico para alterar o esquema associado, eliminado o esquema ou eliminado as revisões do esquema associadas ao tópico. Neste caso, atualize as definições do esquema do tópico para um esquema e um conjunto de revisões que correspondam às mensagens que estão a ser publicadas ou ajuste o formato da mensagem para corresponder ao esquema atual.

Problemas de encriptação de mensagens

Se configurou o seu tópico Pub/Sub para encriptar mensagens publicadas através de uma chave de encriptação gerida pelo cliente, a publicação pode falhar com um erro FAILED_PRECONDITION. Este erro pode ocorrer se a chave do Cloud KMS estiver desativada ou se as chaves geridas externamente através do Cloud EKM já não estiverem acessíveis. Para retomar a publicação, restaure o acesso à chave.

Problemas de transformação de mensagem única (SMT)

Se tiver configurado SMTs no seu tópico do Pub/Sub, a publicação pode falhar com erros INVALID_ARGUMENT quando não é possível aplicar transformações às mensagens. Se qualquer mensagem num lote de publicação não for transformada, a publicação de todo o lote falha. O erro devolvido 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.

Monitorize SMTs

Para compreender o desempenho e o impacto dos SMTs num tópico, use as seguintes métricas de monitorização:

A métrica topic/message_transform_latencies mede o tempo que as SMTs demoram a ser aplicadas a uma mensagem. A métrica mede apenas a latência do SMT e não inclui outras partes do tempo de entrega das mensagens.

A métrica fornece duas etiquetas principais:

status: indica se a transformação foi bem-sucedida ou se ocorreu um problema.
filtered: indica se o SMT fez com que a mensagem fosse filtrada. Quando um SMT filtra uma mensagem num tópico, o Pub/Sub rejeita a mensagem e esta nunca é enviada para os subscritores. Esta etiqueta filtered é verdadeira apenas quando um SMT realiza a filtragem. As mensagens filtradas através das capacidades de filtragem incorporadas do Pub/Sub não se refletem nesta métrica específica.

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

Quando um SMT filtra uma mensagem, o operation_type é smt_publish_filter_drop.
Se um SMT não conseguir transformar uma mensagem, vê um response_code que não é OK.

O que se segue?

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

Resolução de problemas de um tópico padrão Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.