Scoring GreenOps et conversion carbone

Score d'intensité I/O (IIS)

La métrique centrale est le Score d'Intensité I/O (I/O Intensity Score) : le nombre d'opérations I/O générées par requête utilisateur pour un endpoint donné.

IIS(endpoint) = total_io_ops(endpoint) / invocation_count(endpoint)

Un endpoint appelé à travers 3 traces avec 18 opérations I/O au total a IIS = 18 / 3 = 6.0. Cela normalise les différents volumes de trafic : un endpoint à fort trafic avec 1000 invocations et 6000 opérations I/O a le même IIS (6.0) qu'un endpoint à faible trafic avec 3 invocations et 18 opérations.

Le dénominateur utilise .max(1) comme garde contre la division par zéro, bien que ce cas ne puisse pas se produire en pratique (un endpoint qui apparaît dans endpoint_stats a forcément été vu dans au moins une trace).

Algorithme de scoring : cinq étapes

Étape 1 : statistiques par endpoint

for (trace_idx, trace) in traces.iter().enumerate() {
    for span in &trace.spans {
        total_io_ops += 1;
        let stats = endpoint_stats.entry(key).or_insert_with(|| EndpointStats {
            total_io_ops: 0,
            invocation_count: 0,
            last_seen_trace: usize::MAX,
        });
        stats.total_io_ops += 1;
        if stats.last_seen_trace != trace_idx {
            stats.invocation_count += 1;
            stats.last_seen_trace = trace_idx;
        }
    }
}

Passe unique avec sentinelle par trace : invocation_count est incrémenté la première fois qu'une paire (service, endpoint) est vue dans une trace donnée, puis last_seen_trace est positionné pour bloquer toute ré-incrémentation sur la même trace. Initialiser la sentinelle à usize::MAX (et non 0) garde l'index de trace 0 valide comme marqueur de "première rencontre". Cela évite une seconde passe get_mut sur un HashSet par trace (une sonde HashMap de moins par paire (trace, endpoint)).

EndpointStats<'a> avec service emprunté : le champ service emprunte &'a str depuis les événements span au lieu de cloner le String. Le clone ne se produit que plus tard lors de la construction des structs TopOffender pour la sortie. Cela évite un clone de String par endpoint unique dans la boucle interne.

Structure sous-jacente (HashMap + sort vs BTreeMap) : la map par endpoint est un HashMap finalisé par un unique sort_by pour la vue publique, et non un BTreeMap. Sous le régime d'accès de perf-sentinel (beaucoup de spans par endpoint unique, K petit devant N), les mesures sur 1M de spans donnent systématiquement l'avantage à HashMap + sort :

Le tri gratuit à l'itération du BTreeMap est noyé par son surcoût O(log K) par insertion. Le tri terminal est O(K log K) sur K petit (20-90 µs sur toute la plage), négligeable à côté du volume d'insertions.

Étape 2 : dédup des I/O évitables

let mut dedup: HashMap<(&str, &str, &str), usize> = HashMap::with_capacity(findings.len());
for f in &findings {
    if matches!(f.finding_type, FindingType::SlowSql | FindingType::SlowHttp) {
        continue; // les findings lents ne sont pas évitables
    }
    let avoidable = f.pattern.occurrences.saturating_sub(1);
    let entry = dedup.entry((&f.trace_id, &f.pattern.template, &f.source_endpoint)).or_insert(0);
    *entry = (*entry).max(avoidable);
}

Pourquoi inclure source_endpoint dans la clé ? Le même template SQL (ex. SELECT * FROM config WHERE key = ?) peut être appelé depuis deux endpoints différents dans la même trace. Les opérations évitables de chaque endpoint doivent être comptées indépendamment. Sans source_endpoint, max(5, 3) = 5 sous-compterait : le total correct est 5 + 3 = 8.

