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 de l'abonné 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 déterminer les facteurs pouvant contribuer à une latence inattendue ou accrue.
L'âge 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 message le plus ancien dans le backlog d'un abonnement qui n'a pas encore été confirmé par un abonné. Cette métrique fournit des insights précieux sur les retards de traitement ou les goulots d'étranglement potentiels.
La surveillance du backlog de messages 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 où 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 de backlog courants 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 votre investigation sur les composants de l'abonné :
État du client : analysez l'utilisation des ressources sur les machines hébergeant les 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 dans le code de l'abonné peuvent avoir un impact significatif sur les taux 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 ou limites Pub/Sub imposés par votre service d'hébergement. Si les abonnés sont hébergés dans Google Cloud, consultez les quotas de ressources Compute Engine ou GKE pour éviter les goulots d'étranglement potentiels.
L'abonné a confirmé négativement les messages
Lorsqu'un abonné envoie un accusé de réception négatif (nack) pour un message, il signale à Pub/Sub que le message n'a pas pu être traité correctement. 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 des messages.
Notez que l'envoi d'un accusé de réception négatif pour un message ne garantit pas que l'extraction suivante récupérera un message différent. La règle de nouvelle livraison de Pub/Sub peut continuer à livrer à nouveau les messages nacké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 stratégie de nouvelle tentative, de préférence une intervalle exponentiel entre les tentatives, afin de différer les messages individuels susceptibles d'être traités ultérieurement, mais qui nécessitent un peu plus de temps avant d'être renvoyés.
Si vous devez ignorer intentionnellement certains messages, l'approche recommandée consiste à les accuser réception, même si vous ne les traitez pas. Cela les supprime de l'abonnement, évite les nouvelles livraisons inutiles et réduit la consommation de ressources. Laisser des messages sans accusé de réception, intentionnellement ou non, crée des problèmes de backlog et de distribution en double.
Latence de diffusion élevée
Dans Pub/Sub, la latence de distribution correspond au temps nécessaire pour qu'un message d'un éditeur parvienne à 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 utilisant StreamingPull, afin d'obtenir une latence faible et constante, maintenez plusieurs connexions StreamingPull ouvertes vers votre abonnement. Sans connexions d'abonnés actives, Pub/Sub ne peut pas distribuer les messages rapidement. Un flux unique 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. Utilisez cette option pour vous assurer de toujours disposer de suffisamment de flux pour gérer les messages entrants.
Pour les clients utilisant l'extraction unaire, afin d'obtenir une latence faible et constante, maintenez plusieurs demandes d'extraction en attente pour votre abonnement. Des requêtes peu fréquentes peuvent entraîner l'accumulation de messages dans le backlog et augmenter la latence. Cette approche permet de minimiser les interruptions 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 haut débit et d'une faible latence, avec des coûts opérationnels et de traitement minimaux. Par défaut, la bibliothèque cliente de haut niveau utilise l'API StreamingPull, car elle constitue généralement un meilleur choix 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 Problèmes de configuration du client.
Arriéré élevé
Notez qu'un backlog 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 distribution correcte. Cette coordination peut réduire la disponibilité et augmenter la latence. Bien que la différence soit minime en régime permanent, toutes les étapes de coordination nécessaires peuvent entraîner des augmentations temporaires de la latence ou un taux d'erreur accru. 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 une faible latence est votre priorité absolue, limiter l'utilisation de ces fonctionnalités peut vous aider à réduire les délais de traitement des messages.
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 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. Mettez en corrélation 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 en être la cause.
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 d'un même abonnement. Pub/Sub équilibre la charge des messages entre tous les clients actifs, mais l'objectif principal est de maximiser le débit global de traitement des messages et de minimiser l'arriéré, plutôt que d'assurer une distribution parfaitement uniforme. Le système dirige de manière dynamique davantage de messages vers les consommateurs qui démontrent une plus grande capacité, c'est-à-dire ceux qui accusent réception des messages rapidement et ne sont pas limités par leurs paramètres de contrôle de flux. Les consommateurs qui traitent les messages à des vitesses différentes ou qui fonctionnent dans des conditions différentes (par exemple, disponibilité des ressources, latence du réseau) traiteront probablement des volumes de messages différents. En général, les consommateurs plus rapides et plus réactifs reçoivent et traitent une plus grande partie de la charge de messages.
Cette méthode de distribution entre plusieurs consommateurs signifie que l'ordre dans lequel les messages sont reçus et traités peut varier. Par conséquent, à moins que le tri des messages ne soit activé pour l'abonnement et que les éditeurs n'incluent des clés de tri, il n'est pas garanti que les messages soient traités par les consommateurs dans l'ordre dans lequel ils ont été publiés.
Notez que des messages peuvent déjà être en attente pour les clients, et qu'un backlog de messages non confirmés ne signifie pas nécessairement que vous recevrez ces messages lors de votre prochaine demande d'extraction d'extraction. Sachez qu'un consommateur peut être une personne qui utilise l'extraction 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 Pull unaires, vous pouvez observer que certaines demandes d'extraction ne renvoient aucun message. Comme indiqué dans la section Nombre d'abonnés insuffisant, il est recommandé de maintenir plusieurs demandes d'extraction en attente, car certaines demandes peuvent renvoyer un nombre de messages inférieur au nombre maximal configuré, voire aucun message, même s'il existe un backlog. En effet, d'autres consommateurs peuvent détenir des baux sur les messages disponibles.
Si un consommateur n'accuse pas réception d'un message dans le délai d'accusé de réception, ou s'il envoie un accusé de réception négatif (NACK), Pub/Sub tente de le renvoyer. Cette tentative de nouvelle livraison peut être effectuée auprès de n'importe quel consommateur actif de l'abonnement, pas nécessairement celui qui l'a reçu initialement. Par conséquent, un ID de message particulier peut être distribué à plusieurs consommateurs différents connectés à l'abonnement au cours de sa durée de vie, et son traitement peut être tenté par ces consommateurs, jusqu'à ce que l'un d'eux l'accuse de réception.
Si vous suspectez des comportements de distribution de messages inattendus, vérifiez si plusieurs consommateurs sont associés simultanément à l'abonnement, et inspectez leurs métriques de performances et configurations individuelles.
Filtrer sur l'abonnement
Vérifiez si un filtre est associé à l'abonnement. Si c'est le cas, vous ne recevez que les messages qui correspondent 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 backlog.
Utiliser l'option returnImmediately
Si votre client utilise la méthode Pull unaire, vérifiez si le champ returnImmediately est défini sur "true". Ce champ obsolète indique au service Pub/Sub de répondre immédiatement à la demande d'extraction, même si elle ne renvoie aucun message. Cela peut entraîner le renvoi de demandes d'extraction avec 0 message, même s'il existe un backlog.
Problèmes de configuration du client
Si vous utilisez la bibliothèque cliente Java et que vous initialisez votre abonné avec un canal gRPC personnalisé à l'aide de la méthode setChannelProvider(), vous devez vous assurer que le paramètre maxInboundMessageSize est d'au moins 20 Mo (correspondant à la valeur par défaut de la bibliothèque) lors de la création de votre TransportChannelProvider. Lorsque cette valeur est inférieure à 10 Mo, les messages d'une taille supérieure à maxInboundMessageSize ne sont pas reçus correctement. Les méthodes courantes pour configurer ce paramètre sont InstantiatingGrpcChannelProvider.Builder.setMaxInboundMessageSize() et ManagedChannelBuilder.maxInboundMessageSize().
Gérer les doublons
Un abonné peut recevoir des messages en double dans les cas suivants :
Nouvelle livraison. Un client a envoyé un accusé de réception négatif pour un message ou le délai d'accusé de réception a expiré. Ce comportement est normal.
Livraison en double. Un message est renvoyé après un accusé de réception réussi ou avant l'expiration du délai d'accusé de réception. Les abonnements pour lesquels la distribution de type "exactement une fois" est activée ne reçoivent pas de distributions en double.
Messages en double de l'éditeur. L'éditeur envoie un message deux fois en raison de la logique de l'application de l'éditeur. Le service Pub/Sub les traite comme des messages Pub/Sub distincts et leur attribue des ID de message uniques.
Si les ID de message sont identiques, cela signifie que Pub/Sub a renvoyé ou redistribué le message. Si les ID de message sont différents, cela signifie que la duplication s'est produite en amont au niveau de l'éditeur.
Délais de confirmation expirés
La duplication des messages dans Pub/Sub se produit souvent lorsque les abonnés ne peuvent pas accuser réception des messages dans le délai de confirmation. Cela entraîne la redistribution des messages, ce qui donne l'impression qu'ils sont en double. Vous pouvez mesurer la fréquence à laquelle les abonnés ne respectent pas l'échéance d'accusé de réception à l'aide de la métrique subscription/expired_ack_deadlines_count. Découvrez comment surveiller l'expiration du délai d'accusé de réception.
Pour réduire le taux de duplication, prolongez les délais de traitement des messages.
- Les bibliothèques clientes gèrent automatiquement l'extension du délai, mais il existe des limites par défaut pour le délai d'extension maximal 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 extraits dans l'abonné plus rapidement qu'ils ne peuvent être traités et confirmés, certains messages peuvent expirer et nécessiter des prolongations 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 surcharge de doublons pour un abonné, ce qui aggrave l'accumulation de messages. Les doublons arrivant à expiration génèrent ensuite de nouveaux doublons.
Pour éviter de surcharger l'abonné, réduisez le nombre de messages qu'il extrait à la fois. De cette façon, l'abonné a moins de messages à traiter dans le délai imparti. Moins de messages expirent et moins de messages sont relivrés.
Pour réduire le nombre de messages que l'abonné extrait à la fois, vous devez réduire le paramètre du 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 l'abonné. Sachez que chaque application traite les messages différemment et met un temps différent à accuser réception d'un message.
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 avec un ackDeadlineSeconds défini sur 0.
Clés de tri
Lorsque Pub/Sub redistribue un message ayant une clé de tri, il redistribue également tous les messages ultérieurs 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'est pas garanti que les messages dépendants ne soient envoyés qu'après l'envoi d'un accusé de réception des messages précédents de la séquence.
L'abonné nacke les messages
Consultez L'abonné nacke les messages.
Opérations de recherche
Lorsque vous effectuez une opération de recherche sur un code temporel ou un instantané, Pub/Sub redistribue les messages qui ont été publiés après le code temporel ou inclus dans l'instantané. Cette nouvelle livraison est un comportement attendu et se produit même si la distribution de type "exactement une fois" est activée sur l'abonnement. Pour en savoir plus, consultez Rechercher avec une distribution de type "exactement une fois".
Déduplication en aval
Les abonnés et les autres systèmes en aval peuvent dédupliquer les messages. Par exemple, Dataflow est compatible avec la distribution de type "exactement une fois". Si des messages en double apparaissent de manière inattendue en aval, la cause peut se trouver dans l'abonné plutôt que dans Pub/Sub.
Résoudre les problèmes d'un abonnement StreamingPull
Relation entre la métrique de latence des requêtes 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 des requêtes, utilisez le score d'état de latence de distribution pour vérifier quels facteurs contribuent à l'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 indique simplement que le flux est déconnecté. Les requêtes n'échouent pas. Par conséquent, même si l'API StreamingPull peut avoir un taux d'erreur surprenant de 100 %, ce comportement est normal.
É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 des 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 non remplie peuvent se produire si des messages du backlog d'abonnement sont chiffrés avec une clé Cloud KMS désactivée. Pour reprendre l'extraction, rétablissez 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 nécessaire si vous utilisez une bibliothèque cliente.
Des 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.