Présentation des métriques définies par l'utilisateur

Les métriques définies par l'utilisateur correspondent à toutes les métriques qui ne sont pas définies par Google Cloud. Il s'agit de métriques que vous pouvez définir et de métriques qui qu'une application tierce définit. Les métriques définies par l'utilisateur permettent des données propres à l'application ou des données système côté client. Les métriques intégrées collectées par Cloud Monitoring peuvent vous donner des informations sur la latence du backend ou l'utilisation du disque, mais ils ne peuvent pas vous dire vous permet, par exemple, de déterminer le nombre de routines d'arrière-plan générées par votre application.

Vous pouvez également créer des métriques basées sur le contenu des entrées de journal. Les métriques basées sur les journaux sont une classe définie par l'utilisateur, mais vous devez créer depuis Cloud Logging. Pour en savoir plus sur les métriques basées sur les journaux, consultez Présentation des métriques basées sur les journaux

Les métriques définies par l'utilisateur sont parfois appelées métriques personnalisées spécifiques à l'application. Ces métriques vous permettent, à vous ou à un tiers, application, définir et collecter des informations que les métriques intégrées à Cloud Monitoring ne peuvent pas obtenir. Vous pouvez capturer ces métriques à l'aide d'une API fournie par une bibliothèque pour instrumenter Vous envoyez ensuite les métriques à une application backend Cloud Monitoring.

Vous pouvez créer des métriques définies par l'utilisateur, à l'exception des métriques basées sur les journaux, en utilisant directement l'API Cloud Monitoring. Toutefois, nous vous recommandons d'utiliser OpenTelemetry. Pour savoir comment des métriques définies par l'utilisateur, consultez les documents suivants:

En ce qui concerne Cloud Monitoring, vous pouvez utiliser des métriques définies par l'utilisateur comme les métriques intégrées. Vous pouvez les représenter sous forme de graphique, et les surveiller. Pour en savoir plus sur la lecture des données de métriques, consultez les documents suivants:

  • Répertorier les types de métriques et de ressources : explique comment répertorier et examiner vos types de métriques intégrées et définies par l'utilisateur. Par exemple : vous pouvez utiliser les informations contenues dans ce document pour lister descripteurs de métriques dans votre projet.
  • Découvrez comment récupérer les données de séries temporelles. comment récupérer des données de séries temporelles à partir de métriques à l'aide de API Monitoring. Par exemple, ce document explique comment vous pouvez utiliser l'API pour connaître l'utilisation du processeur de machines virtuelles (VM) dans votre projet Google Cloud.

La console Google Cloud fournit une page dédiée qui vous permet de consulter votre utilisation définies par l'utilisateur. Pour en savoir plus sur le contenu de cette page, consultez Afficher et gérer l'utilisation des métriques

Descripteurs de métriques définies par l'utilisateur

Chaque type de métrique doit être associé à un descripteur de la métrique qui définit la manière dont les données de métriques sont organisées. Le descripteur de la métrique définit aussi les étiquettes pour la métrique et son nom. Par exemple, Les listes de métriques affichent les descripteurs de métriques pour tous les éléments intégrés types de métriques.

Cloud Monitoring peut créer le descripteur de la métrique à votre place à l'aide de la commande de données de métrique que vous écrivez, ou vous pouvez créer explicitement la métrique et écrire les données de métriques. Dans les deux cas, vous devez décider comment vous souhaitez organiser vos données de métriques.

Exemple de conception

Supposons que vous ayez un programme qui s'exécute sur une seule machine, et que ce programme appelle les programmes auxiliaires A et B. Vous voulez compter la fréquence à laquelle les programmes A et B sont appelés. Vous voulez également savoir quand Le programme A est appelé plus de 10 fois par minute, tandis que le programme B est plus de cinq fois par minute. Enfin, supposons que vous avez un seul projet Google Cloud, et si vous prévoyez d'écrire les données sur la ressource surveillée global.

