Ce document fournit quelques conseils courants de dépannage 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 d'examiner d'abord le score d'état de la latence de distribution (subscription/delivery_latency_health_score) afin de vérifier les facteurs pouvant contribuer à une latence inattendue ou accrue.
L'âge du plus ancien message non confirmé ne cesse d'augmenter
The 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 dans les messages en attente 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 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 sont en retard. Cette pratique permet une intervention précoce pour résoudre les problèmes potentiels liés à la dégradation des performances.
Voici quelques problèmes courants liés aux messages 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 suivent pas le volume de messages. Dans ce cas, concentrez votre enquête sur les composants de l'abonné :
É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 du réseau. Recherchez les points de pression qui pourraient nuire à l'efficacité du traitement.
Code client : examinez les modifications de code récentes et les journaux d'erreurs. Les bugs ou les inefficacités dans le code de l'abonné peuvent avoir un impact considérable sur les taux de traitement des messages. Notez qu'il peut y avoir des problèmes 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, consultez les quotas de ressources Compute Engine ou GKE pour éviter les goulots d'étranglement potentiels.
L'abonné a accusé réception négativement des messages
Lorsqu'un abonné accuse réception négativement d'un message, il signale à Pub/Sub que le message n'a pas pu être traité correctement. Pub/Sub tente ensuite de renvoyer le même message. Les accusés de réception négatifs répétés pour un message entraînent des doublons et potentiellement un délai important dans la distribution des messages.
Notez que l'accusé de réception négatif d'un message ne garantit pas que l'extraction suivante récupère un message différent. La règle de nouvelle tentative de Pub/Sub peut continuer à renvoyer les messages ayant fait l'objet d'un accusé de réception négatif avant les nouveaux. Par conséquent, ne vous fiez pas aux accusés de réception négatifs comme méthode de filtrage ou d'ignorance de messages spécifiques. Définissez plutôt une règle de nouvelle tentative, de préférence un intervalle exponentiel entre les tentatives, afin de laisser passer un intervalle entre les tentatives pour les messages individuels qui pourront probablement être traités ultérieurement, mais qui nécessitent un peu plus de temps avant d'être renvoyés.
Si vous devez intentionnellement ignorer certains messages, l'approche recommandée consiste à accuser réception, même si vous ne les traitez pas. Cela les supprime de l'abonnement, évite les nouvelles tentatives inutiles et réduit la consommation de ressources. Le fait de laisser des messages sans accusé de réception, intentionnellement ou non, crée des problèmes de messages en attente et des distributions en double.
Latence de distribution é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 distribution é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 à votre abonnement. Sans connexions d'abonnés actives, Pub/Sub ne peut pas distribuer les messages rapidement. 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 fournit une visibilité sur le nombre de connexions de streaming actives. Utilisez-la pour vous assurer que vous disposez toujours 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 requêtes d'extraction en attente pour votre abonnement. Les requêtes peu fréquentes peuvent potentiellement accumuler des messages dans les messages en attente et augmenter la latence. Cette approche permet de réduire les écarts de connectivité et d'améliorer la latence de distribution.
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 une surcharge opérationnelle et un coût de traitement minimaux. Par défaut, la bibliothèque cliente de haut niveau utilise l'API StreamingPull, car elle est généralement un meilleur choix pour minimiser 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.
Messages en attente élevés
Notez que les messages en attente de messages non confirmés dans un abonnement Pub/Sub augmentent 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 état stable, toutes les étapes de coordination nécessaires peuvent entraîner des augmentations temporaires de la latence ou une augmentation 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 n'ont pas été confirmés.
Déterminez si le tri des messages ou la distribution de type "exactement une fois" sont absolument essentiels pour votre application. Si une faible latence est votre priorité absolue, minimiser 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 constatez 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 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 les messages ne sont pas distribués correctement à votre abonné, l'une des raisons suivantes peut être un facteur contributif.
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 du 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 les messages en attente, plutôt que de garantir une distribution parfaitement uniforme. Le système dirige dynamiquement plus de messages vers les consommateurs qui présentent une capacité plus élevée : ceux qui accusent réception des messages rapidement et qui 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) gèrent probablement des volumes de messages différents. En règle générale, les consommateurs plus rapides et plus réactifs recevront et traiteront 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, sauf si le tri des messages est activé pour l'abonnement et que les éditeurs incluent des clés de tri, les messages ne sont pas garantis d'être traités par les consommateurs dans l'ordre dans lequel ils ont été publiés.
Notez que les 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. Sachez qu'un consommateur peut être une personne qui utilise l'extraction dans la Google Cloud console ou Google Cloud CLI, ou qui exécute un abonné personnalisé localement pour vérifier les messages.
Pour les clients d'extraction unaire, vous pouvez observer que certaines requêtes d'extraction renvoient zéro message. Comme indiqué dans la section Nombre d'abonnés insuffisant, il est recommandé de maintenir plusieurs requêtes d'extraction en attente, car certaines requêtes 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 de confirmation, ou s'il accuse réception négativement du message, Pub/Sub tente de le renvoyer. Cette tentative de renvoi peut être effectuée auprès de n'importe quel consommateur actif de l'abonnement, et 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 plusieurs d'entre eux jusqu'à ce que l'un d'eux accuse réception.
Si vous suspectez des comportements de distribution de messages inattendus, vérifiez si plusieurs consommateurs sont attachés simultanément à l'abonnement et inspectez leurs métriques de performances et configurations individuelles.
Filtrer 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. Tenez compte de l'impact des filtres sur les métriques de messages en attente.
Utiliser l'option returnImmediately
Si votre client utilise l'extraction unaire, vérifiez si le returnImmediately champ 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 renvoi de requêtes d'extraction avec 0 message, même en cas de messages en attente.
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
setChannelProvider()
méthode, vous devez vous assurer que le maxInboundMessageSize paramètre est d'au moins
20 Mo (correspondant à la valeur par défaut de la bibliothèque)
lorsque vous créez votre TransportChannelProvider. Lorsque cette valeur est inférieure à 10 Mo, les messages dont la taille est supérieure à maxInboundMessageSize ne sont pas reçus correctement.
InstantiatingGrpcChannelProvider.Builder.setMaxInboundMessageSize()
et
ManagedChannelBuilder.maxInboundMessageSize() sont des méthodes courantes pour configurer ce paramètre.
Gérer les doublons
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. Les messages sont alors renvoyés, ce qui donne l'impression qu'il y a des doublons. Vous pouvez mesurer le taux 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 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
modifyAckDeadlineméthode pour prolonger le délai de confirmation.
Si les messages sont extraits de l'abonné plus rapidement qu'ils ne peuvent être traités et confirmés, certains messages peuvent expirer et nécessiter une prolongation du délai. Toutefois, si l'abonné reste surchargé, les prolongations répétées du délai finissent par échouer. Dans le pire des cas, cela peut entraîner un débordement de l'abonné avec des doublons, ce qui exacerbe les messages en attente. Les doublons expirés génèrent ensuite de nouveaux doublons.
Pour éviter de surcharger l'abonné, réduisez le nombre de messages que l'abonné extrait à la fois. L'abonné aura ainsi moins de messages à traiter dans le délai imparti. Moins de messages expirent et moins de messages sont renvoyé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 de contrôle de flux de votre abonné. Il n'existe pas de valeur unique, vous devez donc ajuster la limite maximale de messages en attente en fonction de votre débit et de la capacité de l'abonné. Tenez compte du fait que chaque application traite les messages différemment et prend un temps différent pour accuser réception d'un message.
Forcer les nouvelles tentatives
Pour forcer Pub/Sub à envoyer à nouveau un message, envoyez une requête nack. Si vous n'utilisez pas les bibliothères clientes de haut niveau client libraries, envoyez une requête modifyAckDeadline avec un ackDeadlineSeconds défini sur 0.
Clés de tri
Lorsque Pub/Sub renvoie un message avec une clé de tri, il renvoie également tous les messages suivants 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 soient envoyés qu'après l'accusé de réception réussi des messages précédents de la séquence.
L'abonné accuse réception négativement des messages
Consultez L'abonné accuse réception négativement des messages.
Résoudre les problèmes liés à un abonnement StreamingPull
Relation entre la métrique de latence des requêtes et la latence de distribution 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 distribution de bout en bout.
Au lieu d'utiliser la métrique de latence des requêtes, utilisez le score d'état de la latence de distribution pour vérifier les facteurs qui contribuent à une latence de distribution de bout en bout accrue.
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, bien que l'API StreamingPull puisse avoir un taux d'erreur surprenant de 100 %, ce comportement est intentionnel.
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 Failed precondition (Échec de la précondition) 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 l'extraction, rétablissez l'accès à la clé.
Des erreurs Unavailable (Non disponible) 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 tente à nouveau d'exécuter les requêtes. Aucune action de votre part n'est nécessaire si vous utilisez une bibliothèque cliente.
Des erreurs Not found (Introuvable) 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.