Session 1 — Calibrage CPU Chaos & Refonte Monitoring¶

Durée : ~6 heures
Objectif initial : Créer 3 dashboards Grafana + restructurer le monitoring en 3 tabs
Objectif final : Calibrage complet du chaos CPU + dashboards Grafana + préparation refonte monitoring

🎯 Réalisations¶

1. Dashboards Grafana (3 créés)¶

Temps : ~1h30

✅ backend-springboot.json¶

6 sections thématiques (Mémoire JVM, CPU, Threads, BDD, HTTP, Chaos)
15+ panels avec métriques Prometheus
Bargauges anomalies chaos + évolution temporelle
Difficulté : ⭐⭐ Simple - Structure connue

✅ frontend-container.json¶

Focus perfshop-frontend + section tous containers
Métriques Docker (CPU %, RAM, réseau, I/O)
Bargauges comparatifs
Difficulté : ⭐ Très simple - Métriques Docker standardisées

✅ perfshop-general-v1.json¶

Vue d'ensemble multi-containers
Stats globales + comparatifs + table récapitulative
Difficulté : ⭐⭐ Simple - Agrégation métriques

2. Restructuration Monitoring UI¶

Temps : ~2h

Architecture 3 tabs¶

Tab Backend : 6 stats + 5 graphiques + chaos grid (7 anomalies)
Tab Frontend : 6 stats Docker + 4 graphiques + chaos grid (4 anomalies)
Tab Vue Générale : 4 stats globales + 4 graphiques multi-containers

Ajouts notables¶

Status banners avec résumé anomalies actives
Contrôles période (Temps Réel / Période Personnalisée)
Bouton Pause/Resume par tab
Liens Grafana dynamiques
Descriptions détaillées des 11 anomalies chaos

Difficulté : ⭐⭐⭐ Moyenne - Beaucoup de HTML/CSS/JS, gestion états multiples

3. Calibrage CPU Chaos Backend¶

Temps : ~2h30 (le plus long !)

Problématique initiale¶

CPU chaos existant ne montrait aucun impact sur les métriques
Cause : Dépendait des requêtes HTTP (interceptor) → trop peu de trafic
4 req/min seulement → CPU quasi à 0%

Tentatives successives¶

Tentative 1 : Augmenter itérations SHA-256 dans interceptor
❌ Échec : Bloque les requêtes HTTP, saturation mais trafic s'effondre
Difficulté : ⭐⭐⭐⭐

Tentative 2 : Créer CpuChaosScheduler avec boucle fibonacci
❌ Échec : JIT HotSpot optimise complètement → 10M itérations = 0ms
Difficulté : ⭐⭐⭐⭐⭐ - Très difficile, problème d'optimisation compilateur

