Qui fait grossir la facture de métriques ?

Mode de lecture

IngénieurDécideur

Fin de mois, chez un éditeur de logiciels. Le contrôleur de gestion ouvre la facture de la plateforme d’observabilité : la ligne « métriques » a doublé en quatre semaines. Il appelle l’équipe technique. Le trafic n’a pas bougé, les tableaux de bord sont au vert, personne n’a rien changé « de gros ». Ce scénario est inventé, mais il est courant.

Ce n’est pas une panne. Quand le trafic ne bouge pas, la cause la plus fréquente est la cardinalité : quelqu’un a ajouté à une métrique un label dont les valeurs n’ont pas de fin. Un identifiant client, un identifiant de requête, une adresse web complète, ou encore le nom d’un pod qui change à chaque déploiement. La page La cardinalité expliquée raconte le mécanisme. Celle-ci explique comment trouver le responsable.

Lire le texte de la vidéo

Fin de mois : la ligne « métriques » de la facture a doublé. Le trafic n’a pas bougé. Les tableaux de bord sont au vert.

La finance voit la hausse en premier. Elle n’en voit pas la cause. Les ingénieurs ont les outils pour la voir. Rien ne les alerte. Il leur faut une question commune.

D’abord, écarter les causes simples en cinq minutes. Si rien n’a changé, la piste est un label de trop.

Quelle métrique a le plus grossi ? À cause de quel label ? Depuis quand ? Et surtout : à qui est-elle ? Sans propriétaire, personne ne décidera de la réduire.

La réponse tient sur une page : le rapport du mois. Les métriques les plus lourdes, leur évolution, le label qui pèse le plus, leur propriétaire. Ici, une adresse complète en label : 180 % de plus en un mois. Là, une métrique que personne n’a lue depuis cinq mois.

La finance n’y lit plus une ligne de facture, mais une liste de décisions. Chaque décision a un nom en face : celui du propriétaire. Les équipes voient leur métrique avant qu’on vienne leur en parler.

Sans rapport, la hausse se découvre sur la facture, souvent tard. Avec le rapport, elle se voit dès le premier mois.

Chiffres fictifs.

Qui fait grossir la facture de métriques ? meantimetolearn.com.

Musique : « Radar Focus », Blue Saga (Epidemic Sound).

Ceux qui voient, ceux qui paient

La difficulté est surtout humaine. La finance ressent le problème en premier, sur la facture, mais elle n’a aucun moyen d’en voir la cause. Les ingénieurs ont les outils pour la voir, mais rien ne les alerte : aucun écran ne devient rouge quand une métrique passe de mille à cent mille séries.

Pour en sortir, il faut une question que les deux comprennent. Elle tient en une phrase : quelles métriques ont le plus grossi, à cause de quel label et depuis quand ? Puis : à qui sont-elles ?

Avant d’accuser la cardinalité

Quelques causes plus simples s’éliminent en cinq minutes, en posant la question à l’équipe technique :

• de nouvelles machines, de nouveaux services ou de nouveaux environnements sont-ils surveillés depuis le mois dernier ?
• la fréquence de collecte a-t-elle augmenté (une mesure toutes les 15 secondes au lieu de toutes les minutes, c’est quatre fois plus de points) ?
• la durée de conservation des données a-t-elle été allongée ?
• le contrat ou le mode de facturation a-t-il changé ?

Si la réponse est non partout, la piste de la cardinalité devient la bonne. Elle compte d’autant plus si le fournisseur facture au nombre de séries.

Trois questions, dans l’ordre

Pensez à une facture d’électricité qui double. On ne commence pas par démonter chaque prise. On regarde d’abord quel appareil consomme le plus, puis ce qui a changé sur cet appareil, puis depuis quand.

Quelle métrique ? Une série, c’est une ligne du tableau de suivi : une combinaison de valeurs, stockée et souvent facturée. Les bases de métriques savent classer les métriques par nombre de séries. Souvent, une poignée de métriques pèse à elle seule une grosse part du total. C’est là qu’il faut chercher.

Quel label ? Sur la métrique en tête, on regarde pour chaque label combien de valeurs différentes il prend. La plupart en ont quelques-unes : un code de réponse, une région, un nom de service. Le coupable en a des milliers. Et le chiffre grimpe chaque jour.

