Surveiller Pub/Sub dans Cloud Monitoring

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

Ce document vous 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 Surveiller les thèmes et Surveiller les abonnements.

Pour connaître les bonnes pratiques concernant l'utilisation des métriques dans votre 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 :

  • Un compte de facturation Cloud

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

Pour vérifier que vous avez bien obtenu les deux, suivez le guide de démarrage rapide sur l'utilisation de 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 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 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 la console Google Cloud , 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 et 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 la console Google Cloud , 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 PromQL

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 de requête Prometheus (PromQL) pour interroger et analyser vos métriques Pub/Sub.

Pour accéder à l'éditeur de code et interroger les métriques Cloud Monitoring avec PromQL dans l'explorateur de métriques, consultez Utiliser l'éditeur de code pour PromQL.

Par exemple, vous pouvez saisir une requête PromQL pour surveiller le nombre de messages envoyés à un abonnement spécifique sur une période glissante d'une heure :

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="your-project-id",
    "subscription_id"="your-subscription-id"
  }[1h])
)

Surveiller l'utilisation du quota

Pour un projet donné, vous pouvez utiliser le tableau de bord "IAM et administration" sur la page "Quotas" pour afficher les quotas et l'utilisation actuels.

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

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

Par exemple, la requête PromQL suivante crée un graphique avec la fraction du quota d'éditeur utilisée dans chaque région :

sum by (quota_metric, location) (
  rate({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
)
/
(max by (quota_metric, location) (
  max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
) / 60 )

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

sum by (quota_metric, location) (
  increase({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
/
max by (quota_metric, location) (
   max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
> 0.8

Pour une surveillance et des alertes plus personnalisées sur les métriques de quota, consultez 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 de ses propriétés à 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 faible latence de distribution des messages.

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

Surveiller le backlog de messages

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 backlog suivantes, agrégées par ressource, pour tous vos abonnements :

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'a pas nécessairement de sens. Un backlog d'un million de messages peut être acceptable pour un abonnement à un million de messages par seconde, mais inacceptable pour un abonnement à un message par seconde.

Utiliser la version régionale des métriques au lieu des versions mondiales

Pub/Sub propose des versions régionales et mondiales des métriques utilisées pour surveiller le backlog de vos abonnements. Assurez-vous d'utiliser les versions régionales avec le suffixe by_region :

N'utilisez pas les versions globales de ces métriques si vous souhaitez que vos tableaux de bord de surveillance et vos règles d'alerte soient résilients aux pannes dans une seule région. Les versions mondiales de ces métriques nécessitent de calculer le backlog dans toutes les régions connues pour avoir des messages, ce qui signifie qu'une indisponibilité dans une seule région entraîne un manque de données. En revanche, les versions by_region des métriques calculent et indiquent le backlog pour chaque région. Si le backlog ne peut pas être calculé pour une seule région, la métrique indique quand même des valeurs pour les autres régions.

Problèmes courants liés au backlog

Symptômes Problème Solutions
Les valeurs oldest_unacked_message_age_by_region et num_unacked_messages_by_region augmentent conjointement. Les abonnés ne suivent pas le volume de messages
  • Ajoutez des threads ou processus pour les abonnés.
  • Ajoutez des machines ou conteneurs pour les abonnés.
  • Recherchez dans votre code des signes de bugs qui l'empêchent d'accuser réception des messages ou de les traiter en temps voulu. Consultez Surveiller l'expiration du délai de confirmation.
Si la taille du backlog est faible et stable, et que le oldest_unacked_message_age_by_region augmente de manière constante, il est possible que certains messages ne puissent pas être traités. Messages bloqués
  • Examinez les journaux de votre application pour déterminer si certains messages sont à l'origine du 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. Déposez une demande d'assistance une fois que vous êtes sûr 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 lettres mortes.
Le oldest_unacked_message_age_by_region dépasse la durée de conservation des messages d'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 backlog 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 à l'augmentation de la latence.

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

  • Demandes de recherche négligeables.

  • Messages confirmés négativement (NACK) négligeables.

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

  • Latence de confirmation constante inférieure à 30 secondes.

  • Une utilisation faible et constante, ce qui signifie que l'abonnement dispose 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 fait l'objet de requêtes de recherche au cours des 10 dernières minutes, le score est défini sur 0. Rechercher un abonnement peut entraîner la relecture d'anciens messages longtemps après leur première publication, ce qui augmente leur latence de distribution.

  • Messages avec accusé de réception négatif (NACK) : si l'abonnement a reçu des demandes d'accusé de réception 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 redistribution d'un message avec une latence de distribution accrue.

  • Délais de confirmation expirés : si des délais de confirmation ont expiré pour l'abonnement 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 rediffusés avec une latence de distribution plus élevée.

  • 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 a dépassé 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 du côté du client abonné.

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

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

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

    • Pull : si vous n'avez pas assez de demandes d'extraction en attente, le score est défini sur 0. Ouvrez plus de demandes d'extraction 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 d'état de la latence de remise 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 aires empilées et pointez sur un moment précis pour vérifier les scores de critères de l'abonnement à ce moment-là.

La capture d'écran ci-dessous montre la métrique représentée sur une période d'une heure à l'aide d'un graphique en aires empilées. Le score de santé combiné atteint 5 à 4h15, avec un score de 1 pour chaque critère. Plus tard, le score combiné diminue à 4 à 4h20, lorsque le score d'utilisation tombe à 0.

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

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

sum_over_time(
  {
    "__name__"="pubsub.googleapis.com/subscription/delivery_latency_health_score",
    "monitored_resource"="pubsub_subscription",
    "subscription_id"="$SUBSCRIPTION"
  }[${__interval}]
)

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 un délai limité pour accuser réception d'un message donné. Cette période est appelée "délai d'accusé de réception". Si vos abonnés mettent trop de temps à accuser réception des messages, ceux-ci sont renvoyés, ce qui entraîne l'affichage de messages en double. Plusieurs raisons peuvent expliquer cette nouvelle tentative de livraison :

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

  • Le traitement de chaque message prend plus de temps que le délai d'accusé de réception. Les bibliothèques clientes Cloud étendent généralement le délai pour les messages individuels jusqu'à un maximum 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 le taux de non-respect du délai d'accusé de réception par les abonnés. 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 faible taux d'expiration (par exemple, de 0,1 à 1%) peut être sain.

Surveiller le débit de messages

Les abonnés 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 de messages par lot traités par vos abonnés à l'aide des métriques suivantes :

Vous pouvez surveiller le débit de messages individuels ou non regroupé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 PromQL suivante vous fournit un graphique de série temporelle indiquant le nombre total de messages envoyés à un abonnement Pub/Sub spécifique sur une période glissante de 10 minutes. Remplacez les valeurs des espaces réservés $PROJECT_NAME et $SUBSCRIPTION_NAME par les identifiants réels de votre projet et de votre thème.

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="$PROJECT_NAME",
    "subscription_id"="$SUBSCRIPTION_NAME"
  }[10m])
)

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 subscription_id. Étant donné que les abonnements push Pub/Sub utilisent des codes de réponse comme confirmations implicites des messages, 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 ils entraînent une livraison lente et un backlog croissant. Vous pouvez créer une métrique filtrée par classe de réponse. Toutefois, le nombre de requêtes push est probablement plus utile pour examiner la taille et l'ancienneté croissantes 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,essayez de ne pas avoir plus de 1 000 messages en attente. Une fois que le débit atteint un taux de l'ordre de 10 000 messages par seconde, le service ajuste la limite du nombre de messages en attente. Cette limitation est effectuée par incréments de 1 000. Aucune garantie spécifique n'est donnée au-delà de la valeur maximale. Par conséquent, 1 000 messages en attente est une bonne indication.

  • subscription/push_request_latencies

    Cette métrique vous aide à comprendre la distribution 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 bénéficier de limites de messages en attente plus élevées, les abonnés aux notifications push doivent confirmer plus de 99% des messages qu'ils reçoivent.

Vous pouvez calculer la fraction de messages que les abonnés accusent réception à l'aide de PromQL. La requête PromQL suivante crée un graphique avec la fraction de messages que les abonnés reconnaissent sur un abonnement :

rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION",
  "response_class"="ack"
}[${__interval}])
/
rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION"
}[${__interval}])

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 cet accusé de réception automatique.

