Découvrez les étapes de dépannage qui pourraient vous être utiles si vous rencontrez des problèmes avec Pub/Sub.
Impossible de créer un sujet
Vérifiez que vous disposez des autorisations nécessaires
permissions.
Pour créer un sujet Pub/Sub, vous devez disposer
du rôle Identity and Access Management Éditeur Pub/Sub (roles/pubsub.editor)
sur le projet. Si vous ne disposez pas de ce rôle, contactez votre administrateur.
Pour en savoir plus sur le dépannage des sujets, consultez les pages suivantes :
Impossible de créer un abonnement
Vérifiez que vous avez effectué les opérations suivantes :
Vérifiez que vous disposez des autorisations nécessaires permissions. Pour créer un abonnement Pub/Sub, vous devez disposer du rôle IAM Éditeur Pub/Sub (roles/pubsub.editor) sur le projet. Si vous ne disposez pas de ce rôle, contactez votre administrateur.
Vous avez spécifié un nom pour l'abonnement.
Vous avez spécifié le nom d'un sujet existant auquel vous souhaitez associer l'abonnement.
Si vous créez un abonnement push, vous avez spécifié
https://en minuscule, et nonhttp://ouHTTPS://, en tant que protocole pour votre URL de réception dans le champpushEndpoint.
Pour en savoir plus sur le dépannage des abonnements, consultez les pages suivantes :
Résoudre les problèmes liés à l'extraction, au push, à BigQuery, ou à Cloud Storage
Résoudre les problèmes liés aux abonnements avec des transformations de message unique
Résoudre les problèmes d'autorisations
Les autorisations Pub/Sub contrôlent les utilisateurs et les comptes de service qui peuvent effectuer des actions sur vos ressources Pub/Sub. Lorsque les autorisations sont mal configurées, cela peut entraîner des erreurs d'autorisation refusée et perturber le flux de messages. Les journaux d'audit fournissent un enregistrement détaillé de toutes les modifications d'autorisation, ce qui vous permet d'identifier la source de ces problèmes.
Pour résoudre les problèmes d'autorisations Pub/Sub à l'aide des journaux d'audit :
Obtenez les autorisations requises pour afficher l'explorateur de journaux.
Pour plus d'informations, consultez la section Avant de commencer.
Dans la Google Cloud console, accédez à la page Explorateur de journaux.
Sélectionnez un projet, un dossier ou une organisation existants Google Cloud .
Voici une liste de filtres que vous pouvez utiliser pour trouver les journaux pertinents :
resource.type="pubsub_topic" OR resource.type="pubsub_subscription": utilisez cette requête comme point de départ lorsque vous résolvez un problème qui peut impliquer des modifications de la configuration d'un sujet ou d'un abonnement, ou du contrôle des accès. Vous pouvez la combiner avec d'autres filtres pour affiner votre recherche.protoPayload.methodName="google.iam.v1.SetIamPolicy": utilisez cette requête lorsque vous pensez qu'un problème est dû à des autorisations incorrectes ou manquantes. Elle vous permet de savoir qui a apporté des modifications à la stratégie IAM et quelles étaient ces modifications. Cela peut être utile pour résoudre des problèmes tels que des utilisateurs qui ne peuvent pas publier dans des sujets ni s'abonner à des abonnements, des applications dont l'accès aux ressources Pub/Sub est refusé ou des modifications inattendues du contrôle des accès.protoPayload.status.code=7: utilisez cette requête lorsque vous rencontrez des erreurs explicitement liées aux autorisations. Cela vous permet d'identifier les actions qui échouent et qui les tente. Vous pouvez combiner cette requête avec les précédentes pour identifier la ressource spécifique et la modification de la stratégie IAM qui peuvent être à l'origine du refus d'autorisation.
Analysez les journaux pour déterminer des facteurs tels que l'horodatage de l'événement, le compte principal qui a effectué la modification et le type de modifications apportées.
En fonction des informations collectées à partir des journaux d'audit, vous pouvez prendre des mesures correctives.
Résoudre les problèmes d'autorisations Terraform
Lorsque vous utilisez Pub/Sub avec Terraform, accordez explicitement les rôles requis dans votre code Terraform. Par exemple, pour la publication, le compte de service de votre application a besoin du rôle roles/pubsub.publisher. Si ce rôle n'est pas explicitement défini dans votre code Terraform, une future commande terraform apply pourrait le supprimer. Cela se produit souvent lors de mises à jour non liées, ce qui entraîne l'échec soudain d'une application fiable avec des erreurs PERMISSION_DENIED.
La définition explicite du rôle dans votre code empêche ces régressions accidentelles.
L'abonnement a été supprimé
Les abonnements Pub/Sub peuvent être supprimés de deux manières principales :
Un utilisateur ou un compte de service disposant des autorisations suffisantes supprime intentionnellement l'abonnement.
Un abonnement est automatiquement supprimé après une période d'inactivité, qui est de 31 jours par défaut. Pour en savoir plus sur la règle d'expiration des abonnements, consultez la section Période d'expiration.
Pour résoudre un problème lié à un abonnement supprimé, procédez comme suit :
Dans la Google Cloud console, accédez à la page Abonnements Pub/Sub et vérifiez que l'abonnement n'est plus listé. Pour en savoir plus sur la façon de lister les abonnements, consultez la section Lister un abonnement.
Consultez les journaux d'audit. Accédez à l'explorateur de journaux. Utilisez le filtre
protoPayload.methodName="google.pubsub.v1.Subscriber.DeleteSubscription"pour trouver les abonnements supprimés. Examinez les journaux pour déterminer si quelqu'un a supprimé l'abonnement ou s'il a été supprimé en raison d'une inactivité.InternalExpireInactiveSubscriptionindique qu'un abonnement a été supprimé en raison d'une inactivité. Pour en savoir plus sur l'utilisation des journaux d'audit à des fins de dépannage, consultez la section Résoudre les problèmes Pub/Sub à l'aide des journaux d'audit.
Erreur 403 (Forbidden)
Une erreur 403 signifie généralement que vous ne disposez pas des autorisations appropriées pour effectuer une action. Par exemple, vous pouvez recevoir une erreur 403 User not authorized lorsque vous essayez de publier dans un sujet ou d'extraire des données d'un abonnement.
Si vous rencontrez cette erreur, procédez comme suit :
- Assurez-vous d'avoir activé l'API Pub/Sub dans la Google Cloud console.
Vérifiez que le compte principal à l'origine de la requête dispose des autorisations nécessaires sur les ressources de l'API Pub/Sub correspondantes, en particulier si vous vous servez de cette API pour communiquer entre plusieurs projets.
Si vous utilisez Dataflow, assurez-vous que
{PROJECT_NUMBER}@cloudservices.gserviceaccount.comet le compte de service Compute Engine{PROJECT_NUMBER}-compute@developer.gserviceaccount.comdisposent des autorisations requises sur la ressource de l'API Pub/Sub appropriée. Pour en savoir plus, consultez la section Sécurité et autorisations pour Dataflow.Si vous utilisez App Engine, consultez la page relative aux autorisations de votre projet pour savoir si un compte de service App Engine est répertorié en tant qu'éditeur Pub/Sub. Si ce n'est pas le cas, ajoutez votre compte de service App Engine en tant qu'éditeur Pub/Sub. Normalement, le compte de service App Engine est au format
<project-id>@appspot.gserviceaccount.com.Vous pouvez utiliser les journaux d'audit pour résoudre les problèmes d'autorisations.
Autres codes d'erreur courants
Pour obtenir la liste des autres codes d'erreur courants liés à l'API Pub/Sub et leur description, consultez la section Codes d'erreur.
Délai de connexion expiré, latence ou erreurs réseau
Vous pouvez rencontrer des échecs intermittents ou persistants lorsque vos applications clientes Pub/Sub tentent de se connecter à Google Cloud des services. Ces problèmes peuvent se manifester comme suit :
- Retards importants lors de la publication de messages, ce qui peut entraîner des files d'attente d'applications.
- Erreurs de délai avant expiration, telles que gRPC
DEADLINE_EXCEEDED,code = DeadlineExceededoujava.net.SocketTimeoutException. - Échecs d'E/S réseau, tels que
UNAVAILABLE: io exceptionou erreursConnection refusedlorsque vous essayez d'accéder à des services tels quepubsub.googleapis.comouoauth2.googleapis.com.
Ces problèmes de connectivité peuvent survenir même sans modification de votre configuration Pub/Sub ni du code de votre application. Cela se produit fréquemment lorsque les pare-feu sur site ou VPC utilisent des listes d'autorisation d'adresses IP codées en dur pour les API Google. Les services Google, y compris Pub/Sub et ses dépendances telles que les services d'authentification, utilisent une plage dynamique d'adresses IP. Si votre pare-feu ne tient pas compte des nouvelles adresses IP, il peut bloquer le trafic vers ces nouvelles adresses, ce qui entraîne des échecs de connexion et d'authentification.
Pour garantir une connectivité stable, évitez les règles de pare-feu basées sur des adresses IP statiques pour les services Google. Effectuez plutôt les opérations suivantes :
- Configurez votre pare-feu pour autoriser le trafic à l'aide des plages d'adresses IP publiées par Google pour les domaines par défaut, plutôt que des adresses codées en dur. Pour savoir comment obtenir ces plages et automatiser les mises à jour de vos règles de pare-feu, consultez la section Adresses IP pour les domaines par défaut.
- Activez l'accès privé à Google, qui permet aux instances de votre réseau VPC d'accéder aux API et services Google sans passer par l'Internet public, ce qui simplifie la gestion du pare-feu.
JWT non valide : le jeton doit être un jeton à courte durée de vie
Si vous recevez une erreur telle que Invalid JWT: Token must be a short-lived token (60
minutes) and in a reasonable timeframe lorsque votre application interagit avec l'
API Pub/Sub, cela indique généralement un problème lié au timing des
identifiants d'authentification.
Cette erreur se produit lors de la validation du jeton Web JSON (JWT) utilisé pour authentifier les requêtes API. Une cause fréquente est une différence de temps significative (décalage temporel) entre la machine cliente exécutant la bibliothèque Pub/Sub et les serveurs d'authentification de Google. Étant donné que les JWT ont une fenêtre de validité limitée, les différences d'horloge peuvent les faire traiter comme expirés ou non encore valides.
Pour résoudre ce problème, synchronisez l'horloge de votre machine cliente :
Vérifiez que la date, l'heure et le fuseau horaire de votre machine sont corrects.
Utilisez un service NTP (Network Time Protocol) pour synchroniser l'heure du système et vérifiez que le service est en cours d'exécution et correctement configuré.
Utiliser des opérations d'administration excessives
Si vous constatez que vous utilisez une trop grande partie de votre
quota pour des opérations d'administration,
vous devrez peut-être refactoriser votre code. À titre d'exemple, intéressons-nous à ce pseudo-code. Dans cet exemple, une opération d'administration (GET) est utilisée pour vérifier la présence d'un abonnement avant de tenter de consommer ses ressources. GET et CREATE sont des opérations d'administrateur :
if !GetSubscription my-sub {
CreateSubscription my-sub
}
Consume from subscription my-sub
Un modèle plus efficace consiste à essayer de consulter des messages de l'abonnement (en supposant que vous soyez suffisamment sûr du nom de l'abonnement). Dans cette approche optimiste, vous n'accédez à l'abonnement ou ne le créez qu'en cas d'erreur. Considérez l'exemple suivant :
try {
Consume from subscription my-sub
} catch NotFoundError {
CreateSubscription my-sub
Consume from subscription my-sub
}
Vous pouvez utiliser les exemples de code suivants pour implémenter ce modèle dans le langage de votre choix :
Go
L'exemple suivant utilise la version majeure de la bibliothèque cliente Go Pub/Sub (v2). Si vous utilisez toujours la bibliothèque v1, consultez le guide de migration vers la v2. Pour afficher la liste des exemples de code v1, consultez les exemples de code obsolètes.
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Go qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub pour Go.
Java
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Java qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub pour Java .
Node.js
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Node.js qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub pour Node.js.
Node.ts
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Node.js qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub pour Node.js.
Python
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Python qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour Python.
C++
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage C++ qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub pour C++ .