Comprendre et requête forte cardinalité métriques

Il est important de comprendre le fonctionnement de la forte cardinalité, car cela peut avoir un impact sur la rapidité avec laquelle vous atteignez vos limites de données.

Qu’est-ce que la cardinalité et pourquoi est-ce important ?

La cardinalité est généralement définie comme le nombre d’éléments uniques dans un ensemble. Pour les métriques dimensionnelles, l'ensemble en question est la collection de cartes uniques d'attributs observées pour une métrique donnée sur une période d'un jour. Vous pouvez interroger la cardinalité d'une métrique dans New Relic avec le format NRQL suivant :

FROM Metric SELECT cardinality(metric.name) SINCE today RAW

Par exemple, pour interroger la cardinalité de la métrique memory.heap et découvrir combien de paires valeur-clé uniques existent pour cette métrique, exécutez la requête suivante :

FROM Metric SELECT cardinality(memory.heap) SINCE today RAW

Bien que les bases de ce que signifie la cardinalité puissent être simples à énoncer, apprendre à aborder et à gérer la forte cardinalité peut être un peu plus compliqué.

Limites de cardinalité et application

New Relic impose des limites à votre cardinalité métrique à la fois au niveau par métrique et au niveau du compte. La cardinalité est évaluée au cours d'une journée UTC, commençant à 00:00:00 UTC et se terminant à 23:59:59 UTC.

Pour plus d'informations sur les limites de données et les politiques associées, consultez Limites et politiques d'utilisation des données New Relic

Cardinalité et métriques dimensionnelles

La cardinalité d'une métrique est la taille de l'ensemble des cartes uniques d'attributs observées pour la métrique donnée sur une période d'un jour. Si les clés ou les valeurs de cette carte changent au fil du temps, elles ajouteront une nouvelle cardinalité pour cette métrique. Voyons un exemple.

Imaginez un réseau de 4 hôtes, chacun avec 2 conteneurs en cours d'exécution, et chaque conteneur rapporte périodiquement la jauge métrique memory.heap, avec le nom de l'hôte et l'identifiant du conteneur ajoutés comme attribut.

Lorsqu'elle est soumise à l'API métrique, l'une de ces métriques pourrait ressembler à ceci :

{
  "metrics": [
    {
      "name": "memory.heap",
      "type": "gauge",
      "value": 5514,
      "timestamp": 1234567890,
      "attributes": {
        "host": "W",
        "container": "1"
      }
    }
  ]
}

Cette métrique aurait alors une cardinalité de 8, car c'est le nombre de modélisations uniques de host et container possibles. Si une nouvelle mesure pour cette métrique est prise avec un attribut identique à celui précédemment rapporté, aucune nouvelle cardinalité ne sera comptabilisée.

Influences de la cardinalité

Comme indiqué ci-dessus, toute modification apportée aux clés ou aux valeurs représentera une nouvelle cardinalité, mais prédire comment ces modifications affecteront votre cardinalité totale peut devenir un peu délicat. Il est tentant de supposer que la cardinalité d'une métrique est alors le produit du nombre de toutes les valeurs possibles pour chaque clé possible, mais c'est rarement le cas dans la pratique, car les valeurs d'une clé donnée dépendent souvent ou déterminent les valeurs d'autres clés.

En utilisant l'exemple précédent, une fois que nous avions une valeur container de 1, la valeur de host a été fixée à W, en supposant que ces identifiants de conteneur sont uniques au niveau mondial. Ainsi, bien qu'il y ait 8 conteneurs sur 4 hôtes, la cardinalité est toujours 8, et non 4 * 8 = 32, puisque la plupart des combinaisons comptées par la méthode de multiplication simple ne sont pas possibles et ne contribuent donc pas à la cardinalité de cette métrique. Nous ne verrons jamais la combinaison de host = 'X', container = 1, par instance.

Cela signifie également que l’ajout de clés supplémentaires à une carte d’attributs n’implique pas nécessairement une augmentation de la cardinalité totale. Si la valeur de la nouvelle clé est déterminée de manière unique par les valeurs des clés existantes, elle n’ajoutera pas de nouvelle cardinalité à long terme. Par instance si vous ajoutez quelque chose comme region à votre carte dans l'exemple, il est probable que la valeur container soit également fixée à une valeur de région particulière et maintienne donc votre cardinalité à 8.

Un avertissement important ici est que même si l’ajout de region n’augmentera pas la cardinalité à l’avenir, il introduira une nouvelle cardinalité lors de son premier ajout. Cela est dû au fait que l’ajout de clés rendra ces cartes d’attributs distinctes de toutes celles qui les ont précédées, augmentant temporairement la cardinalité totale pour ce jour.

Exemples et exemples de workflow

