6.4 KiB
Executable File
6.4 KiB
Executable File
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.shdans 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.shpour :- 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
- Stabiliser MVP (Phase 1 + tests fichier 09)
- UX de base + tri / filtre (Phase 2)
- Graphes d’historique (Phase 3)
- Détection régressions + petites alertes (Phase 4)
- Intégrations Home Assistant / Prometheus (Phase 5)
- Support multi-OS (Phase 6)
- 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.