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 la console Google Cloud à l'aide de Monitoring.
Si vous souhaitez afficher les métriques d'autres ressources Google Cloud en plus pour les métriques Pub/Sub, utilisez Monitoring.
Sinon, vous pouvez utiliser les tableaux de bord de surveillance fournis Pub/Sub. Consultez Surveiller les sujets. et surveiller les abonnements.
Pour connaître les bonnes pratiques d'utilisation des métriques dans votre l'autoscaling, consultez les Bonnes pratiques pour l'utilisation des métriques Pub/Sub en tant que signal de scaling.
Avant de commencer
Avant d'utiliser Monitoring, assurez-vous d'avoir préparé ce qui suit:
Un compte de facturation Cloud
Un projet Pub/Sub avec la facturation activée
Pour vous assurer d'avoir bien 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 contexte. Google Cloud propose des tableaux de bord prédéfinis et personnalisés. Pour Par exemple, vous pouvez afficher un tableau de bord Pub/Sub prédéfini ou créer qui affiche les données de métriques, les règles d'alerte et les entrées de journal vers Pub/Sub.
Pour surveiller votre projet Pub/Sub à l'aide de Cloud Monitoring, procédez comme suit:
Dans Google Cloud Console, accédez à la page Monitoring.
En haut de la page, sélectionnez le nom de votre projet s'il n'est pas déjà sélectionné.
Cliquez sur Tableaux de bord dans le menu de navigation.
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, utilisez le filtre Dans Tous les tableaux de bord, sélectionnez la propriété Nom, puis saisissez
Pub/Sub
.
Pour en savoir plus sur la création, la modification et la gestion d'un tableau de bord personnalisé, consultez l'article 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:
Dans Google Cloud Console, accédez à la page Monitoring.
Dans le volet de navigation, sélectionnez Explorateur de métriques.
Dans la section Configuration, cliquez sur Sélectionner une métrique.
Dans le filtre, saisissez
Pub/Sub
.Dans Ressources actives, sélectionnez Abonnement Pub/Sub. ou Sujet Pub/Sub.
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
Pour savoir quelles métriques Pub/Sub sont transmises à Cloud Monitoring, consultez la liste des métriques Pub/Sub Documentation Cloud Monitoring.
Pour afficher les détails de
pubsub_topic
, procédez comme suit :pubsub_subscription
oupubsub_snapshot
les types de ressources surveillées, consultez la section Types de ressources surveillées dans la documentation Cloud Monitoring.
Surveiller l'utilisation des quotas
Pour un projet donné, vous pouvez utiliser IAM et Tableau de bord des quotas pour les administrateurs pour afficher les quotas et l'utilisation actuels.
Vous pouvez afficher 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 en savoir plus sur les métriques liées aux quotas, consultez
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 des alertes se déclenchent lorsque votre utilisation atteint une partie 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 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 opérationnel
Pour conserver un abonnement opérationnel, vous pouvez surveiller plusieurs à l'aide de métriques fournies par Pub/Sub. Par exemple, vous pouvez surveiller le volume des messages non confirmés, l'expiration des messages les délais d’accusé de réception, etc. Vous pouvez aussi vérifier si votre abonnement est suffisamment opérationnel pour atteindre une faible latence de distribution des messages.
Reportez-vous aux sections suivantes pour en savoir plus sur ces 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 backlog suivantes, agrégées par pour tous vos abonnements:
Messages non confirmés (
subscription/num_undelivered_messages
) pour afficher le nombre de messages non confirmés.Âge du plus ancien message non confirmé (
subscription/oldest_unacked_message_age
) pour voir l'âge du plus ancien message non confirmé en attente de l'abonnement.Score de santé de latence de distribution (
subscription/delivery_latency_health_score
) pour vérifier l'état général de l'abonnement par rapport à la latence de distribution. Pour en savoir plus sur cette métrique, consultez la section correspondante de ce document.
Créez des règles d'alerte qui se déclenchent lorsque ces valeurs se trouvent en dehors de acceptable dans le contexte de votre système. Par exemple, la valeur absolue le nombre de messages non confirmés n'est pas forcément significatif. Le backlog d'un un million de messages peut être acceptable pour un million de messages par seconde abonnement, mais non acceptable pour un abonnement à un message par seconde.
Problèmes courants liés aux tâches en attente
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 |
|
S'il existe une petite taille stable
et un nombre réduit d'instances
oldest_unacked_message_age augmente, il se peut que certains messages ne puissent pas être traités. |
Messages bloqués |
|
La valeur de oldest_unacked_message_age dépasse celle de l'abonnement
la durée de conservation des messages. |
Perte définitive de données |
|
Surveiller l'état de la latence de distribution
Dans Pub/Sub, la latence de distribution désigne le temps nécessaire pour qu'une publication
à un abonné.
Si le nombre de messages en attente augmente, vous pouvez utiliser la colonne État de latence de distribution
score (subscription/delivery_latency_health_score
) pour identifier les facteurs qui contribuent à l'augmentation de la latence.
Cette métrique mesure la santé d'un seul abonnement Intervalle de 10 minutes Cette métrique fournit des insights sur les critères suivants : nécessaires pour qu'un abonnement obtienne une latence faible et constante:
Demandes de recherche négligeables.
Messages négligeables confirmés de façon négative (messages masqués)
Délais de confirmation des messages arrivés à expiration négligeables.
Latence de confirmation cohérente inférieure à 30 secondes.
Faible utilisation constante, ce qui signifie que l'abonnement présente systématiquement une capacité suffisante pour traiter les nouveaux messages.
La métrique Score d'état de 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 sain 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 minutes, le score est défini sur 0. Recherche Un abonnement peut entraîner la relecture d'anciens messages bien après leur première lecture ce qui augmente la 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 amène un message à être livré avec une latence de distribution accrue.
Délais de confirmation expirés: si l'abonnement est arrivé à expiration d'accusés de réception au cours des 10 dernières minutes, le score est défini sur 0. Messages dont le délai d'accusé de réception a expiré sont renvoyés avec une la latence de distribution.
Latences d'accusé de réception: si le 99,9e centile de l'ensemble des accusés de réception au cours des 10 dernières minutes était supérieur à 30 secondes, le score est défini sur 0. Une latence de confirmation élevée indique qu'un client abonné le traitement d'un message prend beaucoup de temps. 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 le nombre de flux ouverts est insuffisant, le score est défini à 0. Ouvrez davantage de flux afin de vous assurer que vous disposez d'une capacité suffisante pour les nouveaux messages.
Push: si vous avez trop de messages en attente auprès de votre point de terminaison push, le score est défini sur 0. Augmentez la capacité de votre point de terminaison push pour les nouveaux messages.
Pull: si le nombre de demandes d'extraction en attente est insuffisant, le score est est définie sur 0. Ouvrez davantage de demandes d'extraction simultanées pour vous assurer que vous êtes prêt à recevoir de nouveaux messages.
Pour afficher la métrique, Explorateur de métriques sélectionnez l'option État de latence de distribution score pour le type de ressource d'abonnement Pub/Sub. Ajoutez un filtre pour sélectionner un seul abonnement à la fois. Sélectionnez l'option Aires empilées graphique et indiquez une heure spécifique pour vérifier les scores des critères pour le pour l'instant.
Voici une capture d'écran de la métrique représentée sur une période d'une heure avec un graphique en aires empilées. Le score de santé combiné atteint 5 à 4 h 15, avec une une note de 1 pour chaque critère. Plus tard, le score combiné descend à 4 à 4h20, lorsque le score d'utilisation tombe à 0.
Monitoring Query Language fournit une interface textuelle expressive permettant 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 distribution 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 d'accusé de réception
Afin de réduire la latence de distribution des messages, Pub/Sub permet aux clients abonnés un délai limité pour accuser réception . Cette période est appelée délai de confirmation. Si vos abonnés suivent trop long pour accuser réception des messages, les messages sont redistribués, ce qui entraîne les abonnés voient les messages en double. Cette nouvelle livraison peut se produire raisons:
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 la confirmation de réception du message les délais. Les bibliothèques clientes Cloud étendent généralement délai maximal configurable pour des messages individuels. 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 :
Pull et StreamingPull:
subscription/expired_ack_deadlines_count
Push :
subscription/push_request_count
filtrée parresponse_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. Inversement, un faible taux d'expiration (par exemple, de 0,1 à 1%) peuvent être opérationnels.
Surveiller le débit des messages
Les abonnés Pull et StreamingPull peuvent recevoir 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é par vos abonnés avec ces métriques:
Pull :
subscription/pull_request_count
Notez que cette métrique peut également inclure des requêtes d'extraction qui ont renvoyé aucun message)StreamingPull:
subscription/streaming_pull_response_count
Vous pouvez surveiller le débit des messages individuels ou non par lot
traités par vos abonnés avec 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
etsubcription_id
. Les abonnements push Pub/Sub utilisent les codes de réponse comme accusés de réception de messages implicites, il est important et 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 entraînent une livraison lente et un retard croissant. Vous pouvez créer une métrique filtrée par classe de réponse. Cependant, le nombre de requêtes push sera probablement plus utile, car un outil pour étudier la taille et l'âge croissant des backlogs.
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 a atteint un débit de l'ordre de 10 000 messages par seconde, le service ajuste la limite pour le nombre messages en attente. Cette limite est appliquée par incréments de 1 000. Non garanties spécifiques sont apportées au-delà de la valeur maximale, de sorte que 1 000 les messages en attente est un bon guide.
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 aux limites plus élevées des messages en attente, procédez comme suit : 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 à l'aide de filtres
Si vous configurez un filtre sur un abonnement, Pub/Sub accuse automatiquement réception des messages qui ne correspondent pas le filtre. Vous pouvez surveiller cet accusé de réception automatique.
Les métriques en attente n'incluent que les messages qui correspondent au filtre.
Pour surveiller le taux de messages confirmés automatiquement qui ne correspondent pas au filtre, utilisez le
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 le filtre 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 des tarifs de Pub/Sub.
Surveiller les messages non distribués transférés
Pour surveiller les messages non distribués que Pub/Sub
redirige vers une file d'attente de lettres mortes, utilisez la
subscription/dead_letter_message_count
la métrique. 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 devez
vous pouvez comparer la métrique subscription/dead_letter_message_count
avec
topic/send_request_count
la métrique. Faites la comparaison avec le file d'attente de lettres mortes auquel
Pub/Sub transfère ces messages.
Vous pouvez également associer un abonnement à la file d'attente de lettres mortes et surveiller a transféré les messages impossibles à distribuer sur cet abonnement à l'aide des métriques suivantes:
subscription/num_undelivered_messages
- le nombre de messages transférés accumulés dans l'abonnement.
subscription/oldest_unacked_message_age
- l'âge du plus ancien message transféré dans l'abonnement
Maintenir un éditeur sain
Le principal objectif d'un éditeur est de conserver rapidement les données des messages. Surveiller
les performances à l'aide
topic/send_request_count
(regroupement par response_code
). Cette métrique vous indique si Pub/Sub est opérationnel et accepte les requêtes.
Un taux d'erreurs renouvelables en arrière-plan (inférieur à 1%) n'est pas un
vous préoccupez, car la plupart des bibliothèques clientes Cloud relancent
é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 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. Consultez Publier des messages pour en savoir plus méthodes de détection des échecs de publication permanents lors de l'utilisation de Cloud Client Bibliothèques. L'application d'éditeur doit au minimum 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. Toi vous pouvez surveiller le débit des messages envoyés par vos éditeurs métriques:
topic/send_request_count
: le volume de messages groupés envoyés par les éditeurs.A count sur
topic/message_sizes
: le volume de messages individuels (sans lot) envoyés par les éditeurs.Vous pouvez calculer le nombre de messages envoyés en appliquant une méthode à cette métrique, ou à l'aide du langage de requête Monitoring. La requête MQL suivante crée un graphique présentant le taux d'impressions messages 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()]
Étape suivante
Pour créer une alerte pour une métrique spécifique, consultez la page Gérer les règles d'alerte basées sur les métriques.
Pour en savoir plus sur l'utilisation de MQL pour créer graphiques de surveillance, consultez la page Utiliser l'éditeur de requête.
Pour en savoir plus sur les ressources de l'API Monitoring telles que les métriques, les ressources surveillées, les groupes de ressources surveillées et les règles d'alerte, consultez la page Ressources de l'API.