Comment gérer les métriques de cardinalité élevée dans Prometheus et Kubernetes
Au cours des derniers mois, un thème commun et récurrent dans nos conversations avec les utilisateurs a été la gestion des coûts d’observabilité, qui augmente à un rythme plus rapide que l’empreinte des applications et de l’infrastructure surveillées. Alors que les entreprises s’appuient sur des architectures cloud natives et que la popularité de Prometheus continue de croître, il n’est pas surprenant que la cardinalité des métriques (une combinaison cartésienne de métriques et d’étiquettes) augmente également. Cependant, le taux de croissance a pris certaines entreprises par surprise et est devenu une priorité à l’heure de construire et de maintenir des systèmes et des pratiques d’observabilité.
Si cela vous rappelle votre propre situation et que vous explorez actuellement les façons de contrôler la croissance des métriques, regardez notre webinaire « Comment contrôler la croissance des métriques dans Prometheus et Kubernetes avec Grafana Cloud » pour découvrir des trucs et astuces exploitables que vous pourrez commencer à mettre en œuvre dès aujourd’hui.
Pourquoi les métriques augmentent-elles à un rythme sans précédent ?
Les environnements natifs du cloud et les architectures basées sur les microservices, associés à l’autonomie et à la flexibilité des développeurs, créent la combinaison gagnante pour une augmentation exponentielle des métriques. Dans les infrastructures natives du cloud, telles que Kubernetes, les niveaux d’abstraction croissants entraînent davantage de séries chronologiques. Ce qui était autrefois un serveur « bare-metal » unique exécutant une application a maintenant été remplacé par des pods multiples exécutant de nombreux microservices, dispersés sur de nombreux nœuds. Chacune de ces couches abstraites a besoin d’une étiquette pour pouvoir être identifiée de façon unique, et chacun de ces composants génère ses propres métriques, créant ainsi leur ensemble unique de séries temporelles.
En outre, la nature éphémère des charges de travail dans Kubernetes finit par créer plus de séries chronologiques. Considérons la métrique kube_pod_status_phase (l’une des kube-state-metrics), qui génère une nouvelle série temporelle chaque fois qu’un pod change d’état, disons de « en attente » à « en cours » à « échoué » ou « réussi ». En fonction du taux d’événements de cluster, en particulier avec beaucoup de travaux courts, le suivi du statut d’un seul pod peut générer beaucoup de métriques.
La facilité d’instrumentation et l’autonomie créées par une architecture de microservices peuvent parfois entraîner une augmentation de la cardinalité. Compte tenu du riche ensemble d’exportateurs open source, ainsi que des bibliothèques clientes pour plus de 15 langages de programmation, il n’a jamais été aussi facile d’instrumenter votre application pour exposer les métriques Prometheus. Chaque équipe étant habilitée à ajouter des métriques à son application, la gouvernance devient plus complexe. Parfois, les métriques pertinentes dans un environnement de développement peuvent s’infiltrer dans un environnement de production et provoquer un pic dans les séries chronologiques. Quand autant d’équipes instrumentent leurs applications, il devient complexe, pour une équipe d’observabilité centralisée, de repérer et de prévenir ces fuites.
Est-ce seulement la surveillance native dans le cloud qui entraîne une augmentation de la cardinalité des métriques ?
Bien que la cardinalité élevée soit certainement plus courante dans les environnements natifs du cloud, elle est également courante lorsque les anciennces infrastructure (matérielle ou logicielle) non Prometheus sont migrée vers un format compatible Prometheus avec les exportateurs. Ces exportateurs peuvent générer un nombre très élevé de métriques, ce qui contribue à une cardinalité élevée. Par exemple, l’exportateur de nœuds Prometheus, qui fournit des métriques matérielles et au niveau du système d’exploitation, émet environ 500 séries chronologiques Prometheus par défaut. L’exportateur mySQL publie environ 1 000 séries chronologiques qui ne sont pas toutes utiles.
Quel que soit l’environnement, l’une des erreurs les plus couramment observées tient à l’utilisation d’étiquettes sous-optimales dans les bases de données de métriques. Puisque la cardinalité est un produit cartésien de deux ensembles (métriques et étiquettes), la façon dont les étiquettes sont définies contribue grandement au maintien de la cardinalité sous contrôle. Si des étiquettes générées de manière aléatoire et n’ayant pas de limite supérieure de valeurs uniques sont utilisées (par exemple, si des {session_id} sont générées à chaque nouvelle connexion), le nombre de séries chronologiques peut augmenter lorsque le trafic vers le système augmente. La même chose est valable pour {user_id} ou {device_id}.
Une cardinalité élevée est donc un symptôme de l’environnement, mais pourquoi est-ce important ?
Une augmentation de la cardinalité signifie que vous avez maintenant besoin de plus d’infrastructure et de calcul pour stocker et traiter ces séries chronologiques. Cela a à son tour un impact direct sur le montant que vous dépensez sur votre plate-forme d’observabilité. Récemment, cet aspect a été une priorité pour les opérateurs et les équipes d’observabilité centralisées.
Cette situation a également un impact sur les performances de votre plate-forme d’observabilité. Au fur et à mesure que votre base de données grandit, le nombre de séries chronologiques consultées sur une requête donnée augmente, ce qui peut ralentir radicalement votre système lorsque vous interrogez ou visualisez les données. Les tableaux de bord qui chargent lentement ou les requêtes qui mettent du temps à renvoyer des données prolongent le MTTR lors du dépannage des pannes.
Remarque : l’avantage lié à l’utilisation d’une plate-forme d’observabilité native dans le cloud, comme Grafana Cloud, qui est alimentée par la base de données de séries chronologiques la plus évolutive Grafana Mimir, tient au fait que vous ne rencontrerez pas ces problèmes de performance à mesure que votre nombre de séries chronologiques augmente.
Alors, comment contrôler la croissance des métriques ?
Étant donné que la croissance des métriques est inévitable et a des conséquences sur votre résultat, cela soulève la question de savoir comment contrôler et optimiser les métriques et les coûts croissants. Comme c’est le cas pour la surveillance et l’observabilité, on doit commencer par avoir la bonne visibilité et la bonne compréhension des données pour trouver des réponses à ces questions.
Voici trois étapes clés pour contrôler la cardinalité et les coûts des métriques :
1. Obtenez une visibilité sur les métriques à cardinalité élevée et les métriques utiles
La première étape vers toute optimisation consiste à acquérir de la visibilité sur les métriques et les étiquettes qui contribuent à la cardinalité et à identifier les métriques qui sont utiles. Les métriques utilisées dans les tableaux de bord, les alertes et les règles d’enregistrement sont évidemment nécessaires ; cependant, d’autres peuvent n’être utilisées que pour des requêtes ad hoc lors du dépannage ou ne pas être interrogées du tout.
Le diagramme ci-dessous montre des métriques divisées en quatre quadrants basés sur la cardinalité et la valeur. Il vous faudra commencer par identifier les métriques dans le quadrant 3, qui sont coûteuses, mais qui ne sont pas utilisées. Pour les métriques appartenant au quadrant 4, la réévaluation de la granularité et de l’architecture des étiquettes peut produire d’excellents rendements pour les métriques et les étiquettes qui fournissent de la valeur, mais qui ont une cardinalité élevée.
Identification des métriques et des étiquettes à cardinalité élevée
Les abonnements Grafana Cloud Pro et Advanced incluent un ensemble de tableaux de bord de gestion de la cardinalité pour vous aider à identifier les mesures et les étiquettes à cardinalité élevée et à guider vos efforts d’optimisation.
Pour en savoir plus sur la façon de suivre facilement la cardinalité à l’aide des tableaux de bord Grafana, consultez les ressources suivantes :
- Comment gérer la cardinalité avec des tableaux de bord prêts à l’emploi dans Grafana Cloud
- Analyse de l’utilisation des métriques avec des tableaux de bord de gestion de cardinalité
Si vous utilisez Grafana Cloud et souhaitez en savoir plus sur l’optimisation des métriques, contactez-nous.
Découvrir les métriques inutilisées
Mimirtool est un outil open source qui peut être utilisé pour identifier les métriques dans Mimir, Prometheus ou dans les bases de données compatibles avec Prometheus qui ne sont pas utilisées dans les tableaux de bord, les alertes ou les règles d’enregistrement. Mimirtool est exécuté via une ligne de commande et génère un fichier JSON contenant des métriques inutilisées.
Les métriques qui ne sont pas entièrement utilisées peuvent être supprimées en toute sécurité, si elles ne sont pas requises pour des requêtes ad hoc ou des projets futurs.
Pour en savoir plus sur l’utilisation de Mimirtool pour identifier les métriques inutilisées dans ces documents :
- Comment trouver rapidement les métriques inutilisées et optimiser votre utilisation de Grafana Cloud
- Analyse et réduction de l’utilisation des métriques avec Grafana Mimirtool
2. Comprenez quelles équipes sont responsables de la croissance des métriques
Il vous faudra ensuite comprendre quelles équipes et quels environnements contribuent pour la plus grande part à la cardinalité de votre organisation.
Grafana Cloud Advanced inclut des informations d’utilisation pour aider à identifier les sources de cardinalité dans votre environnement. Suivez le nombre de séries chronologiques ayant une étiquette spécifique ou un ensemble d’étiquettes appliquées au fil du temps afin de comprendre comment les différentes équipes, les différents environnements ou les différentes applications contribuent au nombre total de séries. En disposant de ces données sous forme de séries chronologiques, vous pouvez facilement déterminer comment un changement à un moment donné a entraîné une augmentation de votre facture d’observabilité.
Pour en savoir plus sur l’utilisation des groupes d’utilisation pour surveiller l’allocation des métriques, consultez cet article de blog :
3. Commencez à optimiser les métriques
Dans cette section, nous vous expliquerons comment commencer à optimiser les métriques, une fois que vous aurez une visibilité sur les métriques et les étiquettes qui entraînent une cardinalité élevée, et que vous aurez été en mesure d’identifier les métriques de faible et de forte valeur.
Inspecter la fréquence des données
Lors de la prévision des besoins en capacité pour les métriques, il est important de tenir compte de vos besoins en fréquence de données. L’intervalle scrape_interval par défaut pour Prometheus est de 15 secondes, soit 4 points de données par minute (DPM). Mais si cette fréquence n’est pas requise, la configuration par défaut peut entraîner le stockage d’une quantité de données supérieure à ce qui a été prévu.
Pour inspecter votre scrape_interval actuel, utilisez la requête ci-dessous pour trouver le nombre d’échantillons dans le scrape au cours de la dernière minute, divisé par cible :
count_over_time(scrape_samples_scraped[1m])
Vous pouvez ensuite inspecter ces métriques et augmenter le scrape_interval pour des métriques moins critiques afin de réduire les coûts. Souvent, les métriques moins critiques peuvent être définies sur un scrape_interval de 60 secondes, ce qui peut réduire les coûts jusqu’à 75 %.
Pour en savoir plus sur l’ajustement des scrape_intervals, consultez notre documentation :
Inspecter les histogrammes
Les histogrammes vous permettent de comprendre la distribution d’une quantité particulière. La précision de cette distribution est déterminée par le nombre de buckets que vous avez dans cet histogramme. Dans Prometheus, chaque bucket est suivi comme une série temporelle qui a une valeur spécifique de l’étiquette le (inférieure ou égale à).
En utilisant le tableau de bord Grafana de gestion de la cardinalité dans Grafana Cloud, nous pouvons voir les valeurs de l’étiquette le et comprendre en quoi celle-ci contribue à la cardinalité globale. Choisissez les buckets qui sont les plus pertinents pour votre environnement. Par exemple, si le SLO pour un service est un temps de réponse de 50 mSec, vous n’aurez peut-être pas besoin de faire la distinction entre les requêtes qui prennent 5 mSec et celles qui prennent 10 mSec.
Vous pouvez tranquillement mettre de côté les séries de métriques pour les buckets qui ne sont pas nécessaires. Cela n’entraînera pas de perte de données, car les buckets sont cumulatifs. Par exemple, si vous mettez de côté le bucket « inférieur ou égal à 10 », ces valeurs seront simplement incluses au bucket « inférieur ou égal à 25 ». Si ce niveau de dimensionnalité n’est pas requis, vous pouvez tranquillement mettre de côté la valeur 10 pour l’étiquette le.
Voici un exemple de configuration de relabel :
# mettez de côté toutes les séries métriques se terminant par _bucket et où le="10"
- source_labels: [__name__, le]
separator: _
regex: ".+_bucket_10"
action: "drop"
Pour en savoir plus sur la réduction de l’utilisation des métriques Prometheus et la configuration de relabel, consultez notre documentation :
Réduire les étiquettes
Pour les métriques dont les étiquettes sont inutilisées, il ne suffit pas de simplement mettre de côté les étiquettes qui ne sont pas utilisées. Mettre de côté une étiquette peut entraîner des doublons de séries, qui seront mis de côté par Prometheus. Voyez les exemples ci-dessous. Dans le premier exemple, vous pouvez tranquillement mettre de côté l’étiquette ip car les séries restantes sont uniques. En revanche, dans le deuxième exemple, vous constatez comment le fait de mettre de côté l’étiquette ip va créer des doublons de séries chronologiques, que Prometheus mettra de côté. Dans cet exemple, Prometheus recevra des valeurs de 1, 3 et 7 pour my_metric_total avec le même horodatage et mettra de côté 2 des points de données.
# Vous pouvez mettre de côté l'étiquette ip, les séries restantes sont toujours uniques
my_metric_total{env=“dev”, ip=“1.1.1.1"} 12
my_metric_total{env=“tst”, ip=“1.1.1.1"} 14
my_metric_total{env=“prd”, ip=“1.1.1.1"} 18
# Valeurs restantes après avoir mis de côté l'étiquette ip
my metric_total{env=“dev”} 12
my_metric_total{env=“tst”} 14
my_metric_total{env=“prd”} 18
# Vous ne pouvez pas mettre de côté l'étiquette ip, les séries restantes ne sont pas uniques
my_metric_total{env=“dev”, ip=“1.1.1.1"} 1
my_metric_total{env=“dev”, ip=“3.3.3.3"} 3
my_metric_total{env=“dev”, ip=“5.5.5.5"} 7
# Les valeurs restantes après avoir mis de côté l'étiquette ip ne sont pas uniques
my_metric_total{env=“dev”} 1
my_metric_total{env=“dev”} 3
my_metric_total{env=“dev”} 7Vous pouvez tranquillement mettre de côté les étiquettes, si cela n’entraîne pas de doublons de séries.
Dans les environnements où vous avez le contrôle de l’application, vous pouvez reconfigurer les agents utilisés pour la collecte de métriques de façon à ce qu’ils mettent de côté les étiquettes inutilisées.
Si vous n’avez pas le contrôle de l’application et que la suppression des étiquettes entraîne des doublons de séries, l’application d’une fonction (par ex. sum, avg, min, max) via les règles d’enregistrement Prometheus peut vous permettre de conserver les données agrégées, tout en mettant de côté les séries individuelles. Dans l’exemple ci-dessous, nous utilisons la fonction sum pour stocker la métrique agrégée, ce qui nous permet de mettre de côté les séries chronologiques individuelles.
# sum par env
my_metric_total{env="dev", ip="1.1.1.1"} 1
my_metric_total{env="dev", ip="3.3.3.3"} 3
my_metric_total{env="dev", ip="5.5.5.5"} 7
# Règle d'enregistrement
sum by(env) (my_metric_total{})
my_metric_total{env="dev"} 11Vous pouvez en savoir plus sur la réduction des règles d’enregistrement Prometheus et la configuration de relabel dans les ressources suivantes :
- Règles d’enregistrement Prometheus
- Réduire l’utilisation des métriques Prometheus avec le relabeling
- Comment fonctionne le relabeling dans Prometheus
En savoir plus sur la gestion des métriques dans Prometheus et Kubernetes avec Grafana Cloud
Pour vous lancer dans la compréhension de la cardinalité de votre environnement, l’attribution des coûts aux équipes et aux environnements et l’optimisation de vos coûts de métrique, inscrivez-vous à Grafana Cloud. L’inscription inclut un essai de 14 jours de Grafana Cloud Pro, qui vous permettra de tester les tableaux de bord de gestion de cardinalité, les groupes d’utilisation et d’autres technologies dans votre environnement.
Pour en savoir plus sur la façon de contrôler les coûts des métriques dans les environnements Prometheus et Kubernetes, vous pouvez également consulter notre webinaire « Comment contrôler la croissance des métriques dans Prometheus et Kubernetes avec Grafana Cloud » à la demande.
Si vous êtes utilisateur de Grafana Cloud et souhaitez en savoir plus sur la façon dont nous pouvons vous aider dans votre parcours d’optimisation des métriques, contactez-nous.
