Surveiller Pub/Sub dans Cloud Monitoring

Vous pouvez surveiller Cloud Pub/Sub à l'aide de la console Google Cloud ou de l'API Cloud Monitoring.

Ce document explique comment surveiller votre utilisation de Pub/Sub dans la console Google Cloud à l'aide de Monitoring.

  • Si vous souhaitez afficher les métriques d'autres ressources Google Cloud en plus des métriques Pub/Sub, utilisez Monitoring.

  • Sinon, vous pouvez utiliser les tableaux de bord de surveillance fournis dans Pub/Sub. Consultez les sections Surveiller les sujets et Surveiller les abonnements.

Avant de commencer

Avant d'utiliser Monitoring, assurez-vous d'avoir préparé les éléments suivants:

  • Un compte de facturation Cloud

  • Un projet Pub/Sub avec la facturation activée

Pour vérifier que vous avez obtenu les deux, suivez le guide de démarrage rapide avec la console Cloud.

Afficher un tableau de bord existant

Un tableau de bord vous permet d'afficher et d'analyser des données provenant de différentes sources dans le même contexte. Google Cloud fournit des tableaux de bord prédéfinis et personnalisés. Par exemple, vous pouvez afficher un tableau de bord Pub/Sub prédéfini ou créer un tableau de bord personnalisé qui affiche les données de métriques, les règles d'alerte et les entrées de journal liées à Pub/Sub.

Pour surveiller votre projet Pub/Sub à l'aide de Cloud Monitoring, procédez comme suit:

  1. Dans Google Cloud Console, accédez à la page Monitoring.

    Accéder à Monitoring

  2. En haut de la page, sélectionnez le nom de votre projet s'il n'est pas déjà sélectionné.

  3. Dans le menu de navigation, cliquez sur Tableaux de bord.

  4. Sur la page Tableaux de bord, créez un tableau de bord ou sélectionnez le tableau de bord Pub/Sub existant.

    Pour rechercher le tableau de bord Pub/Sub existant, dans le filtre Tous les tableaux de bord, sélectionnez la propriété Nom et saisissez Pub/Sub.

Pour en savoir plus sur la création, la modification et la gestion d'un tableau de bord personnalisé, consultez Gérer les tableaux de bord personnalisés.

Afficher une seule métrique Pub/Sub

Pour afficher une seule métrique Pub/Sub à l'aide de la console Google Cloud, procédez comme suit:

  1. Dans Google Cloud Console, accédez à la page Monitoring.

    Accéder à Monitoring

  2. Dans le volet de navigation, sélectionnez Explorateur de métriques.

  3. Dans la section Configuration, cliquez sur Sélectionner une métrique.

  4. Saisissez Pub/Sub dans le filtre.

  5. Dans Ressources actives, sélectionnez Abonnement Pub/Sub ou Sujet Pub/Sub.

  6. Accédez à une métrique spécifique, puis cliquez sur Appliquer.

    La page d'une métrique spécifique s'ouvre.

Pour en savoir plus sur le tableau de bord de surveillance, consultez la documentation de Cloud Monitoring.

Afficher les métriques et les types de ressources Pub/Sub

Surveiller l'utilisation des quotas

Pour un projet donné, vous pouvez consulter les quotas et l'utilisation actuels dans le tableau de bord des quotas IAM et administration.

Vous pouvez afficher l'historique de votre utilisation du quota à l'aide des métriques suivantes:

Ces métriques utilisent le type de ressource surveillée consumer_quota. Pour obtenir plus de métriques liées aux quotas, consultez la liste des métriques.

Par exemple, la requête Langage MQL (Monitoring Query Language) suivante crée un graphique avec la fraction de quota d'éditeur utilisée dans chaque région :

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio

Si vous prévoyez que votre utilisation dépasse les limites de quota par défaut, créez des règles d'alerte pour tous les quotas correspondants. Ces alertes se déclenchent lorsque votre utilisation atteint une partie de la limite. Par exemple, la requête de langage de requête Monitoring suivante déclenche une règle d'alerte lorsqu'un quota Pub/Sub dépasse 80% d'utilisation:

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio
| every 1m
| condition gt(val(), 0.8 '1')

Pour une surveillance et des alertes plus personnalisées sur les métriques de quota, consultez la page Utiliser des métriques de quota.

Pour en savoir plus, consultez la page Quotas et limites.

Maintenir un abonnement sain

Pour conserver un abonnement opérationnel, vous pouvez surveiller plusieurs propriétés d'abonnement à l'aide des métriques fournies par Pub/Sub. Par exemple, vous pouvez surveiller le volume de messages non confirmés, l'expiration des délais d'accusé de réception des messages, etc. Vous pouvez également vérifier si votre abonnement est suffisamment opérationnel pour atteindre une latence de distribution des messages faible.