Si vous atteignez l'une de vos limites de cardinalité, vous pouvez utiliser plusieurs options pour remédier à la situation. Une réponse simple consiste à augmenter vos limites, mais si vous préférez ne pas le faire, une bonne alternative est d’explorer les dimensions qui contribuent le plus à votre cardinalité et de penser à les supprimer si elles n’apportent pas de valeur. Cela peut vous permettre d’économiser sur les coûts de stockage et de bande passante et potentiellement vous éviter d’avoir à augmenter vos limites.

Trouver les contributeurs de cardinalité : métriques

Rappelons comment obtenir la cardinalité d’une métrique particulière :

FROM Metric SELECT cardinality(memory.heap) SINCE today RAW

Pour la cardinalité totale du compte, vous pouvez utiliser la même structure de requête de base et simplement omettre le nom de la métrique :

FROM Metric SELECT cardinality() SINCE today RAW

La cardinalité du compte est essentiellement la somme de la cardinalité de chaque métrique, donc l'ajout d'une simple requête FACET peut aider à trouver la cardinalité métrique forte :

FROM Metric SELECT cardinality() SINCE today RAW FACET metricName

Enfin, si vous pensez avoir atteint l'une de vos limites de cardinalité, vous pouvez le confirmer en recherchant un NrIntegrationError associé :

FROM NrIntegrationError SELECT count(*) 
WHERE name = 'CardinalityViolationException' AND newRelicFeature = 'Metrics' 
FACET cardinalityLimitType, metricName, message SINCE today

Recherche des contributeurs de cardinalité : dimensions

Une fois que vous avez déterminé la métrique que vous souhaitez explorer, l’étape suivante consiste à déterminer quelles dimensions d’une métrique donnée contribuent le plus à sa cardinalité. Si vous n'êtes pas familier avec les valeurs de vos dimensions, vous pouvez les considérer comme ceci :

FROM Metric SELECT dimensions() WHERE metricName = 'memory.heap' SINCE today RAW

La vue des résultats JSON sera probablement recommandée ici. En les examinant, vous pourriez découvrir certaines dimensions contenant un identifiant unique ou une autre valeur très variable qui pourrait valoir la peine d'être supprimée.

Si vous connaissez déjà les valeurs que votre attribut peut prendre, les résultats keySet() peuvent être plus faciles à analyser :

FROM Metric SELECT keySet() WHERE metricName = 'memory.heap' SINCE today RAW

Comprendre les dimensions qui ont le plus d’influence sur votre cardinalité totale revient à comprendre comment les valeurs de chaque clé sont corrélées les unes aux autres. Vous pouvez tester quelle serait votre cardinalité sans dimension simplement en l'ajoutant à la liste d'exclusion :

FROM Metric SELECT cardinality(memory.heap, exclude: {'container.id'}) SINCE today RAW

De même, il existe une liste d'inclusion si cela est plus pratique dans le contexte de la requête :

FROM Metric SELECT cardinality(memory.heap, include: {'host.name', 'region'}) SINCE today RAW

La gestion de la cardinalité peut être difficile à conceptualiser, mais les méthodes ci-dessus vous aideront à obtenir des réponses à des questions telles que « Quelle métrique contribue le plus à la cardinalité ? » et « Quel impact un ou plusieurs attributs donnés ont-ils sur cette cardinalité totale ? ».

Il arrive souvent que la cardinalité suive la valeur la plus unique, car cette valeur peut déterminer les valeurs possibles que d'autres attributs peuvent prendre. Cependant, il existe de nombreux cas où l’explosion des combinaisons possibles d’une poignée d’attributs détermine la cardinalité totale. Les éléments qui ressemblent à des identifiants uniques sont généralement un bon point de départ, mais parfois, il ne s'agit pas d'une clé unique mais de la combinaison de deux ou plusieurs clés. Plus vous serez familier avec vos données et le système qui les génère, plus il sera facile de savoir quel attribut inclure ou exclure.

Ajuster les limites de cardinalité

Une fois qu'une métrique a été identifiée avec une forte cardinalité et déterminée comme étant une utilisation valide de cette cardinalité, certains ajustements sont possibles pour aider à atténuer toute violation de limite qui pourrait survenir. Pour augmenter la cardinalité d'un nom de métrique particulier, vous pouvez utiliser notre API NerdGraph. Quelques exemples requests NerdGraph sont inclus ci-dessous.

Avant d’utiliser l’API pour ajuster les limites de cardinalité, examinez les facteurs qui influencent la cardinalité.

mutation {
  dataManagementCreateAccountLimit(
    accountId: "<INSERT_YOUR_ACCOUNT_ID>"
    accountLimit: {
      limit: {
        name: "Dimensional Metric per-metric cardinality ingested per day"
      }
      overrideReason: "<INSERT_REASON_FOR_OVERRIDE>"
      overrideValue: "<THE_DESIRED_CARDINALITY>"
      qualifier: "<INSERT_METRIC_NAME>"
    }
  ) {
    name
    unit
    value
  }
}