Comprendre les chiffres d'énergie et de carbone

Cette page raconte toute l'histoire de l'énergie en langage clair : ce que Perf Sentinel compte, ce qu'il mesure, comment un nombre d'opérations d'I/O devient des kilowattheures et des grammes de CO2, et ce qui change selon les options activées. C'est une synthèse, pas une référence. Les formules se trouvent dans Méthodologie, les bornes de précision dans Limites, et chaque clé de configuration dans Configuration.

L'idée en un paragraphe

Perf Sentinel lit des traces distribuées et compte chaque opération d'I/O qu'une application effectue : requêtes SQL, appels HTTP sortants et publications vers un broker. Ses détecteurs signalent les opérations qui n'avaient pas besoin d'exister, principalement les boucles N+1 et les appels répétés redondants. Le rapport entre opérations évitables et opérations totales est le ratio de gaspillage, et c'est le chiffre le plus robuste que produit l'outil parce qu'il ne dépend d'aucun modèle d'énergie. Tout le reste de cette page consiste à transformer les comptages en énergie et en carbone : le ratio de gaspillage dit quelle part est gaspillée, la chaîne d'énergie dit combien cette part pèse en kWh et en gCO2.

D'où vient chaque chiffre

Les chiffres de carbone suivent le modèle Software Carbon Intensity (SCI, normalisé ISO/IEC 21031:2024) : carbone = énergie x intensité du réseau électrique, plus un terme incorporé pour le matériel lui-même.

• L'énergie (E) démarre comme une estimation et devient une mesure à mesure que vous branchez des backends. Sans rien configurer, chaque opération coûte un forfait de 1e-7 kWh (le coefficient proxy, étiquette de modèle io_proxy_v3). Chaque backend ci-dessous remplace cette estimation par quelque chose de plus proche de la réalité physique.
• L'intensité du réseau (I) convertit les kWh en gCO2 pour la région où le code tourne. Elle part de moyennes nationales annuelles embarquées, peut être modulée par des profils sur 24 heures, et devient une valeur en direct quand l'API Electricity Maps est configurée. La région elle-même vient de l'attribut de span cloud.region, de [green.service_regions], ou de [green] default_region, dans cet ordre.
• Le carbone incorporé (M) rend compte de la fabrication des serveurs. C'est un forfait par requête dérivé d'analyses de cycle de vie publiques de serveurs rack (Boavizta et la méthodologie Cloud Carbon Footprint), configurable via embodied_carbon_per_request_gco2. Corriger un N+1 ne dé-fabrique pas le silicium, donc les chiffres évitables n'incluent jamais ce terme.
• Le PUE multiplie l'énergie pour rendre compte des surcoûts du centre de données (refroidissement, distribution électrique) : 1,09 pour GCP, 1,15 pour AWS, 1,17 pour Azure, 1,24 pour OVHcloud, 1,375 pour Scaleway, 1,5 pour OUTSCALE (qui n'en publie aucun) et pour une infrastructure inconnue.

Chaque rapport dit quel modèle a produit ses chiffres via les étiquettes energy_model et per_service_energy_model, un lecteur peut donc toujours distinguer une estimation d'une mesure.

L'échelle de fidélité

Chaque ligne de ce tableau remplace ou affine la ligne au-dessus. Vous pouvez vous arrêter à n'importe quel barreau, et les rapports indiquent toujours le barreau où vous êtes.

Quand plusieurs backends couvrent le même service, le daemon garde la lecture la plus fidèle : alumet_rapl bat scaphandre_rapl, qui bat kepler_ebpf, puis redfish_bmc, puis cloud_specpower, puis le proxy. Tous les backends mesurés sont réservés au daemon (watch). Le mode batch analyze utilise toujours le chemin proxy.

Une contrainte s'applique à tous les barreaux RAPL : les compteurs matériels ne voient que le CPU et la DRAM, soit environ la moitié aux deux tiers de ce que le serveur tire à la prise. Seul Redfish couvre aussi les ventilateurs, les disques et les cartes réseau, et les pertes de l'alimentation seulement quand le BMC mesure à son entrée.

Le chiffre de la base de données

Compter les opérations côté application manque un point structurel : l'énergie d'un N+1 est surtout brûlée par la base de données qui exécute les N requêtes, et une base n'émet pas de spans, elle est donc invisible pour l'attribution par service. La déclaration [green.alumet.database] comble ce trou avec une règle de trois simple : pointez Alumet sur le cgroup de la base, et chaque fenêtre de scoring multiplie l'énergie mesurée de la base par le ratio de gaspillage SQL seul.

database waste = measured DB energy x (avoidable SQL ops / total SQL ops)

Le résultat est green_summary.database_waste, avec une conversion gCO2 quand vous déclarez la région de la base. Et le chiffre existe même sans Alumet : quand aucune mesure n'est disponible (exécutions batch, bases managées, pas de [green.alumet.database]), il est estimé depuis l'énergie modélisée des spans SQL, et son étiquette model dit quel chemin l'a produit (alumet_rapl = mesuré, estimated = modélisé). Le mesuré est une borne basse (énergie CPU seulement, ni DRAM ni disque). L'estimé n'est pas plus précis que le modèle d'énergie derrière le rapport (le proxy I/O et son encadrement 2x dans le cas courant). Les deux utilisent un ratio par comptage, le chiffre reste donc informatif. La variante mesurée est de l'énergie additionnelle exclue de energy_kwh et de co2. La variante estimée est une part re-présentée de ces totaux (ne jamais l'additionner par-dessus). La divulgation ne publie le chiffre que comme bloc séparé étiqueté hors de tous les totaux. La liste complète des bornes est dans Limites.

Le chiffre du broker

