Saiba mais sobre as etapas de solução de problemas que podem ser úteis se você tiver problemas durante o uso do Pub/Sub.
Não é possível criar um tópico
Verifique se você tem as permissões necessárias
permissions.
Para criar um tópico do Pub/Sub, você precisa
do papel Editor do Pub/Sub (roles/pubsub.editor) do Identity and Access Management
no projeto. Se você não tiver esse papel, entre em contato com o administrador.
Para mais informações sobre a solução de problemas relacionados a tópicos, consulte as seguintes páginas:
Não é possível criar uma assinatura
Verifique se você fez o seguinte:
Verifique se você tem as permissões necessárias permissions. Para criar uma assinatura do Pub/Sub, você precisa do papel de IAM Editor do Pub/Sub (roles/pubsub.editor) no projeto. Se você não tiver esse papel, entre em contato com o administrador.
Especificou um nome para a assinatura.
Especificou o nome de um tópico existente ao qual você quer anexar a assinatura.
Se você estiver criando uma assinatura por push, especifique
https://em letras minúsculas (nãohttp://ouHTTPS://) como o protocolo para o URL de recebimento no campopushEndpoint.
Para mais informações sobre a solução de problemas relacionados a assinaturas, consulte as seguintes páginas:
Solução de problemas de pull, push, BigQuery, ou Cloud Storage
Solução de problemas de assinaturas com transformações de mensagem única
Resolver problemas de permissão
As permissões do Pub/Sub controlam quais usuários e contas de serviço podem realizar ações nos recursos do Pub/Sub. Quando as permissões estão mal configuradas, isso pode levar a erros de permissão negada e interromper o fluxo de mensagens. Os registros de auditoria fornecem um registro detalhado de todas as mudanças de permissão, permitindo que você identifique a origem desses problemas.
Para resolver problemas de permissão do Pub/Sub com registros de auditoria:
Receba as permissões necessárias para acessar a Análise de registros.
Para mais informações, consulte Antes de começar.
No Google Cloud console do, acesse a página Análise de registros.
Selecione um Google Cloud projeto, uma pasta ou uma organização do.
Confira uma lista de filtros que podem ser usados para encontrar registros relevantes:
resource.type="pubsub_topic" OR resource.type="pubsub_subscription": Use esta consulta como ponto de partida ao resolver qualquer problema que possa envolver mudanças nas configurações de tópico ou assinatura, ou controle de acesso. É possível combiná-la com outros filtros para refinar ainda mais a pesquisa.protoPayload.methodName="google.iam.v1.SetIamPolicy": use essa consulta quando suspeitar que um problema é causado por permissões incorretas ou ausentes. Ela ajuda a rastrear quem fez mudanças na política do IAM e quais foram essas mudanças. Isso pode ser útil para resolver problemas como usuários que não conseguem publicar em tópicos ou se inscrever em assinaturas, aplicativos com acesso negado a recursos do Pub/Sub ou mudanças inesperadas no controle de acesso.protoPayload.status.code=7: use essa consulta quando encontrar erros explicitamente relacionados a permissões. Isso ajuda a identificar quais ações estão falhando e quem está tentando realizá-las. É possível combinar essa consulta com as anteriores para identificar o recurso específico e a mudança na política do IAM que podem estar causando a negação de permissão.
Analise os registros para determinar fatores como o carimbo de data/hora do evento, o principal que fez a mudança e o tipo de mudanças feitas.
Com base nas informações coletadas nos registros de auditoria, você pode tomar ações corretivas.
Resolver problemas de permissão do Terraform
Ao usar o Pub/Sub com o Terraform, conceda explicitamente os papéis necessários no código do Terraform. Por exemplo, para publicar, a conta de serviço do aplicativo precisa do papel roles/pubsub.publisher. Se esse papel não estiver definido explicitamente no código do Terraform, um terraform apply futuro poderá removê-lo. Isso geralmente acontece durante atualizações não relacionadas, fazendo com que um aplicativo confiável falhe repentinamente com erros PERMISSION_DENIED.
Definir explicitamente o papel no código impede essas regressões acidentais.
A assinatura foi excluída
As assinaturas do Pub/Sub podem ser excluídas de duas maneiras principais:
Um usuário ou conta de serviço com permissões suficientes exclui intencionalmente a assinatura.
Uma assinatura é excluída automaticamente após um período de inatividade, que é de 31 dias por padrão. Para mais informações sobre a política de expiração de assinatura, consulte Período de expiração.
Para resolver problemas de uma assinatura excluída, siga estas etapas:
No Google Cloud console do, acesse a página de assinaturas do Pub/Sub e verifique se a assinatura não está mais listada. Para mais informações sobre como listar assinaturas, consulte Listar uma assinatura.
Verifique os registros de auditoria. Acesse a Análise de registros. Use o filtro
protoPayload.methodName="google.pubsub.v1.Subscriber.DeleteSubscription"para encontrar assinaturas excluídas. Examine os registros para determinar se alguém excluiu a assinatura ou se ela foi excluída devido à inatividade.InternalExpireInactiveSubscriptionindica que uma assinatura foi excluída devido à inatividade. Para mais informações sobre como usar registros de auditoria para solução de problemas, consulte Resolver problemas do Pub/Sub com registros de auditoria.
Erro 403 (Forbidden)
Um erro 403 geralmente significa que você não tem as permissões corretas para realizar uma ação. Por exemplo, você pode receber um erro 403 User not authorized ao tentar publicar em um tópico ou extrair de uma assinatura.
Se você receber esse erro, faça o seguinte:
- Verifique se você ativou a API Pub/Sub no Google Cloud console.
Confira se quem fez a solicitação tem as permissões necessárias para os recursos relevantes da API Pub/Sub, especialmente se a API Pub/Sub estiver sendo usada para a comunicação entre projetos.
Se você usa o Cloud Dataflow, certifique-se de que o
{PROJECT_NUMBER}@cloudservices.gserviceaccount.come a conta de serviço do Compute Engine{PROJECT_NUMBER}-compute@developer.gserviceaccount.comtenham as permissões necessárias no recurso da API Pub/Sub correspondente. Para mais informações, consulte Segurança e permissões do Dataflow.Se você está usando o App Engine, verifique a página Permissões do seu projeto para ver se uma conta de serviço do App Engine está listada como um Editor do Pub/Sub. Se não houver, adicione sua conta de serviço do App Engine como um Editor do Pub/Sub. Normalmente, a conta de serviço do App Engine está no formato
<project-id>@appspot.gserviceaccount.com.É possível usar registros de auditoria para resolver problemas de permissão.
Outros códigos de erro comuns
Para uma lista de outros códigos de erro comuns relacionados à API Pub/Sub e suas descrições, consulte Códigos de erro.
Tempos limite de conexão, latência ou erros de rede
Você pode ter falhas intermitentes ou persistentes quando os aplicativos cliente do Pub/Sub tentam se conectar a Google Cloud serviços. Esses problemas podem se manifestar como:
- Atrasos significativos ao publicar mensagens, o que pode causar atrasos no aplicativo.
- Erros de tempo limite, como gRPC
DEADLINE_EXCEEDED,code = DeadlineExceededoujava.net.SocketTimeoutException. - Falhas de E/S de rede, como
UNAVAILABLE: io exceptionou errosConnection refusedao tentar acessar serviços comopubsub.googleapis.comouoauth2.googleapis.com.
Esses problemas de conectividade podem surgir mesmo sem mudanças na configuração do Pub/Sub ou no código do aplicativo. Isso ocorre com frequência quando firewalls locais ou de VPC usam listas de permissões de endereço IP codificadas para APIs do Google. Os serviços do Google, incluindo o Pub/Sub e dependências como serviços de autenticação, usam um intervalo dinâmico de endereços IP. Se o firewall não considerar novos endereços IP, ele poderá bloquear o tráfego para os novos endereços IP, causando falhas de conexão e autenticação.
Para garantir uma conectividade estável, evite regras de firewall estáticas baseadas em IP para serviços do Google. Em vez disso:
- Configure o firewall para permitir o tráfego usando os intervalos de IP publicados do Google para domínios padrão, em vez de endereços codificados. Para saber como acessar esses intervalos e automatizar atualizações nas regras de firewall, consulte Endereços IP para domínios padrão.
- Ative o Acesso privado do Google, que permite que instâncias na rede VPC alcancem APIs do Google e serviços sem atravessar a Internet pública, simplificando o gerenciamento de firewall.
JWT inválido: o token precisa ser de curta duração
Se você receber um erro como Invalid JWT: Token must be a short-lived token (60
minutes) and in a reasonable timeframe quando o aplicativo interage com a
API Pub/Sub, isso geralmente indica um problema com o tempo das
credenciais de autenticação.
Esse erro ocorre durante a validação do JSON Web Token (JWT) usado para autenticar solicitações de API. Uma causa comum é uma diferença de tempo significativa (distorção de tempo) entre a máquina cliente que executa a biblioteca do Pub/Sub e os servidores de autenticação do Google. Como os JWTs têm uma janela de validade limitada, as discrepâncias de relógio podem fazer com que eles sejam tratados como expirados ou ainda não válidos.
Para resolver esse problema, sincronize o relógio da máquina cliente:
Verifique se a data, a hora e o fuso horário da máquina estão corretos.
Use um serviço de Network Time Protocol (NTP) para manter a hora do sistema sincronizada e verifique se o serviço está em execução e configurado corretamente.
Operações administrativas excessivas
Se você perceber que está gastando muito da
cota de operações administrativas,
talvez seja necessário refatorar o código. Para ilustrar, considere este pseudo-código. Neste exemplo, uma operação administrativa (GET) está sendo usada para verificar a presença de uma assinatura antes de tentar consumir os recursos dela. As operações GET e CREATE são do administrador:
if !GetSubscription my-sub {
CreateSubscription my-sub
}
Consume from subscription my-sub
Um padrão mais eficiente é tentar consumir mensagens da assinatura (supondo que você possa ter certeza razoável do nome da assinatura). Nesse caso, você só recebe ou cria a assinatura em caso de erro. Por exemplo,
try {
Consume from subscription my-sub
} catch NotFoundError {
CreateSubscription my-sub
Consume from subscription my-sub
}
É possível usar os exemplos de código a seguir para implementar esse padrão na linguagem de sua preferência:
Go
O exemplo a seguir usa a versão principal da biblioteca de cliente do Go Pub/Sub (v2). Se você ainda estiver usando a biblioteca v1, consulte o guia de migração para a v2. Para conferir uma lista de exemplos de código v1, consulte os exemplos de código obsoletos.
Antes de tentar esse exemplo, siga as instruções de configuração do Go em Guia de início rápido: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API Pub/Sub Go.
Java
Antes de tentar essa amostra, siga as instruções de configuração do Java em Guia de início rápido: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API Pub/Sub para Java (em inglês).
Node.js
Antes de tentar essa amostra, siga as instruções de configuração do Node.js em Guia de início rápido: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API Pub/Sub para Node.js (em inglês).
Node.ts
Antes de tentar essa amostra, siga as instruções de configuração do Node.js em Guia de início rápido: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API Pub/Sub para Node.js (em inglês).
Python
Antes de tentar esse exemplo, siga as instruções de configuração do Python em Guia de início rápido: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API Python do Pub/Sub.
C++
Antes de tentar esse exemplo, siga as instruções de configuração do C++ em Guia de início rápido: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API Pub/Sub C++.