217 lines
6.4 KiB
Markdown
217 lines
6.4 KiB
Markdown
|
||
# 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.
|