Dépannage

Découvrez les étapes de dépannage qui pourraient vous être utiles si vous rencontrez des problèmes avec Cloud Pub/Sub.

Impossible de créer un abonnement

Vérifiez que vous avez réalisé toutes les actions suivantes :

  • Vous avez indiqué un nom pour l'abonnement dans le champ name. Pour les versions v1beta2 et ultérieures, le nom de l'abonnement doit se présenter sous la forme projects/project-identifier/subscriptions/subscription-name.
  • Vous avez saisi le nom d'un sujet existant auquel vous souhaitez vous abonner dans le champ topic. Pour les versions v1beta2 et ultérieures, le nom du sujet doit se présenter sous la forme projects/project-identifier/topics/topic-name.
  • Vous avez spécifié la chaîne https:// en minuscule, et non http:// ou HTTPS://, en tant que protocole pour votre URL de réception dans le champ pushEndpoint.

Aucun message reçu par l'abonné push

Vérifiez les éléments suivants :

  • Dans Stackdriver Monitoring, recherchez d'éventuelles erreurs liées à l'abonnement en question.
  • Sur App Engine, nous vous recommandons d'utiliser le préfixe /_ah/push-handlers/ dans le chemin de l'URL des points de terminaison, comme décrit dans la section relative à l'enregistrement des points de terminaison App Engine. L'utilisation de ce préfixe permet au point de terminaison de recevoir des messages en mode push de l'API Cloud Pub/Sub.
  • Dans les autres environnements, assurez-vous que votre URL de point de terminaison est accessible depuis Internet sans devoir s'identifier. Vous pouvez vérifier que l'URL n'est pas limitée en y accédant à l'aide d'un outil de diagnostic, tel que cURL.
  • Pour les domaines autres que appspot.com, veillez à enregistrer le domaine dans la console Google Cloud Platform. Pour en savoir plus, consultez la section relative à l'enregistrement d'autres points de terminaison.

Erreur 403 (Forbidden)

Si vous rencontrez cette erreur, procédez comme suit :

  • Assurez-vous d'avoir activé l'API Cloud Pub/Sub dans la console GCP.
  • Vérifiez que le principal à l'origine de la requête dispose des autorisations nécessaires sur les ressources de l'API Cloud Pub/Sub correspondantes, en particulier si vous vous servez de cette API pour communiquer entre plusieurs projets.
  • Si vous utilisez Cloud Dataflow, assurez-vous que <projectId>@cloudservices.gserviceaccount.com et le compte de service Compute Engine <projectId>-compute@developer.gserviceaccount.com ont les autorisations requises sur la ressource de l'API Cloud Pub/Sub appropriée. Pour en savoir plus, consultez la section concernant la sécurité et les autorisations de Google Cloud 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. Si ce n'est pas le cas, ajoutez votre compte de service App Engine en tant qu'éditeur. Normalement, le compte de service App Engine est au format suivant : <project-id>@appspot.gserviceaccount.com.

Gérer les messages en double et forcer les nouvelles tentatives

Si vous ne confirmez pas un la réception d'un message avant l'expiration de son délai de confirmation, Cloud Pub/Sub le renvoie. En conséquence, Cloud Pub/Sub peut envoyer des messages en double. Avec Stackdriver, surveillez les opérations de confirmation avec le code de réponse expired pour détecter cette condition. Une méthode permettant d'obtenir ces données est la métrique Acknowledge message operations (Opérations de message de confirmation), groupées par response_code (code_réponse).

Utilisation de Stackdriver pour rechercher des délais de confirmation de messages expirés

Pour réduire le taux de duplication, prolongez le délai du message :

  • Les bibliothèques clientes gèrent automatiquement la prolongation du délai, mais des limites par défaut s'appliquent au délai maximal de prolongation que vous pouvez configurer.
  • Si vous créez votre propre bibliothèque cliente, utilisez la méthode modifyAckDeadline pour prolonger le délai de confirmation.

D'un autre côté, si vous souhaitez forcer Cloud Pub/Sub à envoyer à nouveau un message, définissez modifyAckDeadline sur 0.

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. Ici, une opération d'administration (GET) est utilisée pour vérifier la présence d'un abonnement avant toute tentative d'utilisation de ses ressources. Notez que GET et CREATE sont des opérations d'administration :


    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
    }
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation sur Cloud Pub/Sub