Dépannage

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 abonnement

Vérifiez que vous avez:

  • 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é https:// en minuscule, et non http:// ou HTTPS://, en tant que protocole pour votre URL de réception dans le champ pushEndpoint.

403 (Forbidden) erreur

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

  • Assurez-vous d'avoir activé l'API Pub/Sub dans la console Google Cloud.
  • Vérifiez que le 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 <projectId>@cloudservices.gserviceaccount.com et le compte de service Compute Engine <projectId>-compute@developer.gserviceaccount.com disposent 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 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 tentatives

Si vous ne confirmez pas la réception d'un message avant l'expiration de son délai de confirmation, Pub/Sub le renvoie. En conséquence, Pub/Sub peut envoyer des messages en double. Utilisez Cloud Monitoring pour surveiller les opérations de confirmation à l'aide du code de réponse expired afin de détecter cette condition. Pour obtenir ces données, sélectionnez la métrique subscription/expired_ack_deadlines_count.

Utiliser Cloud Monitoring pour rechercher les délais de confirmation des messages arrivés à expiration

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.

Sinon, pour forcer Pub/Sub à renvoyer 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
    }