Reportez-vous aux sections suivantes pour en savoir plus sur les métriques spécifiques.

Surveiller les messages en attente

Pour vous assurer que vos abonnés suivent le flux de messages, créez un tableau de bord. Le tableau de bord peut afficher les métriques de tâches en attente suivantes, agrégées par ressource:

Créez des règles d'alerte qui se déclenchent lorsque ces valeurs sont en dehors de la plage acceptable dans le contexte de votre système. Par exemple, le nombre absolu de messages non confirmés n'est pas forcément pertinent. Un retard de plusieurs millions de messages peut être acceptable pour un abonnement à un message par seconde, mais pas pour un abonnement à un message par seconde.

Problèmes courants en attente

Symptômes Problème Solutions
Les valeurs oldest_unacked_message_age et num_undelivered_messages augmentent conjointement. Les abonnés ne suivent pas le volume des messages
  • Ajoutez des threads ou processus pour les abonnés.
  • Ajoutez des machines ou conteneurs pour les abonnés.
  • Recherchez des signes de bugs dans votre code qui l'empêchent d'accuser réception des messages ou de les traiter dans les meilleurs délais. Consultez la section Surveiller l'expiration du délai de confirmation.
Si le nombre de messages en attente est faible et stable, et que le nombre de oldest_unacked_message_age augmente régulièrement, certains messages ne peuvent pas être traités. Messages bloqués
  • Examinez les journaux de votre application pour déterminer si certains messages entraînent le plantage de votre code. Il est peu probable, mais possible, que les messages incriminés soient bloqués dans Pub/Sub plutôt que dans votre client. Envoyez une demande d'assistance une fois que vous êtes certain que votre code parvient à traiter chaque message.
  • Si certains messages entraînent le plantage de votre code, envisagez de les transférer vers un sujet de lettre morte.
La valeur oldest_unacked_message_age dépasse la durée de conservation des messages de l'abonnement. Perte définitive de données
  • Configurez une alerte qui se déclenche avant l'expiration de la durée de conservation des messages.

Surveiller l'état de la latence de diffusion

Dans Pub/Sub, la latence de distribution correspond au temps écoulé après la publication d'un message, puis sa distribution à un abonné. Si le nombre de messages en attente augmente, vous pouvez utiliser le score de santé de la latence de distribution (subscription/delivery_latency_health_score) pour vérifier les facteurs qui contribuent à une latence accrue.

Cette métrique mesure l'état d'un seul abonnement sur une période glissante de 10 minutes. La métrique fournit des insights sur les critères suivants, qui sont nécessaires pour qu'un abonnement obtienne une faible latence constante:

  • Requêtes de recherche négligeables

  • Messages négligeables confirmés (messages ancrés).

  • Délais d'accusé de réception des messages arrivés à expiration négligeables.

  • Latence d'accusé de réception cohérente en moins de 30 secondes

  • Une faible utilisation constante, ce qui signifie que l'abonnement dispose d'une capacité suffisante pour traiter de nouveaux messages.

La métrique Latence de diffusion indique un score de 0 ou de 1 pour chacun des critères spécifiés. Un score de 1 indique un état opérationnel et un score de 0 indique un état non opérationnel.

  • Requêtes de recherche: si l'abonnement a reçu des requêtes de recherche au cours des 10 dernières minutes, le score est défini sur 0. La recherche d'un abonnement peut entraîner la relecture des anciens messages longtemps après leur première publication, ce qui augmente la latence de distribution.

  • Messages confirmés (négatif) : si l'abonnement a reçu des requêtes d'accusé de réception négatives dans les 10 dernières minutes, le score est défini sur 0. Un accusé de réception négatif entraîne la remise d'un message avec une latence de distribution accrue.

  • Délais d'accusé de réception arrivés à expiration : si l'abonnement comporte des délais d'accusé de réception arrivés à expiration au cours des 10 dernières minutes, le score est défini sur 0. Les messages dont le délai d'accusé de réception a expiré sont redistribués avec une latence de distribution accrue.

  • Latences d'accusé de réception : si le 99,9e centile de toutes les latences d'accusé de réception au cours des 10 dernières minutes était supérieur à 30 secondes, le score est défini sur 0. Une latence d'accusé de réception élevée indique que le client a besoin de temps anormalement long pour traiter un message. Ce score peut impliquer un bug ou des contraintes de ressources côté client abonné.

  • Faible utilisation : l'utilisation est calculée différemment pour chaque type d'abonnement.

    • StreamingPull : si le nombre de flux ouverts est insuffisant, le score est défini sur 0. Ouvrez plus de flux pour vous assurer que vous disposez de la capacité nécessaire pour recevoir de nouveaux messages.

    • Push: si le nombre de messages en attente de votre point de terminaison push est trop important, le score est défini sur 0. Ajoutez de la capacité à votre point de terminaison push pour pouvoir stocker de nouveaux messages.

    • Pull : si vous n'avez pas suffisamment de requêtes pull en attente, le score est défini sur 0. Ouvrez d'autres requêtes pull simultanées pour vous assurer que vous êtes prêt à recevoir de nouveaux messages.

