maj
This commit is contained in:
216
docs/10_roadmap_evolutions.md
Normal file
216
docs/10_roadmap_evolutions.md
Normal file
@@ -0,0 +1,216 @@
|
||||
|
||||
# 10 – Roadmap & évolutions futures pour Linux BenchTools
|
||||
|
||||
Objectif : lister les évolutions possibles de l’application, organisées par phases, avec une vision
|
||||
à court, moyen et long terme. Ce fichier sert de base pour prioriser les développements.
|
||||
|
||||
---
|
||||
|
||||
# 1. Vision globale
|
||||
|
||||
Linux BenchTools doit évoluer depuis un simple serveur de benchmarks centralisés vers :
|
||||
|
||||
- Un **inventaire matériel dynamique** de ton parc.
|
||||
- Un **historique de performance** exploitable (avant/après upgrade, changement de config, etc.).
|
||||
- Un **outil d’aide à la décision** (quelle machine est la plus adaptée pour tel usage).
|
||||
- Un **hub de diagnostics** (détection de régression de perf, disques fragiles, réseau bridé…).
|
||||
|
||||
---
|
||||
|
||||
# 2. Phase 1 – MVP (déjà spécifiée dans les fichiers 01 → 09)
|
||||
|
||||
Fonctionnalités :
|
||||
|
||||
- Réception de benchmarks via `bench.sh`
|
||||
- Stockage dans SQLite
|
||||
- Dashboard avec classement des machines
|
||||
- Détail device + historique de benchmarks
|
||||
- Liens constructeur
|
||||
- Upload de documents (PDF, images)
|
||||
- Script d’installation (Docker / compose)
|
||||
|
||||
Objectif :
|
||||
Avoir une base utilisable **en production perso** sur ton infra maison.
|
||||
|
||||
---
|
||||
|
||||
# 3. Phase 2 – Améliorations UX & stabilité
|
||||
|
||||
## 3.1. Frontend
|
||||
|
||||
- Tri avancé sur les colonnes (score, date dernier bench, hostname).
|
||||
- Filtre par tags, type de machine (bare-metal / VM / SBC).
|
||||
- Ajout d’icônes simples (type machine, OS, réseau 1G/2.5G/10G…).
|
||||
- Page “Benchmarks” globale (tous les benchmarks, filtrables par device).
|
||||
|
||||
## 3.2. Backend
|
||||
|
||||
- Meilleure gestion des erreurs côté API (messages clairs, codes cohérents).
|
||||
- Pagination plus fine (page_size configurable).
|
||||
- Logging structuré (JSON logs optionnels).
|
||||
- Limitation taille payload JSON (protection simple).
|
||||
|
||||
## 3.3. Script client
|
||||
|
||||
- Mode “dry-run” (afficher JSON sans l’envoyer).
|
||||
- Mode “debug” (log détaillé des commandes).
|
||||
|
||||
---
|
||||
|
||||
# 4. Phase 3 – Historisation avancée & graphes
|
||||
|
||||
## 4.1. Graphes dans la WebUI
|
||||
|
||||
- Sur page device :
|
||||
- Graphique du **global_score** sur le temps.
|
||||
- Graphiques séparés :
|
||||
- CPU score vs temps
|
||||
- Mémoire score vs temps
|
||||
- Disque score vs temps
|
||||
- Réseau score vs temps
|
||||
- Lib JS possible :
|
||||
- Chart.js ou ECharts (simple, self-hosté).
|
||||
|
||||
## 4.2. Comparaison de benchmarks
|
||||
|
||||
- Comparer 2 benchmarks d’un même device :
|
||||
- Afficher les différences (avant/après ajout RAM, changement SSD…).
|
||||
- Comparer 2 devices :
|
||||
- Table des scores côte-à-côte.
|
||||
- Exemple d’usage :
|
||||
- “Quelle machine est la meilleure candidate pour un nouveau service Docker ?”
|
||||
|
||||
---
|
||||
|
||||
# 5. Phase 4 – Détection de régressions & alertes
|
||||
|
||||
## 5.1. Détection automatique
|
||||
|
||||
- Calcul d’un “baseline” par device :
|
||||
- par exemple moyenne des N meilleurs scores.
|
||||
- Lors d’un nouveau bench :
|
||||
- si le score est inférieur de X% à la baseline → marquer en **WARNING**.
|
||||
- Indicateurs :
|
||||
- CPU plus lent
|
||||
- Disque sensiblement plus lent (fragilité SSD/HDD)
|
||||
- Réseau plus lent (câble / switch / config ?)
|
||||
|
||||
## 5.2. Alertes
|
||||
|
||||
- Marquage visuel dans la WebUI (icône warning).
|
||||
- Export JSON ou webhook Webhook simple :
|
||||
- POST vers un endpoint externe (ex: Home Assistant, Node-RED, etc.)
|
||||
- Intégration possible :
|
||||
- Appel HTTP vers Home Assistant pour créer une notification.
|
||||
|
||||
---
|
||||
|
||||
# 6. Phase 5 – Intégrations externes
|
||||
|
||||
## 6.1. Intégration Gitea / Git
|
||||
|
||||
- Stocker le dépôt `bench.sh` dans une forge (déjà le cas).
|
||||
- Ajouter :
|
||||
- Liens vers la version exacte du script qui a généré tel bench.
|
||||
- Option :
|
||||
- Webhook Gitea → déclencher bench sur un device après un changement de config.
|
||||
|
||||
## 6.2. Intégration Home Assistant
|
||||
|
||||
- Exposer certains indicateurs via une API ou MQTT :
|
||||
- Dernier score par device
|
||||
- Warn/alert sur régression
|
||||
- Dashboard HA :
|
||||
- Carte des machines avec état “OK / Warning / Error”.
|
||||
|
||||
## 6.3. Intégration Prometheus / Grafana (option)
|
||||
|
||||
- Exporter métriques (nombre de devices, benchs, scores moyens) via `/metrics`.
|
||||
- Visualisation dans Grafana.
|
||||
|
||||
---
|
||||
|
||||
# 7. Phase 6 – Extensions techniques
|
||||
|
||||
## 7.1. Support multi-OS
|
||||
|
||||
- Extension `bench.sh` pour :
|
||||
- Linux non-Debian (Arch, Fedora)
|
||||
- macOS (optionnel)
|
||||
- Windows (PowerShell script séparé)
|
||||
|
||||
## 7.2. Agents “semi-persistants”
|
||||
|
||||
- Mode où un service systemd sur certains serveurs :
|
||||
- exécute un bench toutes les X semaines.
|
||||
- envoie automatiquement les données au backend.
|
||||
|
||||
## 7.3. Export / Import
|
||||
|
||||
- Export complet de :
|
||||
- devices
|
||||
- benchmarks
|
||||
- hardware_snapshots
|
||||
- Formats :
|
||||
- JSON
|
||||
- CSV (pour certains tableaux)
|
||||
- Import depuis un ancien fichier → migration facile vers nouvelle instance.
|
||||
|
||||
---
|
||||
|
||||
# 8. Phase 7 – UX & ergonomie avancées
|
||||
|
||||
- Tags et “groupes” de devices (ex: “serveurs prod”, “lab”, “RPi”, “Proxmox nodes”).
|
||||
- Vues filtrées :
|
||||
- Vue “serveurs”
|
||||
- Vue “VM Proxmox”
|
||||
- Vue “SBC (RPi, OPi, etc.)”
|
||||
- Possibilité de nommer des “profils” :
|
||||
- ex: “Profil NVR”, “Profil VM/Proxmox”, “Profil PC Gaming”
|
||||
- et voir les devices qui matchent le mieux chaque profil en fonction de leur score.
|
||||
|
||||
---
|
||||
|
||||
# 9. Idées long terme (si tu veux pousser très loin)
|
||||
|
||||
- Auto-détection hardware via une petite API agent qui tourne sur les machines en continu (au-delà du script ponctuel).
|
||||
- Benchmark réseau multi-nœuds :
|
||||
- topologie logical de ton réseau
|
||||
- latences et débits entre plusieurs points.
|
||||
- Vue “Carte du réseau” :
|
||||
- affichage graphique des performances entre différentes machines.
|
||||
- Plugins :
|
||||
- Ajouter une API plugin pour créer ses propres tests (ex: bench spécifique Docker, base de données, etc.).
|
||||
|
||||
---
|
||||
|
||||
# 10. Priorisation suggérée
|
||||
|
||||
1. **Stabiliser MVP** (Phase 1 + tests fichier 09)
|
||||
2. UX de base + tri / filtre (Phase 2)
|
||||
3. Graphes d’historique (Phase 3)
|
||||
4. Détection régressions + petites alertes (Phase 4)
|
||||
5. Intégrations Home Assistant / Prometheus (Phase 5)
|
||||
6. Support multi-OS (Phase 6)
|
||||
7. Développements avancés (Phase 7+8)
|
||||
|
||||
---
|
||||
|
||||
# 11. TODO résumé par phase
|
||||
|
||||
- Phase 1 :
|
||||
- Implémenter API, DB, bench.sh, WebUI minimal, Docker, install.sh
|
||||
- Phase 2 :
|
||||
- Tri, filtres, ergonomie
|
||||
- Phase 3 :
|
||||
- Graphes (global_score, composantes)
|
||||
- Phase 4 :
|
||||
- Baselines, détection de régression, marquage visuel
|
||||
- Phase 5 :
|
||||
- Webhooks / MQTT / intégration HA
|
||||
- Phase 6 :
|
||||
- Scripts bench pour autres OS
|
||||
- Phase 7 :
|
||||
- Vues avancées, cartes réseau, plugins
|
||||
|
||||
Ce document pourra servir de base à un Kanban (Gitea, Kanboard, etc.) en créant une tâche par élément de la roadmap.
|
||||
Reference in New Issue
Block a user