Présentation de la surveillance

L'API Pub/Sub exporte les métriques via Cloud Monitoring. Cloud Monitoring vous permet de créer des tableaux de bord et des règles d'alerte de surveillance, ou d'accéder aux métriques par programmation.

Afficher les métriques

Pour afficher les tableaux de bord Cloud Monitoring ou définir des règles d'alerte, accédez à Monitoring dans Google Cloud Console :

Accéder à Monitoring

Vous pouvez également utiliser l'API Cloud Monitoring pour interroger et afficher des métriques sur les abonnements et les sujets.

Métriques et types de ressources

Garantir que vous n'avez pas atteint votre quota

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:

  • serviceruntime.googleapis.com/quota/rate/net_usage
  • serviceruntime.googleapis.com/quota/limit

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

Par exemple, la requête Monitoring Query Language suivante crée un graphique avec la fraction de quota d'éditeurs 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 estimez que votre utilisation dépasse les limites de quota par défaut, créez des règles d'alerte pour tous les quotas pertinents. Ces alertes doivent se déclencher lorsque votre utilisation atteint un certain seuil de la limite. Par exemple, la requête "Langage de requête Monitoring" suivante déclenche votre 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 et une alerte plus personnalisées sur les métriques de quota, consultez la page Utiliser des métriques de quota.

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

S'assurer que les abonnés restent opérationnels

Surveiller les tâches en attente

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

  • subscription/num_undelivered_messages
  • subscription/oldest_unacked_message_age

Créez des règles d'alerte qui se déclenchent lorsque ces valeurs sont inhabituellement élevées dans le cadre de votre système. Par exemple, le nombre absolu de messages non distribué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.

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 la page Surveiller l'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 un petit nombre de messages impossibles à traiter. Messages bloqués Examinez vos journaux d'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 sur 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.
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 bien avant l'arrivée à expiration de la durée de conservation des messages de l'abonnement.

Surveiller l'arrivée à expiration du délai de confirmation

Afin de réduire la latence de bout en bout de la distribution des messages, Pub/Sub accorde aux clients abonnés une période limitée pour accuser réception d'un message donné (nommé "délai de confirmation") avant de le redistribuer. 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. Ce problème peut avoir plusieurs causes :

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

Il peut être utile d'évaluer le rythme auquel les abonnés dépassent le délai de confirmation. La métrique spécifique dépend du type d'abonnement :

  • Pull et StreamingPull : valeur de subscription/pull_ack_message_operation_count filtrée par response_code != "success"

  • Push : valeur de subscription/push_request_count filtrée par response_code != "success"

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 les abonnements push

Pour les abonnements push, vous devez également surveiller ces métriques :

  • 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 (créez une métrique filtrée par classe de réponse), car ces taux entraînent un ralentissement de la distribution et une augmentation du nombre de tâches en attente. 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. Vous devez cibler un nombre inférieur à 1 000 messages en attente dans la plupart des cas. En règle générale, le service ajuste la limite en fonction du débit global de l'abonnement par incréments de 1 000, une fois que le débit atteint une valeur de l'ordre de 10 000 messages par seconde. 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.

  • subscription/push_request_latencies

    Cette métrique vous aide à comprendre la répartition de la latence des réponses de votre 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 la fraction de messages confirmés par les abonnés à l'aide du langage de requête Monitoring. La requête MQL suivante crée un graphique contenant la fraction de messages confirmés par les abonnés lors d'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

Pub/Sub reconnaît automatiquement les messages qui ne correspondent pas au filtre. Vous pouvez surveiller le nombre, la taille et le coût de ces messages.

Pour surveiller le nombre de messages qui ne correspondent pas à un filtre, utilisez la métrique subscription/ack_message_count avec le libellé delivery_type et la valeur filter.

Pour surveiller la taille et le coût des messages qui ne correspondent pas à un filtre, utilisez la métrique subscription/byte_cost avec le libellé operation_type et la valeur filter_drop. Pour en savoir plus sur les frais liés à ces messages, consultez la page des tarifs de Pub/Sub.

Surveiller les messages transférés qui ne sont pas distribués

Pour surveiller les messages impossibles à distribuer par Pub/Sub vers un sujet inactif, utilisez la métrique subscription/dead_letter_message_count. La métrique subscription/dead_letter_message_count compte le nombre de messages non distribués transférés par Pub/Sub depuis 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_message_operation_count à partir du sujet vers lequel Pub/Sub transmet ces messages.

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

  • subscription/num_undelivered_messages: nombre de messages que les abonnés n'ont pas traités.

  • subscription/oldest_unacked_message_age: délai avant l'expiration du message suivant

S'assurer que les éditeurs sont opérationnels

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.

Le taux d'erreurs renouvelables en arrière-plan (nettement inférieur à 1%) ne devrait pas être une source d'inquiétude, car la plupart des bibliothèques clientes Google Cloud effectuent de nouvelles tentatives après échec. Vous devez examiner les taux d'erreur supérieurs à 1%. Étant donné que l'application traite les codes qui ne sont pas reproductibles (plutôt que 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 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 Google 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.