Pour afficher la métrique, dans l'explorateur de métriques, sélectionnez la métrique Score de santé de la latence de diffusion pour le type de ressource d'abonnement Pub/Sub. Ajoutez un filtre pour sélectionner un seul abonnement à la fois. Sélectionnez le graphique en aires empilées et pointez sur un moment spécifique pour vérifier les scores des critères de l'abonnement pour ce moment précis.

Voici une capture d'écran de la métrique représentée pour une période d'une heure à l'aide d'un graphique en aires empilées. La note de santé combinée passe à 5 à 4h15 du matin, avec un score de 1 pour chaque critère. Plus tard, le score combiné diminue à 4 à 4h20, lorsque le taux d'utilisation tombe à 0.

Capture d'écran de la métrique de latence de diffusion

Le langage de requête Monitoring fournit une interface textuelle expressive aux données de séries temporelles Cloud Monitoring. La requête MQL suivante crée un graphique pour mesurer le score d'état de latence de livraison pour un abonnement.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/delivery_latency_health_score'
| filter (resource.subscription_id == '$SUBSCRIPTION')
| group_by 1m,
   [value_delivery_latency_health_score_sum:
     sum(if(value.delivery_latency_health_score, 1, 0))]
| every 1m

Surveiller l'expiration du délai d'accusé de réception

Afin de réduire la latence de distribution des messages, Pub/Sub accorde aux clients abonnés un temps limité pour accuser réception d'un message donné (confirmation). Cette période est appelée la date limite de confirmation. Si vos abonnés mettent trop de temps à accuser réception des messages, ceux-ci sont redistribués, ce qui entraîne la diffusion de messages en double. Cette livraison peut se produire pour différentes raisons:

  • Vos abonnés sont sous-provisionnés (vous avez besoin de davantage de threads ou de machines).

  • Le délai de traitement de chaque message est supérieur au délai de confirmation. Les bibliothèques clientes Cloud reprennent généralement la durée maximale pour les messages individuels jusqu'à une valeur maximale configurable. Toutefois, la prolongation du délai maximale s'applique également aux bibliothèques.

  • Certains messages entraînent systématiquement le plantage du client.

Vous pouvez mesurer la fréquence à laquelle les abonnés ne respectent pas la date limite de confirmation. La métrique spécifique dépend du type d'abonnement :

Des taux d'expiration du délai de confirmation excessifs peuvent entraîner des sources d'inefficacité coûteuses dans votre système. Chaque redistribution et chaque tentative de traitement d'un message entraîne des coûts. À l'inverse, un taux d'expiration faible (par exemple, entre 0,1 et 1%) peut être sain.

Surveiller le débit des messages

Les abonnés en mode pull et StreamingPull peuvent recevoir des lots de messages dans chaque réponse pull. Les abonnements push reçoivent un seul message dans chaque requête push. Vous pouvez surveiller le débit des messages par lot en cours de traitement par vos abonnés à l'aide des métriques suivantes:

Vous pouvez surveiller le débit des messages individuel ou non par lot en cours de traitement par vos abonnés à l'aide de la métrique subscription/sent_message_count filtrée par le libellé delivery_type.

Surveiller les abonnements push

Pour les abonnements push, surveillez les métriques suivantes:

  • subscription/push_request_count

    Regroupez la métrique par response_code et subcription_id. Étant donné que les abonnements push Pub/Sub utilisent des codes de réponse comme des accusés de réception de messages implicites, il est important de surveiller les codes de réponse aux requêtes push. Étant donné que les abonnements push cessent de fonctionner de manière exponentielle en cas de délais avant expiration ou d'erreurs, le nombre de vos tâches en attente peut augmenter rapidement en fonction de la réponse de votre point de terminaison.

    Envisagez de définir une alerte pour les taux d'erreur élevés, car ils ralentissent la livraison et augmentent le nombre de tâches en attente. Vous pouvez créer une métrique filtrée par classe de réponse. Cependant, le nombre de requêtes push peut s'avérer plus utile pour identifier la taille et l'ancienneté en attente des requêtes.

  • subscription/num_outstanding_messages

    En règle générale, Pub/Sub limite le nombre de messages en attente. Dans la plupart des cas,essayez de ne pas dépasser 1 000 messages en attente. Une fois que le débit atteint un débit de l'ordre de 10 000 messages par seconde, le service ajuste la limite du nombre de messages en attente. Cette limite est définie par incréments de 1 000. Étant donné qu'aucune garantie spécifique n'est effectuée au-delà de la valeur maximale, 1 000 messages en attente constituent un bon guide.

  • subscription/push_request_latencies

    Cette métrique vous aide à comprendre la répartition de la latence de réponse du point de terminaison push. En raison de la limite appliquée au nombre de messages en attente, la latence du point de terminaison a une incidence sur le débit de l'abonnement. Si le traitement de chaque message nécessite 100 millisecondes, il est probable que votre limite de débit soit de 10 messages par seconde.