Les métriques sur le backlog n'incluent que les messages correspondant au filtre.

Pour surveiller le taux de messages reconnus 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 abonnements avec les SMT

Si votre abonnement contient un SMT qui filtre les messages, les métriques de backlog incluent les messages filtrés jusqu'à ce que le SMT s'exécute réellement sur eux. Cela signifie que le volume de messages en attente peut sembler plus important et que l'âge du plus ancien message non confirmé peut sembler plus élevé que ce qui sera envoyé à votre abonné. Il est particulièrement important de garder cela à l'esprit si vous utilisez ces métriques pour effectuer le scaling automatique des abonnés.

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 à la métrique topic/send_request_count. Comparez-le à la file d'attente de lettres mortes vers laquelle 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 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 pouvant faire l'objet d'une nouvelle tentative en arrière-plan (inférieur à 1%) n'est pas préoccupant, car la plupart des bibliothèques clientes Cloud réessaient les échecs de messages. 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 demandes 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. Consultez la section Publication de messages pour découvrir comment détecter les échecs de publication permanents lorsque vous utilisez les bibliothèques clientes Cloud. Votre application d'éditeur doit au minimum 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 de messages

Les éditeurs peuvent envoyer des messages par lots. Vous pouvez surveiller le débit de 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 PromQL suivante. Cette requête PromQL récupère efficacement le nombre de messages individuels publiés dans un sujet Pub/Sub spécifique au cours d'intervalles de temps définis. Remplacez les valeurs des espaces réservés $PROJECT_NAME et $TOPIC_ID par les identifiants réels de votre projet et de votre thème.

sum by (topic_id) (
  increase({
    "__name__"="pubsub.googleapis.com/topic/message_sizes_count",
    "monitored_resource"="pubsub_topic",
    "project_id"="$PROJECT_NAME",
    "topic_id"="$TOPIC_ID"
  }[${__interval}])
)

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

  • Affichez 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.

Étapes suivantes