bench_go/prompt_bench_client.md

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