nonobis/Heimdall
Watch
1
0
Fork
You've already forked Heimdall
 0
Code Issues 24 Pull requests Projects Releases Packages Activity Actions 1

FEAT: Télémétrie agent — inventaire CPU complet (marque, modèle, cœurs physiques/logiques, fréquence, flags) #82

New issue
Closed
opened 2026-08-12 10:16:25 +02:00 by nonobis · 0 comments
nonobis commented 2026-08-12 10:16:25 +02:00
Owner
Copy link

🎯 Contexte

Objectif : maximum d'informations sur les machines des agents, même dockerisées. Le CPU est la première chose à connaître : marque, modèle exact, nombre de cœurs physiques vs logiques, threads, fréquence, architecture, cache, jeux d'instructions (AVX/AVX2/FMA — importants pour les perfs ONNX Runtime). L'entité Agent ne stocke qu'un CpuCores (int) et le SystemMetricsProvider n'expose pas la topologie.

📚 Référence spec / décision

Décision : inventaire capturé au démarrage de l'agent (et rafraîchi périodiquement), remonté au central, persisté sur l'entité Agent.

  • Sources Linux : /proc/cpuinfo (model name, vendor, physical id, core id, cpu cores, siblings, flags, cpu MHz), /sys/devices/system/cpu/ (topologie), lscpu si dispo
  • Docker : /proc/cpuinfo reflète le host par défaut, MAIS avec --cpuset-cpus seuls les CPUs alloués sont visibles → détecter la limite cgroup (/sys/fs/cgroup/cpu.max v2, cpuset.cpus) et l'exposer séparément des specs host
  • CpuCores (int) → structuré : CpuVendor, CpuModel, CpuArchitecture, PhysicalCores, LogicalCores, ThreadsPerCore, CpuFrequencyMhz, CpuFlags (AVX/AVX2/FMA/AVX512), CpuCacheBytes

🔍 État actuel (vérifié dans le code)

