Présentation

Le processeur Tag Cardinality Control limite le nombre de valeurs de tag pour chaque métrique. Par exemple, une métrique avec des clés de tag non bornées, telles que userID, peut entraîner un pic de cardinalité de la métrique et impacter les coûts d’ingestion et d’indexation. Pour éviter ces pics inattendus, utilisez le processeur pour définir une limite de cardinalité pour les métriques qui correspondent à la requête de filtrage, et soit supprimez les métriques reçues après l’atteinte de la limite, soit supprimez les tags de ces métriques.

En option, vous pouvez également configurer des remplacements par métrique pour définir une limite pour une métrique spécifique ou pour exclure la métrique de toute limite de cardinalité. Pour chaque remplacement par métrique, vous pouvez également définir une limite personnalisée pour des tags individuels au sein de la métrique, ou les exclure de la limite de cardinalité par métrique.

Configuration

Pour configurer le processeur Tag Cardinality Control :

1. Définissez une requête de filtre. Consultez Syntaxe de recherche de métriques pour plus d’informations.
   • Seules les métriques correspondant au filtre sont traitées.
   • Toutes les métriques, qu’elles correspondent ou non à la requête de filtrage, sont envoyées à l’étape suivante du pipeline.
2. Sélectionnez un Mode de suivi dans le menu déroulant. Consultez la section Modes exact et probabiliste pour plus d’informations.
3. Saisissez une limite de cardinalité pour le nombre maximal de valeurs distinctes par tag. Cette limite s’applique à toutes les métriques qui correspondent à la requête de filtrage.
4. Dans le menu déroulant Lorsque la limite est atteinte, sélectionnez si vous souhaitez Supprimer le tag ou Supprimer l’événement pour les métriques ayant dépassé la limite de cardinalité.

Paramètres de remplacement par métrique facultatifs

Si vous souhaitez définir une limite de cardinalité pour une métrique spécifique :

1. Cliquez sur Gérer les remplacements puis sur Ajouter un remplacement de métrique dans le panneau latéral.
2. Saisissez le nom de la métrique.
3. Sélectionnez le mode de remplacement dans le menu déroulant.
   • Limite personnalisée : définit une limite de cardinalité pour cette métrique.
   • Exclure de la limite : exclut cette métrique du comptage vers la limite de cardinalité. Ceci est utile lorsque vous suivez une métrique importante et que vous ne souhaitez supprimer aucun échantillon ni aucun tag en raison d’une limite de cardinalité.
4. Dans le menu déroulant Lorsque la limite est atteinte, sélectionnez si vous souhaitez Supprimer le tag ou Supprimer l’événement pour les métriques ayant dépassé la limite de cardinalité.

Remplacements par tag

Pour ajouter des remplacements de tag spécifiques pour cette métrique :

1. Cliquez sur Ajouter un remplacement de tag.
2. Saisissez la clé de tag pour laquelle vous souhaitez définir une limite.
3. Sélectionnez le mode de remplacement dans le menu déroulant :
   • Limite personnalisée : définit une limite sur le nombre de valeurs uniques par tag. Par exemple, si la limite de tag est définie sur 5, les cinq premières valeurs de tag reçues sont utilisées.
     • Remarque : les valeurs de tag persistent jusqu’au redémarrage du Worker ou à la mise à jour de la configuration du pipeline. Toute mise à jour de la configuration du pipeline réinitialise les valeurs de tag, même si la mise à jour n’affecte pas le processeur Tag Cardinality Control.
   • Exclure de la limite : exclut les métriques avec le tag spécifié du comptage vers la limite de cardinalité.
4. Saisissez la limite pour le nombre maximal de valeurs de clé de tag.
5. Cliquez sur Ajouter un remplacement.

Fonctionnement du processeur

Modes exact et probabiliste

Le processeur Tag Cardinality Control prend en charge deux modes pour le suivi de la cardinalité des tags :

• Exact : stocke les valeurs de tag sous forme d’un hachage de 8 octets pour optimiser l’utilisation de la mémoire, au prix d’une probabilité extrêmement faible que deux valeurs distinctes soient hachées dans la même empreinte.
• Probabilistea: Utilise des filtres de Bloom pour suivre les valeurs vues, ce qui peut fortement optimiser l’utilisation de la mémoire au prix de faux positifs occasionnels. Un faux positif se produit lorsqu’une valeur qui n’a pas encore été vue est incorrectement déterminée comme ayant été vue, ce qui amène le processeur à dépasser légèrement la limite de cardinalité spécifiée.

Utilisation de la mémoire pour le mode exact

La formule suivante calcule la quantité de mémoire utilisée par le mode exact :

$$A = \text"nombre total de métriques"\ \×\ \text"nombre moyen de clés de tag par métrique"$$

$$B = \text"longueur moyenne de chaque clé de tag"\ + (\text"value_limit"\ \×\ \text"longueur moyenne des valeurs de tag")$$

$$\text"Utilisation de la mémoire" = A\ \×\ B$$

Comme chaque valeur de tag est stockée sous forme d’empreinte de hachage de 8 octets, le average length of tag values est 8.

Utilisation de la mémoire pour le mode probabiliste

Le mode probabiliste utilise des filtres de Bloom pour suivre les valeurs vues pour chaque paire (métrique, tag). Par exemple, si le nom de la métrique est request.latency avec les clés de tag host et region, les paires suivies sont :

• (request.latency, host)
• (request.latency, region)

La formule suivante estime l’utilisation de la mémoire pour le mode probabiliste :

$$A = \text"nombre total de métriques"\ \×\ \text"nombre moyen de clés de tag par métrique"$$

$$B = \text"longueur moyenne des noms de champs pour les tags"\ \+\ \text"cache_size_per_key"$$

$$\text"Utilisation de la mémoire" = A\ \×\ B$$

Vous pouvez calculer cache_size_per_key avec un calculateur de filtre de Bloom en utilisant une formule standard, où n est la limite de cardinalité et le taux de faux positifs (p) est fixé à 0.1% dans le Worker.

Benchmarks pour le mode exact par rapport au mode probabiliste

Les tableaux suivants présentent des benchmarks pour le mode exact et le mode probabiliste. À mesure que le nombre de valeurs uniques pour chaque tag augmente, le mode probabiliste devient plus efficace en utilisation de mémoire. Les noms de métriques et les noms de tags utilisés pour ces benchmarks étaient des chaînes de 20 octets générées aléatoirement.

Le type de machine utilisé pour le benchmarking est une instance AWS M6gd.4xlarge.

Benchmarks pour 10 000 métriques suivies

Le tableau suivant montre l’utilisation de la mémoire RSS du Worker pour les modes probabiliste et exact lors du suivi de 10 000 métriques.

10 tags par métrique

Benchmarks pour 50 000 métriques suivies

Le tableau suivant montre l’utilisation de la mémoire RSS du Worker pour les modes probabiliste et exact lors du suivi de 50 000 métriques.

10 tags par métrique

50 tags par métrique

Benchmarks pour 100 000 métriques suivies

Le tableau suivant présente l’utilisation de la mémoire RSS du Worker pour les modes probabiliste et exact lors du suivi de 100 000 métriques.

10 tags par métrique

50 tags par métrique