Metric Aggregate Pruning : un nouvel outil pour la gestion de cardinalité des métriques

Aujourd'hui, nous annonçons la sortie de Metric Aggregate Pruning, un nouvel outil pour gérer la cardinalité des métriques dimensionnelles dans New Relic One. 

Notre nouvelle capacité Metric Aggregate Pruning vous permet de créer des règles indiquant à New Relic One quels attributs de données métriques sont importants pour connaître les tendances et analyses à plus long terme et quels sont ceux qui sont pertinents pour le dépannage à court terme uniquement.  La configuration de New Relic One pour « élaguer » les attributs dont vous n'avez pas besoin lors des requêtes sur de longues périodes de temps vous aide à éviter les limites de cardinalité qui réduisent l'utilité de vos données.

Metric Aggregate Pruning est la toute dernière nouveauté ajoutée à notre API de gestion des données des règles de suppression NerdGraph.  Si vous connaissez déjà les limites de cardinalité et les API de règles de suppression des données et que vous aimeriez démarrer immédiatement avec Metric Aggregate Pruning, consultez notre documentation ou passez à « Comment utiliser Metric Aggregate Pruning ». 

Si, par contre, vous n'êtes pas familiarisé avec la cardinalité des métriques, nous aborderons brièvement de quoi il s'agit, nous verrons comment déterminer s'il y a une limite de cardinalité et nous partagerons avec vous trois solutions à ce problème. 

Qu'est-ce que la cardinalité des métriques ? 

Les métriques sont un élément clé de toute plateforme d'observabilité. Il s'agit de mesures dans le temps qui représentent un seul point de données, tel que le pourcentage de CPU utilisé sur un système ou une mesure agrégée, ainsi que le nombre d'octets envoyé à un réseau au cours de la dernière minute. Elles sont ainsi idéales pour identifier les tendances dans le temps ou observer les taux de changement. 

Dans le domaine du monitoring, la cardinalité fait référence au nombre de combinaisons uniques de paires clé/valeurs qui existent pour les attributs que vous incluez sur une métrique.  Par exemple, vous recueillez peut-être sur chacun de vos systèmes un pourcentage de la métrique de CPU utilisé, appelé « cpuPercent ».  Si vous incluez un attribut hostname avec cette métrique afin de pouvoir identifier le système sur lequel la métrique est recueillie et que vous disposez de deux hôtes générant des rapports appelés « host1 » et « host2 », la cardinalité est faible. Cela est dû au fait qu'il n'y a qu'un seul attribut hostname et deux valeurs uniques pour la métrique : host1 et host2. La cardinalité est de 2. Par contre, si vous recueillez une métrique appelée « cpuPercent » avec un attribut hostname et un attribut process id pour tous les processus d'un système, et que vous avez des milliers de systèmes, la cardinalité est alors élevée. Cela est dû au fait qu'il pourrait y avoir des millions de combinaisons uniques d'identifiants de processus et de systèmes.

Les valeurs à faible cardinalité et (surtout) celles à cardinalité élevée sont importantes lorsque nous essayons de répondre à des questions telles que : « Montrez-moi tous les utilisateurs qui ont rencontré une erreur 504 aujourd'hui entre 9h30 et 10h30 » comme indiqué dans cet article sur l'importance des données à cardinalité élevées dans l'observabilité. Afin de résoudre ce problème, vous aurez besoin de corréler un grand nombre de données. Toutefois, vous ne voulez pas que l'énorme quantité de données empêche votre capacité à y effectuer des recherches. 

Lorsque vous envoyez des données à New Relic One, non seulement tous les points de données brutes sont stockés, mais ces métriques sont également agrégées en nouveaux points de données, appelés « cumuls », à divers intervalles temporels. Cela permet de les rendre efficaces pour le stockage et plus rapides pour les requêtes, surtout sur de longs intervalles temporels. Afin de s'assurer que les requêtes reviennent rapidement, New Relic One choisit, selon la requête, d'utiliser les points de données brutes ou un cumul temporel.  

Quand utiliser Metric Aggregate Pruning

Grâce à la puissance et à l'évolutivité de la plateforme de données sous-jacente, New Relic peut facilement traiter les données dans un compte avec des millions de séries temporelles de métriques uniques. Toutefois, comme pour tous les systèmes, il est nécessaire d'imposer certaines limites afin de protéger le système et d'assurer les performances pour tous. 

Si vous rencontrez une des limites de cardinalité, New Relic signale une erreur NrIntegrationError dans votre compte. Il s'agit d'un événement que vous pouvez interroger avec NRQL, et que vous pouvez également voir dans la section des limites du Data Management Hub de New Relic One. Une fois qu'une limite est atteinte, New Relic continue à traiter et stocker toutes vos données, mais interrompt la création des cumuls le reste de la journée.  Si vous êtes en train d'examiner une requête qui s'étend sur plus d'une heure lorsque cela se produit, vous pourriez croire que la création des rapports sur les données s'est arrêtée, car les cumuls utilisés pour ces requêtes dans les intervalles temporels plus longs ne sont pas disponibles.  

Pas d'inquiétude : comme nous l'avons déjà mentionné, les données brutes que vous avez envoyées sont toujours disponibles. Pour y accéder, vous pouvez interroger des fenêtres de temps plus courtes (d'une heure ou moins) ou ajouter le mot clé RAW à votre requête pour extraire les données dont vous avez besoin pour le dépannage. Pour éviter d'atteindre les limites, vous pouvez utiliser la nouvelle capacité Metric Aggregate Pruning.

Comment utiliser Metric Aggregate Pruning

Metric Aggregate Pruning  (DROP_ATTRIBUTES_FROM_METRIC_AGGREGATES) vous permet de spécifier un ou plusieurs attributs à exclure du cumul des métriques. 

Metric Aggregate Pruning est idéal pour les attributs à cardinalité élevée parfois inclus dans les métriques, tels que l'identifiant du conteneur ou d'autres identificateurs. Ces attributs à cardinalité élevée contiennent d'importants détails lors du dépannage d'un incident (intervalle temporel étroit), mais ils perdent leur valeur dans le temps et ne sont pas pertinents lorsque vous recherchez des tendances à plus long terme. 

Dans la capture d'écran suivante, il y a un exemple pour définir le nettoyage de l'attribut containerId pour une métrique hypothétique nommée some.metric.

Autres solutions

Vous pouvez éviter d'atteindre les limites cardinales de deux autres façons :

• Vous pouvez partitionner vos données, les diviser et les envoyer à plusieurs sous-comptes New Relic. 
• Vous pouvez également supprimer définitivement les métriques à faible valeur ou leurs attributs, soit du côté client, soit en utilisant nos capacités de suppression de données disponibles avec NerdGraph.  Les mesures et les attributs supprimés de cette manière ne sont pas du tout stockés.