Ce document fournit des conseils de dépannage courants pour les abonnements pull Pub/Sub. Pour en savoir plus sur les abonnements pull, consultez le Guide pour les abonnés pull.
Pour surveiller efficacement votre abonnement Pub/Sub, nous vous recommandons de commencer par examiner le score d'état de latence de distribution (subscription/delivery_latency_health_score) pour vérifier quels facteurs peuvent contribuer à une latence inattendue ou accrue.
L'ancienneté du plus ancien message non confirmé ne cesse d'augmenter
La métrique oldest_unacked_message_age est essentielle pour surveiller l'état des abonnements Pub/Sub. Elle mesure l'âge, en secondes, du plus ancien message en attente d'un abonnement qui n'a pas encore été confirmé (confirmé) par un abonné. Cette métrique fournit des informations précieuses sur les retards de traitement ou les goulots d'étranglement potentiels.
La surveillance des messages en attente garantit un traitement rapide et efficace des messages. En suivant l'âge du plus ancien message non confirmé, vous pouvez identifier de manière proactive les situations dans lesquelles les consommateurs prennent du retard. Cette pratique permet d'intervenir rapidement pour résoudre les problèmes potentiels liés à une dégradation des performances.
Voici quelques-uns des problèmes courants en attente que vous pouvez examiner:
Problèmes de configuration du client
Lorsque les métriques oldest_unacked_message_age et num_undelivered_messages augmentent simultanément, cela peut signifier que les abonnés ne parviennent pas à suivre le volume de messages. Dans ce cas, concentrez-vous sur les composants de l'abonnement:
État du client: analysez l'utilisation des ressources sur les machines hébergeant des clients abonnés, telles que le processeur, la mémoire et la bande passante réseau. Recherchez les points de pression qui pourraient nuire à l'efficacité du traitement.
Code client: examinez les modifications récentes du code et examinez les journaux d'erreurs. Des bugs ou des inefficacités dans le code d'abonné peuvent avoir un impact significatif sur les tarifs de traitement des messages. Notez que certains messages peuvent présenter des problèmes. Par exemple, plusieurs messages peuvent avoir besoin d'accéder simultanément à la même ligne d'une base de données. Ce comportement peut entraîner des conflits et une latence élevée.
Limites de quota: vérifiez que vous n'avez pas dépassé les quotas ni les limites Pub/Sub imposés par votre service d'hébergement. Si les abonnés sont hébergés dans Google Cloud, examinez les quotas de ressources Compute Engine ou GKE pour éviter les éventuels goulots d'étranglement.
L'abonné a accusé réception négative des messages
Lorsqu'un abonné confirme la réception d'un message de manière négative (signifiant son absence), il signale à Pub/Sub que le message n'a pas pu être traité correctement. Pub/Sub tente ensuite de redistribuer le même message. Des erreurs répétées d'affichage d'un message entraînent la création de doublons et potentiellement un retard important dans la distribution des messages.
Notez que l'omission d'un message ne garantit pas qu'un autre message sera récupéré lors de la prochaine extraction. La règle de redistribution de Pub/Sub peut continuer à redistribuer les messages bloqués avant les nouveaux. Par conséquent, ne vous fiez pas aux nacks pour filtrer ou ignorer des messages spécifiques. Définissez plutôt une règle de nouvelle tentative, de préférence un intervalle exponentiel entre les tentatives, pour arrêter la diffusion sur des messages individuels susceptibles d'être traités plus tard, mais qui nécessitent un peu plus de temps avant d'être à nouveau distribués.
Si vous devez ignorer intentionnellement certains messages, nous vous recommandons de les confirmer, même si vous ne les traitez pas. Cela les supprime de l'abonnement, évite des renvois inutiles et réduit la consommation de ressources. Le fait de laisser les messages non confirmés, que ce soit intentionnellement ou non, crée des problèmes en attente et des diffusions en double.
Latence de diffusion élevée
Dans Pub/Sub, la latence de distribution est le temps nécessaire pour qu'un message d'un éditeur parvienne à un abonné. Certaines causes possibles d'une latence de distribution élevée sont décrites dans les sections suivantes.
Nombre d'abonnés insuffisant
Si vous utilisez StreamingPull, maintenez plusieurs connexions StreamingPull ouvertes avec votre abonnement afin d'obtenir une latence toujours faible. Sans connexion d'abonné active, Pub/Sub ne peut pas distribuer rapidement les messages. Un seul flux peut être un point de défaillance unique, ce qui augmente le risque de retards. La métrique subscription/open_streaming_pulls offre une visibilité sur le nombre de connexions en flux continu actives. Cette option vous permet de vous assurer que vous disposez systématiquement de suffisamment de flux pour gérer les messages entrants.
Si vous utilisez le mode pull unaire, assurez-vous de gérer plusieurs demandes d'extraction en attente pour votre abonnement afin d'obtenir une latence toujours faible. Les requêtes peu fréquentes peuvent potentiellement accumuler des messages en attente et augmenter la latence. Cette approche permet de réduire les écarts de connectivité et d'améliorer la latence de livraison.
La bibliothèque cliente de haut niveau est recommandée dans les cas où vous avez besoin d'un débit élevé et d'une faible latence avec des coûts d'exploitation et de traitement minimaux. Par défaut, la bibliothèque cliente de haut niveau utilise l'API StreamingPull, car elle est généralement plus adaptée pour réduire la latence. Les bibliothèques clientes de haut niveau contiennent des fonctions et des classes prédéfinies qui gèrent les appels d'API sous-jacents pour l'authentification, l'optimisation du débit et de la latence, la mise en forme des messages et d'autres fonctionnalités.
Problèmes de configuration du client
Consultez la section Problèmes de configuration du client.
En attente élevé
Notez qu'un nombre de messages non confirmés en attente dans un abonnement Pub/Sub augmente intrinsèquement la latence de bout en bout, car les messages ne sont pas traités immédiatement par les abonnés.
Ordre des clés et distribution de type "exactement une fois"
Les clés de commande et la distribution de type "exactement une fois" sont des fonctionnalités intéressantes, mais elles nécessitent une coordination supplémentaire au sein de Pub/Sub pour garantir une distribution correcte. Cette coordination peut réduire la disponibilité et augmenter la latence. Bien que la différence soit minime à l'état stable, toute étape de coordination nécessaire peut entraîner une augmentation temporaire de la latence ou du taux d'erreur. Si le tri est activé, les messages avec une clé de tri ne peuvent pas être distribués tant que les messages précédents avec la même clé de tri ne sont pas ACK.
Déterminez si l'ordre des messages ou la distribution "exactement une fois" sont absolument essentiels pour votre application. Si votre priorité est une faible latence, vous pouvez réduire les délais de traitement des messages en réduisant au maximum l'utilisation de ces fonctionnalités.
Augmentation de la taille des messages
Une augmentation soudaine de la taille des messages peut potentiellement augmenter le temps de transfert entre Pub/Sub et votre client, et ralentir le traitement des messages côté client.
Si vous observez une augmentation de la latence de distribution, vous pouvez vérifier la taille des messages à l'aide de la métrique topic/message_sizes, en les regroupant par topic_id. Corrélez les pics de taille des messages avec les problèmes de performances observés.
Messages manquants
Si vous pensez que des messages ne sont pas distribués correctement à votre abonné, l'une des raisons suivantes peut être à l'origine du problème.
Distribution des messages dans les abonnements Pub/Sub avec plusieurs consommateurs
Dans Pub/Sub, les messages peuvent être répartis de manière inégale entre les consommateurs. Ce comportement est dû au fait que Pub/Sub distribue les messages entre les consommateurs actifs pour plus d'efficacité. Parfois, un même consommateur peut recevoir moins de messages que prévu ou un sous-ensemble de messages différent de celui des autres consommateurs.
Notez que les messages peuvent déjà être en attente pour les clients et qu'un nombre important de messages non confirmés en attente ne signifie pas nécessairement que vous les recevrez lors de votre prochaine demande d'extraction d'extraction. N'oubliez pas qu'un client peut utiliser le mode pull de la console Google Cloud ou Google Cloud CLI, ou exécuter un abonné personnalisé localement pour vérifier les messages.
Pour les clients pull unaires, il se peut que certaines requêtes ne renvoient aucun message. Comme indiqué dans la section Nombre d'abonnés insuffisant, il est recommandé de conserver plusieurs demandes d'extraction en attente, car certaines requêtes peuvent renvoyer un nombre de messages inférieur au nombre maximal configuré ou même zéro.
Si vous soupçonnez l'un de ces comportements, vérifiez si plusieurs consommateurs sont simultanément associés à l'abonnement et examinez-les.
Filtrer sur l'abonnement
Vérifiez si l'abonnement est associé à un filtre. Dans ce cas, vous ne recevez que les messages correspondant au filtre. Le service Pub/Sub reconnaît automatiquement les messages qui ne correspondent pas au filtre. Réfléchissez à l'impact des filtres sur les métriques de tâches en attente.
Utiliser l'option returnImmediately
Si votre client utilise le mode pull unaire, vérifiez si le champ returnImmediately est défini sur "true". Il s'agit d'un champ obsolète qui indique au service Pub/Sub de répondre immédiatement à la demande d'extraction, même si elle est renvoyée sans message. Par conséquent, les demandes d'extraction peuvent être renvoyées sans aucun message, même en cas de retard.
Gérer les doublons
La duplication de messages dans Pub/Sub se produit souvent lorsque les abonnés ne peuvent pas confirmer les messages dans le délai de confirmation. Les messages sont alors à nouveau distribués, ce qui crée l'impression de doublons. Vous pouvez mesurer le taux de non-respect du délai de confirmation par les abonnés à l'aide de la métrique subscription/expired_ack_deadlines_count. Découvrez comment surveiller l'expiration du délai de confirmation.
Pour réduire le taux de duplication, prolongez les délais des messages.
- Les bibliothèques clientes gèrent automatiquement les extensions de délai. Toutefois, il existe des limites par défaut concernant le délai maximal de prolongation que vous pouvez configurer.
- Si vous créez votre propre bibliothèque cliente, utilisez la méthode
modifyAckDeadlinepour prolonger le délai de confirmation.
Si les messages sont récupérés dans l'abonné plus rapidement qu'ils ne peuvent être traités et confirmés, certains messages peuvent expirer et nécessiter des extensions de délai. Toutefois, si l'abonné reste submergé, les extensions de délai répétées finissent par échouer. Dans le pire des cas, cela peut entraîner une augmentation du nombre d'abonnés en double, aggravant ainsi les tâches en attente. Les doublons arrivant à expiration, puis en générant de nouveaux
Pour éviter de submerger l'abonné, réduisez le nombre de messages qu'il récupère en même temps. De cette façon, l'abonné a moins de messages à traiter dans le délai imparti. Moins de messages arrivent à expiration et moins de messages sont redistribués.
Pour réduire le nombre de messages que l'abonné extrait en même temps, vous devez réduire le paramètre "Nombre maximal de messages en attente" dans la configuration du contrôle de flux de votre abonné. Il n'existe pas de valeur universelle. Vous devez donc ajuster la limite maximale de messages en attente en fonction de votre débit et de la capacité de vos abonnés. Gardez à l'esprit que chaque application traite les messages différemment et que leur accusé de réception prend un temps différent.
Forcer les nouvelles tentatives
Pour forcer Pub/Sub à réessayer d'envoyer un message, envoyez une requête nack. Si vous n'utilisez pas les bibliothèques clientes de haut niveau, envoyez une requête modifyAckDeadline en définissant ackDeadlineSeconds sur 0.
Trier les clés
Lorsque Pub/Sub redistribue un message avec une clé de tri, il redistribue également tous les messages suivants ayant la même clé de tri, même s'ils ont déjà été confirmés. Cela permet de préserver l'ordre de la séquence. Toutefois, il n'y a aucune garantie stricte que les messages dépendants ne soient envoyés qu'après la suppression réussie des messages précédents de la séquence.
L'abonné ne comprend pas les messages
Consultez la section L'abonné ne traite pas les messages.
Résoudre les problèmes liés à un abonnement StreamingPull
Les flux StreamingPull se ferment toujours avec un état non OK. Contrairement à un état d'erreur pour les RPC unaires, cet état pour StreamingPull n'est qu'une indication que le flux est déconnecté. Les requêtes n'échouent pas. Par conséquent, bien que l'API StreamingPull puisse avoir un taux d'erreur surprenant de 100 %, ce comportement est inhérent à sa conception.
É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 de flux lors du diagnostic des erreurs. Concentrez-vous plutôt sur la métrique de réponse StreamingPull subscription/streaming_pull_response_count, regroupée par response_code ou response_class.
Recherchez les erreurs suivantes :
Des erreurs de condition préalable ayant échoué peuvent se produire si des messages en attente d'abonnement sont chiffrés avec une clé Cloud KMS désactivée. Pour reprendre l'extraction, restaurez l'accès à la clé.
Des erreurs non disponibles peuvent se produire lorsque Pub/Sub ne parvient pas à traiter une requête. Il s'agit probablement d'un état temporaire et la bibliothèque cliente relance les requêtes. Aucune action de votre part n'est requise si vous utilisez une bibliothèque cliente.
Les erreurs Introuvable peuvent se produire lorsque l'abonnement est supprimé ou s'il n'a jamais existé. Le second cas se produit si vous avez fourni un chemin d'abonnement non valide.