Tentative 3 : Scheduler avec mesure temporelle (boucle while jusqu'à X ms)
❌ Échec : Tourne pendant 5 secondes au lieu de 90ms → 1 cycle toutes les 5s
Difficulté : ⭐⭐⭐⭐

Tentative 4 : SHA-256 avec salage (empêche cache JIT)
✅ SUCCÈS : Scheduler toutes les 100ms avec vraie charge CPU
Difficulté : ⭐⭐⭐ Moyenne - Une fois la bonne approche trouvée

Calibration finale¶

Formule : intensity * 3_200 iterations SHA-256
Résultat : 50% slider = 50% CPU, 100% = 100% CPU
Validation : docker stats confirme les valeurs

Moment clé : Comprendre que process_cpu_usage (métrique JVM) ≠ charge CPU réelle du container

4. Correction Métriques Prometheus¶

Temps : ~30 min

Problèmes identifiés¶

process_cpu_usage montre 7-9% alors que container = 50-100% CPU réel
Spring Boot 3.2 n'expose PAS tomcat_threads_* → expose executor_*

Solutions¶

Utiliser docker_container_cpu_percent{container="perfshop-app"} partout
Remplacer panels Tomcat par executor_active_threads{name="applicationTaskExecutor"}
Dashboard Grafana corrigé

Difficulté : ⭐⭐ Simple une fois le problème identifié

🎢 Chronologie Détaillée¶

Heure 1-2 : Démarrage Fluide ✅¶

Création dashboards Grafana
Restructuration monitoring 3 tabs
Tout fonctionne du premier coup
Ressenti : 🟢 Productif, cadre clair

Heure 3 : Première Difficulté 🟡¶

CPU chaos ne fonctionne pas
Diagnostic : dépend du trafic HTTP
Tentative 1 : Augmenter itérations → bloque requêtes
Ressenti : 🟡 Patience requise, debugging actif

Heure 4 : Blocage JIT 🔴¶

Création scheduler avec fibonacci
Logs montrent 10M iterations en 0ms
JIT HotSpot optimise complètement la boucle
Ressenti : 🔴 Frustration, problème inattendu

Heure 5 : Percée SHA-256 🟢¶

Changement d'approche : opérations cryptographiques
SHA-256 avec salage → le JIT ne peut pas optimiser
Premier succès : CPU monte à 100% !
Ressenti : 🟢 Soulagement, momentum retrouvé

Heure 6 : Calibration & Corrections 🟢¶

Ajustement formule (3_500 → 3_200 iterations)
Tests 50%, 75%, 100% → validation OK
Correction métriques Prometheus
Création documentation multi-sessions
Ressenti : 🟢 Satisfaction, objectif atteint

🧠 Moments Clés d'Apprentissage¶

1. JIT HotSpot est TRÈS intelligent¶

Le compilateur Java optimise agressivement. Une boucle mathématique pure (fibonacci, factorielle) sera réduite à quasi-rien.
Solution : Opérations cryptographiques (SHA-256) que le JIT ne peut pas éliminer.

2. Métriques JVM ≠ Métriques Container¶

process_cpu_usage mesure uniquement le thread principal JVM, pas les threads @Scheduled en background.
Solution : Toujours utiliser docker_container_cpu_percent pour le CPU réel.

3. Spring Boot 3.2 a changé les métriques¶

Migration de tomcat_threads_* vers executor_* pour les thread pools.
Leçon : Toujours vérifier les métriques exposées via /actuator/prometheus avant de créer des dashboards.

4. Calibration empirique > théorique¶

Impossible de calculer à l'avance combien d'itérations SHA-256 donnent X% CPU.
Méthode : Version debug avec logs, ajustement progressif (10k → 100k → 1M → 350k).

5. Context Pack pour sessions longues¶

Un projet complexe nécessite un système de documentation pour préserver le contexte entre sessions.
Solution : ARCHITECTURE.md + ROADMAP.md + fichiers specs détaillés.

📊 Métriques de la Session¶

Métrique	Valeur
Durée totale	~6 heures
Fichiers créés	12
Fichiers modifiés	5
Lignes de code	~800 (Java + JS + JSON)
Dashboards Grafana	3
Anomalies testées	2 (CPU, Mémoire)
Tentatives échecs CPU	4
Bugs corrigés	3
Documentation produite	4 fichiers MD (2000+ lignes)

🎯 Difficultés Rencontrées¶

🔴 Très Difficile (⭐⭐⭐⭐⭐)¶

Problème : JIT HotSpot optimise fibonacci → 10M iterations = 0ms
Temps perdu : ~45 min
Solution : Passer à SHA-256 avec salage
Leçon : Tester empiriquement, ne pas assumer le comportement du compilateur

🟡 Difficile (⭐⭐⭐⭐)¶

Problème : Boucle temporelle tourne 5s au lieu de 90ms
Temps perdu : ~30 min
Solution : Réduire drastiquement les iterations, passer à 100ms interval
Leçon : Mesurer le temps réel d'exécution avant de calibrer

🟢 Moyen (⭐⭐⭐)¶

Problème : process_cpu_usage vs docker_container_cpu_percent
Temps perdu : ~20 min
Solution : Lire la doc Spring Boot Actuator + tester avec curl
Leçon : Toujours vérifier la source des métriques Prometheus

✅ Ce Qui a Bien Fonctionné¶

Vibe Coding Efficace¶

Itérations rapides : Test → Log → Ajustement → Redéploiement en <5 min
Debugging progressif : Logs stratégiques (System.out.println, log.info) pour comprendre
Validation terrain : docker stats comme source de vérité, pas les métriques

Communication Clara¶

Questions précises : "Montre-moi les logs", "Quel est le résultat de cette commande ?"
Partage d'écran mental : Description exacte de ce qui est vu (oscillation 0-100%)
Feedback immédiat : "Ça monte à 55% au lieu de 50%" → calibration fine

Documentation Proactive¶

Création du Context Pack pendant la session, pas après
Résumé des décisions techniques au fil de l'eau
Template SESSION pour faciliter les futures sessions

🎓 Conclusion¶

Cette session de 6 heures en vibe coding a permis de :

✅ Créer une infrastructure monitoring complète (3 dashboards Grafana + UI 3 tabs)
✅ Résoudre un problème technique complexe (calibrage CPU chaos)
✅ Poser les bases pour 10+ sessions futures (Context Pack)
✅ Apprendre des leçons précieuses sur JIT, métriques Prometheus, et debugging

Ratio temps productif / temps total : ~85%
Objectifs atteints : 100% (+ bonus : documentation multi-sessions)

Le vibe coding a particulièrement brillé lors du debugging CPU chaos : itérations rapides, tests empiriques, ajustements fins. La clé du succès : ne jamais assumer, toujours mesurer.¶

🤖 Erreurs imputables à Claude AI — Session 1¶

Auto-critique honnête des mauvaises suggestions et diagnostics incomplets.

❌ Erreur #1 — Proposition Fibonacci sans vérification JIT¶

Ce que j'ai proposé : Créer un CpuChaosScheduler avec boucle fibonacci (intensity * 100_000 iterations) pour consommer du CPU proportionnellement à l'intensité.

Ce qui s'est passé : Le code compilait parfaitement, les logs montraient "10M iterations" exécutées. Mais le CPU restait à 0-1% dans docker stats. Le JIT HotSpot avait complètement optimisé la boucle.

Pourquoi c'était une erreur : J'aurais dû avertir immédiatement des risques d'optimisation JIT pour les boucles mathématiques pures, et proposer d'emblée SHA-256 ou une opération non-optimisable comme alternative.

Temps perdu : ~45 min | Sévérité : ⭐⭐⭐⭐⭐ Critique

❌ Erreur #2 — Formule temporelle sans calibration préalable¶

Ce que j'ai proposé : Une boucle while (System.nanoTime() < endTime) avec endTime = now + (intensity * 900_000L) nanos pour occuper exactement X% du temps CPU.

Ce qui s'est passé : La boucle tournait pendant 5 secondes au lieu de 90ms. Le scheduler s'exécutait 1 fois toutes les 5 secondes au lieu de ~10 fois par seconde.

Pourquoi c'était une erreur : Proposer une formule théorique sans aucune validation empirique préalable. J'aurais dû demander une version "calibration" d'abord.

Temps perdu : ~30 min | Sévérité : ⭐⭐⭐⭐ Élevée

❌ Erreur #3 — Dashboard Grafana avec métriques non vérifiées¶

Ce que j'ai proposé : Des panels Grafana utilisant tomcat_threads_busy_threads, tomcat_threads_config_max_threads, tomcat_threads_current_threads.

Ce qui s'est passé : Panels en "No data". Spring Boot 3.2 n'expose PAS ces métriques Tomcat — il expose executor_* à la place.

Pourquoi c'était une erreur : Créer un dashboard de 10+ panels basé sur des hypothèses non vérifiées. J'aurais dû demander un curl /actuator/prometheus | grep -E 'tomcat|executor' avant.

Temps perdu : ~20 min | Sévérité : ⭐⭐⭐ Moyenne

❌ Erreur #4 — Utilisation de `process_cpu_usage` sans clarification¶

Ce que j'ai proposé : process_cpu_usage comme métrique CPU de référence dans le monitoring et Grafana.

Ce qui s'est passé : Affichait 7-9% alors que docker stats montrait 50-100% réel. La métrique ne compte que le thread principal JVM, pas les threads @Scheduled en background.

Pourquoi c'était une erreur : Utiliser cette métrique sans expliquer ses limites. La différence JVM thread vs container total est fondamentale dans ce contexte de chaos CPU.

Temps perdu : ~20 min | Sévérité : ⭐⭐⭐ Moyenne

❌ Erreur #5 — Augmentation itérations interceptor sans analyse d'impact¶

Ce que j'ai proposé : Augmenter massivement les itérations SHA-256 dans ChaosInterceptor (de 10k à 10M) pour rendre le chaos visible.

Ce qui s'est passé : Requêtes HTTP complètement bloquées, trafic effondré de 4 req/min à ~0. Le chaos saturait le CPU mais rendait l'application inutilisable.

Pourquoi c'était une erreur : Proposer un "quick fix" sans analyser que l'interceptor bloque les threads HTTP. La bonne solution immédiate : un @Scheduled indépendant du trafic.

Temps perdu : ~15 min | Sévérité : ⭐⭐⭐⭐ Élevée

❌ Erreur #6 — Iterations trop élevées sans test progressif¶

Ce que j'ai proposé : intensity * 10_000 iterations SHA-256 dans le scheduler (soit 1M iterations à 100% intensity).

Ce qui s'est passé : Le scheduler s'exécutait avec un intervalle de 50 secondes au lieu de 100ms — les iterations prenaient trop de temps, bloquant le cycle suivant.

Pourquoi c'était une erreur : Proposer un multiplicateur arbitraire sans validation empirique. Violation du principe "test progressif".

Temps perdu : ~25 min | Sévérité : ⭐⭐⭐⭐ Élevée

❌ Erreur #7 — Pas de version debug/calibration proposée en premier¶

Ce que j'ai proposé : Directement le code "production" de CpuChaosScheduler avec la formule finale.

Ce qui s'est passé : Plusieurs cycles d'ajustements nécessaires (10k → 100k → 500k → 3500 → 3200).

Pourquoi c'était une erreur : J'aurais dû proposer d'abord une version de calibration avec logs de durée réelle, puis calculer la formule à partir des mesures.

Temps perdu : ~40 min | Sévérité : ⭐⭐⭐⭐ Élevée

📊 Récapitulatif Session 1¶

#	Erreur	Temps perdu	Sévérité	Catégorie
1	Fibonacci sans vérification JIT	~45 min	⭐⭐⭐⭐⭐	Connaissance technique
2	Formule temporelle non calibrée	~30 min	⭐⭐⭐⭐	Méthodologie
3	Métriques Grafana non vérifiées	~20 min	⭐⭐⭐	Hypothèse environnement
4	`process_cpu_usage` sans clarification	~20 min	⭐⭐⭐	Documentation
5	Augmentation interceptor sans analyse	~15 min	⭐⭐⭐⭐	Analyse impact
6	Iterations trop élevées sans test	~25 min	⭐⭐⭐⭐	Test progressif
7	Pas de version calibration d'abord	~40 min	⭐⭐⭐⭐	Méthodologie
	TOTAL	~3h15

Pattern : Syndrome du "Fix Théorique Sans Validation Empirique" — proposer des solutions basées sur des hypothèses non vérifiées sur l'environnement réel (JIT HotSpot, métriques Spring Boot 3.2, Docker).

Session 1 — Calibrage CPU Chaos & Refonte Monitoring¶

🎯 Réalisations¶

1. Dashboards Grafana (3 créés)¶

✅ backend-springboot.json¶

✅ frontend-container.json¶

✅ perfshop-general-v1.json¶

2. Restructuration Monitoring UI¶

Architecture 3 tabs¶

Ajouts notables¶

3. Calibrage CPU Chaos Backend¶

Problématique initiale¶

Tentatives successives¶

Calibration finale¶

4. Correction Métriques Prometheus¶

Problèmes identifiés¶

Solutions¶

🎢 Chronologie Détaillée¶

Heure 1-2 : Démarrage Fluide ✅¶

Heure 3 : Première Difficulté 🟡¶

Heure 4 : Blocage JIT 🔴¶

Heure 5 : Percée SHA-256 🟢¶

Heure 6 : Calibration & Corrections 🟢¶

🧠 Moments Clés d'Apprentissage¶

1. JIT HotSpot est TRÈS intelligent¶

2. Métriques JVM ≠ Métriques Container¶

3. Spring Boot 3.2 a changé les métriques¶

4. Calibration empirique > théorique¶

5. Context Pack pour sessions longues¶

📊 Métriques de la Session¶

🎯 Difficultés Rencontrées¶

🔴 Très Difficile (⭐⭐⭐⭐⭐)¶

🟡 Difficile (⭐⭐⭐⭐)¶

🟢 Moyen (⭐⭐⭐)¶

✅ Ce Qui a Bien Fonctionné¶

Vibe Coding Efficace¶

Communication Clara¶

Documentation Proactive¶

🎓 Conclusion¶

Le vibe coding a particulièrement brillé lors du debugging CPU chaos : itérations rapides, tests empiriques, ajustements fins. La clé du succès : ne jamais assumer, toujours mesurer.¶

🤖 Erreurs imputables à Claude AI — Session 1¶

❌ Erreur #1 — Proposition Fibonacci sans vérification JIT¶

❌ Erreur #2 — Formule temporelle sans calibration préalable¶

❌ Erreur #3 — Dashboard Grafana avec métriques non vérifiées¶

❌ Erreur #4 — Utilisation de process_cpu_usage sans clarification¶

❌ Erreur #5 — Augmentation itérations interceptor sans analyse d'impact¶

❌ Erreur #6 — Iterations trop élevées sans test progressif¶

❌ Erreur #7 — Pas de version debug/calibration proposée en premier¶

📊 Récapitulatif Session 1¶

❌ Erreur #4 — Utilisation de `process_cpu_usage` sans clarification¶