Un broker de messages pose le problème de la base de données en double : il brûle l'énergie d'une boucle de publication N+1, il n'émet aucun span à lui, et il est très souvent managé, donc il n'existe aucun hôte où faire tourner un agent. La même règle de trois y répond, avec le ratio messaging seul.

broker waste = broker energy x (avoidable publish ops / total publish ops)

Le résultat est green_summary.messaging_waste. Ce qui change par rapport à la base, c'est le nombre de façons d'obtenir l'énergie du broker, et elles n'ont pas le même statut.

• [green.alumet.broker] mesure le cgroup du broker. Même barreau que la base, même borne : la formule d'attribution par défaut d'Alumet ne couvre que le CPU, donc il sous-compte.
• [green.broker_static] déclare un cluster provisionné (nodes et un type d'instance) et ne demande aucun agent, ce qui est la seule voie ouverte sur Confluent Cloud, MSK, SQS ou un Pulsar managé. Elle lit E(n) = n x P_max dans la table SPECpower embarquée. Cette table couvre le CPU et la carte mère : le résultat borne donc les vCPU déclarés à pleine charge et non la consommation murale du cluster, et un broker limité par le stockage peut consommer davantage. Ce chiffre ne bouge pas non plus quand l'application se met à publier par lots, ce qui est une vraie faiblesse pour une valeur censée montrer qu'une remédiation fonctionne.
• Sans aucune des deux, le chiffre est estimé depuis l'énergie modélisée des spans de publication, exactement comme le repli de la base.

L'étiquette model dit quel chemin l'a produit (alumet_rapl, broker_specpower, estimated), et la divulgation périodique garde les trois séparés plutôt que de fondre une déclaration dans les sommes mesurées. Rien de tout cela ne repose sur un coefficient de joules par message. La puissance d'un broker cesse de suivre le débit au-delà d'environ 20 % de sa capacité, donc l'énergie marginale d'une publication n'est pas une constante. Les trois éléments qui la détermineraient (taux d'utilisation du cluster, facteur de réplication, topologie) sont tous invisibles depuis un span producteur. Les bornes sont dans Limites.

Ce que les chiffres ne sont pas

L'outil est un compteur directionnel de gaspillage avec un ancrage énergétique de plus en plus solide, pas un wattmètre et pas un inventaire carbone certifié. Le chemin proxy porte un encadrement multiplicatif de 2x. La puissance au repos et statique des serveurs n'est pas redistribuée aux services. Les ratios par comptage traitent pareil un SELECT indexé bon marché et une écriture lourde, alors que les mesures académiques montrent des écarts de puissance de plusieurs dizaines de pour cent. Tout cela est quantifié, avec le raisonnement, dans Limites.

Sources

Ce que chaque source externe apporte aux chiffres ci-dessus :

• Green Software Foundation, spécification Software Carbon Intensity (ISO/IEC 21031:2024) : le cadre carbon = E x I + M, l'exigence d'une intensité du réseau location-based, et l'obligation de divulguer la méthodologie derrière chaque chiffre.
• Tsirogiannis, Harizopoulos, Shah, "Analyzing the Energy Efficiency of a Database Server", SIGMOD 2010 : à utilisation CPU égale, des opérateurs de base de données peuvent présenter jusqu'à 60 % d'écart de puissance. Fonde les multiplicateurs par verbe SQL et la réserve sur les ratios par comptage.
• Xu, Tu, Wang, "Exploring Power-Performance Tradeoffs in Database Systems", ICDE 2010 et Lella et al., "DBJoules: An Energy Measurement Tool for Database Management Systems", arXiv:2311.08961 : le coût énergétique relatif des classes d'opérations SQL derrière la pondération par verbe.
• Khan et al., "RAPL in Action: Experiences in Using RAPL for Power Measurements", ACM TOMPECS 2018 : les lectures RAPL corrèlent étroitement avec des mesures externes à la prise, la raison pour laquelle les backends RAPL passent devant ceux à base de modèle.
• Raffin, Trystram, "Dissecting the software-based measurement of CPU energy consumption: a comparative analysis", arXiv:2401.15985 (IEEE TPDS 2025) : les pièges des lecteurs RAPL logiciels, et la raison pour laquelle alumet_rapl surclasse scaphandre_rapl.
• Raffin, Trystram, Richard, "Alumet: a Modular Framework to Standardize the Measurement of Energy Consumption", PECS 2025 : le cadre de mesure derrière le backend recommandé.
• Pijnacker et al., "Container-level Energy Observability in Kubernetes Clusters", arXiv:2504.10702 : des erreurs d'attribution mesurées sur l'ancien Kepler eBPF 0.7.2, avant la réécriture 0.10 que lit Perf Sentinel. Le billet CNCF "Kepler, re-architected" (juin 2026) rend compte de la validation de cette réécriture par le projet lui-même, pas d'une validation indépendante, et indique que Kepler n'attribue que l'usage CPU actif par charge. kepler_ebpf se place sous les backends RAPL pour ces raisons actuelles, pas sur la base des résultats de la 0.7.2.
• Mytton, Lunden, Malmodin, "Network energy use not directly proportional to data volume", Journal of Industrial Ecology 28(4), 2024 : pourquoi le terme optionnel de transport réseau est modélisé prudemment.
• Les résultats publiés SPEC SPECpower_ssj2008 et la méthodologie Cloud Carbon Footprint : l'interpolation utilisation-vers-watts derrière cloud_specpower.
• Boavizta : les analyses de cycle de vie de serveurs derrière le terme incorporé.
• Electricity Maps : l'API d'intensité du réseau en direct derrière la source d'intensité real_time.

La justification de conception plus profonde, y compris la normalisation de la forme de lecture de chaque backend, se trouve dans 05 · GreenOps & carbon.