Pour avoir accès à des limites de messages en attente plus élevées, les abonnés push doivent accuser réception de plus de 99% des messages qu'ils reçoivent.

Vous pouvez calculer le pourcentage de messages confirmés par les abonnés à l'aide du langage MQL (Monitoring Query Language). La requête MQL suivante permet de créer un graphique avec le pourcentage de messages confirmés par les abonnés sur un abonnement :

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/push_request_count'
| filter
    (resource.subscription_id == '$SUBSCRIPTION')
    | filter_ratio_by [], metric.response_class == 'ack'
    | every 1m

Surveiller les abonnements avec des filtres

Si un filtre est configuré sur un abonnement, Pub/Sub accuse automatiquement réception des messages qui ne correspondent pas au filtre. Vous pouvez surveiller cette confirmation automatique.

Pour surveiller le taux de messages confirmés automatiquement qui ne correspondent pas au filtre, utilisez la métrique subscription/ack_message_count avec le libellé delivery_type défini sur filter.

Pour surveiller le débit et le coût des messages confirmés automatiquement qui ne correspondent pas au filtre, utilisez la métrique subscription/byte_cost avec le libellé operation_type défini sur filter_drop. Pour en savoir plus sur les frais associés à ces messages, consultez la page Tarifs de Pub/Sub.

Surveiller les messages non transmis transférés

Pour surveiller les messages impossibles à distribuer que Pub/Sub transfère vers un sujet de lettres mortes, utilisez la métrique subscription/dead_letter_message_count. Cette métrique indique le nombre de messages non distribuables que Pub/Sub transfère à partir d'un abonnement.

Pour vérifier que Pub/Sub transfère les messages impossibles à distribuer, vous pouvez comparer la métrique subscription/dead_letter_message_count à la métrique topic/send_request_count. Comparez le sujet des lettres mortes vers lequel Pub/Sub transfère ces messages.

Vous pouvez également associer un abonnement au sujet des lettres mortes, puis surveiller les messages non transmis pour cet abonnement à l'aide des métriques suivantes:

Maintenir un éditeur sain

Le principal objectif d'un éditeur est de conserver rapidement les données des messages. Surveillez ces performances à l'aide de topic/send_request_count, regroupées par response_code. Cette métrique vous indique si Pub/Sub est opérationnel et accepte les requêtes.

Un taux d'erreurs en arrière-plan (inférieur à 1%) n'est pas une cause d'inquiétude, car la plupart des bibliothèques clientes Cloud retentent les échecs. Examinez les taux d'erreur supérieurs à 1%. Étant donné que les codes non renouvelables sont traités par votre application (et non par la bibliothèque cliente), vous devez examiner les codes de réponse. Si votre application d'éditeur ne permet pas de signaler un état défaillant correctement, envisagez de définir une alerte sur la métrique topic/send_request_count.

Il est tout aussi important de suivre les requêtes de publication ayant échoué dans votre client de publication. Bien que les bibliothèques clientes relancent généralement les requêtes ayant échoué, elles ne garantissent pas la publication. Reportez-vous à la page Publier des messages pour savoir comment détecter les échecs de publication permanents lorsque vous utilisez les bibliothèques clientes Cloud. Au minimum, votre application d'éditeur doit enregistrer les erreurs de publication permanentes. Si vous enregistrez ces erreurs dans Cloud Logging, vous pouvez configurer une métrique basée sur les journaux avec une règle d'alerte.

Surveiller le débit des messages

Les éditeurs peuvent envoyer des messages par lot. Vous pouvez surveiller le débit des messages envoyés par vos éditeurs à l'aide des métriques suivantes:

  • topic/send_request_count : volume de messages par lot envoyés par les éditeurs.

  • Nombre de topic/message_sizes : volume de messages individuels (non groupés) envoyés par les éditeurs.

    Vous pouvez calculer le nombre de messages envoyés en appliquant un agrégateur de comptes à cette métrique ou en utilisant le langage de requête Monitoring. La requête MQL suivante crée un graphique avec le taux de messages individuels envoyés sur un sujet:

    fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter
    (resource.topic_id == '$TOPIC')
| align delta(1m)
| every 1m
| group_by [], [row_count: row_count()]

Étapes suivantes