Partager via

Métriques personnalisées dans Azure Monitor (préversion)

  • Article

Azure met à votre disposition des métriques prêtes à l’emploi. Il s’agit de métriques standard ou de plateforme. Les métriques personnalisées sont des indicateurs de performances ou des métriques spécifiques à l’entreprise qui peuvent être collectés via les données de télémétrie de votre application, l’agent Azure Monitor, une extension de diagnostic qui s’exécute sur vos ressources Azure ou un système de supervision externe. Une fois que les métriques personnalisées sont publiées sur Azure Monitor, vous pouvez les parcourir, les interroger et leur créer des alertes comme pour les métriques Azure standard.

Les métriques personnalisées d’Azure Monitor sont actuellement en préversion publique.

Conseil

Pour une comparaison détaillée entre les métriques standard, les métriques basées sur les journaux et les métriques personnalisées, consultez Métriques dans Application Insights.

Méthodes d’envoi de métriques personnalisées

Les métriques personnalisées peuvent être envoyées à Azure Monitor à l’aide de plusieurs méthodes :

Modèle de tarification et rétention

En général, l’ingestion de métriques standard (métriques de plateforme) dans un magasin de métriques Azure Monitor est gratuite, mais les métriques personnalisées engendrent des coûts lorsqu’elles sont mises en disponibilité générale. Les requêtes adressées à l’API de métriques engendrent des coûts. Pour plus d’informations sur l’activation de la facturation pour les métriques personnalisées et les requêtes de métriques, consultez la page des tarifs Azure Monitor.

Les métriques personnalisées sont conservées pendant la même durée que les métriques de plateforme.

Remarque

Pour offrir une meilleure expérience, les métriques personnalisées envoyées à Azure Monitor à partir de l’API Application Insights classique (Kits de développement logiciel (SDK)) sont toujours stockées dans Log Analytics et le magasin de métriques. Vos coûts pour stocker ces métriques sont uniquement basés sur le volume ingéré par Log Analytics. Il n’existe aucun coût supplémentaire pour les données stockées dans le magasin de métriques.

Définitions de métriques personnalisées

Chaque point de données de métrique publié contient un espace de noms, un nom et des informations de dimension. Ainsi, la première fois qu’une métrique personnalisée est émise vers Azure Monitor, une définition de métrique est automatiquement créée. Cette nouvelle définition de métrique peut ensuite être découverte sur toute ressource pour laquelle la métrique est émise via les définitions de métrique. Il n’est pas nécessaire de prédéfinir une métrique personnalisée dans Azure Monitor avant son émission.

Remarque

Application Insights, l’extension de diagnostics et l’agent InfluxData Telegraf sont déjà configurés pour générer des valeurs de métrique sur le bon point de terminaison régional, ainsi que pour intégrer toutes les propriétés précédentes dans chaque émission.

Utilisation de métriques personnalisées

Une fois les métriques personnalisées envoyées à Azure Monitor, vous pouvez les parcourir dans le portail Azure et les interroger par l’intermédiaire des API REST Azure Monitor. Vous pouvez également créer des alertes les concernant, afin d’être averti lorsque certaines conditions sont remplies.

Notes

Vous devez avoir un rôle Lecteur ou Contributeur pour afficher des métriques personnalisées. Consultez Lecteur d’analyse.

Parcourir vos métriques personnalisées dans le Portail Azure

  1. Accédez au portail Azure.
  2. Sélectionnez le volet Surveiller.
  3. Sélectionnez Métriques.
  4. Sélectionnez une ressource pour laquelle vous avez émis des métriques personnalisées.
  5. Sélectionnez l’espace de noms de métrique de votre métrique personnalisée.
  6. Sélectionnez la métrique personnalisée.

Pour plus d’informations sur l’affichage des métriques dans le Portail Azure, consultez Analyser des métriques avec Azure Monitor Metrics Explorer.

Conservation de stockage et latence

L’affichage d’une métrique ou dimension nouvellement ajoutée à une métrique peut prendre jusqu’à trois minutes. Une fois que les données sont dans le système, elles devraient apparaître en moins de 30 secondes dans 99 % des cas.

Si vous supprimez une métrique ou une dimension, il faudra peut-être d’une semaine à un mois pour que la modification soit supprimée du système.

Quotas et limites

Azure Monitor impose les limites d’utilisation suivantes quant aux métriques personnalisées :

Category Limite
Nombre total de séries chronologiques actives dans un abonnement par région 50 000
Clés de dimension par métrique 10
Longueur de chaîne pour les espaces de noms de métrique, les noms de métrique, les clés de dimension et les valeurs de dimension 256 caractères
Longueur combinée de tous les noms de métriques personnalisées, à l’aide de l’encodage utf-8 64 Ko

Une série chronologique active se définit comme toute combinaison unique de métriques, clés de dimension ou valeurs de dimension pour laquelle des valeurs de métrique ont été publiées au cours des 12 dernières heures.

Pour comprendre la limite des 50 000 séries chronologiques, considérez la métrique suivante :

Temps de réponse du serveur avec les dimensions Region, Department, CustomerID

Avec cette métrique, si vous avez 10 régions, 20 départements et 100 clients, cela donne 10 x 20 x 100 = 20 000 séries chronologiques.

Si vous avez 100 régions, 200 départements et 2 000 clients, cela donne 100 x 200 x 2 000 = 40 millions de séries chronologiques, ce qui est bien au-delà de la limite, rien que pour cette métrique.

Rappelons que cette limite ne s’applique pas à une métrique individuelle, mais à la somme de toutes ces métriques à l’échelle d’un abonnement et d’une région.