Cet exemple décrit quelques conceptions différentes que vous pouvez utiliser pour vos métriques définies par l'utilisateur:

  • Vous utilisez deux métriques: Metric-type-A comptabilise les appels au programme A et Metric-type-B comptabilisent les appels au programme B. Dans ce cas, Metric-type-A contient une série temporelle et Metric-type-B contient une série temporelle.

    Vous pouvez créer une seule règle d'alerte avec deux conditions ou vous pouvez créer deux règles d'alerte une condition avec ce mode de données. Une règle d'alerte peut accepter plusieurs conditions, mais elle possède une configuration unique pour les canaux de notification.

    Ce modèle peut être approprié lorsque vous n'êtes pas intéressé par des similitudes entre les données des activités surveillées. Dans cet exemple, les activités correspondent au taux d'appels aux programmes A et B.

  • Vous utilisez une seule métrique et un libellé pour stocker un identifiant de programme. Par exemple, le libellé peut stocker la valeur A ou B. Monitoring crée une série temporelle pour chaque combinaison unique de libellés. Par conséquent, il existe une série temporelle dont la valeur de l'étiquette est A, une autre série temporelle dont la valeur de l'étiquette est B.

    Comme avec le modèle précédent, vous pouvez créer une ou deux règles d'alerte. Cependant, les conditions de la règle d'alerte sont plus complexes. Une condition qui génère lorsque le taux d'appels pour le programme A dépasse un seuil doit Utilisez un filtre qui n'inclut que les points de données dont la valeur de libellé est A.

    L'un des avantages de ce modèle est qu'il facilite le calcul des ratios. Par exemple, vous pouvez déterminer la somme totale due aux appels à A.

  • Vous utilisez une seule métrique pour compter le nombre d'appels, n'utilisez pas de label pour enregistrer quel programme a été appelé. Dans ce modèle, il existe une seule série temporelle qui combine les données des deux programmes. Cependant, vous ne pouvez pas créer une règle d'alerte qui répond à vos objectifs, car les données de deux programmes ne peuvent pas être séparées.

Les deux premières conceptions vous permettent de répondre à vos exigences en matière d’analyse de données ; Toutefois, pas la dernière conception.

Pour en savoir plus, consultez Créez une métrique définie par l'utilisateur.

Noms des métriques définies par l'utilisateur

Lorsque vous créez une métrique définie par l'utilisateur, vous définissez un identifiant de chaîne qui représente le type de métrique. Cette chaîne doit être unique parmi les définies par l'utilisateur Google Cloud. Il doit utiliser un préfixe qui marque la métrique en tant que définie par l'utilisateur. Pour Monitoring, les préfixes autorisés sont les suivants : custom.googleapis.com/, workload.googleapis.com/ external.googleapis.com/user et external.googleapis.com/prometheus. Ce préfixe est suivi d'un nom décrit ce que vous collectez. Pour en savoir plus sur la méthode recommandée pour nommer une métrique, consultez Conventions d'attribution de noms aux métriques Voici des exemples des deux genres d'identifiants employés pour les types de métriques :

    custom.googleapis.com/cpu_utilization
    custom.googleapis.com/instance/cpu/utilization

Dans l'exemple précédent, le préfixe custom.googleapis.com indique que les deux sont des métriques définies par l'utilisateur. Ces deux exemples concernent des métriques qui mesurent Utilisation du processeur mais ils utilisent des modèles organisationnels différents. Lorsque vous d'un grand nombre de métriques définies par l'utilisateur, nous vous recommandons utiliser une structure de nommage hiérarchique comme celle utilisée dans le deuxième exemple.

Tous les types de métriques possèdent des identifiants uniques globaux appelés noms de ressources. La structure d'un nom de ressource pour un type de métrique est la suivante :

projects/PROJECT_ID/metricDescriptors/METRIC_TYPE

où METRIC_TYPE est l'identifiant de chaîne du type de métrique. Si les exemples de métriques précédents sont créés dans le projet my-project-id, leurs ressources pour ces métriques sont les suivantes:

    projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization
    projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization

