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 consulter le score d'état de latence de distribution (subscription/delivery_latency_health_score) afin d'identifier les facteurs pouvant entraîner 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. Il 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 offre des informations précieuses sur les retards ou goulots d'étranglement potentiels dans le traitement.
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 à une dégradation des performances.
Voici quelques-uns des problèmes courants liés au backlog 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'abonné:
État du client: analysez l'utilisation des ressources (processeur, mémoire et bande passante réseau) sur les machines hébergeant des clients abonnés. Recherchez les points de pression qui peuvent entraver l'efficacité du traitement.
Code client: examinez les dernières modifications apportées au code et examinez les journaux d'erreurs. Des bugs ou des inefficacités dans le code de l'abonné peuvent avoir un impact significatif sur la vitesse 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 de Compute Engine ou de GKE pour éviter d'éventuels goulots d'étranglement.
L'abonné a accusé réception des messages de manière négative
Lorsqu'un abonné accuse réception d'un message de manière négative, il signale à Pub/Sub que le message n'a pas pu être traité. Pub/Sub tente ensuite de redistribuer le même message. La répétition des rappels automatiques d'un message entraîne des doublons et potentiellement un retard important dans la distribution du message.
Notez que l'attribution d'un tag à un message ne garantit pas que la prochaine extraction récupérera un message différent. La règle de rédistribution de Pub/Sub peut continuer à redistribuer les messages faisant l'objet d'un rappel automatique avant les nouveaux. Par conséquent, n'utilisez pas les 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, afin d'arrêter les messages individuels susceptibles d'être traités ultérieurement, mais qui ont besoin d'un peu plus de temps avant d'être redistribués.
Si vous devez ignorer intentionnellement certains messages, la méthode recommandée consiste à les confirmer, même si vous ne les traitez pas. Cela les supprime de l'abonnement, évite les renvois inutiles et réduit la consommation de ressources. Le fait de laisser des messages non confirmés, intentionnellement ou non, crée des problèmes 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 arrive à 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, vous devez maintenir plusieurs connexions StreamingPull ouvertes pour votre abonnement afin d'obtenir une latence toujours faible. 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 offre une visibilité sur le nombre de connexions de streaming actives. Utilisez cette option pour vous assurer de disposer de suffisamment de flux pour gérer les messages entrants.
Pour les clients utilisant le mode pull unaire, gérez 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 minimiser les écarts de connectivité et d'améliorer la latence de distribution.
La bibliothèque cliente de haut niveau est recommandée pour les cas où vous avez besoin d'un débit élevé et d'une faible latence avec des coûts opérationnels et des coûts 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 classes et des fonctions prédéfinies qui gèrent les appels d'API sous-jacents à des fins d'authentification, d'optimisation du débit et de la latence, de 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 important
Notez que les messages non confirmés en attente 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.
Trier les clés et distribution de type "exactement une fois"
Le tri des clés et la distribution "exactement une fois" sont des fonctionnalités intéressantes, mais ils nécessitent une coordination supplémentaire au sein de Pub/Sub pour garantir une distribution correcte. Cette coordination permet de réduire la disponibilité et d'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 associés à une clé de tri ne peuvent pas être distribués tant que les messages antérieurs ayant la même clé de tri n'ont pas été accusés de réception.
Déterminez si l'ordre des messages ou la distribution "exactement une fois" est absolument essentiel pour votre application. Si la faible latence est votre priorité absolue, minimiser l'utilisation de ces fonctionnalités peut contribuer à 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 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 regroupant les données par topic_id. Faites le lien entre les pics de taille des messages et 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 le facteur déterminant.
Distribution de messages dans les abonnements Pub/Sub avec plusieurs clients
Dans Pub/Sub, les messages peuvent être distribués de manière inégale entre les clients. 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 des messages peuvent déjà être en attente pour les clients. Si des messages non confirmés sont en attente, cela ne signifie pas nécessairement que vous recevrez ces messages lors de votre prochaine demande d'extraction. Sachez qu'un client peut être une personne qui utilise le mode d'extraction dans la console Google Cloud ou Google Cloud CLI, ou qui exécute un abonné personnalisé localement pour consulter les messages.
Pour les clients pull unaires, il se peut que certaines requêtes pull 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 demandes peuvent renvoyer moins de messages que le nombre maximal configuré, voire aucun message.
Si vous suspectez l'un de ces comportements, vérifiez si plusieurs utilisateurs sont associés simultanément à l'abonnement.
Filtrer sur l'abonnement
Vérifiez si un filtre est associé à l'abonnement. Si tel 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. Réfléchissez à l'impact des filtres sur les métriques des tâches en attente.
Avec 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 renvoie un résultat sans message. Cela peut entraîner le renvoi de demandes d'extraction avec zéro message, même en cas de tâches en attente.
Gérer les doublons
Les messages sont souvent dupliqués dans Pub/Sub lorsque les abonnés ne peuvent pas confirmer les messages dans le délai de confirmation. Les messages sont alors redistribués, créant ainsi une impression de double. Vous pouvez mesurer la fréquence à laquelle les abonnés ne respectent pas la date limite de confirmation à 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 des messages.
- Les bibliothèques clientes gèrent automatiquement l'extension du délai, mais 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 extraits 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 prolongations répétées finissent par échouer. Dans le pire des cas, cela peut conduire à un nombre d'abonnés plein de doublons, exacerbant ainsi le traitement en attente. Les doublons arrivant à expiration sont alors générés.
Pour éviter de surcharger 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 expirent et moins de messages sont redistribués.
Pour réduire le nombre de messages extraits simultanément par l'abonné, 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 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é. Notez que chaque application traite les messages différemment et prend un temps différent pour confirmer 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èques clientes de haut niveau, envoyez une requête modifyAckDeadline avec un ackDeadlineSeconds défini sur 0.
Trier les clés
Lorsque Pub/Sub redistribue un message avec une clé de tri, les envois suivants sont également renvoyés messages ayant 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'y a pas de règles strictes garantir que les messages dépendants ne sont envoyés qu'une fois des messages précédents de la séquence.
L'abonné récupère les messages
Consultez la section L'abonné récupère les messages.
Résoudre les problèmes liés à un abonnement StreamingPull
Les flux StreamingPull se ferment toujours avec un état non OK. Retirer le "J'aime" à 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 Le taux d'erreur de l'API StreamingPull peut être surprenant de 100 %, conception.
Étant donné que les flux StreamingPull se ferment toujours avec une erreur, il n'est pas utile
examiner les métriques d'arrêt de flux tout en diagnostiquant les erreurs. Concentrez-vous plutôt sur
la métrique de réponse StreamingPull
subscription/streaming_pull_response_count,
regroupées par response_code ou response_class.
Recherchez les erreurs suivantes :
Des erreurs de condition préalable ayant échoué peuvent se produire si le champ en attente et chiffrés avec une clé Cloud KMS désactivée. À reprendre l'extraction, restaurer l'accès à la clé.
Des erreurs non disponibles peuvent se produire lorsque Pub/Sub ne peut pas pour traiter une demande. Il s'agit très probablement d'un état temporaire et le client relance les requêtes. Aucune action n'est requise de votre part à l'aide d'une bibliothèque cliente.
Des erreurs de type "Page introuvable" peuvent se produire lorsque l'abonnement est supprimé ou s'il n'a jamais été existait au départ. Ce cas de figure se produit si vous avez fourni un code chemin d'abonnement.