Pourquoi max() au lieu de sum() ? Au sein du même (trace, template, endpoint), les détecteurs N+1 et redondant peuvent tous deux se déclencher sur des ensembles de spans qui se chevauchent. Prendre le max empêche le double comptage : si N+1 rapporte 9 évitables et redondant rapporte 4 évitables pour le même groupe, le vrai compteur d'évitables est 9 (l'ensemble le plus grand inclut déjà le plus petit).

Findings lents exclus : les requêtes lentes sont des opérations nécessaires qui se trouvent être lentes. Elles ont besoin d'optimisation (indexation, cache), pas d'élimination. Les inclure dans le ratio de gaspillage confondrait "I/O gaspillées" avec "I/O lentes".

Étape 3 : calcul de l'IIS par endpoint

let iis_map: HashMap<&str, f64> = endpoint_stats.iter()
    .map(|(&ep, stats)| {
        let invocations = stats.invocation_count.max(1) as f64;
        (ep, stats.total_io_ops as f64 / invocations)
    })
    .collect();

La map IIS est calculée une seule fois et réutilisée pour l'enrichissement des findings (étape 4) et le classement des top offenders (étape 5).

Étape 4 : enrichir les findings

Chaque finding reçoit un GreenImpact :

GreenImpact {
    estimated_extra_io_ops: if slow { 0 } else { occurrences - 1 },
    io_intensity_score: iis,
}

Étape 5 : top offenders

Triés par IIS décroissant, avec un ordre alphabétique en cas d'égalité pour une sortie déterministe :

top_offenders.sort_by(|a, b| {
    b.io_intensity_score.partial_cmp(&a.io_intensity_score)
        .unwrap_or(Ordering::Equal)
        .then_with(|| a.endpoint.cmp(&b.endpoint))
});

partial_cmp avec unwrap_or(Equal) gère NaN de manière sûre, bien que NaN ne puisse pas se produire puisque le dénominateur est toujours >= 1.0.

Ratio de gaspillage I/O

ratio_gaspillage = avoidable_io_ops / total_io_ops

Quand total_io_ops == 0, le ratio est 0.0 (pas NaN). C'est la fraction d'opérations I/O qui pourraient être éliminées en corrigeant les anti-patterns détectés. Cela s'aligne avec le composant Énergie du modèle SCI (ISO/IEC 21031:2024) de la Green Software Foundation : réduire les calculs inutiles réduit la consommation d'énergie.

Conversion carbone

Le pipeline de scoring résout deux dimensions indépendantes pour chaque span : l'énergie par opération (E) et l'intensité du réseau électrique (I). Chacune a sa propre chaîne de repli, de la source la plus précise jusqu'aux valeurs embarquées par défaut.

Alignement SCI v1.0

perf-sentinel aligne son modèle carbone sur la spécification Software Carbon Intensity v1.0 (adoptée comme ISO/IEC 21031:2024, révision GSF courante v1.1), en cohérence avec la formulation "aligné SCI, directionnel" utilisée partout ailleurs dans le projet : le proxy I/O couvre une frontière logicielle partielle et le rapport publie le numérateur sur son propre schéma plutôt que le format de rapport SCI par R. La formule est :

SCI = ((E × I) + M) per R

Où :

• E = énergie consommée par la charge de travail (kWh)
• I = intensité carbone géographique du réseau (gCO₂eq/kWh)
• M = émissions embodiées de fabrication matérielle, amorties
• R = unité fonctionnelle (le dénominateur "par X")

Dans perf-sentinel :

• R = 1 trace : une requête utilisateur. Chaque trace corrélée est une unité fonctionnelle.
• E = io_ops × ENERGY_PER_IO_OP_KWH : proxy à partir du compteur d'ops I/O.
• I = lookup_region(region).intensity : depuis la table carbone embarquée.
• M = traces.len() × embodied_per_request_gco2 : configurable, défaut 0,001 g/req.

Constante énergétique

pub const ENERGY_PER_IO_OP_KWH: f64 = 0.000_000_1; // 0,1 uWh par opération I/O

