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

Assurez-vous d'avoir effectué les opérations 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é 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 Cloud 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 l'enregistrement des points de terminaison App Engine. Ce code permet au point de terminaison de recevoir des messages en mode push depuis l'API 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 Google Cloud Console. Pour en savoir plus, consultez la section sur l'enregistrement d'autres points de terminaison.

La diffusion de messages en mode push est en retard de plusieurs heures

Un message en mode push non confirmé peut retarder la diffusion de nouveaux messages. Un message n'est pas confirmé si le point de terminaison push échoue ou renvoie un code d'état différent de 200, 201, 202, 204 ou 102. Pour régler ce problème de retard, mettez à jour le code de point de terminaison pour qu'il gère les messages ayant échoué ou extrayez manuellement ces messages avant de les confirmer. Pour en savoir plus sur la détection de messages non confirmés et la création d'alertes, consultez la page Présentation de la surveillance.

Erreur 403 (Forbidden)

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

  • Assurez-vous d'avoir activé l'API Pub/Sub dans Cloud Console.
  • 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 la suite des opérations de Google Cloud à des fins de surveillance des opérations de confirmation avec le code de réponse expired pour détecter cette condition. Pour obtenir ces données, sélectionnez la métrique Acknowledge message operations (Opérations de message de confirmation), puis regroupez ou filtrez ces données à l'aide de l'étiquette response_code. Notez que response_code n'est pas une métrique, mais un libellé système sur une métrique.

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 Pub/Sub à envoyer à nouveau un message, définissez modifyAckDeadline sur 0.

Échec des opérations de publication avec erreur DEADLINE_EXCEEDED

Ce problème est probablement dû à un goulot d'étranglement côté client, tel que des processeurs de service insuffisants, un mauvais état de thread ou un encombrement du réseau. Si un appel Publish renvoie DEADLINE_EXCEEDED, les appels Publish asynchrones sont en file d'attente plus rapidement qu'ils ne sont envoyés au service, ce qui augmente progressivement la latence des requêtes. Pour déterminer le débit Publish avec une seule VM pour différents paramètres (cœurs, nœuds de calcul, taille des messages), consultez la page Tester les clients Cloud Pub/Sub pour optimiser les performances de diffusion. Vous pouvez également exécuter une version de la bibliothèque cliente qui présente un problème connu. Consultez l'outil de suivi des problèmes de votre bibliothèque cliente.

Enfin, il est possible que le délai que vous avez défini soit inférieur aux performances habituelles de latence de publication de Pub/Sub. Il est recommandé de définir le délai initial sur 10 secondes et le délai total avant expiration sur 600 secondes.

Vérifiez si l'un des éléments suivants vous permet de résoudre le problème :

  • Vérifiez si vous publiez des messages plus rapidement que le client ne peut les envoyer. En général, chaque appel Publish asynchrone renvoie un objet Future. Pour suivre le nombre de messages en attente d'envoi, stockez le nombre de messages à envoyer avec cet appel de publication et supprimez-le uniquement dans le rappel de l'objet Future. Lorsque vous effectuez des appels Publish plus rapidement que les requêtes correspondantes au service Pub/Sub, la latence d'un appel Publish individuel effectué ultérieurement augmente considérablement.
  • Vérifiez que vous disposez d'une bande passante de transfert suffisante entre la machine sur laquelle l'éditeur est exécuté et Google Cloud. Il est courant que les réseaux Wi-Fi utilisés pour le développement aient une bande passante comprise entre 1 et 10 Mo/s, soit 1 000 à 1 000 messages par seconde. La publication de ces messages en boucle et sans limitation de débit peut générer une courte période d'utilisation intensive de bande passante. Vous pouvez obtenir davantage de bande passante en exécutant l'éditeur sur une machine dans GCP ou en réduisant la vitesse à laquelle vous publiez les messages pour correspondre à votre bande passante disponible.
  • Assurez-vous que votre délai avant expiration est assez long pour l'appel défini dans les paramètres de nouvelle tentative. Dans certains cas, les pics de latence des requêtes entraînent des erreurs, même si vous n'accumulez pas un volume important de messages non envoyés en attente. L'augmentation du délai initial à 10 secondes et du délai avant expiration total à 600 secondes entraîne une baisse du taux des délais avant expiration. Notez que si vos problèmes sont causés par un goulot d'étranglement persistant plutôt que par des délais avant expiration occasionnels, des tentatives plus fréquentes vont entraîner davantage d'erreurs.
  • Vérifiez si la latence entre votre hôte et Google Cloud est très élevée pour des raisons telles que l'encombrement du réseau de démarrage ou les pare-feu. Le calcul du débit du réseau permet de déterminer la bande passante et la latence adaptées à différents scénarios.
  • Passez à la dernière version de la bibliothèque cliente. Assurez-vous d'avoir sélectionné toutes les mises à jour pertinentes qui pourraient inclure des correctifs tels que des améliorations des performances.
  • Vérifiez si la VM hébergeant le client éditeur manque de ressources, y compris le processeur, la mémoire RAM et les threads. Il se peut que l'appel attende trop longtemps pour être programmé avant d'envoyer une requête au service.
  • À terme, le volume de données pouvant être publiées sur une seule machine est limité. Vous devrez peut-être essayer de procéder au scaling horizontal ou exécuter plusieurs instances du client éditeur sur plusieurs machines. La section Tester les clients Cloud Pub/Sub pour optimiser les performances de diffusion montre comment Pub/Sub évolue sur une seule VM Google Cloud avec une augmentation du nombre de processeurs. Par exemple, vous pouvez atteindre 500 Mo/s à 700 Mo/s pour les messages de 1 Ko sur une instance Compute Engine à 16 cœurs.

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
    }