Mono-binaire auto-hébergé · OpenTelemetry · Open source AGPL-3.0

Détectez les I/O gaspillées de vos traces. Chiffrez-les en énergie et carbone.

perf-sentinel repère les N+1, appels redondants, requêtes lentes et fanout dans vos traces OpenTelemetry, en quality gate CI ou en daemon OTLP, puis convertit chaque I/O évitable en énergie et en CO₂.

ouvrir ↗
Rapport HTML ou TUI, selon vos préférences.
À lire en premier

Prérequis : vos services émettent des traces OpenTelemetry (spans SQL et HTTP) portant le texte de la requête (db.statement / db.query.text) et l’URL cible (http.url / url.full).
Mise en place par langage (Java, C#, Rust, Go, Node.js, Python).

Auditez votre tracing d’abord : les spans qui ne portent pas ces attributs sont écartés en silence, sans avertissement, donc un rapport maigre ou vide peut signifier aucun problème détecté ou aucune instrumentation exploitable. perf-sentinel inspect montre ce qui a réellement été extrait, un arbre de spans vide signifie que les attributs porteurs manquent en amont. Voir ce qui borne les findings.

Ce que ce n’est pas : un APM complet, un profiler continu, ni (pour le moment) une plateforme de comptabilité carbone réglementaire standalone. Voir le comparatif.

Maturité : bêta, pré-1.0. La CLI, les clés de configuration et les formats sur disque peuvent encore changer avant la 1.0. Les enums de sortie JSON sont la seule partie sous contrat de stabilité explicite, les ruptures de compatibilité étant signalées dans les notes de version.

// le problème

Pourquoi perf-sentinel ?

Les anti-patterns d’I/O touchent toute application, monolithe comme microservices. En distribué, une requête cascade sur plusieurs services et personne ne voit le chemin complet.

Les outils existants n’en couvrent qu’une part : Hypersistence se limite à JPA, Datadog et New Relic sont des agents lourds, Sentry dépend de son SDK. Aucun détecteur au niveau protocole, auto-hébergeable, en gate CI comme en daemon.

perf-sentinel lit les traces que votre application émet déjà (SQL, HTTP), quel que soit le langage ou l’ORM : il voit les requêtes générées, sans avoir besoin de comprendre JPA ou EF Core.

Chaque I/O évitable est aussi chiffré en énergie et en CO₂, par le bas et attribuable au code.

// l’angle mort

Le poids carbone du numérique,
et l’angle mort que personne ne mesure

Le numérique pèse déjà 1,8 % à 3,9 % des émissions mondiales de GES, à la hauteur de l’aviation civile et en croissance rapide. Mais la part due au code et aux applications web lourdes mal optimisées reste non quantifiée à l’échelle mondiale.

Le numérique pèse 1,8 % à 3,9 % des GES mondiaux
5 %4 %3 %2 %1 %0 %
1,8 %
3,9 % (dont ? %)
?
Estimation basse
Estimation haute
Mesuré : data centers, réseaux, terminaux
Zone non mesurée : manque d’optimisation des apps webs lourdes
Un trou dans les données que personne ne comble

ITU et IEA confirment la hausse rapide du numérique. Mais la part due au code et aux apps web lourdes reste non quantifiée à l’échelle mondiale.

30 à 80 %
de réduction d’émissions atteignable sur un site web mal optimisé
// mesurer par le bas, pas estimer par le haut

L’approche bottom-up de perf-sentinel face au top-down des outils actuels

Approche top-down
SI et outils carbone actuels
•Part de moyennes : consommation des data centers, ratios sectoriels.
•Estime une empreinte globale depuis la facture cloud ou les effectifs.
•Donne un chiffre annuel, mais pas le détail de ce qui pèse.
Résultat
Chiffre global, non attribuable et non actionnable.
Approche bottom-up
perf-sentinel sur les apps web lourdes
✓Observe l’application réelle, requête par requête.
✓Traduit chaque traitement en énergie puis en carbone (méthode reconnue).
✓Pointe les gaspillages évitables et leur coût.
Résultat
Gisement chiffré, attribuable au code et directement actionnable.
// ce qui est détecté

Dix anti-patterns d'I/O, au niveau protocole

Sur les requêtes SQL et HTTP que vos services émettent déjà, quel que soit le langage ou l’ORM.

01
N+1 SQL
Même template de requête tiré ≥ N fois dans une trace.
02
N+1 HTTP
Même template d'URL appelé ≥ N fois dans une trace.
03
SQL redondant
Requête identique, paramètres identiques, même trace.
04
HTTP redondant
Appel identique, paramètres identiques, même trace.
05
SQL lent
Durée de requête au-dessus du seuil configuré.
06
HTTP lent
Durée de requête au-dessus du seuil configuré.
07
Fanout excessif
Un span démarre ≥ N enfants en parallèle.
08
Service bavard
A → B de manière répétée dans une seule requête utilisateur.
09
Saturation de pool
Requêtes concurrentes en vol au-dessus de la taille du pool.
10
Appels sérialisés
I/O séquentiels qui pourraient être parallélisés.

Chaque finding embarque : type, sévérité, template normalisé, occurrences, endpoint source, suggestion, localisation source et impact GreenOps. En mode daemon, s’y ajoute la corrélation cross-trace.

// quatre façons de l'exécuter

1 binaire, 2 modes, 4 postures

mode batch · local
Exploration

En local : drill-down clavier Analyze · Inspect · Explain en TUI, ou un dashboard HTML offline en un seul fichier à ouvrir et partager. Démo intégrée, rien à configurer.

mode batch · CI
Batch CI

Sur traces capturées : exit 1 au dépassement de seuil, sortie SARIF pour le code scanning, JSON déterministe. Pas de gate qui clignote.

mode daemon · sidecar
Sidecar

Un daemon par service pour du debug isolé, qui ingère les traces OTLP de ce service juste à côté.

mode daemon · central
Centralisé

Un daemon unique long-running vers lequel un OTel Collector route : gRPC :4317 + HTTP :4318, /metrics Prometheus, dashboard live, API de query et corrélation cross-trace.

Déploiement en détail dans le guide →
// écrit en rust

Un mono-binaire Rust, mesuré

RustVersion 1.96.0

Édition 2024, lié statiquement à musl et livré dans des images FROM scratch. Les chiffres ci-dessous chronomètrent le pipeline d’analyse seul (mono-thread, sur jeux de données synthétiques) : ils isolent le coût du pipeline, pas un débit de bout en bout.

576k–1.2M
évts/s, débit pipeline (GCP c3-standard-8 x86 à M4 Pro)
0.8–1.9 µs
par évènement, p50 à p99
~17 Mo
RSS daemon au repos (≈190 Mo sous ~1M évts/s)
Rust 2024
avec binaire statique musl et image FROM scratch
Benchmarks détaillés dans la doc →
// greenops

Chaque I/O évitable a un coût,
en temps, énergie et carbone

co2.total = (E × I) + M

Réduire les N+1 et les appels redondants améliore les temps de réponse et la consommation d'énergie : les deux objectifs ne s'opposent pas. co2.total suit le numérateur Software Carbon Intensity v1.0 (ISO/IEC 21031:2024) : l’énergie consommée (E) multipliée par l’intensité carbone du réseau électrique (I), plus les émissions matérielles embarquées (M), le tout sommé sur les traces analysées.

Score d'intensité I/O (IIS)
Total des opérations I/O d'un endpoint divisé par son nombre d'invocations.
Ratio de gaspillage I/O
Opérations évitables sur opérations totales, la part directement récupérable.
co2.total multi-régions
Numérateur SCI v1.0, scoring par région automatique quand les spans portent cloud.region.

Estimation directionnelle (encadrement ~2× en mode proxy, plus serrée avec une source mesurée : Scaphandre RAPL, Kepler eBPF, Redfish BMC ou SPECpower cloud + calibration). Exploitable comme activity data pour Watershed · Sweep · Greenly · Persefoni, ou pour démontrer la conformité RGESN. Il peut aussi émettre des rapports de divulgation publique périodiques énergie et carbone (JSON trimestriel ou annuel, signature Sigstore optionnelle, vérifiables par hash).

Métriques GreenOps dans le guide →
// comment ça se compare

Léger, agnostique, CI-natif, carbon-aware

Capacité
APM commercial type
perf-sentinel
Empreinte runtime
Agent ~100–150 Mo RSS
Binaire autonome <20 Mo RSS
Couverture langages
Agents par langage ou SDK
Tout runtime instrumenté OTel
Détection N+1 SQL & HTTP
Oui, liée à l’agent
Oui, au niveau protocole
Corrélation cross-service
Oui
Oui, via trace ID
Quality gate CI natif
Alertes, pas de gate
Oui, exit 1 sur seuil
Attribution carbone par span
Non
Oui (aligné SCI, directionnel)
Score GreenOps (IIS, gaspillage)
Non
Intégré
Licence & hébergement
SaaS propriétaire, à l’usage
AGPL-3.0, auto-hébergeable

« APM commercial type » généralise les outils SaaS à base d’agent comme Datadog ou New Relic ; le comportement exact varie selon le produit, et les empreintes sont des ordres de grandeur issus de déploiements publics. perf-sentinel n’est pas un APM complet et ne remplace pas une suite d’observabilité, il s’y adosse. Le comparatif détaillé par outil (Sentry, Hypersistence, Digma, Pyroscope, OTJAE) figure dans la doc.

Comparatif complet dans le guide →

Ce que perf-sentinel n’est pas

✗Pas un remplacement d’APM complet. Pas de dashboards, pas d’UI d’alerting, pas de RUM, pas d’agrégation de logs, pas de profiling distribué. Si vous avez besoin de ça, Datadog, New Relic et Sentry restent les bons outils.
✗Pas un profiler continu. L’outil observe les patterns d’I/O au niveau protocole, il ne fait pas de sampling on-CPU, d’allocations ni de stack traces. Pour les flame graphs et le profiling CPU/mémoire par langage, Grafana Pyroscope est l’équivalent open-source et se marie bien : pyroscope dit où passe le temps CPU, perf-sentinel dit quels patterns d’I/O le déclenchent.
✗Pas une solution de monitoring temps réel. Le mode daemon stream les findings, mais le centre de gravité du projet ce sont les quality gates CI et l’analyse post-hoc, pas l’observabilité prod live.
✗Pas (encore) une plateforme de comptabilité carbone réglementaire standalone. Un reporting CSRD ou GHG Protocol Scope 2/3 standalone exige une vérification tiers-partie et des scopes non-IT qu’il ne couvre pas. Périmètre exact, couplages (Watershed, Sweep, Greenly, Persefoni) et cas RGESN : voir la section GreenOps.
✗Pas un substitut à la mesure énergétique. Le modèle I/O-vers-énergie est certes une mesure, mais approximative. Pour une puissance mesurée plus précise, brancher Scaphandre (RAPL x86), Kepler (eBPF, compatible ARM) ou Redfish (puissance murale BMC bare-metal), les trois sont supportés en entrée, ou utiliser les APIs énergie du fournisseur cloud. Pour ce qu’une attribution purement logicielle peut et ne peut pas couvrir sur un serveur typique, voir la documentation sur les limites.
✗Pas zéro-config. La détection au niveau protocole exige une instrumentation OTel dans vos apps. Si votre stack n’émet pas de traces, perf-sentinel n’a rien à analyser.
✗Pas un plugin IDE. Pour du feedback in-IDE en JVM/.NET au fil de la frappe, Digma offre une expérience JetBrains bien intégrée.
// licence

AGPL-3.0, ce que ça implique pour votre code

open source

Un résumé pratique et lisible par un service juridique, pour que personne n’ait à fouiller le dépôt. perf-sentinel est sous licence GNU Affero General Public License v3.0.

✓
Vos services restent les vôtres

Faire tourner perf-sentinel ne place pas vos propres services sous AGPL. C’est un processus autonome : vos applications lui envoient seulement des traces OpenTelemetry par le réseau (OTLP), une communication à distance et non un lien de compilation, qui ne crée donc aucune œuvre dérivée et n’impose aucune obligation de licence sur votre code.

✓
Binaires non modifiés, aucune obligation

L’AGPL couvre le code source de perf-sentinel lui-même. Utiliser les binaires ou l’image officiels non modifiés n’entraîne aucune obligation de copyleft, d’aucune sorte.

La seule condition : si vous modifiez perf-sentinel et proposez la version modifiée à des tiers via un réseau, l’article 13 vous oblige à mettre cette source modifiée à disposition de ces utilisateurs. Ceci est un résumé pratique et non un avis juridique. Consultez votre service juridique en cas de doute.

Posez la sentinelle dans votre pipeline

Démo intégrée sans rien installer côté apps, puis quality gate sur traces capturées ou daemon OTLP à côté de votre tracing.

$ perf-sentinel demo # rapport terminal
$ perf-sentinel demo --tui # TUI interactif
$ perf-sentinel demo --html demo.html # dashboard HTML
perf sentinelperf sentinel
GitHub
{{ eyebrowHero }}{{ eyebrowHeroGreen }}

{{ heroTitle }}

{{ heroSub }}

{{ embedCaption }}
{{ prereqTitle }}

{{ prereq1Label }} {{ prereq1Text }}
{{ prereq1Setup }} {{ prereq1Link }}.

{{ prereq2Label }} {{ prereq2Text }} {{ prereq2Link }}.

{{ prereq3Label }} {{ prereq3Text }} {{ prereq3Link }}.

{{ prereq4Label }} {{ prereq4Text }} {{ prereq4Link }}.

{{ whyEyebrow }}

{{ whyT1 }}{{ whyTName }}{{ whyT2 }}

{{ whyP1 }}

{{ whyP2 }}

{{ whyP3 }}

{{ whyP4 }}

{{ carbonEyebrow }}

{{ carbonT1 }}{{ carbonTW }}{{ carbonT2a }}
{{ carbonT2b }}{{ carbonTW2 }}{{ carbonT3 }}

{{ carbonIntro }}

{{ carbonChartTitle }}
5 %4 %3 %2 %1 %0 %
{{ carbonAnnBasse }}
{{ carbonAnnHaute }} {{ carbonAnnHauteSubPre }}{{ carbonAnnHauteQ }})
?
{{ carbonBarBasse }}
{{ carbonBarHaute }}
{{ carbonLegMeasured }}
{{ carbonLegUnmeasured }}
{{ carbonChartSrc }}ITU 2025, IEA 2025, Freitag et al. 2021
{{ carbonNarrTitle }}