Depuis quand ? Une hausse brutale pointe vers un déploiement précis, ou vers la mise à jour d’une bibliothèque, qu’on retrouve dans l’historique des mises en production. Une hausse lente et régulière pointe plutôt vers un label qui accumule des valeurs : des clients, des pods, des sessions.

Reste la quatrième question, qui n’est pas technique : à qui est cette métrique ? Sans propriétaire, personne ne décidera de la réduire.

Les suspects habituels

Quelques familles de labels reviennent dans presque toutes les enquêtes :

• les identifiants de personnes ou d’objets métier : client, utilisateur, commande, session ;
• les identifiants techniques uniques : identifiant de requête, de trace, de conteneur ;
• les adresses web complètes, avec leurs paramètres, au lieu du modèle de route (/commande/{id}) ;
• les noms de pods dans Kubernetes : chaque déploiement crée de nouveaux noms, donc de nouvelles séries, même si le nombre de pods ne change pas. On appelle cela le churn, le renouvellement des séries. Il se paie même à nombre de pods constant : certaines offres facturent les séries actives sur la période, ou leur moyenne horaire, si bien que chaque déploiement ajoute des séries au compte du mois ;
• les messages d’erreur recopiés tels quels dans un label ;
• les histogrammes croisés avec trop de labels : chaque combinaison est multipliée par le nombre de tranches de l’histogramme ;
• les attributs ajoutés par une mise à jour : une nouvelle version d’un SDK, d’une instrumentation ou d’un exporter OpenTelemetry peut ajouter des attributs, donc des labels, sans que personne n’ait « rien changé » ;
• les attributs de ressource transformés en labels : quand la configuration recopie sur chaque série les attributs qui décrivent la machine ou le pod (nom d’hôte, identifiant de conteneur…), toutes les séries se multiplient d’un coup.

Un dernier suspect est plus discret : la métrique que plus personne ne consulte. Elle ne grossit pas forcément, mais elle coûte tous les mois pour rien. Certains outils savent dire quand une métrique a été interrogée pour la dernière fois.

Le rapport qui met tout le monde d’accord

Une fois la méthode connue, le plus utile est de la rendre régulière. Un rapport mensuel d’une page suffit souvent : les dix métriques qui ont le plus de séries, leur évolution sur le mois, le label qui pèse le plus sur chacune et leur propriétaire. Par exemple (chiffres fictifs) :

Métrique	Séries	Sur un mois	Label le plus lourd	Propriétaire
http_server_request_duration_seconds_bucket	412 000	+ 180 %	url : 9 800 valeurs	équipe Paiement
kube_pod_container_status_restarts_total	96 000	+ 12 %	pod : renouvelé à chaque déploiement	équipe Plateforme
app_cache_hits_total	54 000	stable	customer_id	équipe Catalogue, jamais lue depuis cinq mois

La première ligne demande une décision rapide : remplacer l’adresse complète par le modèle de route. C’est ce que prévoient les conventions sémantiques HTTP stables d’OpenTelemetry : la métrique http.server.request.duration porte le modèle de route (http.route) et non l’adresse complète, justement pour limiter le nombre de séries. La troisième pose une autre question : faut-il garder une métrique que personne ne lit ?

La finance y lit une liste de décisions plutôt qu’une ligne de facture. Les équipes y voient leur métrique avant que quelqu’un ne vienne leur en parler. Et la prochaine hausse se voit au bout d’un mois, pas au bout de trois.

Pour les équipes techniques : où trouver les chiffres

Prometheus. La page Status › TSDB Status de l’interface, ou l’API correspondante, donne les métriques et les paires label=valeur qui ont le plus de séries, les labels qui ont le plus de valeurs et la mémoire qu’occupent ces valeurs :

curl -s 'http://prometheus:9090/api/v1/status/tsdb?limit=20'
# seriesCountByMetricName     : les métriques les plus lourdes
# labelValueCountByLabelName  : les labels qui ont le plus de valeurs
# seriesCountByLabelValuePair : les paires label=valeur les plus lourdes
# memoryInBytesByLabelName    : la mémoire occupée par les valeurs de chaque label

