Extraire la collecte de metriques vers metrics.js #11

New issue

Closed

opened 2026-08-15 20:09:17 +00:00 by maximus · 0 comments

maximus commented

2026-08-15 20:09:17 +00:00

Owner

Sortir la collecte CPU / RAM / disque de index.js vers un module metrics.js partage entre le serveur et le futur agent local. Aucun changement de comportement attendu : cette issue est le point de bissection avant le refactor de routage qui suit.

Fichiers concernes

metrics.js (creer)
index.js (modifier)
Dockerfile (modifier)

Depends on

aucune

Criteres d'acceptation

metrics.js expose getCpuPercent, getDisk, collectMetrics ; getHealth() s'appuie dessus
Le COPY du Dockerfile inclut metrics.js — il ne copie aujourd'hui que package.json index.js, et l'oublier fait planter le conteneur au demarrage
getHealth() conserve Promise.all([collectMetrics(), getLogtoHealth()])
GET /health repond champ pour champ a l'identique avant et apres
GET /health repond sous ~1,5 s avec un Logto lent simule
npm test passe (14 tests existants inchanges)

Review caveats

TECHNIQUE (MEDIUM) : l'echantillon CPU de 500 ms et le controle Logto de 3 s sont deliberement concurrents (index.js:215-218, commentaire d'avertissement a index.js:58-59). Une extraction naive les serialise et fait grimper le p99 de /health jusqu'a 3 s. Une comparaison de champs seule ne verrait rien : d'ou l'assertion de latence.

Decisions prises en planification

Issue volontairement isolee et sans changement de comportement : le service n'a pas d'auto-deploy et sert un dashboard en production, il faut pouvoir bissecter si quelque chose casse apres le redeploy manuel.

Spec source

la-compagnie-maximus/spec-plan-monitoring-postes.md + spec-decisions-monitoring-postes.md (depot different : ce body est auto-suffisant, ne pas compter sur le fichier) (Issue 1)

Sortir la collecte CPU / RAM / disque de `index.js` vers un module `metrics.js` partage entre le serveur et le futur agent local. Aucun changement de comportement attendu : cette issue est le point de bissection avant le refactor de routage qui suit. ## Fichiers concernes - `metrics.js` (creer) - `index.js` (modifier) - `Dockerfile` (modifier) ## Depends on - aucune ## Criteres d'acceptation - [ ] `metrics.js` expose `getCpuPercent`, `getDisk`, `collectMetrics` ; `getHealth()` s'appuie dessus - [ ] Le `COPY` du Dockerfile inclut `metrics.js` — il ne copie aujourd'hui que `package.json index.js`, et l'oublier fait planter le conteneur au demarrage - [ ] `getHealth()` conserve `Promise.all([collectMetrics(), getLogtoHealth()])` - [ ] `GET /health` repond champ pour champ a l'identique avant et apres - [ ] `GET /health` repond sous ~1,5 s avec un Logto lent simule - [ ] `npm test` passe (14 tests existants inchanges) ## Review caveats - TECHNIQUE (MEDIUM) : l'echantillon CPU de 500 ms et le controle Logto de 3 s sont deliberement concurrents (`index.js:215-218`, commentaire d'avertissement a `index.js:58-59`). Une extraction naive les serialise et fait grimper le p99 de `/health` jusqu'a 3 s. Une comparaison de champs seule ne verrait rien : d'ou l'assertion de latence. ## Decisions prises en planification - Issue volontairement isolee et sans changement de comportement : le service n'a pas d'auto-deploy et sert un dashboard en production, il faut pouvoir bissecter si quelque chose casse apres le redeploy manuel. ## Spec source la-compagnie-maximus/spec-plan-monitoring-postes.md + spec-decisions-monitoring-postes.md (depot different : ce body est auto-suffisant, ne pas compter sur le fichier) (Issue 1)