Surveiller Pub/Sub dans Cloud Monitoring

Vous pouvez utiliser la console Google Cloud ou l'API Cloud Monitoring pour surveiller Pub/Sub.

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

  • Si vous souhaitez afficher des métriques provenant 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 Surveiller les sujets et Surveiller les abonnements.

Pour connaître les bonnes pratiques d'utilisation des métriques dans l'autoscaling, consultez Bonnes pratiques pour utiliser les métriques Pub/Sub comme signal de scaling.

Avant de commencer

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

  • Compte de facturation Cloud

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

Pour vérifier que vous disposez de ces deux éléments, suivez le guide de démarrage rapide sur l'utilisation de Cloud Console.

Afficher un tableau de bord existant

Un tableau de bord vous permet de visualiser et d'analyser les données de différentes sources dans le même contexte. Google Cloud propose 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 des données de métrique, des règles d'alerte et des 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 Aperçu des 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, puis saisissez Pub/Sub.

Pour savoir comment créer, modifier et gérer 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. Dans le filtre, saisissez Pub/Sub.

  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 Cloud Monitoring.

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

Accéder à l'éditeur MQL

L'explorateur de métriques est une interface de Cloud Monitoring conçue pour explorer et visualiser vos données de métriques. Dans l'explorateur de métriques, vous pouvez utiliser le langage MQL(Monitoring Query Language) pour interroger et analyser vos métriques Pub/Sub.

Pour accéder à l'éditeur MQL lorsque vous utilisez l'explorateur de métriques, consultez la section Accéder à l'éditeur de code.

Créer votre requête MQL

Voici quelques règles de base pour créer une requête MQL pour les métriques Pub/Sub.

  1. Commencez par fetch pubsub_topic ou fetch pubsub_subscription. Cette ligne de code indique à l'éditeur le type de ressource Pub/Sub que vous souhaitez interroger, par exemple des sujets ou des abonnements.

  2. Sélectionnez votre métrique. Utilisez | metric 'metric_name' pour spécifier la métrique que vous souhaitez analyser. Un exemple de métrique Pub/Sub est pubsub.googleapis.com/subscription/ack_message_count (pour les messages confirmés).

  3. Utilisez | filter pour affiner vos données. Voici quelques-uns des filtres courants:

    • resource.project_id == 'your-project-id'
    • resource.topic_id == 'your-topic-id'
    • resource.subscription_id == 'your-subscription-id'

  4. Utilisez | align et | group_by pour regrouper vos données en intervalles et groupes pertinents.

  5. Affinez vos données avec d'autres clauses. MQL propose plusieurs autres clauses, telles que | every (pour définir la fréquence d'exécution des requêtes), | within (pour spécifier une plage temporelle), etc.