Ces chiffres portent sur le bloc en mémoire (les dernières heures). Pour analyser un bloc déjà écrit sur disque (par défaut le plus récent), y compris les labels les plus impliqués dans le renouvellement des séries, il y a promtool, à lancer sur le répertoire de données (/prometheus dans l’image officielle). Il ouvre la base en lecture seule ; sur un serveur de production chargé, lancez-le plutôt sur une copie du répertoire :

promtool tsdb analyze /prometheus
# Highest cardinality metric names, Highest cardinality labels,
# Label names most involved in churning

VictoriaMetrics. L’onglet Explore cardinality de vmui montre les mêmes classements pour une journée donnée, ce qui permet de comparer avec un jour antérieur. L’API accepte un sélecteur et un label sur lequel se concentrer :

curl -s 'http://victoriametrics:8428/api/v1/status/tsdb?topN=20&date=2026-10-25'
# -g : sans cette option, curl interprète les crochets de match[]
curl -sg 'http://victoriametrics:8428/api/v1/status/tsdb?match[]=http_requests_total&focusLabel=user_id'

Ces adresses valent pour la version mono-nœud. En cluster, la même API passe par vmselect : http://vmselect:8481/select/<accountID>/prometheus/api/v1/status/tsdb.

L’explorateur affiche aussi, si le suivi d’usage est activé, le nombre de fois où chaque métrique a été interrogée et la date de la dernière requête : la liste des métriques jamais lues sort en quelques clics.

En PromQL, pour une métrique précise, le nombre de valeurs de chaque label candidat et l’évolution sur une semaine :

count(count by (user_id) (http_requests_total))
count(http_requests_total) / count(http_requests_total offset 7d)

Évitez count by (__name__) ({__name__=~".+"}) sur une grosse base : la requête parcourt toutes les séries et peut elle-même poser problème. Les API d’état ci-dessus sont faites pour ça.

Les attributs de ressource promus en labels se règlent à l’entrée. Côté Prometheus, le récepteur OTLP ne promeut que les attributs listés dans promote_resource_attributes ; l’option promote_all_resource_attributes les promeut tous et la documentation prévient du risque de renouvellement des séries. Côté Collector, l’exporter Prometheus recopie tous les attributs de ressource si resource_to_telemetry_conversion est activé (option dépréciée, remplacée par resource_constant_labels, qui permet de choisir les attributs).

Le renouvellement des séries se suit avec le rythme de création de nouvelles séries. Sur Prometheus :

rate(prometheus_tsdb_head_series_created_total[1h])

Une alerte sur ce rythme prévient d’une fuite bien avant la facture ; le lab de La cardinalité expliquée en montre un exemple.

Pour aller plus loin

• La cardinalité expliquée : le mécanisme, avec une vidéo et un lab qui rejoue le scénario.
• Simulateur de facture de métriques : ajoutez ou retirez des labels et voyez le nombre de séries changer.
• Gouverner les données d’observabilité : propriétaires, budgets de séries et contrôles avant la mise en production.

Sources

• Prometheus, API HTTP : statistiques de la TSDB
• Prometheus, promtool : commande tsdb analyze
• VictoriaMetrics, explorateur de cardinalité et /api/v1/status/tsdb
• Prometheus, configuration du récepteur OTLP : promote_resource_attributes
• OpenTelemetry Collector, exporter Prometheus : resource_constant_labels
• OpenTelemetry, conventions sémantiques des métriques HTTP : http.server.request.duration et http.route
• Prometheus, nommage des métriques et des labels : la mise en garde contre les labels aux valeurs illimitées

PasserellesCe que cette page change au-delà de l'équipe technique.

BusinessValeur, coût, risque

Le classement mensuel transforme une ligne de facture opaque en une liste de décisions : garder, réduire ou supprimer une métrique, avec un nom en face de chacune.

OrganisationQui décide, qui possède

Chaque métrique lourde a un propriétaire et un budget de séries ; le sujet est traité dans Gouverner les données d'observabilité.

HumainÉquipes, astreinte, compétences

Le but n'est pas de trouver un coupable. La plupart de ces labels ont été ajoutés pour une bonne raison, un jour d'incident.

MétiersProduit, finance, risque, relation client

Pour la finance, une question suffit : quelles métriques ont le plus grossi ce mois-ci et qui en est propriétaire ?

Pourquoi des passerelles →