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 – Mode 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) afin de vérifier quels facteurs peuvent contribuer à une latence inattendue ou accrue.
Âge du plus ancien message non confirmé ne cesse d'augmenter
oldest_unacked_message_age est une métrique essentielle pour surveiller l'état des abonnements Pub/Sub. Elle mesure l'âge, en secondes, du message le plus ancien de la file d'attente d'un abonnement qui n'a pas encore été confirmé par un abonné. Cette métrique fournit des insights intéressants sur les retards ou goulots d'étranglement potentiels de traitement.
Surveiller le traitement des messages en attente permet de traiter les messages de manière rapide et efficace. En suivant l'âge du message le plus ancien qui n'a pas fait l'objet d'un accusé de réception, vous pouvez identifier de manière proactive les situations où les consommateurs sont en retard. Cette pratique permet d'intervenir rapidement pour résoudre les problèmes potentiels liés à la dégradation des performances.
Voici quelques-uns des problèmes courants liés à la pile de demandes 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 suivent pas le volume de messages. Dans ce cas, concentrez votre investigation sur les composants d'abonnement:
État du client: analysez l'utilisation des ressources sur les machines hébergeant des clients abonnés, comme le processeur, la mémoire et la bande passante réseau. Recherchez les points de pression susceptibles d'entraver l'efficacité du traitement.
Code client: examinez les modifications récentes du code et les journaux d'erreurs. Les bugs ou les inefficacités du code de l'abonné peuvent avoir un impact significatif sur les taux de traitement des messages. Notez que des problèmes peuvent se produire dans des messages spécifiques. 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 ou les limites Pub/Sub imposés par votre service d'hébergement. Si les abonnés sont hébergés dans Google Cloud, vérifiez les quotas de ressources Compute Engine ou GKE pour éviter les goulots d'étranglement potentiels.
L'abonné a refusé les messages
Lorsqu'un abonné refuse de confirmer la réception d'un message, il indique à Pub/Sub que le message n'a pas pu être traité. Pub/Sub tente ensuite de redistribuer le même message. Les nacks répétés pour un message entraînent des doublons et potentiellement un retard important dans la distribution du message.
Notez que le nack d'un message ne garantit pas que l'extraction suivante récupère un message différent. La stratégie de nouvelle diffusion de Pub/Sub peut continuer à renvoyer les messages non distribués avant les nouveaux. Par conséquent, ne vous appuyez pas sur les nacks pour filtrer ou ignorer des messages spécifiques. Définissez plutôt une stratégie de nouvelle tentative, de préférence un intervalle exponentiel entre les tentatives, pour retarder le traitement des messages individuels qui sont susceptibles d'être traités plus tard, mais qui ont besoin d'un délai un peu plus long avant d'être renvoyés.
Si vous devez ignorer intentionnellement certains messages, nous vous recommandons de les confirmer, même si vous ne les traitez pas. Ils sont ainsi supprimés de l'abonnement, ce qui évite les renvois inutiles et réduit la consommation de ressources. Laisser des messages non confirmés, que ce soit intentionnellement ou non, crée des problèmes de retard et de distribution en double.
Latence de diffusion élevée
La latence de distribution dans Pub/Sub correspond au temps nécessaire pour qu'un message d'un éditeur atteigne un abonné. Certaines causes possibles d'une latence de diffusion élevée sont décrites dans les sections suivantes.
Nombre d'abonnés insuffisant
Pour les clients qui utilisent StreamingPull, maintenez plusieurs connexions StreamingPull ouvertes à votre abonnement afin d'obtenir une latence faible et constante. Sans connexions d'abonnés actives, Pub/Sub ne peut pas distribuer les messages rapidement. Un seul flux peut constituer un point de défaillance unique, ce qui augmente le risque de retards. La métrique subscription/open_streaming_pulls permet de connaître le nombre de connexions de streaming actives. Vous pouvez ainsi vous assurer de disposer en permanence de suffisamment de flux pour gérer les messages entrants.
Pour les clients qui utilisent la méthode pull unaire, pour obtenir une latence faible et constante, conservez plusieurs requêtes pull en attente pour votre abonnement. Les requêtes peu fréquentes peuvent entraîner l'accumulation de messages dans la file d'attente et augmenter la latence. Cette approche permet de réduire les lacunes de connectivité et d'améliorer la latence de diffusion.
La bibliothèque cliente de haut niveau est recommandée lorsque vous avez besoin d'un débit élevé et d'une latence faible, avec un coût de traitement et des frais opérationnels 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.
Pile d'attente élevée
Notez qu'un arriéré de messages non confirmés 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.
Clés de tri et distribution de type "exactement une fois"
Les clés de tri et la distribution de type "exactement une fois" sont des fonctionnalités utiles, mais elles nécessitent une coordination supplémentaire dans Pub/Sub pour garantir une diffusion correcte. Cette coordination peut réduire la disponibilité et augmenter la latence. Bien que la différence soit minime à l'état stable, les étapes de coordination nécessaires peuvent entraîner une augmentation temporaire de la latence ou un taux d'erreur plus élevé. 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 n'ont pas été confirmés.
Déterminez si l'ordre des messages ou la distribution de type "exactement une fois" sont absolument essentiels pour votre application. Si la faible latence est votre priorité absolue, vous pouvez réduire les délais de traitement des messages en limitant 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 temps de traitement des messages côté client.
Si vous constatez une augmentation de la latence de diffusion, vous pouvez vérifier la taille des messages à l'aide de la métrique topic/message_sizes, en regroupant par topic_id. Correlez les pics de taille des messages avec les problèmes de performances observés.
Messages manquants
Si vous pensez que les messages ne sont pas distribués à 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 distribués de manière inégale entre les consommateurs. Ce comportement se produit, car Pub/Sub distribue les messages entre les consommateurs actifs pour plus d'efficacité. Il arrive qu'un seul consommateur reçoive moins de messages que prévu ou un sous-ensemble de messages différent de celui des autres consommateurs.
Notez que des messages peuvent déjà être en attente auprès des clients. Un arriéré de messages non confirmés ne signifie pas nécessairement que vous les recevrez lors de votre prochaine demande d'extraction. Notez qu'un consommateur peut être quelqu'un qui utilise la méthode pull dans la console Google Cloud ou Google Cloud CLI, ou qui exécute un abonné personnalisé localement pour vérifier les messages.
Pour les clients de récupération unaire, vous pouvez observer que certaines requêtes de récupération ne renvoient aucun message. Comme indiqué dans la section Pas assez d'abonnés, nous vous recommandons de conserver plusieurs requêtes en attente, car certaines d'entre elles peuvent renvoyer moins que le nombre maximal de messages configurés, voire aucun.
Si vous suspectez l'un de ces comportements, vérifiez si plusieurs consommateurs sont associés simultanément à l'abonnement et inspectez-les.
Filtrer sur l'abonnement
Vérifiez si un filtre est associé à l'abonnement. Si c'est le 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. Découvrez comment les filtres affectent les métriques de la pile de travail.
Utiliser l'option returnImmediately
Si votre client utilise la méthode 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 s'il ne renvoie aucun message. Cela peut entraîner le retour de requêtes pull avec 0 messages, même en cas d'accumulation.
Gérer les doublons
La duplication de messages dans Pub/Sub se produit souvent lorsque les abonnés ne peuvent pas confirmer la réception des messages dans le délai de confirmation. Les messages sont alors renvoyés, ce qui donne l'impression qu'ils sont en double. Vous pouvez mesurer le rythme auquel les abonnés dépassent le délai de confirmation à 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 de diffusion des messages.
- 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
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 accusés de réception, certains d'entre eux peuvent expirer et nécessiter des extensions de délai. Toutefois, si l'abonné reste submergé, les délais répétés échouent à terme. Dans le pire des cas, cela peut entraîner une accumulation de doublons pour un abonné, ce qui aggrave la situation. Les doublons qui expirent génèrent ensuite de nouveaux doublons.
Pour éviter de submerger l'abonné, réduisez le nombre de messages qu'il récupère à la fois. L'abonné a ainsi moins de messages à traiter dans le délai. Moins de messages expirent et sont renvoyés.
Pour réduire le nombre de messages que l'abonné extrait à la fois, vous devez réduire le nombre maximal de messages en attente dans la configuration de contrôle de flux de votre abonné. Il n'existe pas de valeur universelle. Vous devez donc ajuster la limite maximale des messages en attente en fonction de votre débit et de votre capacité d'abonnés. N'oubliez pas que chaque application traite les messages différemment et qu'elle met un temps différent à confirmer un message.
Forcer des nouvelles tentatives
Pour forcer Pub/Sub à renvoyer un message, envoyez une requête nack. Si vous n'utilisez pas les bibliothèques clientes de haut niveau, envoyez une requête modifyAckDeadline avec un ackDeadlineSeconds défini sur 0.
Clés de tri
Lorsque Pub/Sub redistribue un message avec une clé de tri, il redistribue également tous les messages ultérieurs avec la même clé de tri, même s'ils ont déjà été confirmés. Cela permet de conserver l'ordre de la séquence. Toutefois, il n'existe aucune garantie stricte que les messages dépendants ne sont envoyés qu'après la confirmation réussie des messages précédents de la séquence.
L'abonné nacke les messages
Consultez L'abonné nack les messages.
Résoudre les problèmes liés à un abonnement StreamingPull
Relation entre la métrique de latence de la requête et la latence de diffusion de bout en bout
Pour StreamingPull, la métrique serviceruntime.googleapis.com/api/request_latencies représente la durée pendant laquelle le flux est ouvert. Cette métrique n'est pas utile pour déterminer la latence de diffusion de bout en bout.
Au lieu d'utiliser la métrique de latence de la requête, utilisez le score d'état de latence de distribution pour vérifier quels facteurs contribuent à une augmentation de la latence de distribution de bout en bout.
Les connexions StreamingPull se ferment avec un état non OK
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 ne sont pas en échec. Par conséquent, bien que l'API StreamingPull ait un taux d'erreur de 100% qui peut sembler surprenant, cela tient à sa conception.
Comme les flux StreamingPull se terminent toujours par une erreur, il est inutile d'examiner les métriques de fin 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 Condition préalable non remplie peuvent se produire si des messages compris dans les tâches d'abonnement en attente sont chiffrés avec une clé Cloud KMS désactivée. Pour reprendre la récupération, restaurez l'accès à la clé.
Des erreurs d'indisponibilité peuvent se produire lorsque Pub/Sub ne parvient pas à traiter une requête. Il s'agit probablement d'une condition 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.
Des erreurs de non-trouvabilité peuvent se produire lorsque l'abonnement est supprimé ou s'il n'a jamais existé. Ce dernier cas se produit si vous avez fourni un chemin d'abonnement non valide.