Saiba mais sobre as etapas de solução de problemas que podem ser úteis se você tiver problemas ao usar o Pub/Sub.
Não é possível criar um tópico
Verifique se você tem as permissões necessárias.
Para criar um tópico do Pub/Sub, você precisa da função Editor do Pub/Sub (roles/pubsub.editor) do Identity and Access Management no projeto. Se você não tiver essa função, entre em contato com o administrador.
Para mais informações sobre 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. Para criar uma assinatura do Pub/Sub, você precisa do papel do IAM Editor do Pub/Sub (roles/pubsub.editor) no projeto. Se você não tiver essa função, entre em contato com o administrador.
Especificou um nome para a assinatura.
Especificou o nome de um tópico atual a que você quer anexar a assinatura.
Se você estiver criando uma assinatura por push, especifique
https://no campopushEndpointcomo o protocolo para o URL de recebimento em letras minúsculas, nãohttp://ouHTTPS://.
Para mais informações sobre a solução de problemas de assinaturas, consulte as seguintes páginas:
Solução de problemas de pull, push, BigQuery ou Cloud Storage
Solução de problemas com assinaturas usando transformações de mensagens únicas
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 seus recursos do Pub/Sub. Quando as permissões são configuradas incorretamente, 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 identificar a origem desses problemas.
Para resolver problemas de permissão do Pub/Sub com registros de auditoria:
Consiga as permissões necessárias para acessar o Análise de registros.
Para mais informações, consulte Antes de começar.
No console do Cloud de Confiance , acesse a página Análise de registros.
Selecione um projeto, uma pasta ou uma organização do Cloud de Confiance .
Confira uma lista de filtros que você pode usar para encontrar registros relevantes:
resource.type="pubsub_topic" OR resource.type="pubsub_subscription": use essa consulta como ponto de partida ao resolver problemas que possam envolver mudanças nas configurações de tópicos ou assinaturas, ou controle de acesso. Você pode combinar esse filtro com outros para refinar ainda mais sua pesquisa.protoPayload.methodName="google.iam.v1.SetIamPolicy": use esta consulta quando suspeitar que um problema é causado por permissões incorretas ou ausentes. Ele ajuda a rastrear quem fez as 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 assinar assinaturas, aplicativos com acesso negado a recursos do Pub/Sub ou mudanças inesperadas no controle de acesso.protoPayload.status.code=7: use esta consulta quando encontrar erros explicitamente relacionados a permissões. Isso ajuda a identificar quais ações estão falhando e quem está tentando executá-las. Você pode 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 dos registros de auditoria, você pode tomar medidas corretivas.
Resolver problemas de permissão do Terraform
Ao usar o Pub/Sub com o Terraform, conceda explicitamente as funções necessárias no código do Terraform. Por exemplo, para publicar, a conta de serviço do
aplicativo precisa da função roles/pubsub.publisher. Se
essa função não estiver definida explicitamente no seu código do Terraform, uma futura
terraform apply poderá removê-la. Isso geralmente acontece durante atualizações não relacionadas, fazendo com que um aplicativo confiável falhe repentinamente com erros PERMISSION_DENIED.
Definir explicitamente a função no código evita 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 uma 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 da assinatura, consulte Período de expiração.
Para resolver problemas com uma assinatura excluída, siga estas etapas:
No console Cloud de Confiance , acesse a página "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 as inscrições 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 por 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.
403 (Forbidden) erro
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 esse erro aparecer, faça o seguinte:
- Verifique se você ativou a API Pub/Sub no consoleCloud de Confiance .
Confira se quem fez a solicitação tem as permissões necessárias nos recursos relevantes da API Pub/Sub, especialmente se ela estiver sendo usada para a comunicação entre projetos.
Se você usa o Dataflow, verifique se o
{PROJECT_NUMBER}@cloudservices.s3ns-system.iam.gserviceaccount.come a conta de serviço do Compute Engine{PROJECT_NUMBER}-compute@developer.s3ns-system.iam.gserviceaccount.comtêm as permissões necessárias no recurso da API Pub/Sub relevante. Para mais informações, consulte Segurança e permissões do Dataflow.Se você estiver 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 tem o formato
<project-id>@appspot.s3ns-system.iam.gserviceaccount.com.Use os registros de auditoria para resolver problemas de permissão.
Outros códigos de erro comuns
Para ver 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 aos serviços do Cloud de Confiance by S3NS. Esses problemas podem se manifestar como:
- Atrasos significativos na publicação de mensagens, o que pode causar backlogs de aplicativos.
- Erros de tempo limite, como gRPC
DEADLINE_EXCEEDED,code = DeadlineExceededoujava.net.SocketTimeoutException. - Falhas de E/S de rede, como erros
UNAVAILABLE: io exceptionouConnection refusedao tentar acessar serviços comopubsub.googleapis.comouoauth2.googleapis.com.
Esses problemas podem surgir mesmo sem mudanças na configuração do Pub/Sub ou no código do aplicativo. Isso acontece com frequência quando firewalls locais ou da VPC usam listas de permissão de endereços IP codificados 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 os novos endereços IP, ele poderá bloquear o tráfego para eles, 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 pelo Google para domínios padrão em vez de endereços codificados. Para saber como obter esses intervalos e automatizar as atualizações das regras de firewall, consulte Endereços IP para domínios padrão.
- Ative o Acesso privado do Google, que permite que as instâncias na sua rede VPC alcancem APIs e serviços do Google sem passar pela 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 interagir 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 estão corretos na sua máquina.
Use um serviço Network Time Protocol (NTP) para manter o tempo do sistema sincronizado 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 pseudocó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ê esteja razoavelmente seguro 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
}
Use os exemplos de código a seguir para implementar esse padrão na linguagem de sua escolha:
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 da v1, consulte os exemplos de código descontinuados.
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 Java.
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 Node.js.
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 Node.js.
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 Pub/Sub Python.
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++.