C'est une approximation d'ordre de grandeur, pas une valeur mesurée. Elle tient compte d'une requête de base de données ou d'un aller-retour HTTP typique sur une infrastructure cloud. Le projet Cloud Carbon Footprint utilise une approche similaire d'estimation de l'énergie à partir de l'utilisation des ressources plutôt que d'une mesure directe.

La valeur doit être divulguée comme méthodologie selon les exigences SCI. Elle est documentée dans le code, dans Limites et ici.

Carbone embodié (terme M)

pub const DEFAULT_EMBODIED_CARBON_PER_REQUEST_GCO2: f64 = 0.001;

Le défaut de 0,001 gCO₂/requête est dérivé d'hypothèses typiques sur le cycle de vie d'un serveur :

• Un serveur x86 moderne a une empreinte carbone embodiée de ~1000 kgCO₂eq sur un cycle de vie de 4 ans (sources : API Boavizta lifecycle assessments, méthodologie Cloud Carbon Footprint).
• 4 ans × 365 jours × 86400 secondes × 1 requête/sec ≈ 126 millions de requêtes amorties par serveur.
• 1000 g par serveur / 126e6 requêtes ≈ 0,000008 gCO₂/req (8e-6 g) à 1 req/sec, montant à ~0,001 à des taux de requêtes plus bas ou pour du matériel moins amorti.

Le défaut 0,001 g/req est une borne supérieure conservatrice pour des serveurs microservices peu chargés. La méthodologie AWS Customer Carbon Footprint (2025) rapporte ~320 kgCO2eq/an pour un Dell R640, ce qui à des taux d'utilisation typiques donne 10-50 ugCO2/req, soit 10-20x en dessous de notre défaut. Les utilisateurs avec des données d'infrastructure mesurées devraient abaisser cette valeur via [green] embodied_carbon_per_request_gco2.

L'embodié est indépendant de la région. Les émissions de fabrication matérielle ne varient pas selon le lieu de déploiement. perf-sentinel émet le carbone embodié inconditionnellement quand le scoring vert est activé, même quand aucune région ne se résout, pour que les utilisateurs voient au moins une estimation plancher.

Formule de conversion

Pour chaque bucket de région :

operational_region = io_ops_in_region × ENERGY_PER_IO_OP_KWH × carbon_intensity × PUE

Total opérationnel sur toutes les régions :

operational_gco2 = Σ operational_region

Embodié :

embodied_gco2 = traces.len() × embodied_per_request_gco2

Mid-point CO₂ total :

total.mid = operational_gco2 + embodied_gco2

CO₂ évitable (via ratio, voir "Évitable via ratio" ci-dessous) :

accounted_io_ops = total_io_ops - unknown_ops
avoidable.mid = operational_gco2 × (avoidable_io_ops / accounted_io_ops)

