Dashboards livrés¶
PerfShop livre 10 dashboards Grafana organisés en deux dossiers — Élèves (5 dashboards en accès anonyme) et Formateurs (5 dashboards Admin-only). Cette page liste chaque dashboard, son UID, sa cible, sa datasource principale et tous ses panels, lus directement dans les fichiers JSON sources.
Source de vérité
Tous les titres de panels, UIDs et datasources de cette page sont extraits programmatiquement des fichiers grafana/dashboards/eleves/*.json et grafana/dashboards/formateurs/*.json. Aucun titre n'est paraphrasé : il s'agit du libellé exact tel qu'affiché à l'utilisateur.
Tableau récapitulatif¶
| Dossier | Fichier | UID | Datasource(s) principale(s) | Panels |
|---|---|---|---|---|
| Élèves | dashboard-apm-eleve.json |
perfshop-apm-eleve |
Prometheus + Tempo + Pyroscope | 22 |
| Élèves | dashboard-backend-eleve.json |
perfshop-backend-eleve |
Prometheus | 19 |
| Élèves | dashboard-frontend-eleve.json |
perfshop-frontend-eleve |
Prometheus | 23 |
| Élèves | dashboard-jmeter.json |
perfshop-jmeter-live |
Prometheus + Loki | 22 |
| Élèves | dashboard-logs-eleve.json |
perfshop-logs-eleve |
Loki | 9 |
| Formateurs | dashboard-apm-formateur.json |
perfshop-apm-formateur |
Prometheus + Tempo + Pyroscope | 23 |
| Formateurs | dashboard-backend-formateur.json |
perfshop-backend-formateur |
Prometheus | 27 |
| Formateurs | dashboard-frontend-formateur.json |
perfshop-frontend-formateur |
Prometheus | 28 |
| Formateurs | dashboard-logs-formateur.json |
perfshop-logs-formateur |
Loki | 12 |
| Formateurs | perfshop-general-v1.json |
perfshop-general-v1 |
Prometheus (job docker) | 16 |
Total : 201 panels sur 10 dashboards. Le dashboard perfshop-general-v1 est configuré comme dashboard home par le seed Grafana — c'est ce que voient les utilisateurs anonymes en arrivant sur l'URL Grafana sans préciser de chemin.
Dossier Élèves¶
perfshop-apm-eleve — APM Élève (Traces + Latences)¶
Cible : un étudiant qui veut comprendre les latences globales du backend, observer les traces récentes, et explorer un flamegraph CPU.
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 | Vue d'ensemble — Santé de l'application | Traces reçues / min (stat) · Latence P95 — toutes routes (stat) · Taux d'erreur HTTP 5xx (stat) · Heap JVM utilisée (stat) |
| 2 | Latences — Observer les dégradations | Latence P50 / P95 / P99 — toutes routes (timeseries) |
| 3 | Traces — Rechercher les anomalies | Guide pédagogique (text) · Erreurs HTTP 5xx (dernière heure) (stat) · Opérations instrumentées (stat) · Latence max observée (stat) · « Boîte à outils TraceQL » (text) · Traces récentes — cliquer sur un Trace ID pour explorer (table TraceQL {}) |
| 4 | JVM — Mémoire & Threads | Heap JVM — Used / Max (timeseries) · Threads JVM — live / daemon (timeseries) |
| 5 | Profiling CPU — Flamegraphs Pyroscope | Guide pédagogique (text) · CPU Flamegraph — Linux (perf_event) (flamegraph) · CPU Flamegraph — Docker Desktop / Windows / macOS (itimer) (flamegraph) · Lock Contention Flamegraph — verrous JVM (A8 Race Condition) (flamegraph) |
Particularité pédagogique : deux panels flamegraph CPU coexistent — l'un utilise perf_event (qui marche sur les hôtes Linux natifs) et l'autre itimer (qui marche sur Docker Desktop). L'un sera vide selon l'environnement, mais l'étudiant peut les voir tous les deux et comprendre la différence.
Datasource Pyroscope utilisée pour les flamegraphs ; Tempo pour la table TraceQL ; Prometheus pour tout le reste.
perfshop-backend-eleve — Backend Élève (Analyse)¶
Cible : un étudiant qui veut comprendre la santé du backend Spring Boot — CPU, JVM, threads, BDD, latences HTTP.
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 | Indicateurs temps réel | CPU Application (stat) · Mémoire JVM (stat) · Threads JVM (stat) · Connexions BDD actives (stat) · Threads HTTP occupés (stat) · Temps réponse p99 (stat) |
| 2 | Métriques applicatives | CPU — Container application (timeseries) · Heap JVM — usage vs maximum (timeseries) · Threads HTTP Tomcat — occupés vs maximum (timeseries) · GC — Temps de pause (timeseries) · Connexions BDD — état du pool HikariCP (timeseries) · Temps d'acquisition connexion BDD (ms) (timeseries) · Débit requêtes HTTP — 2xx / 5xx (timeseries) · Temps de réponse HTTP — p50 / p95 / p99 (timeseries) · Latence /api/products — p50 / p95 / p99 (timeseries) · Erreurs HTTP /api/products (timeseries) · GC — Fréquence des collections (timeseries) · Threads JVM — états (timeseries) |
Datasource unique : Prometheus.
Métriques mobilisées (toutes vues dans prometheus.md) : docker_container_cpu_percent, jvm_memory_used_bytes, jvm_memory_max_bytes, jvm_threads_live_threads, jvm_threads_states_threads, hikaricp_connections_*, tomcat_threads_*, http_server_requests_seconds_*, jvm_gc_pause_seconds_*.
perfshop-frontend-eleve — Frontend Élève (Analyse)¶
Cible : un étudiant qui veut observer l'impact d'un chaos sur le frontend — à la fois côté container nginx et côté navigateur (Web Vitals).
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 | Container Nginx | CPU Container · RAM Container · RAM % · Réseau IN · Réseau OUT · Processus (6 stats) |
| 2 | Navigateur client — Performance JS | FPS · Heap JS · Long Tasks/s · Requêtes fetch/s · Noeuds DOM · Requêtes fetch/s (6 stats — Web Vitals poussés par chaos-agent.js) |
| 3 | CPU Worker & Fraîcheur des métriques | CPU Worker actif (stat) · Âge métriques client (s) (stat) · Requêtes fetch/s — évolution (timeseries) |
| 4 | Graphiques temporels — Container | CPU — Container Nginx · RAM — usage vs limite · Réseau IN / OUT (octets/s) · I/O Disque (octets/s) (4 timeseries) |
| 5 | Graphiques temporels — Navigateur JS | FPS (images par seconde) · Heap JS utilisé (Mo) · Long Tasks par seconde (tâches >50ms) · Requêtes fetch lancées (req/s) · Noeuds DOM · Réseau OUT container (octets/s) (6 timeseries) |
Particularité : ce dashboard mélange deux familles de métriques très différentes — les docker_container_* (job perfshop-docker, scrape périodique) et les perfshop_client_* (poussées en temps réel par chaos-agent.js depuis le navigateur de l'étudiant). Voir dashboard-html.md pour le détail du flux client → backend → Prometheus.
Datasource unique : Prometheus.
perfshop-jmeter-live — JMeter Load Test¶
Cible : un étudiant qui lance un tir JMeter via perfshop-jmeter-ui et veut suivre son tir en temps réel ainsi que l'impact sur le backend.
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 | JMeter — Vue d'ensemble tir en cours | vUsers actifs · Transactions/s · Taux d'erreur % · P95 (ms) · Total échantillons · Temps moyen (ms) (6 stats) |
| 2 | Temps de réponse | Latence P50 / P95 / P99 / Moy (ms) · Latence P95 / P99 par label (sampler) (2 timeseries) |
| 3 | Débit & Erreurs | Transactions/s (succès + erreurs) · Taux succès / erreur % (par label) · Transactions/s par label (sampler) · Transactions cumulées par label (3 timeseries + 1 bargauge) |
| 4 | Utilisateurs virtuels (threads) | Threads actifs / démarrés / terminés · Échantillons cumulés (total) (2 timeseries) |
| 5 | Corrélation Backend PerfShop (JVM + Spring Boot) | Heap JVM backend (utilisé / max) · Taux erreurs HTTP backend (4xx / 5xx) · Latence backend P50 / P95 / P99 (Spring Boot) · Threads JVM (daemon / non-daemon) · CPU backend (process) · Latence backend par endpoint (P95) (6 timeseries) |
| 6 | Logs — JMeter & JMeter UI | Logs — perfshop-jmeter (tirs JMeter) (logs Loki) · Logs — perfshop-jmeter-ui (Node.js API) (logs Loki) |
Particularité : c'est le seul dashboard Élève qui mixe trois sources — Prometheus (métriques jmeter_* et métriques backend), Loki (logs JMeter et JMeter UI). Il sert à corréler en temps réel : « mon tir applique 200 vUsers → quel impact sur le heap JVM et le pool HikariCP ? ».
Datasource Loki sur les deux derniers panels via les sélecteurs {container="perfshop-jmeter"} et {container="perfshop-jmeter-ui"}.
perfshop-logs-eleve — Logs Élève (Filtré)¶
Cible : un étudiant qui veut lire les logs du backend, les erreurs, et les logs du frontend nginx et de la BDD — avec un filtrage qui exclut les logs internes du moteur chaos (pour ne pas spoiler ce qui se passe sous le capot).
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 | Logs Backend Spring Boot | Logs Application — Backend Spring Boot (logs Loki, filtre exclusion [BusinessChaos], [BackendChaos], [SecurityChaos], [ChaosInterceptor], [FrontendChaos], [ChaosScripting], chaos_intensity) |
| 2 | Erreurs & Exceptions | Erreurs backend uniquement (ERROR / Exception) (logs Loki, mêmes exclusions + |= "ERROR") |
| 3 | Logs Frontend & Base de données | Logs Nginx — Accès HTTP Frontend (logs Loki) · Logs MySQL — Base de données (logs Loki, filtre exclusion [note]) |
| 4 | Analyse — Volume & tendances | Volume de logs par niveau (hors chaos) (timeseries — count_over_time avec exclusion chaos pour ERROR/WARN/INFO) · Erreurs HTTP Nginx (4xx / 5xx) (timeseries — count_over_time \| " 4" et \| " 5") |
Stratégie d'exclusion : la requête LogQL utilise plusieurs != pour cacher tous les logs internes du moteur de chaos. C'est volontaire — l'étudiant doit pouvoir observer l'impact (exception, latence) sans voir les détails d'implémentation. Les formateurs ont leur propre dashboard logs sans ces exclusions.
Datasource unique : Loki.
Dossier Formateurs¶
perfshop-apm-formateur — APM Formateur (Tempo + Pyroscope)¶
Cible : un formateur qui veut investiguer en profondeur — TraceQL avancé, panels par type d'exception, capture des headers admin.
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 | Traces Distribuées — Tempo | Traces / min · Latence P95 — /api/orders · Erreurs HTTP 5xx (traces) · Niveau Chaos Fonctionnel · JVM Heap utilisée · Erreurs HTTP 5xx (5 min) · F4 — Corruptions silencieuses (5 min) (7 stats) |
| 2 | Latences & Taux d'erreur — Spanmetrics (Tempo → Prometheus) | Latence P50 / P95 / P99 — toutes routes (timeseries) · Taux d'erreur par opération (timeseries) |
| 3 | Explorateur de Traces — Tempo | Traces avec déclenchement admin — X-Admin-Token capturé (table TraceQL {span.http.request.header.x-admin-token != ""}) · Traces SQL instrumentées — requêtes JDBC capturées (S1 SQLi) (table TraceQL {span.db.statement != ""}) · F1 — Traces NullPointerException (niveau 1+) (TraceQL {span.exception.type="NullPointerException"}) · F2 — Traces StackOverflowError (niveau 2+) (TraceQL {span.exception.type="StackOverflowError"}) · F3 — Traces OutOfMemoryError (niveau 3+) (TraceQL {span.exception.type="OutOfMemoryError"}) · Traces récentes — toutes (filtrables par service/opération) (TraceQL {}) |
| 4 | Profiling Continu — Pyroscope (Flamegraphs) | CPU Flamegraph — Linux (perf_event) · CPU Flamegraph — Docker Desktop / Windows / macOS (itimer) · Lock Contention Flamegraph — verrous JVM (A8 Race Condition) · Heap Flamegraph — allocations mémoire (F3-OOM) (4 flamegraphs) |
| 5 | JVM Détail — Mémoire / Threads / GC | Heap JVM — Used / Committed / Max (timeseries) · Threads JVM — live / daemon / peak (timeseries) |
Particularité : c'est le dashboard le plus puissant — il combine TraceQL avancé (filtrage par type d'exception, par header HTTP, par statement SQL), flamegraphs Pyroscope (4 vues différentes dont une heap pour traquer les fuites), et les spanmetrics générées par Tempo (metrics_generator qui pousse les latences agrégées dans Prometheus).
Le panel Traces avec déclenchement admin mérite une attention particulière : grâce à Dotel.instrumentation.http.capture-headers.server.request=X-Admin-Token, l'agent OpenTelemetry capture la valeur du header X-Admin-Token dans chaque span. Le formateur peut ainsi voir quelles requêtes ont été déclenchées par un appel admin authentifié — utile pour auditer une démonstration.
perfshop-backend-formateur — Backend Formateur (Analyse)¶
Cible : version étendue du dashboard Backend Élève, avec des sections supplémentaires sur l'état des chaos.
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 | Indicateurs temps réel | Identique au dashboard Élève (6 stats) |
| 2 | Métriques applicatives | Identique au dashboard Élève (12 timeseries) |
| 3 | État des Chaos — Formateur | Intensité des anomalies chaos (bargauge) · Évolution temporelle des anomalies chaos (timeseries multi-séries chaos_intensity{type="cpu|memory|thread_pool|db_pool|slow_query|deadlock|network"}) |
| 4 | Chaos Scripting — Activité HTTP (section repère, pas de panel dédié) | — |
| 5 | Security Chaos — Activité OWASP | Requêtes Security Chaos par type (timeseries rate(...uri=~".*/api/security.*"), rate(...uri=~".*/api/chaos.*")) · Activité Checkout & Auth — Endpoints soumis au Chaos Scripting (timeseries rate(...uri=~".*/api/auth.*"), rate(...uri=~".*/api/checkout.*\|.*/api/orders.*"), rate(...status=~"4..")) · Taux erreurs 4xx (tokens rejetés) (stat) · Latence p99 Checkout (stat histogram_quantile(0.99, ...uri=~".*/api/checkout.*\|.*/api/orders.*")) · Taux succès HTTP (%) (stat) |
Datasource unique : Prometheus.
Particularité : la section « État des chaos » expose la gauge custom chaos_intensity{type=...} déclarée par le service ChaosService du backend. Le formateur voit ainsi en un coup d'œil quels chaos sont actifs et à quelle intensité.
perfshop-frontend-formateur — Frontend Formateur (Analyse)¶
Cible : version étendue du dashboard Frontend Élève, avec des sections supplémentaires sur la corrélation Frontend Chaos.
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 à 5 | (Identiques au dashboard Élève) | 23 panels reproduits à l'identique |
| 6 | Frontend Chaos — État & Impact | CPU Worker actif (stat) · Fetch flood — req/s client (stat) · FPS navigateur (stat) · Âge métriques client (s) (stat) · Corrélation — FPS, Fetch flood, CPU Worker, Long Tasks (timeseries multi-séries) |
| 7 | Impact détaillé — Dégradation observée | FPS vs Long Tasks — Dégradation UI (CPU chaos) (timeseries) · Fetch flood vs Heap JS — Corrélation (fetch + memory chaos) (timeseries) |
Particularité : les deux panels finaux de la section 7 sont des panels de corrélation qui superposent plusieurs métriques navigateur pour montrer l'effet d'un chaos frontend sur les Web Vitals. Quand le chaos CPU Worker est actif, le formateur voit instantanément les FPS chuter et les Long Tasks exploser sur le même graphe.
perfshop-logs-formateur — Logs Formateur (Complet)¶
Cible : un formateur qui veut tout voir — les logs internes du moteur chaos sont inclus ici, contrairement au dashboard Élève.
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 | Recherche & Filtres | Logs Backend Spring Boot — Complet (formateur) (logs Loki {container="perfshop-app"} \| logfmt) |
| 2 | Logs Chaos — Backend | Logs BusinessChaos (Métier A1-A16) uniquement (\|= "[BusinessChaos]") · Logs BackendChaos (Infra : CPU/Mémoire/Pool/Réseau) uniquement (\|= "[BackendChaos]") · Logs SecurityChaos uniquement (\|= "[SecurityChaos]") · Logs ChaosInterceptor — Sessions (\|= "[ChaosInterceptor]") |
| 3 | Logs Frontend & BDD | Logs Nginx — Frontend · Logs MySQL — Base de données |
| 4 | Volume & Taux d'erreurs | Volume de logs par niveau (backend) (timeseries — sum by (level)(count_over_time({container="perfshop-app"} \| logfmt \| level="ERROR" [1m])), idem pour WARN et INFO) · Volume logs chaos (BusinessChaos + BackendChaos + SecurityChaos) (timeseries — count_over_time séparé par préfixe [BusinessChaos], [BackendChaos], [SecurityChaos], [ChaosInterceptor]) |
Datasource unique : Loki.
Stratégie LogQL : chaque famille de chaos préfixe ses logs avec un tag entre crochets. Le filtre |= "[BusinessChaos]" ne fait remonter que les logs émis par BusinessChaosService. Pour la décomposition par niveau (ERROR/WARN/INFO), on utilise le parser logfmt qui extrait le label level directement depuis la ligne JSON Spring Boot.
perfshop-general-v1 — Vue Générale Containers (dashboard home)¶
Cible : tous — c'est le dashboard home configuré par le seed Grafana via PATCH /api/org/preferences {"homeDashboardUID":"perfshop-general-v1"}. Tout visiteur arrivant sur l'URL Grafana sans préciser de chemin atterrit ici.
Sections et panels :
| # | Section | Panels |
|---|---|---|
| 1 | Vue d'ensemble globale | CPU Total (stat sum(docker_container_cpu_percent)) · RAM Totale (stat sum(docker_container_mem_usage_bytes)) · Réseau IN Total (stat sum(rate(docker_container_net_rx_bytes[1m]))) · Réseau OUT Total (stat sum(rate(docker_container_net_tx_bytes[1m]))) |
| 2 | Comparatif tous les containers | CPU % — tous les containers (timeseries docker_container_cpu_percent) · RAM — tous les containers (timeseries docker_container_mem_usage_bytes) · Réseau IN — tous les containers · Réseau OUT — tous les containers · I/O Disque Lecture — tous · I/O Disque Écriture — tous (6 timeseries) |
| 3 | Bargauges comparatifs | CPU % — comparatif instantané (bargauge) · RAM % — comparatif instantané (bargauge) |
| 4 | Table récapitulative | État de tous les containers (table avec cpu_percent, mem_percent, mem_usage_bytes) |
Datasource unique : Prometheus, job perfshop-docker exclusivement.
Particularité : c'est un dashboard placé dans le dossier Formateurs, mais qui utilise uniquement les métriques docker_container_* (donc pas de panels JVM, pas de panels HTTP). C'est volontaire — la version « générale » se concentre sur l'infrastructure et l'état des containers, sans descendre dans le détail applicatif.
Containers visibles
Comme expliqué dans prometheus.md, seuls quatre containers sont surveillés par le service perfshop-monitoring qui produit les métriques docker_container_* : perfshop-frontend, perfshop-app, perfshop-db, perfshop-monitoring. Les autres services de la stack (Grafana, Loki, Tempo, Squash TM, etc.) n'apparaissent pas sur ce dashboard. C'est cohérent avec l'usage pédagogique : on surveille la chaîne front → back → BDD pendant les démos chaos, pas la stack d'observabilité elle-même.
Comment ajouter ou modifier un dashboard¶
Les dashboards livrés sont rechargés toutes les 10 secondes par Grafana (updateIntervalSeconds: 10 dans dashboards.yml). Trois façons de les modifier :
| Approche | Quand ? | Inconvénient |
|---|---|---|
| Édition directe en UI Grafana | Test rapide, exploration | Écrasé toutes les 10 s par le contenu du fichier JSON |
| Édition du fichier JSON puis copie dans le bind mount | Développement | Nécessite de connaître la structure JSON Grafana |
| Export depuis l'UI puis remplacement du fichier | Modification durable | Le JSON exporté contient des clés UI inutiles à nettoyer |
Pour ajouter un nouveau dashboard livré, déposer un fichier JSON dans grafana/dashboards/eleves/ ou grafana/dashboards/formateurs/ selon la cible. Grafana le détectera dans les 10 secondes suivantes, sans redémarrage du container.
Pour aller plus loin¶
- Vue d'ensemble — flux global d'observabilité et corrélations
- Grafana — datasources, ACL, accès anonyme
- Prometheus — métriques scrapées et exemples PromQL
- Loki — pipelines de logs et exemples LogQL
- Tempo — traces et
metrics_generator - Pyroscope — flamegraphs CPU / heap / lock