Agent entity : CpuCores (int, mis via UpdateCapabilities) — aucune marque/modèle/fréquence. SystemMetricsProvider.GetCpuCount() compte les lignes cpuN de /proc/stat (logiques), GetCpuUsage utilise ce compte (correct depuis le fix #22). Pas de lecture de /proc/cpuinfo, pas de distinction physique/logique, pas de conscience cgroup/cpuset.

🧩 À faire

  • Collecteur CpuInfoProvider : parse /proc/cpuinfo (vendor, model name, physical id/core id → cœurs physiques vs logiques, flags, MHz), topologie /sys/devices/system/cpu/
  • Détection conteneur : lire /proc/self/cgroup (v2) + /sys/fs/cgroup/cpuset.cpus et cpu.max → exposer ContainerCpuLimit séparé du host
  • Extension entité Agent + migration EF (AddAgentCpuInventory) : champs structurés CPU (voir spec)
  • Heartbeat : transporter l'inventaire CPU (au register + refresh périodique 5 min, pas à chaque tick)
  • UI Admin : afficher marque/modèle/fréquence/cœurs sur la page agent (badge compact + section détail)
  • Tests : parsing cpuinfo (fixture multi-socket, hyperthreading), cgroup v2, fallback non-Linux

🧪 Critères d'acceptation

  • Un agent Intel i5-10600K déclare : vendor GenuineIntel, modèle exact « Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz », 6 physiques / 12 logiques, AVX2 présent
  • En conteneur avec --cpuset-cpus=0-1 : specs host complètes + limite conteneur 2 CPUs exposée distinctement
  • Migration EF appliquée sans casser les agents existants (champs nullable)
  • make test vert

📁 Fichiers concernés

src/Heimdall.Agent/Services/CpuInfoProvider.cs (nouveau), src/Heimdall.Agent/Services/SystemMetricsProvider.cs, src/Heimdall.Agent/Services/AgentRegistrationService.cs (register payload), src/Heimdall.Domain/Entities/Agent.cs, src/Heimdall.Infrastructure/Data/Migrations/, src/Heimdall.Web/Pages/Agents/AgentDetail.razor, tests/

⚠️ Impact

Migration EF + évolution du contrat register/heartbeat (rétrocompatible : champs optionnels).

📝 Notes

Base de la télémétrie : les tickets mémoire/disque/GPU/OS/UI s'appuient sur la même architecture de collecte + remontée + persistance.

## 🎯 Contexte Objectif : **maximum d'informations sur les machines des agents**, même dockerisées. Le CPU est la première chose à connaître : marque, modèle exact, nombre de cœurs **physiques** vs **logiques**, threads, fréquence, architecture, cache, jeux d'instructions (AVX/AVX2/FMA — importants pour les perfs ONNX Runtime). L'entité `Agent` ne stocke qu'un `CpuCores` (int) et le `SystemMetricsProvider` n'expose pas la topologie. ## 📚 Référence spec / décision Décision : inventaire capturé au démarrage de l'agent (et rafraîchi périodiquement), remonté au central, persisté sur l'entité Agent. - Sources Linux : `/proc/cpuinfo` (model name, vendor, physical id, core id, cpu cores, siblings, flags, cpu MHz), `/sys/devices/system/cpu/` (topologie), `lscpu` si dispo - **Docker** : `/proc/cpuinfo` reflète le host par défaut, MAIS avec `--cpuset-cpus` seuls les CPUs alloués sont visibles → détecter la limite cgroup (`/sys/fs/cgroup/cpu.max` v2, `cpuset.cpus`) et l'exposer séparément des specs host - `CpuCores` (int) → structuré : `CpuVendor`, `CpuModel`, `CpuArchitecture`, `PhysicalCores`, `LogicalCores`, `ThreadsPerCore`, `CpuFrequencyMhz`, `CpuFlags` (AVX/AVX2/FMA/AVX512), `CpuCacheBytes` ## 🔍 État actuel (vérifié dans le code) `Agent` entity : `CpuCores` (int, mis via `UpdateCapabilities`) — aucune marque/modèle/fréquence. `SystemMetricsProvider.GetCpuCount()` compte les lignes `cpuN` de `/proc/stat` (logiques), `GetCpuUsage` utilise ce compte (correct depuis le fix #22). Pas de lecture de `/proc/cpuinfo`, pas de distinction physique/logique, pas de conscience cgroup/cpuset. ## 🧩 À faire - [ ] Collecteur `CpuInfoProvider` : parse `/proc/cpuinfo` (vendor, model name, physical id/core id → cœurs physiques vs logiques, flags, MHz), topologie `/sys/devices/system/cpu/` - [ ] Détection conteneur : lire `/proc/self/cgroup` (v2) + `/sys/fs/cgroup/cpuset.cpus` et `cpu.max` → exposer `ContainerCpuLimit` séparé du host - [ ] Extension entité `Agent` + migration EF (`AddAgentCpuInventory`) : champs structurés CPU (voir spec) - [ ] Heartbeat : transporter l'inventaire CPU (au register + refresh périodique 5 min, pas à chaque tick) - [ ] UI Admin : afficher marque/modèle/fréquence/cœurs sur la page agent (badge compact + section détail) - [ ] Tests : parsing cpuinfo (fixture multi-socket, hyperthreading), cgroup v2, fallback non-Linux ## 🧪 Critères d'acceptation - [ ] Un agent Intel i5-10600K déclare : vendor GenuineIntel, modèle exact « Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz », 6 physiques / 12 logiques, AVX2 présent - [ ] En conteneur avec `--cpuset-cpus=0-1` : specs host complètes + limite conteneur 2 CPUs exposée distinctement - [ ] Migration EF appliquée sans casser les agents existants (champs nullable) - [ ] `make test` vert ## 📁 Fichiers concernés src/Heimdall.Agent/Services/CpuInfoProvider.cs (nouveau), src/Heimdall.Agent/Services/SystemMetricsProvider.cs, src/Heimdall.Agent/Services/AgentRegistrationService.cs (register payload), src/Heimdall.Domain/Entities/Agent.cs, src/Heimdall.Infrastructure/Data/Migrations/, src/Heimdall.Web/Pages/Agents/AgentDetail.razor, tests/ ## ⚠️ Impact Migration EF + évolution du contrat register/heartbeat (rétrocompatible : champs optionnels). ## 📝 Notes Base de la télémétrie : les tickets mémoire/disque/GPU/OS/UI s'appuient sur la même architecture de collecte + remontée + persistance.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/migrate-ci-woodpecker
feat/implement-all-5-tickets-complètement
fix/pending-model-changes-warning
feat/131-user-camera-access-entity
feat/11-persons-ui
feat/mobile-feature
feat/134-camera-access-panel-ui
feat/89-confirm-user-email
fix/27-e2e-tests
feat/133-user-camera-access-api
feat/141-camera-access-tests
fix/mobile-ci
feat/110-camera-discovery-ui
feat/136-filter-sites-by-user-access
feat/142-i18n-localization
feat/14-opentelemetry-metrics
feat/59-toggle-camera-status
feat/75-agent-remote-mode
feat/76-agent-gpu-worker
feat/86-agent-inventory-ui
fix/25-readme-update
fix/47-auth-redirect
fix/77-docker-compose-gpu
feat/11-persons-ui-new
feat/88-edit-user-email
fix/ci-infra-heimdall
feat/feat-application-mobile-android-kotlin-jetpack-com
feat/feat-release-notes-automatiques-forgejo-changelog
feat/feat-service-icameraaccessservice-r-solution-des-a
feat/feat-backup-automatis-postgresql-alarik-avec-test-
feat/feat-filtrage-cam-ras-adapter-getcamerasbysite-aux
feat/feat-suppression-de-site-en-cascade-agents-et-cam-
feature/auto-update-docker
feature/auto-update-native
feature/audit-full-coverage
feat/agent-inventory-ui
feat/integration-settings-ui
feat/ntfy-config-complete
feat/agent-gpu-consumer
fix/ci-refonte-politique-143
No results found.
Labels
Clear labels   
bug
Comportement incorrect ou risque fonctionnel

  
chore
Maintenance, dépendances, CI, outillage

  
design
Ticket avec composante UI — maquette the-designer requise/intégrée

  
dx:ci

   
dx:database

   
dx:dotnet

   
dx:infra

   
dx:security

   
dx:tests

   
dx:ui

   
etape-1
Étape 1 — MVP Multi-Site (phases 1-12)

  
etape-2
Étape 2 — Caméras + Temps réel (phases 13-14)

  
etape-3
Étape 3 — Vidéo + IA (phases 15-16)

  
etape-4
Étape 4 — Événements + Notifications (phases 17-19)

  
etape-5
Étape 5 — UI Blazor complète (phases 20-23)

  
etape-6
Étape 6 — Production Hardening (phase 24)

  
etape-7
Étape 7 — Mobile (phase 25)

  
feature
Nouvelle fonctionnalité / implémentation spec manquante

  
priority-high
Priorité haute — bloque le cœur métier

  
priority-low
Priorité faible / cosmétique

  
priority-medium
Priorité moyenne

  
security
Vulnérabilités CVE, scans Trivy/OWASP, security hardening

  
spec
Référence à MASTER_SPECIFICATION.md

  
tech-debt
Dette technique, obsolescence, drift documentation

No labels
bug
chore
design
dx:ci
dx:database
dx:dotnet
dx:infra
dx:security
dx:tests
dx:ui
etape-1
etape-2
etape-3
etape-4
etape-5
etape-6
etape-7
feature
priority-high
priority-low
priority-medium
security
spec
tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
nonobis/Heimdall#82
No description provided.