{{ carbonNarrText }}

{{ carbonStatNum }}
{{ carbonStatText }}
{{ carbonCmpTitle }}

{{ carbonCmpSub }}

{{ carbonTdEyebrow }}
{{ carbonTdTitle }}
•{{ pt.t }}
{{ carbonResultLabel }}
{{ carbonTdResultA }}{{ carbonTdResultB }}{{ carbonTdResultC }}{{ carbonTdResultD }}.
{{ carbonBuEyebrow }}
{{ carbonBuTitle }}
✓{{ pt.t }}
{{ carbonResultLabel }}
{{ carbonBuResultA }}{{ carbonBuResultB }}{{ carbonBuResultC }}{{ carbonBuResultD }}.
{{ detEyebrow }}

{{ detT1 }}{{ detWAnti }}{{ detT2 }}

{{ detIntro }}

{{ p.n }}
{{ p.name }}
{{ p.trigger }}

{{ detFoot }}

{{ modEyebrow }}

{{ modTitle }}

{{ m.tag }}
{{ m.title }}

{{ m.desc }}
{{ modesMore }} →
{{ perfEyebrow }}

{{ perfT1 }}{{ perfWRust }}{{ perfT2 }}

Rust{{ perfBadge }}

{{ perfIntro }}

{{ s.value }}
{{ s.label }}
{{ perfMore }} →
{{ goEyebrow }}