Le dénominateur accounted_io_ops exclut le bucket synthétique unknown pour que le ratio soit cohérent avec operational_gco2 (qui l'exclut aussi). Numérateur et dénominateur sur la même base comptable.

Intervalle d'incertitude (multiplicatif 2×, pas arithmétique ±50%) :

total.low  = total.mid × 0,5    // mid divisé par 2
total.high = total.mid × 2,0    // mid multiplié par 2
(idem pour avoidable.low / avoidable.high)

C'est un intervalle log-symétrique : la moyenne géométrique de low et high vaut mid. Le cadrage 2× correspond mieux à l'incertitude d'ordre de grandeur du modèle proxy I/O qu'une fenêtre symétrique ±50%. Voir "Cadrage de l'incertitude" ci-dessous.

Sémantique SCI v1.0 : numérateur vs intensité

La spécification SCI v1.0 définit SCI = ((E × I) + M) / R, une intensité exprimée par unité fonctionnelle R. perf-sentinel émet les deux vues : le numérateur de cette formule sommé sur toutes les traces analysées (co2.total), et l'intensité proprement dite (co2.sci_per_trace).

co2.total.mid = Σ operational_gco2 + embodied_gco2
              = (E × I) + M   (sommé sur les traces analysées, l'empreinte)

co2.sci_per_trace.mid = co2.total.mid / traces_analyzed
                      = le score SCI, avec R = 1 trace

co2.total est une empreinte (gCO₂eq absolus), co2.sci_per_trace est le score d'intensité par unité fonctionnelle. L'unité fonctionnelle est déclarée sur co2.functional_unit ("trace", qui correspond à l'unité fonctionnelle Transaction / lecture-ou-écriture base de données de la spec SCI). La spec SCI autorise l'intensité réseau moyenne pour I (elle exige le location-based, pas le market-based, et admet explicitement la moyenne), donc le chiffre est conforme SCI.

Pour taguer cette distinction sémantique au niveau des données, CarbonEstimate porte un champ methodology avec trois valeurs possibles :

• "sci_v1_numerator" : utilisé sur co2.total. L'empreinte (E × I) + M sommée sur les traces.
• "sci_v1_intensity" : utilisé sur co2.sci_per_trace. L'intensité par R ((E × I) + M) / R, R = 1 trace.
• "sci_v1_operational_ratio" : utilisé sur co2.avoidable. Le ratio global aveugle à la région operational × (avoidable/accounted), excluant le carbone embodié.

Les deux valeurs distinctes signalent aux consommateurs en aval que total et avoidable sont calculés différemment et ne doivent pas être comparés comme s'ils étaient des quantités homogènes.

Évitable via ratio (choix de design)

Calculer le CO₂ évitable de manière précise par région nécessiterait de propager la résolution de région à travers la phase de dédup des findings (qui agrège actuellement les ops I/O évitables globalement par (trace_id, template, source_endpoint)). C'est complexe et sujet aux erreurs.

À la place, perf-sentinel calcule :

avoidable.mid = operational_gco2 × (avoidable_io_ops / accounted_io_ops)

Cela préserve l'échelle relative (une réduction de 50% du gaspillage donne une chute de 50% du CO₂ évitable) sans nécessiter d'attribution par finding. Le compromis : quand les ops évitables sont concentrées dans une région à haute intensité, ce ratio sous-attribue légèrement les économies. La simplification est documentée comme limitation connue et taguée au niveau des données via methodology: "sci_v1_operational_ratio".

Le carbone embodié est exclu de l'évitable. Vous ne pouvez pas optimiser le silicium fabriqué en corrigeant des requêtes N+1 : les émissions embodiées sont fixes par requête peu importe l'efficacité de l'application. L'estimation évitable ne considère que le terme opérationnel.

Résolution multi-région

Chaque span résout vers une région effective via une chaîne à 3 niveaux (premier match gagne) :

1. event.cloud_region : extrait de l'attribut de ressource OTel cloud.region (avec fallback sur attribut de span pour les SDKs qui le mettent sur les spans individuels). Le plus autoritatif. Les valeurs sont assainies à la frontière d'ingestion : les chaînes invalides (non-ASCII-alphanumérique-tiret-underscore, longueur > 64 ou vides) sont silencieusement écartées.
2. [green.service_regions][event.service.to_lowercase()] : surcharge config pour les environnements où OTel ne le fournit pas (ex. ingestion Jaeger / Zipkin). Insensible à la casse (le loader de config met les clés en minuscules).
3. [green] default_region : fallback global.

Les spans sans région résolvable atterrissent dans un bucket synthétique "unknown" : zéro contribution au CO₂ opérationnel. Le breakdown regions[] montre tout de même le bucket pour que les utilisateurs voient les ops I/O orphelines (signal visible pour le troubleshooting ; les messages tracing::debug! détaillés sont disponibles via RUST_LOG=debug).

Plafond de cardinalité des régions. Le BTreeMap par région est plafonné à 256 régions distinctes en une passe de scoring (constante MAX_REGIONS). Les chaînes de région excédentaires tombent dans le bucket unknown, empêchant l'épuisement mémoire depuis des attributs OTLP cloud.region contrôlés par un attaquant ou mal configurés.

Scalaire CO₂ des TopOffender en mode multi-région. Quand le scoring multi-région est actif (soit [green.service_regions] est non-vide, soit un span porte cloud.region), le scalaire top_offenders[].co2_grams est mis à None pour tous. Le calculer depuis default_region uniquement serait incohérent avec le breakdown par région ; les utilisateurs doivent se fier à green_summary.regions[] pour l'attribution par région dans les déploiements multi-région.

Cadrage de l'incertitude : multiplicatif 2×, pas ±50%

Chaque estimation CO₂ est rapportée comme { low, mid, high } :

pub struct CarbonEstimate {
    pub low: f64,           // mid × 0,5
    pub mid: f64,           // meilleure estimation
    pub high: f64,          // mid × 2,0
    pub model: &'static str,       // "io_proxy_v1"
    pub methodology: &'static str, // "sci_v1_numerator" ou "sci_v1_operational_ratio"
}

Les facteurs 0,5 et 2,0 encodent un intervalle d'incertitude multiplicative 2× autour du midpoint :

moyenne_géométrique(low, high) = sqrt(low × high) = sqrt(mid² × 0,5 × 2,0) = mid

C'est un intervalle log-symétrique : le mid est le centre géométrique, pas le centre arithmétique. L'écart entre low et high est un facteur 4 (high/low = 4), plus large qu'une fenêtre symétrique ±50% (qui donnerait high/low = 3).

Pourquoi 2× et pas ±50% ? Le modèle proxy I/O a une incertitude d'ordre de grandeur à chaque étape :

• ENERGY_PER_IO_OP_KWH = 0,1 µWh/op est une approximation d'ordre de grandeur.
• Les valeurs d'intensité réseau de CCF/Electricity Maps sont des moyennes annuelles ; l'intensité en temps réel varie 2-3× sur une journée.
• Les PUE sont des moyennes par fournisseur ; les datacenters individuels varient.
• Le carbone embodié suppose une valeur conservatrice de cycle de vie serveur qui peut être décalée d'un ordre de grandeur pour du matériel spécifique.

Une fenêtre symétrique ±50% (high = 1,5 × mid) sous-estimerait cette incertitude réelle. Le cadrage multiplicatif 2× est délibérément choisi pour être honnête : la valeur réelle est dans un facteur 2 de mid, dans un sens ou l'autre.

Les bornes reflètent l'incertitude agrégée du modèle, pas la variance par endpoint. Le modèle n'a pas assez de résolution pour distinguer la précision par endpoint.

Versionnement du modèle

Le champ model: "io_proxy_v1" versionne la méthodologie d'estimation. Les améliorations futures (pondération par opération, profils horaires de carbone, intégration RAPL) bumperont cette version, permettant aux consommateurs en aval de tracer quelle méthodologie a produit un rapport donné.

Recherche par région

La table d'intensité carbone est embarquée comme tableau statique et convertie en HashMap via LazyLock :

static REGION_MAP: LazyLock<HashMap<&'static str, (f64, Provider)>> =
    LazyLock::new(|| CARBON_TABLE.iter().map(...).collect());

Pourquoi LazyLock<HashMap> au lieu d'un scan linéaire ? L'implémentation originale parcourait les 41 entrées à chaque appel. Avec le HashMap, la recherche est O(1). Le coût d'initialisation est payé une seule fois au premier accès.

Recherche insensible à la casse : la fonction publique lookup_region() convertit l'entrée en minuscules via to_ascii_lowercase() avant la recherche. Toutes les clés de la table sont stockées en minuscules. L'étape de scoring multi-région utilise un BTreeMap<String, usize> (pas HashMap) pour répartir les ops I/O par région résolue. Cela garantit un ordre d'itération déterministe et des sommes flottantes stables entre exécutions.

Valeurs PUE

Le PUE (Power Usage Effectiveness) mesure le ratio entre l'énergie totale du datacenter et l'énergie de l'équipement IT. Un PUE de 1,15 signifie 15% de surcoût pour le refroidissement, l'éclairage et l'infrastructure. La moyenne de l'industrie est ~1,58 (Uptime Institute), et les fournisseurs cloud hyperscale atteignent des valeurs significativement plus basses, le 1,09 de GCP passant sous le plancher symbolique des 10% de surcoût.

Données d'intensité carbone

Les intensités carbone régionales du réseau électrique (gCO2eq/kWh) proviennent des moyennes annuelles Electricity Maps (2023-2024) et du projet Cloud Carbon Footprint. La table couvre 15 régions AWS, 8 régions GCP, 6 régions Azure et 14 codes pays ISO.

Quand la région configurée n'est pas trouvée dans la table, les champs CO2 sont omis du rapport (aucune valeur par défaut n'est inventée).

Profils horaires d'intensité carbone

La valeur annuelle plate par région écarte la variance diurne qui peut être importante dans les réseaux avec une forte part de renouvelables variables ou de forts pics de demande. Pour capturer cette variance, perf-sentinel embarque un profil UTC 24 valeurs par région pour quatre régions avec des formes diurnes bien documentées :

• France (eu-west-3) : baseload nucléaire, forme plate-avec-pic-soir.
• Allemagne (eu-central-1) : charbon + gaz + renouvelables variables, pics matin/soir prononcés.
• Royaume-Uni (eu-west-2) : éolien + gaz, pics jumeaux modérés.
• US-East (us-east-1) : gaz + charbon, plateau diurne 13h-18h UTC (9h-14h heure Est).

La moyenne arithmétique de chaque profil approxime la valeur annuelle plate correspondante dans les ±5%, préservant la continuité méthodologique. Le profil Allemagne (eu-central-1) violait historiquement cet invariant (moyenne ~431 gCO₂/kWh, figée au niveau de la crise charbon 2022, contre 338 en annuel) : depuis 0.8.7 il est recalibré sur le niveau Electricity Maps 2024 (~341) et l'invariant tient pour toutes les régions sans exception. Les utilisateurs peuvent désactiver les profils horaires avec use_hourly_profiles = false.

Sources : rapports open-data annuels Electricity Maps (2023-2024), ENTSO-E Transparency Platform, RTE eco2mix (France), Fraunhofer ISE Energy-Charts (Allemagne), NGESO carbonintensity.org.uk (Royaume-Uni), EIA hourly generation data (US-East).

Quatre régions (eu-west-3, eu-central-1, eu-west-2, us-east-1) embarquent des profils mensuels x horaires complets (12x24, MONTHLY_PROFILES), rapportés sous le tag de modèle io_proxy_v3. Les autres régions profilées utilisent un seul profil représentatif de 24 heures (FLAT_YEAR_PROFILES) : pour elles, les données saisonnières additionnelles apporteraient un gain de précision marginal par rapport au coût de maintenance. Le tag IntensitySource distingue annuel, horaire et mensuel par région, promouvoir une région plate vers le mensuel reste donc rétrocompatible.

Le chemin de scoring parcourt chaque span une fois et dispatche entre trois sources d'intensité :

let intensity_used = if ctx.use_hourly_profiles
    && hourly_profile_for_region_lower(region).is_some()
    && let Some(hour) = time::parse_utc_hour(&span.event.timestamp)
{
    lookup_hourly_intensity_lower(region, hour).unwrap_or(annual_intensity)
} else {
    annual_intensity
};

Quand le dispatch sélectionne le chemin horaire pour une région, la ligne RegionBreakdown est taguée intensity_source: "hourly" et le CarbonEstimate.model de niveau supérieur passe de "io_proxy_v1" à "io_proxy_v2". Si le même rapport contient des régions passées par le chemin plat, ces régions restent taguées intensity_source: "annual" tandis que le modèle de niveau supérieur lit toujours "io_proxy_v2". Le tag enregistre "le modèle le plus précis utilisé quelque part dans le run".

Auto-cohérence des lignes de breakdown. L'identité co2_gco2 ≈ io_ops × grid_intensity_gco2_kwh × pue × ENERGY_PER_IO_OP_KWH ne tient que dans le cas proxy (pas de snapshot Scaphandre/cloud). Quand de l'énergie mesurée est présente et que des services dans la même région utilisent des coefficients différents, l'intensité affichée reste la moyenne pondérée mais l'identité devient approximative.

Les timestamps doivent être en UTC. parse_utc_hour rejette les formes d'offset non-UTC (+02:00, -05:00) plutôt que de les décaler silencieusement. Les spans avec timestamps non-parsables retombent sur l'intensité annuelle plate pour la région.

Invariant somme-puis-divise (défense contre la dérive dedup). Un helper unique compute_operational_gco2(io_ops, intensity, pue) empêche la formule d'être réimplémentée de façon incohérente entre chemins, étendu avec un helper de plus bas niveau per_op_gco2(energy_kwh, intensity, pue) qui est la source unique de vérité pour la multiplication energy × intensity × pue. Les trois chemins (proxy, horaire, Scaphandre) passent par ce helper.

Intégration énergétique par processus Scaphandre

Le modèle proxy utilise une constante fixe ENERGY_PER_IO_OP_KWH (0,1 µWh par op). C'est une approximation à deux ordres de grandeur près. perf-sentinel offre un support opt-in pour remplacer le proxy par un coefficient mesuré au niveau service dérivé des lectures de puissance par processus de Scaphandre.

Comment ça s'intègre dans l'architecture. Scaphandre est un processus externe installé par l'utilisateur. perf-sentinel NE bundle PAS et NE fork PAS Scaphandre : il scrape l'endpoint Prometheus /metrics que Scaphandre expose déjà. Le module score/scaphandre.rs possède :

• ScaphandreConfig : parsé depuis [green.scaphandre] dans .perf-sentinel.toml.
• ScaphandreState : supporté par ArcSwap<HashMap<String, ServiceEnergy>> pour des lectures sans verrou depuis le chemin de scoring. Le scraper construit un nouveau Arc<HashMap> à chaque scrape réussi et le swap atomiquement ; les lecteurs font un seul load_full() sans contention de lock.
• spawn_scraper() : une tâche tokio qui s'exécute toutes les scrape_interval_secs.
• parse_scaphandre_metrics() : parser Prometheus sensible aux échappements. Itère par .chars() pour la sécurité UTF-8. Fast path sans allocation quand aucun backslash n'est présent dans les valeurs de labels. Gère les séquences \" et \\.
• OpsSnapshotDiff : un helper de snapshot-diff qui lit les compteurs d'ops par service depuis MetricsState::service_io_ops_total.
• apply_scrape() : applique les lectures de puissance parsées + les deltas d'ops à l'état.

La formule. Pour chaque service mappé dans une fenêtre de scrape :

power_watts       = process_power_microwatts / 1_000_000
joules            = power_watts × scrape_interval_secs
kwh               = joules / 3_600_000
energy_per_op_kwh = kwh / ops_observed_in_window

Quand ops_observed_in_window == 0, l'entrée d'état existante est conservée inchangée plutôt qu'effacée, ce qui évite le flapping du tag model pour les services idle.

Où le coefficient se branche. Le daemon prend un snapshot synchrone de toutes les sources d'énergie au début de chaque tick process_traces via build_tick_ctx. Cette map fusionnée est attachée à CarbonContext.energy_snapshot pour la durée du tick. Chaque EnergyEntry porte le coefficient et un tag de modèle ("scaphandre_rapl" ou "cloud_specpower"). Dans la boucle de spans de compute_carbon_report, l'énergie par op est résolue comme suit :

let (energy_kwh, measured_model) = match &ctx.energy_snapshot {
    Some(snapshot) => match snapshot.get(&span.event.service) {
        Some(entry) => (entry.energy_per_op_kwh, Some(entry.model_tag)),
        None => (ENERGY_PER_IO_OP_KWH, None),
    },
    None => (ENERGY_PER_IO_OP_KWH, None),
};
let op_co2 = per_op_gco2(energy_kwh, intensity_used, pue);

L'étape de scoring suit des flags par région (any_scaphandre, any_kepler_ebpf, any_redfish_bmc, any_cloud_specpower, any_realtime_report) et le CarbonEstimate.model de niveau supérieur reflète la source la plus précise utilisée : "electricity_maps_api" > "scaphandre_rapl" > "kepler_ebpf" > "redfish_bmc" > "cloud_specpower" > "io_proxy_v3" > "io_proxy_v2" > "io_proxy_v1". Quand des facteurs de calibration sont actifs, +cal est ajouté. Toutes les sources d'énergie se composent naturellement avec les profils horaires : une op avec énergie mesurée en eu-west-3 à 3h du matin UTC utilise l'énergie mesurée ET l'intensité horaire simultanément.

Compteur d'ops par service comme source unique de vérité. Le scraper lit le compteur d'ops par service depuis MetricsState::service_io_ops_total (un CounterVec Prometheus) via snapshot_service_io_ops(). Le chemin d'intake d'événements du daemon incrémente ce compteur sur chaque événement normalisé.

Shutdown gracieux. Le daemon capture le JoinHandle du scraper et appelle .abort() sur lui avant le drain process_traces final dans la branche Ctrl-C. Cela empêche les lignes de log "scrape failed" d'apparaître après le message "Shutting down daemon".

Ce que Scaphandre ne fait PAS. Voir la section Limites de précision Scaphandre dans Limites pour la discussion complète. Version courte : Scaphandre donne des coefficients par service, pas d'attribution par finding. Deux findings N+1 dans la même JVM pendant la même fenêtre de scrape partagent le même coefficient par construction, car RAPL est au niveau processus, pas au niveau span.

cpu_percent       = prometheus_query(cpu_metric, service_label)
watts             = idle_watts + (max_watts - idle_watts) * (cpu_percent / 100)
joules            = watts * scrape_interval_secs
kwh               = joules / 3_600_000
energy_per_op_kwh = kwh / ops_in_window

chassis_joules = chassis_watts × scrape_interval_secs
total_ops      = Σ ops_delta(service) pour service ∈ mappé(châssis)
energy_per_op  = (chassis_joules / 3_600_000) / total_ops    (en kWh par opération)

{
  "zone": "FR",
  "carbonIntensity": 56.0,
  "isEstimated": true,
  "estimationMethod": "TIME_SLICER_AVERAGE"
}

{
  "status": "known",
  "region": "eu-west-3",
  "intensity_source": "real_time",
  "grid_intensity_gco2_kwh": 56.0,
  "intensity_estimated": true,
  "intensity_estimation_method": "TIME_SLICER_AVERAGE",
  "co2_gco2": 1.234
}

- fr: 42 I/O ops, 0.000123 gCO₂ (56 gCO₂/kWh, source: real_time, estimated/TIME_SLICER_AVERAGE)
- de: 24 I/O ops, 0.000456 gCO₂ (380 gCO₂/kWh, source: real_time, measured)
- us-east-1: 12 I/O ops, 0.000789 gCO₂ (410 gCO₂/kWh, source: annual)

energy_transport_kwh = bytes_transférés * ENERGY_PER_BYTE_KWH
transport_co2        = energy_transport_kwh * intensité_région_source * pue_source