Qu'est-ce que la cardinalité élevée dans un système de métriques, et comment la gardez-vous sous contrôle ?

La cardinalité, c'est le nombre de combinaisons uniques de labels pour une métrique, et chaque combinaison est une série temporelle distincte gardée en mémoire. Mettre des identifiants utilisateur, des identifiants de requête, des adresses e-mail ou des chemins d'URL bruts dans les labels peut créer des millions de séries et faire tomber une instance Prometheus. Gardez des labels bornés et de faible arité, remplacez les segments de chemin dynamiques par des gabarits, poussez le détail par requête dans les logs ou les traces, et imposez des limites avec du relabeling et des plafonds d'échantillons.

Chaque combinaison unique de valeurs de labels est sa propre série temporelle avec son empreinte mémoire et son bloc sur disque. Donc dès que quelqu'un ajoute user_id ou un chemin brut en label, vous passez de quelques centaines de séries à des millions. On a eu une instance Prometheus qui partait en OOM à répétition, et il s'est avéré qu'une équipe avait ajouté l'URL complète, chaîne de requête comprise, en label sur son compteur de requêtes. La règle que j'applique, c'est qu'une valeur de label doit venir d'un ensemble petit et fermé qu'on pourrait écrire sur un tableau blanc : méthode, classe de statut, gabarit d'endpoint, région. Tout ce qui n'est pas borné va dans une ligne de log ou un attribut de span, où le modèle de stockage est prévu pour ça. En pratique je l'impose avec des metric_relabel_configs pour supprimer les labels connus comme mauvais au moment du scrape, une limite d'échantillons par cible pour qu'un service ne puisse pas faire tomber l'instance entière, et une revue rapide dès qu'une nouvelle métrique apparaît dans une pull request.