{{ goT1 }}{{ goWCost }},
{{ goT2 }}{{ goWEnergy }}{{ goT3 }}{{ goWCarbon }}

co2.total = (E × I) + M

{{ goBodyA }}co2.total{{ goBodyB1 }}Software Carbon Intensity v1.0{{ goBodyB2 }}ISO/IEC 21031:2024{{ goBodyB3 }}

{{ g.title }}
{{ g.body }}

{{ goNote }}

{{ goMore }} →
{{ cmpEyebrow }}

{{ cmpT1 }}{{ cmpWCarbon }}

{{ cmpHCap }}
{{ cmpHApm }}
perf-sentinel
{{ c.cap }}
{{ c.apm }}
{{ c.ps }}

{{ cmpFoot }}

{{ cmpMore }} →

{{ cpNotTitle }}

✗{{ n.lead }} {{ n.body }} {{ n.refText }}.
{{ licEyebrow }}

{{ licTitleA }}{{ licTitleB }}

open source

{{ licIntro }}

✓
{{ licC1Title }}

{{ licC1Body }}

✓
{{ licC2Title }}

{{ licC2Body }}

{{ licDisclaimer }}

{{ ctaTitle }}

{{ ctaText }}

$ perf-sentinel demo # {{ demoCmt1 }}
$ perf-sentinel demo --tui # {{ demoCmt2 }}
$ perf-sentinel demo --html demo.html # {{ demoCmt3 }}