Métriques personnalisées

Les métriques personnalisées vous permettent de capturer des données spécifiques à une 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 elles ne peuvent pas vous indiquer, par exemple, 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. Pour en savoir plus sur ces types de métriques personnalisées, consultez Présentation des métriques basées sur les journaux.

Les métriques personnalisées, également appelées métriques spécifiques à une application, vous permettent de définir et de collecter des informations non disponibles dans les métriques Cloud Monitoring intégrées. Vous capturez ces métriques à l'aide d'une API fournie par une bibliothèque pour instrumenter votre code, puis vous envoyez ces métriques à une application de backend telle que Cloud Monitoring.

Vous pouvez créer des métriques personnalisées en utilisant directement l'API Cloud Monitoring. Cependant, nous vous recommandons d'utiliser OpenCensus. Pour savoir comment créer des métriques personnalisées, consultez les documents suivants:

  • Créez des métriques personnalisées avec OpenCensus, qui explique comment utiliser OpenCensus, une bibliothèque de surveillance et de traçage Open Source. Cette bibliothèque vous permet de créer des métriques personnalisées, d'y ajouter des données et d'exporter des données vers Cloud Monitoring.

  • La section Créer des métriques personnalisées avec l'API explique comment créer des métriques personnalisées à l'aide de l'API Cloud Monitoring et comment y ajouter des données de métrique. Ce document explique comment utiliser l'API Monitoring avec des exemples utilisant les langages de programmation APIs Explorer, C#, Go, Java, Node.js, PHP, Python et Ruby.

En ce qui concerne Cloud Monitoring, vous pouvez utiliser des métriques personnalisées, telles que les métriques intégrées. Vous pouvez les représenter sous forme de graphique, définir des alertes, les lire et les surveiller. Pour en savoir plus sur la lecture des données de métriques, consultez les documents suivants:

  • Parcourir les types de métriques et de ressources explique comment répertorier et examiner vos types de métriques personnalisées et intégrées. Par exemple, vous pouvez utiliser les informations de ce document pour répertorier tous les descripteurs de métriques personnalisés de votre projet.
  • La page Lire les données des métriques explique comment récupérer des données de séries temporelles à partir de métriques personnalisées et intégrées à l'aide de l'API Monitoring. Par exemple, ce document explique comment utiliser l'API afin d'obtenir l'utilisation du processeur pour les instances de machines virtuelles (VM) dans votre projet Google Cloud.

Google Cloud Console fournit une page dédiée pour vous aider à afficher votre utilisation des métriques personnalisées. Pour en savoir plus sur le contenu de cette page, consultez Afficher les diagnostics des métriques.

Descripteurs de métrique pour les métriques personnalisées

Chaque type de métrique doit disposer d'un descripteur qui définit l'organisation des données. Le descripteur de métrique définit également les libellés de la métrique et son nom. Par exemple, les listes de métriques affichent les descripteurs de métriques pour tous les types de métriques intégrés.

Lorsque vous utilisez des métriques personnalisées, Cloud Monitoring peut créer le descripteur de métrique à votre place en utilisant les données que vous rédigez. Vous pouvez également créer explicitement le descripteur de métrique, puis écrire des 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 l'un de vos programmes s'exécute sur une seule machine, et qu'il appelle les programmes auxiliaires A et B. Vous souhaitez compter la fréquence d'appel des programmes A et B. Vous souhaitez également savoir si le programme A est appelé plus de 10 fois par minute et quand le programme B est appelé plus de 5 fois par minute. Enfin, supposons qu'il n'y ait qu'un seul projet Google Cloud et que vous ayez l'intention d'écrire les données dans la ressource surveillée global.

Cet exemple décrit plusieurs conceptions que vous pouvez utiliser pour vos métriques personnalisées:

  • Vous utilisez deux métriques personnalisées : Metric-type-A comptabilise les appels vers le programme A et Metric-type-B les appels vers le 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 créer deux règles d'alerte avec une condition pour 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 personnalisée 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 d'étiquettes. Par conséquent, il existe une série temporelle dont la valeur de libellé est A et une autre série dont la valeur de libellé 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 un incident lorsque le taux d'appels pour le programme A dépasse un seuil doit utiliser 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 personnalisée pour comptabiliser le nombre d'appels, mais vous n'utilisez pas de libellé pour enregistrer le programme ayant é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 d'analyse de données. Toutefois, la dernière conception ne le fait pas.

Pour en savoir plus sur la création de descripteurs de métriques, consultez Créer des descripteurs de métrique.

Noms des métriques personnalisées

Lorsque vous créez une métrique personnalisée, vous définissez un identifiant de chaîne qui représente le type de métrique. Cette chaîne doit être unique parmi les métriques personnalisées de votre projet Google Cloud. Elle doit utiliser un préfixe qui marque la métrique comme étant une métrique définie par l'utilisateur. Pour Monitoring, les préfixes autorisés sont custom.googleapis.com/, external.googleapis.com/user et external.googleapis.com/prometheus. Ce préfixe est suivi d'un nom qui décrit ce que vous collectez. Pour savoir comment nommer une métrique personnalisée, 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 métriques sont personnalisées. Ces deux exemples concernent les métriques qui mesurent l'utilisation du processeur. Toutefois, ils utilisent des modèles organisationnels différents. Lorsque vous prévoyez d'avoir un grand nombre de métriques personnalisées, nous vous recommandons d'utiliser une structure de noms hiérarchiques semblable à 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

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, leur nom de ressource pour ces métriques est le suivant:

    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 personnalisées

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

Réfléchissez à la ressource surveillée avant de créer votre descripteur de 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 libellés pour l'ID du projet, l'ID de l'instance et la zone de l'instance. Par conséquent, si vous prévoyez d'écrire une métrique personnalisée par rapport à une ressource de VM Compute Engine, les libellés de ressources incluent l'ID d'instance afin que vous n'ayez pas besoin d'un libellé pour l'ID d'instance dans le descripteur de métrique.

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

Vous devez utiliser l'un des types de ressources surveillées suivants avec des métriques personnalisées:

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 les données de votre métrique personnalisée avec d'autres données de métriques à partir des mêmes ressources.

global et les 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 avez de nombreuses sources de métriques dans un projet, l'utilisation du même objet de ressource global peut provoquer des collisions et des écrasements de vos données de métriques.

Méthodes de l'API compatibles avec les métriques personnalisées

Le tableau suivant indique les méthodes de l'API Monitoring compatibles avec les métriques personnalisées et celles qui sont compatibles avec les métriques intégrées:

Méthode API Monitoring Utilisation avec des
métriques personnalisées
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 connaître les limites liées aux métriques personnalisées et à la conservation des données, consultez la page Quotas et limites.

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

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

Étapes suivantes