Voici un exemple de requête permettant de surveiller le nombre horaire de messages envoyés à un abonnement spécifique:

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == 'your-project-id'
&& resource.subscription_id == 'your-subscription-id'
| align delta(1h)
| every 1h
| group_by [], [value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

Surveiller l'utilisation des quotas

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

Vous pouvez consulter l'historique de votre utilisation des quotas à l'aide des métriques suivantes:

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

Par exemple, la requête MQL 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 fraction de la limite. Par exemple, la requête MQL suivante déclenche une règle d'alerte lorsqu'un quota Pub/Sub dépasse 80 % :

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 plus personnalisée et des alertes 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 maintenir un abonnement en bon état, 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 de confirmation des messages, etc. Vous pouvez également vérifier si votre abonnement est suffisamment sain pour obtenir une latence de distribution des messages faible.

Pour en savoir plus sur les métriques spécifiques, consultez les sections suivantes.

Surveiller le nombre de messages en attente

Pour vous assurer que vos abonnés gèrent le flux des messages, créez un tableau de bord. Le tableau de bord peut afficher les métriques de messages en attente suivantes, regroupées par ressource, pour tous vos abonnements:

Créez des règles d'alerte qui se déclenchent lorsque ces valeurs se situent 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 significatif. Une valeur d'un million de messages en attente peut être acceptable pour un abonnement à un million de messages par seconde, et inacceptable pour un abonnement à un message par seconde.

Problèmes courants liés à la pile de tâches

Symptômes Problème Solutions
Les valeurs oldest_unacked_message_age et num_undelivered_messages augmentent conjointement. Les abonnés n'arrivent pas à gérer le volume de 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êcheraient d'accuser réception des messages ou de les traiter dans les meilleurs délais. Consultez Surveiller l'arrivée à expiration du délai de confirmation.
Si le volume des tâches en attente est faible et stable, et que la valeur oldest_unacked_message_age augmente progressivement, il peut y avoir quelques messages impossibles à traiter. Messages bloqués
  • Examinez les journaux de votre application pour découvrir si certains messages entraînent le plantage de votre code. Il est peu probable, mais possible, que les messages mis en cause 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 traite correctement 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 définie dans 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 nécessaire pour qu'un message publié soit distribué à un abonné. Si votre file d'attente de messages augmente, vous pouvez utiliser le score de santé de la latence de distribution (subscription/delivery_latency_health_score) pour vérifier quels facteurs contribuent à une augmentation de la latence.

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 atteigne une faible latence cohérente:

  • Requêtes de recherche négligeables.

  • Messages de confirmation négative (nacked) négligeables.

  • Délais de confirmation des messages expirés négligeables.

  • Latence d'acquittement constante inférieure à 30 secondes.

  • Utilisation faible et cohérente, ce qui signifie que l'abonnement dispose de manière cohérente d'une capacité suffisante pour traiter les nouveaux messages.

La métrique Évaluation de la latence de diffusion indique un score de 0 ou 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 d'anciens messages longtemps après leur première publication, ce qui augmente leur latence de diffusion.

  • Messages avec accusé de réception négatif (nacked): si l'abonnement a reçu des requêtes d'acquittement négatif (nack) au cours des 10 dernières minutes, le score est défini sur 0. Un accusé de réception négatif entraîne la nouvelle diffusion d'un message avec une latence de diffusion accrue.

  • Délais de confirmation expirés: si l'abonnement a connu des délais de confirmation expirés au cours des 10 dernières minutes, le score est défini sur 0. Les messages dont le délai de confirmation a expiré sont à nouveau distribués avec une latence de distribution accrue.

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

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

    • StreamingPull: si vous n'avez pas suffisamment de flux ouverts, le score est défini sur 0. Ouvrez davantage de flux pour vous assurer de disposer d'une capacité suffisante pour les nouveaux messages.

    • Push: si vous avez trop de messages en attente sur votre point de terminaison push, le score est défini sur 0. Ajoutez plus de capacité à votre point de terminaison push pour pouvoir accueillir de nouveaux messages.

    • Pull: si vous n'avez pas suffisamment de requêtes pull en attente, le score est défini sur 0. Ouvrez davantage de requêtes de tirage simultanées pour vous assurer d'être 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 ne sélectionner qu'un seul abonnement à la fois. Sélectionnez le graphique en courbes cumulées, puis pointez sur un moment spécifique pour vérifier les scores des critères de l'abonnement à ce moment-là.

Vous trouverez ci-dessous une capture d'écran de la métrique tracée sur une période d'une heure à l'aide d'un graphique en aires empilées. Le score de santé combiné passe à 5 à 4h15, avec un score de 1 pour chaque critère. Plus tard, le score combiné passe à 4 à 4h20 du matin, lorsque le score d'utilisation passe à 0.

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

Le langage MQL fournit une interface textuelle expressive aux données de séries temporelles de Cloud Monitoring. La requête MQL suivante crée un graphique pour mesurer l'évaluation de la latence de diffusion d'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 de confirmation

Afin de réduire la latence de distribution des messages, Pub/Sub accorde aux clients abonnés une période limitée pour accuser réception d'un message donné. Cette période est appelée délai d'expiration de l'acquittement. Si vos abonnés mettent trop de temps à accuser réception des messages, ceux-ci seront redistribués, ce qui entraînera la réception de messages en double. Cette nouvelle livraison peut se produire pour plusieurs raisons:

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

  • Le traitement de chaque message dépasse le délai de confirmation des messages. En règle générale, les bibliothèques clientes Cloud augmentent le délai de chaque message jusqu'à la valeur maximale. 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 le rythme auquel les abonnés dépassent le délai 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 s'avérer plus sain.

Surveiller le débit des messages

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

Vous pouvez surveiller le débit des messages individuels ou non groupés traités par vos abonnés à l'aide de la métrique subscription/sent_message_count filtrée par le libellé delivery_type.

La requête MQL suivante vous fournit un graphique de série temporelle montrant le nombre total de messages envoyés à un abonnement Pub/Sub spécifique toutes les 10 minutes. Remplacez les valeurs d'espace réservé pour $PROJECT_NAME et $SUBSCRIPTION_NAME par vos identifiants de projet et de sujet réels.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.subscription_id == '$SUBSCRIPTION_NAME'
| align delta(10m)
| every 10m
| group_by [],
[value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

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 accusés de réception de messages implicites, il est important de surveiller les codes de réponse des 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 ces taux entraînent un ralentissement de la distribution et une augmentation du nombre de tâches en attente. Vous pouvez créer une métrique filtrée par classe de réponse. Toutefois, le nombre de requêtes push peut s'avérer plus utile en tant qu'outil permettant d'étudier la croissance de la taille et de l'âge des tâches en attente.

  • subscription/num_outstanding_messages

    En règle générale, Pub/Sub limite le nombre de messages en attente. Dans la plupart des cas,visez un nombre inférieur à 1 000 messages en attente. Une fois que le débit atteint une valeur de l'ordre de 10 000 messages par seconde, le service ajuste la limite du nombre de messages en attente. Cette limitation est appliquée par tranche de 1 000. Comme aucune garantie spécifique n'est apportée au-delà de la valeur maximale, il est recommandé de s'en tenir à 1 000 messages en attente.

  • subscription/push_request_latencies

    Cette métrique vous aide à comprendre la répartition de la latence des réponses 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 accéder à 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 vous configurez un filtre sur un abonnement, Pub/Sub reconnaît automatiquement les messages qui ne correspondent pas au filtre. Vous pouvez surveiller cette confirmation automatique.

Les métriques de messages en attente n'incluent que les messages correspondant au filtre.

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 avec accusé de réception automatique 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 liés à ces messages, consultez la page des tarifs de Pub/Sub.

Surveiller les messages non distribuables transférés

Pour surveiller les messages non distribuables que Pub/Sub transfère vers une file d'attente 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 non distribuables, vous pouvez comparer la métrique subscription/dead_letter_message_count avec la métrique topic/send_request_count. Effectuez la comparaison pour le file d'attente de lettres mortes vers lequel Pub/Sub transfère ces messages.

Vous pouvez également associer un abonnement à la file d'attente de lettres mortes, puis surveiller les messages non distribuables transférés sur cet abonnement à l'aide des métriques suivantes:

Maintenir un éditeur opérationnel

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és par response_code. Cette métrique vous indique si Pub/Sub est opérationnel et accepte les requêtes.

Le taux d'erreurs renouvelables en arrière-plan (inférieur à 1%) n'est pas une source d'inquiétude, car la plupart des bibliothèques clientes Cloud effectuent de nouvelles tentatives après échec. 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. Pour savoir comment détecter les échecs de publication permanents lors de l'utilisation des bibliothèques clientes Cloud, reportez-vous à la section Publier des messages. Au minimum, votre application d'éditeur doit consigner 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 lots. Vous pouvez surveiller le débit des messages envoyés par vos éditeurs à l'aide des métriques suivantes:

Pour obtenir un nombre précis de messages publiés, utilisez la requête MQL suivante. Cette requête MQL récupère efficacement le nombre de messages individuels publiés dans un sujet Pub/Sub spécifique à des intervalles de temps définis. Remplacez les valeurs d'espace réservé pour $PROJECT_NAME et $TOPIC_ID par vos identifiants de projet et de sujet réels.

fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.topic_id == '$TOPIC_ID'
| align delta(60m)
| every 60m
| group_by [resource.topic_id],
[value_message_sizes_sum: count(value.message_sizes)]

Pour une meilleure visualisation, en particulier pour les métriques quotidiennes, tenez compte des points suivants:

  • Examinez vos données sur une période plus longue pour mieux comprendre les tendances quotidiennes.

  • Utilisez des graphiques à barres pour représenter le nombre de messages quotidiens.

Étape suivante