226 lines
4.2 KiB
Markdown
226 lines
4.2 KiB
Markdown
# PROMPT — Bench Client Linux (binaire Go / Rust)
|
||
|
||
## 🎯 Objectif
|
||
|
||
Concevoir un **programme binaire autonome** nommé `bench-client`, exécuté sur des machines **Linux x86\_64**, destiné à collecter des informations système, exécuter des benchmarks contrôlés, produire un JSON structuré et l’envoyer à un backend HTTP.
|
||
|
||
Ce programme **remplace un script Bash complexe** et est piloté par un **fichier de configuration YAML distant**.
|
||
|
||
---
|
||
|
||
## 🧠 Rôle attendu
|
||
|
||
Tu es un **développeur système senior (Linux / Go ou Rust)**. Tu dois produire un binaire **robuste, lisible, extensible**, orienté production.
|
||
|
||
---
|
||
|
||
## 🖥️ Environnement cible
|
||
|
||
- OS : Linux (Debian, Ubuntu, Proxmox VE, dérivés)
|
||
- Arch : x86\_64
|
||
- Lancement : `sudo ./bench-client`
|
||
- Langage : **Go (priorité)** ou **Rust**
|
||
- Binaire déjà compilé (aucune compilation sur la machine cible)
|
||
- Pas de dépendances runtime externes (hors outils système)
|
||
|
||
---
|
||
|
||
## 🧩 Déploiement (hors programme)
|
||
|
||
Un script shell externe (déjà existant) :
|
||
|
||
1. installe les outils système requis
|
||
2. télécharge le binaire
|
||
3. télécharge `config.yaml` depuis un serveur HTTP
|
||
4. exporte `API_TOKEN`
|
||
5. exécute `bench-client`
|
||
|
||
Le **binaire ne gère PAS l’installation**.
|
||
|
||
---
|
||
|
||
## ⚙️ Configuration distante (OBLIGATOIRE)
|
||
|
||
Le programme doit charger un fichier `config.yaml` distant qui pilote :
|
||
|
||
- les sections actives/inactives
|
||
- les outils à utiliser
|
||
- les paramètres des benchmarks
|
||
- les limites de sécurité
|
||
- les pondérations du score
|
||
- l’URL du backend
|
||
|
||
### Contraintes
|
||
|
||
- Le token **NE DOIT PAS** être dans la config
|
||
- Le token est fourni via `API_TOKEN`
|
||
- La config distante doit être :
|
||
- validée
|
||
- bornée (timeouts, tailles max)
|
||
- mise en cache localement
|
||
- utilisable en fallback si HTTP indisponible
|
||
|
||
---
|
||
|
||
## 🏗️ Architecture interne
|
||
|
||
### Core
|
||
|
||
- parsing des arguments :
|
||
- `--config-url`
|
||
- `--debug`
|
||
- `--dry-run`
|
||
- chargement config YAML
|
||
- validation des paramètres
|
||
- orchestration des collecteurs
|
||
|
||
---
|
||
|
||
### Collecteurs (pattern obligatoire)
|
||
|
||
Chaque collecteur implémente :
|
||
|
||
- `Check()` → outil présent / droits OK
|
||
- `Run(ctx)` → exécution avec timeout
|
||
- `Parse(output)` → données structurées
|
||
- `Raw()` → sortie brute optionnelle
|
||
|
||
Les collecteurs doivent être **indépendants**.
|
||
|
||
---
|
||
|
||
## 🔧 Outils systèmes à piloter
|
||
|
||
### Informations système
|
||
|
||
- `lscpu`
|
||
- `free`
|
||
- `lsblk`
|
||
- `ip`
|
||
- `dmidecode` (root)
|
||
- `lspci`
|
||
- `lsusb`
|
||
- `ethtool` (root)
|
||
- `iw`
|
||
- `smartctl` (root)
|
||
- `aplay`, `arecord`, `pactl`
|
||
- `systemd-detect-virt`
|
||
- `pveversion`
|
||
- `xrandr`, `xdpyinfo`, `swaymsg`
|
||
|
||
### Benchmarks
|
||
|
||
- `sysbench cpu`
|
||
- `sysbench memory`
|
||
- `fio` (non destructif)
|
||
- `iperf3 -J`
|
||
|
||
Si un outil est absent :
|
||
|
||
- afficher WARN
|
||
- continuer l’exécution
|
||
|
||
---
|
||
|
||
## 📊 Benchmarks
|
||
|
||
- CPU : sysbench single + multi
|
||
- RAM : sysbench memory
|
||
- Disque : fio randrw
|
||
- Réseau : iperf3 bidirectionnel JSON
|
||
- GPU : placeholder (désactivé par défaut)
|
||
|
||
### Pondérations par défaut
|
||
|
||
- CPU : 40 %
|
||
- RAM : 20 %
|
||
- Disque : 20 %
|
||
- Réseau : 10 %
|
||
- GPU : 10 %
|
||
|
||
Tous les benchmarks doivent :
|
||
|
||
- avoir un timeout
|
||
- être annulables via context
|
||
- afficher une progression CLI
|
||
|
||
---
|
||
|
||
## 🖨️ Sortie CLI (temps réel)
|
||
|
||
Le programme doit afficher :
|
||
|
||
- progression globale `[step/total]`
|
||
- état : OK / WARN / ERROR
|
||
- logs en direct des benchmarks
|
||
- couleurs ANSI si TTY
|
||
- mode `--debug` :
|
||
- commandes exécutées
|
||
- sorties brutes
|
||
- JSON sauvegardé dans `/tmp`
|
||
|
||
Exemple :
|
||
|
||
```
|
||
[3/8] CPU : lscpu… OK (12C / 24T)
|
||
[6/8] Disk bench : fio… OK (R=520MB/s W=480MB/s)
|
||
```
|
||
|
||
---
|
||
|
||
## 📦 JSON final
|
||
|
||
Le JSON généré doit contenir :
|
||
|
||
- `device_identifier`
|
||
- `bench_client_version`
|
||
- `hardware`
|
||
- cpu
|
||
- ram
|
||
- gpu
|
||
- storage
|
||
- network
|
||
- audio
|
||
- motherboard
|
||
- os
|
||
- `results`
|
||
- cpu
|
||
- memory
|
||
- disk
|
||
- network
|
||
- gpu
|
||
- global\_score
|
||
- `raw_info` (si debug activé)
|
||
|
||
Le JSON est :
|
||
|
||
- validé
|
||
- envoyé via HTTP POST
|
||
- header :
|
||
```
|
||
Authorization: Bearer $API_TOKEN
|
||
```
|
||
|
||
---
|
||
|
||
## 🔐 Sécurité
|
||
|
||
- aucun benchmark destructif
|
||
- timeouts stricts
|
||
- limites configurables
|
||
- pas de commandes arbitraires
|
||
- pas de secrets dans le binaire
|
||
|
||
---
|
||
|
||
## 🎯 Résultat attendu
|
||
|
||
Un **bench-client binaire** :
|
||
|
||
- stable
|
||
- lisible
|
||
- extensible
|
||
- piloté par config distante
|
||
- capable de remplacer totalement le script Bash existant
|
||
|