Suivez les étapes ci-dessous pour afficher vos métriques de série chronologique actives actuelles et plus d’informations pour faciliter la résolution des problèmes.

  1. Accédez à la section Surveiller du Portail Azure.
  2. Sélectionnez Métriques sur le côté gauche.
  3. Sous Sélectionner une étendue, vérifiez l’abonnement et les groupes de ressources applicables.
  4. Sous Affiner l’étendue, choisissez Utilisation des métriques personnalisées et l’emplacement souhaité.
  5. Sélectionnez le bouton Appliquer.
  6. Choisissez Série chronologique active, Limite de série chronologique active ou Série chronologique limitée.

Il existe une limite de 64 Ko pour la longueur combinée de tous les noms de métriques personnalisées, en supposant l’utilisation de utf-8, soit 1 octet par caractère. Si la limite de 64 Ko est dépassée, les métadonnées des métriques supplémentaires ne seront pas disponibles. Les noms de métriques des métriques personnalisées supplémentaires n’apparaîtront pas dans les champs de sélection du Portail Azure, et ne seront pas retournés par l’API dans les requêtes de définitions de métriques. Les données de métriques sont toujours disponibles et peuvent être interrogées.

Lorsque la limite a été dépassée, réduisez le nombre de métriques que vous envoyez ou diminuez la longueur de leurs noms. L’affichage des noms des nouvelles métriques prend ensuite deux jours maximum.

Pour éviter d’atteindre la limite, n’incluez pas d’aspects variables ou dimensionnels dans vos noms de métriques. Par exemple, les métriques pour l’utilisation du processeur du serveur, CPU_server_12345678-319d-4a50-b27e-1234567890ab et CPU_server_abcdef01-319d-4a50-b27e-abcdef012345 doivent être définies en tant que métriques CPU et avec une dimension Server.

Limitations et considérations relatives à la conception

Utilisation d’Application Insights à des fins d’audit. Le pipeline de télémétrie d’Application Insights est optimisé pour réduire l’impact sur les performances et limiter le trafic lié à la surveillance de votre application. Ainsi, il limite ou échantillonne (n'utilise qu'un pourcentage de vos données de télémétrie et ignore le reste) si le jeu de données initial devient trop volumineux. En raison de ce comportement, vous ne pouvez pas l’utiliser à des fins d’audit, car certains enregistrements sont susceptibles d’être ignorés.

Métriques dont le nom contient une variable. N’utilisez pas de variable dans le nom de la métrique. Utilisez une constante à la place. Chaque fois que la variable change de valeur, Azure Monitor génère une nouvelle métrique. Azure Monitor atteindra alors rapidement la limite du nombre de métriques. En règle générale, lorsque les développeurs souhaitent inclure une variable dans le nom de la métrique, ils veulent suivre plusieurs séries chronologiques au sein d’une même métrique et doivent utiliser des dimensions plutôt que des noms de métriques variables.

Dimensions de métriques à cardinalité élevée. Les métriques avec un trop grand nombre de valeurs valides dans une dimension (cardinalité élevée) sont beaucoup plus susceptibles d’atteindre la limite de 50 000. En général, vous ne devez jamais utiliser une valeur qui change constamment dans une dimension. Le timestamp, par exemple, ne doit jamais être une dimension. Vous pouvez utiliser l’ID d’un serveur, d’un client ou d’un produit, mais uniquement si vous avez un nombre réduit de chacun de ces types.

En guise de test, demandez-vous si vous pourriez créer un graphique de ce type de données. Si vous avez 10, voire 100 serveurs, il pourrait être utile de les afficher tous sur un graphique à des fins de comparaison. En revanche, si vous en avez 1 000, le graphique résultant sera probablement difficile, voire impossible à lire. Une meilleure pratique consiste à limiter le nombre de valeurs valides à moins de 100. Jusqu’à 300, vous êtes dans une zone délicate. Si vous avez besoin de dépasser ce nombre, utilisez plutôt des journaux personnalisés Azure Monitor.

En cas de variable dans le nom ou de dimension à cardinalité élevée, voici les problèmes qui peuvent se produire :

  • Les métriques deviennent peu fiables en raison de la limitation.
  • Metrics Explorer ne fonctionne pas.
  • Les alertes et les notifications deviennent imprévisibles.
  • Les coûts peuvent augmenter de façon inattendue. Microsoft ne facture pas les métriques personnalisées avec dimensions tant que cette fonctionnalité est en préversion publique. Lorsque les frais seront facturés à l’avenir, vous risquez d’encourir des frais inattendus. Nous prévoyons de facturer la consommation de métriques en fonction du nombre de séries chronologiques supervisées et du nombre d’appels d’API effectués.

Si le nom de la métrique ou la valeur de la dimension est rempli avec un identificateur ou une dimension de cardinalité élevée par erreur, vous pouvez facilement corriger l’erreur en supprimant la partie variable.

Toutefois, si une cardinalité élevée est essentielle pour votre scénario, les métriques agrégées ne sont probablement pas le bon choix. Passez à l’utilisation de journaux personnalisés (c’est-à-dire appels d’API trackMetric avec trackEvent). Toutefois, tenez compte du fait que les journaux n’agrègent pas les valeurs, si bien que chaque entrée unique est stockée. Par conséquent, si le volume de journaux est important sur une courte période (1 million par seconde par exemple), cela peut entraîner des limitations et des retards d’ingestion.

Étapes suivantes

Vous pouvez utiliser les métriques personnalisées à partir de différents services :