disk collection into metrics.js (#11) #18

Closed

maximus wants to merge 0 commits from issue-11-extract-metrics into main

maximus commented

2026-08-16 15:30:45 +00:00

Owner

Quoi

Sort la collecte CPU / RAM / disque de index.js vers un module metrics.js autonome. index.js ne garde que le routage, l'auth, le check Logto et la lecture des rapports Defenseurs.

metrics.js expose getCpuPercent, getDisk, collectMetrics (readProcStat reste prive — detail d'implementation Linux-only).
collectMetrics() retourne la tranche { cpu, memory, disk } du payload ; getHealth() la spread pour preserver l'ordre des cles.
Dockerfile : COPY package.json index.js metrics.js ./.

Pourquoi

Point de bissection avant le refactor de routage qui suit, et prealable au partage de la collecte avec le futur agent local. Aucun changement de comportement attendu : /health repond champ pour champ a l'identique.

Ce qui a ete verifie

Parite de champs : nouveau test qui verrouille l'ordre exact des cles de premier niveau (timestamp, hostname, uptime, cpu, memory, disk, logto) et les cles imbriquees de cpu / memory / disk / logto. Le spread ...metrics conserve l'ordre d'insertion, donc le JSON serialise est identique.
Concurrence preservee : getHealth() garde Promise.all([collectMetrics(), getLogtoHealth()]). L'echantillon CPU de 500 ms est le seul await de collectMetrics(), donc le check Logto demarre bien en parallele. getDisk() (execSync bloquant) est appele apres cet await pour ne pas retarder le fetch Logto.
Garde de latence : /health doit repondre sous 1,5 s avec un Logto stubbe a 1200 ms. Mesure : 1223 ms.
Mutation test : en serialisant temporairement (await collectMetrics(); await getLogtoHealth();), le test de latence echoue a 1743 ms — pendant que le test de parite de champs, lui, passe toujours. C'est exactement le point aveugle signale dans le caveat TECHNIQUE de l'issue : une comparaison de champs seule ne verrait pas la serialisation. Mutation annulee ensuite.
Dockerfile : le COPY ne listait que package.json index.js. Sans l'ajout de metrics.js, le conteneur planterait au demarrage en prod sur un MODULE_NOT_FOUND invisible en local.
Requires morts retires de index.js : execSync et delay n'etaient utilises que par le code extrait. Runtime toujours 0-dependance (HTTP natif Node ; vitest en devDep uniquement).
npm test : 20/20 — les 14 tests de findings.test.js sont inchanges, 6 nouveaux dans __tests__/health.test.js.

A savoir pour le merge

Ce service n'a pas d'auto-deploy (source_id=null, cf. la-compagnie-maximus#133). Le merge ne redeploie rien : il faut le trigger manuel Coolify documente dans CLAUDE.md. Le changement de Dockerfile ne prend donc effet qu'au prochain redeploy — et c'est a ce moment-la que son absence aurait casse la prod.

Hors perimetre strict de l'issue

CLAUDE.md mis a jour : compte de tests (14 -> 20, ventile par fichier) et deux gotchas (le COPY explicite du Dockerfile, l'invariant du Promise.all). La ligne « 14 cas » serait devenue fausse. Aucun impact runtime.

Resolves #11

Generated autonomously by /autopilot run of 2026-08-16

## Quoi Sort la collecte CPU / RAM / disque de `index.js` vers un module `metrics.js` autonome. `index.js` ne garde que le routage, l'auth, le check Logto et la lecture des rapports Defenseurs. - `metrics.js` expose `getCpuPercent`, `getDisk`, `collectMetrics` (`readProcStat` reste prive — detail d'implementation Linux-only). - `collectMetrics()` retourne la tranche `{ cpu, memory, disk }` du payload ; `getHealth()` la spread pour preserver l'ordre des cles. - `Dockerfile` : `COPY package.json index.js metrics.js ./`. ## Pourquoi Point de bissection avant le refactor de routage qui suit, et prealable au partage de la collecte avec le futur agent local. **Aucun changement de comportement attendu** : `/health` repond champ pour champ a l'identique. ## Ce qui a ete verifie - **Parite de champs** : nouveau test qui verrouille l'ordre exact des cles de premier niveau (`timestamp, hostname, uptime, cpu, memory, disk, logto`) et les cles imbriquees de `cpu` / `memory` / `disk` / `logto`. Le spread `...metrics` conserve l'ordre d'insertion, donc le JSON serialise est identique. - **Concurrence preservee** : `getHealth()` garde `Promise.all([collectMetrics(), getLogtoHealth()])`. L'echantillon CPU de 500 ms est le seul `await` de `collectMetrics()`, donc le check Logto demarre bien en parallele. `getDisk()` (execSync bloquant) est appele apres cet await pour ne pas retarder le fetch Logto. - **Garde de latence** : `/health` doit repondre sous 1,5 s avec un Logto stubbe a 1200 ms. Mesure : **1223 ms**. - **Mutation test** : en serialisant temporairement (`await collectMetrics(); await getLogtoHealth();`), le test de latence echoue a **1743 ms** — pendant que le test de parite de champs, lui, passe toujours. C'est exactement le point aveugle signale dans le caveat TECHNIQUE de l'issue : une comparaison de champs seule ne verrait pas la serialisation. Mutation annulee ensuite. - **Dockerfile** : le `COPY` ne listait que `package.json index.js`. Sans l'ajout de `metrics.js`, le conteneur planterait au demarrage en prod sur un `MODULE_NOT_FOUND` invisible en local. - **Requires morts retires** de `index.js` : `execSync` et `delay` n'etaient utilises que par le code extrait. Runtime toujours 0-dependance (HTTP natif Node ; vitest en devDep uniquement). - **`npm test` : 20/20** — les 14 tests de `findings.test.js` sont inchanges, 6 nouveaux dans `__tests__/health.test.js`. ## A savoir pour le merge Ce service n'a **pas d'auto-deploy** (`source_id=null`, cf. la-compagnie-maximus#133). Le merge ne redeploie rien : il faut le trigger manuel Coolify documente dans `CLAUDE.md`. Le changement de Dockerfile ne prend donc effet qu'au prochain redeploy — et c'est a ce moment-la que son absence aurait casse la prod. ## Hors perimetre strict de l'issue `CLAUDE.md` mis a jour : compte de tests (14 -> 20, ventile par fichier) et deux gotchas (le `COPY` explicite du Dockerfile, l'invariant du `Promise.all`). La ligne « 14 cas » serait devenue fausse. Aucun impact runtime. Resolves #11 --- Generated autonomously by /autopilot run of 2026-08-16

maximus added 1 commit 2026-08-16 15:30:45 +00:00

refactor: extract CPU/RAM/disk collection into metrics.js 79cb813767

Move readProcStat, getCpuPercent, getDisk and the cpu/memory/disk payload
assembly out of index.js into a standalone metrics.js, so the upcoming
local workstation agent can reuse the same collection code. No behaviour
change: /health returns the exact same fields, in the same order.

Notes:
- collectMetrics() returns the { cpu, memory, disk } slice; getHealth()
  spreads it, keeping the JSON key order the admin dashboard relies on.
- getHealth() keeps Promise.all([collectMetrics(), getLogtoHealth()]).
  The 500ms CPU sample and the 3s Logto check are deliberately concurrent;
  serializing them would push the p99 of /health to ~3.5s.
- collectMetrics() awaits the CPU sample as its only await, so callers
  running it inside a Promise.all keep their concurrency.
- Dockerfile COPY lists files one by one, so metrics.js had to be added
  there or the container would crash on MODULE_NOT_FOUND at startup.
- New __tests__/health.test.js: metrics.js exports, field-for-field
  payload shape, and a latency guard (<1.5s with a 1200ms stubbed Logto).
  Verified by mutation: serializing the two calls fails the latency test
  at ~1743ms while the field comparison still passes.
- Runtime stays 0-dependency; the 14 existing tests are untouched.

Resolves #11

maximus added the

autopilot:pending-human

label 2026-08-16 15:30:57 +00:00

maximus referenced this pull request

2026-08-16 15:36:41 +00:00

test(auth): cover the 401 gate on all four read routes (#12) #19

maximus commented

2026-08-16 18:11:00 +00:00

Author

Owner

Verdict : APPROVE

Refactor a comportement constant, avec le seul piege reel du lot correctement attrape : le COPY du Dockerfile.

Verifie

Ordre des cles preserve : ...metrics etale cpu, memory, disk entre uptime et logto. Le JSON serialise est identique champ pour champ.
Concurrence preservee : Promise.all([collectMetrics(), getLogtoHealth()]) maintenu, garde de latence en place, et le mutation test decrit dans le corps de la PR est la bonne facon de prouver que la garde discrimine vraiment.
Dockerfile : COPY package.json index.js metrics.js ./. Sans ca, MODULE_NOT_FOUND au demarrage en prod, invisible en local — d'autant plus que ce service n'a pas d'auto-deploy et que la casse ne serait apparue qu'au prochain redeploy manuel.
Requires morts : execSync et delay retires ; os, path et les helpers fs restent utilises.
Aucune touche au routage ni a l'auth.

Suggestions (non bloquantes)

Le placement de getDisk() change legerement le comportement, et la justification du corps de PR decrit l'inverse. Sur main, getDisk() (execSync("df -k /"), bloquant) tournait apres le Promise.all, donc apres la reponse Logto. Il tourne maintenant dans collectMetrics() juste apres l'await CPU — sa fenetre de blocage chevauche donc le fetch Logto en vol. Le wall-clock total est egal ou meilleur, donc rien a corriger dans le code ; mais « appele apres cet await pour ne pas retarder le fetch Logto » dit le contraire de ce que fait ce placement : apres l'await est precisement le moment ou le fetch Logto est en vol. A corriger dans le raisonnement, pas dans le code.
Marge du test de latence un peu juste : 1223 ms mesures contre une borne a 1500 ms, soit 277 ms de tete sur une machine potentiellement chargee. Le pouvoir discriminant est reel (serialise = ~1700 ms), mais un stub a 1300-1400 ms elargirait l'ecart sans rien couter.
test("exposes getCpuPercent, getDisk and collectMetrics") — trois typeof, valeur quasi nulle. Inoffensif.

Revue adversariale — chaine #18 -> #22 revue maillon par maillon contre sa propre base.

## Verdict : APPROVE Refactor a comportement constant, avec le seul piege reel du lot correctement attrape : le `COPY` du Dockerfile. ### Verifie - **Ordre des cles preserve** : `...metrics` etale `cpu, memory, disk` entre `uptime` et `logto`. Le JSON serialise est identique champ pour champ. - **Concurrence preservee** : `Promise.all([collectMetrics(), getLogtoHealth()])` maintenu, garde de latence en place, et le mutation test decrit dans le corps de la PR est la bonne facon de prouver que la garde discrimine vraiment. - **Dockerfile** : `COPY package.json index.js metrics.js ./`. Sans ca, `MODULE_NOT_FOUND` au demarrage en prod, invisible en local — d'autant plus que ce service n'a pas d'auto-deploy et que la casse ne serait apparue qu'au prochain redeploy manuel. - **Requires morts** : `execSync` et `delay` retires ; `os`, `path` et les helpers `fs` restent utilises. - Aucune touche au routage ni a l'auth. ### Suggestions (non bloquantes) 1. **Le placement de `getDisk()` change legerement le comportement, et la justification du corps de PR decrit l'inverse.** Sur `main`, `getDisk()` (`execSync("df -k /")`, bloquant) tournait *apres* le `Promise.all`, donc apres la reponse Logto. Il tourne maintenant dans `collectMetrics()` juste apres l'await CPU — sa fenetre de blocage chevauche donc le fetch Logto en vol. Le wall-clock total est egal ou meilleur, donc rien a corriger dans le code ; mais « appele apres cet await pour ne pas retarder le fetch Logto » dit le contraire de ce que fait ce placement : apres l'await est precisement le moment ou le fetch Logto *est* en vol. A corriger dans le raisonnement, pas dans le code. 2. **Marge du test de latence un peu juste** : 1223 ms mesures contre une borne a 1500 ms, soit 277 ms de tete sur une machine potentiellement chargee. Le pouvoir discriminant est reel (serialise = ~1700 ms), mais un stub a 1300-1400 ms elargirait l'ecart sans rien couter. 3. `test("exposes getCpuPercent, getDisk and collectMetrics")` — trois `typeof`, valeur quasi nulle. Inoffensif. --- *Revue adversariale — chaine #18 -> #22 revue maillon par maillon contre sa propre base.*

maximus commented

2026-08-16 18:27:37 +00:00

Author

Owner

Mergee localement sur main en fast-forward (pile chainee : l API de merge Forgejo ne peut pas traiter une pile dont la base n est pas main). Tip integre : e181a96. Forgejo ne detecte pas un merge ff local, donc cette PR est fermee a la main — le code EST sur main.

Mergee localement sur `main` en fast-forward (pile chainee : l API de merge Forgejo ne peut pas traiter une pile dont la base n est pas `main`). Tip integre : `e181a96`. Forgejo ne detecte pas un merge ff local, donc cette PR est fermee a la main — le code EST sur `main`.

maximus closed this pull request

2026-08-16 18:27:37 +00:00