Nom ou type ? Dans le descripteur de métrique, le champ name enregistre le nom de ressource du type de métrique et le champ type enregistre la chaîne METRIC_TYPE.

Types de ressources surveillées pour les métriques définies par l'utilisateur

Lorsque vous écrivez vos données dans une série temporelle, vous devez indiquer leur origine. Pour spécifier la source des données, vous choisissez un un type de ressource surveillée représente la provenance de vos données, puis utilisez-le pour décrire une origine spécifique. La ressource surveillée ne fait pas partie du type de métrique. La série temporelle dans lequel vous écrivez des données inclut une référence au type de métrique référence à la ressource surveillée. Le type de métrique décrit les données la ressource surveillée décrit l'origine des données.

Examinez la ressource surveillée avant de créer votre descripteur de la métrique. Le type de ressource surveillée que vous utilisez a une incidence sur les libellés que vous devez inclure dans le descripteur de métrique. Par exemple, La ressource de VM Compute Engine contient des étiquettes. pour l'ID du projet, l'ID de l'instance et la zone de l'instance. Par conséquent, si vous à écrire votre métrique sur une ressource de VM Compute Engine, les étiquettes de ressource incluent l'ID d'instance, vous n'avez pas besoin d'étiquette pour l'ID d'instance dans le descripteur de la métrique.

Chacun des points de données de votre métrique doit être associé à un objet de type "ressource surveillée". Les points des différents objets de type "ressource surveillée" sont stockés dans des séries temporelles.

Vous devez utiliser l'un des types de ressources surveillées suivants avec les métriques définies par l'utilisateur:

Une pratique courante consiste à utiliser les objets de type "ressource surveillée" représentant les ressources physiques sur lesquelles le code de votre application est exécuté. Cette approche présente plusieurs avantages :

  • Vous obtenez de meilleures performances par rapport à l'utilisation d'un seul type de ressource.
  • Vous évitez les données hors service causées par plusieurs processus écrivant dans la même série temporelle.
  • Vous pouvez regrouper vos données de métriques définies par l'utilisateur avec d'autres données de métriques issues de la les mêmes ressources.

global et ressources génériques

Les types de ressources generic_task et generic_node sont utiles lorsqu'aucun des types de ressources plus spécifiques n'est approprié. Le type generic_task sert à définir des ressources de type "tâche", telles que des applications. Le type generic_node sert à définir des ressources de type "nœud", telles que des machines virtuelles. Les deux types generic_* ont plusieurs libellés communs dont vous pouvez vous servir pour définir des objets de ressource uniques. Cela facilite leur utilisation dans les filtres de métriques pour les agrégations et les réductions.

En revanche, le type de ressource global ne dispose que des libellés project_id et location. Lorsque vous disposez de plusieurs sources de métriques dans un projet, l'utilisation du le même objet ressource global peut entraîner les collisions et les écrasements de vos données de métriques.

Méthodes d'API compatibles avec les métriques définies par l'utilisateur

Le tableau suivant indique les méthodes de l'API Monitoring acceptent les métriques définies par l'utilisateur et les méthodes compatibles avec les métriques intégrées:

Méthode API Monitoring À utiliser avec
des métriques définies par l'utilisateur		 Utilisation avec des
métriques intégrées
monitoredResourceDescriptors.get oui oui
monitoredResourceDescriptors.list oui oui
metricDescriptors.get oui oui
metricDescriptors.list oui oui
timeSeries.list oui oui
timeSeries.create oui
metricDescriptors.create oui
metricDescriptors.delete oui

Limites et latences

Pour les limites liées aux métriques définies par l'utilisateur et à la conservation des données, consultez la page Quotas et limites.

Pour conserver vos données de métriques au-delà de la période de conservation, vous devez : copier manuellement les données vers un autre emplacement, tel que Cloud Storage ou dans BigQuery.

Pour en savoir plus sur les latences associées à l'écriture de données dans définies par l'utilisateur, consultez la section Latence des données de métriques.

Étape suivante