Ce document fournit des conseils de dépannage courants pour les abonnements Pub/Sub StreamingPull. Les abonnements StreamingPull utilisent l'API StreamingPull.
Pour en savoir plus sur les abonnements StreamingPull, consultez le Guide pour les abonnés Pull.
Le taux d'erreur de StreamingPull est de 100 %.
Les flux StreamingPull se ferment toujours avec un état non OK. Contrairement aux RPC unaires, cet état pour StreamingPull indique simplement que le flux est interrompu. Les requêtes n'échouent pas. Par conséquent, bien que l'API StreamingPull ait un taux d'erreur surprenant de 100 %, ce comportement est inhérent à sa conception.
Erreurs de condition préalable non remplie, d'indisponibilité ou de contenu introuvable
Étant donné que les flux StreamingPull se ferment toujours avec une erreur, il n'est pas utile d'examiner les métriques d'arrêt du flux lors du diagnostic des erreurs. Concentrez-vous plutôt sur la métrique de réponse StreamingPull, telle que subscription/streaming_pull_response_count.
Recherchez les erreurs suivantes :
Erreurs de condition préalable ayant échoué qui peuvent se produire dans les cas suivants:
Pub/Sub tente de déchiffrer un message avec une clé Cloud KMS désactivée.
Les abonnements sont temporairement suspendus si des messages en attente d'abonnement sont chiffrés avec une clé Cloud KMS désactivée.
Erreurs non disponibles pouvant se produire lorsque Pub/Sub ne parvient pas à traiter une requête. Il s'agit très probablement d'une condition temporaire, et la bibliothèque cliente relance les requêtes.
Erreurs introuvables qui peuvent se produire lorsque l'abonnement est supprimé ou s'il n'a jamais existé. Le second cas se produit lorsque vous fournissez un chemin d'abonnement non valide.
Nombre important de petits messages en attente dans un abonnement StreamingPull
La pile gRPC de StreamingPull est optimisée pour un débit élevé et assure donc la mise en mémoire tampon des messages. Si vous essayez de traiter un volume important de petits messages en attente, il est possible que les messages soient distribués plusieurs fois. L'équilibrage de charge de ces messages peut ne pas être efficace entre les clients.
Le tampon entre le service Pub/Sub et l'espace utilisateur de la bibliothèque cliente est d'environ 10 Mo. Pour comprendre l'effet de ce tampon sur le comportement de la bibliothèque cliente, prenons l'exemple suivant:
Il y a un traitement en attente de 10 000 messages de 1 Ko sur un abonnement.
Chaque message prend une seconde pour le traitement séquentiel effectué par une instance de client monothread.
La première instance de client à établir une connexion StreamingPull avec le service pour cet abonnement remplit son tampon avec les 10 000 messages.
Le traitement du tampon prend 10 000 secondes (presque trois heures).
Pendant ce temps, certains messages mis en mémoire tampon dépassent les délais de confirmation et sont renvoyés au même client, ce qui entraîne des doublons.
Lorsque plusieurs instances de client sont en cours d'exécution, les messages bloqués dans le tampon d'un client ne sont disponibles pour aucune autre instance de client. Cette situation ne se produit pas si vous utilisez le contrôle de flux pour StreamingPull. Le service ne dispose jamais des 10 Mo de messages en même temps et est capable d'équilibrer efficacement la charge des messages entre plusieurs abonnés.