Rassemble Glowroot APM, PostgreSQL (CloudNativePG), Kubernetes et Victoria
Metrics derrière vingt et un outils orientés question. Le but n'est pas
d'exposer des API mais d'empêcher les erreurs de diagnostic : chaque réponse
est normalisée, agrégée et accompagnée de ses réserves.

Trois pièges neutralisés par construction :

- Les variantes de paramètres Hibernate (:co_orderNumber_62) sont fusionnées
  avant tout classement, le nombre de variantes est rendu, et la moyenne se
  recalcule sur les totaux agrégés — jamais en moyennant des moyennes. Une
  requête invisible sous cent entrées de 20 ms devient 4 721 appels à 533 ms.
- Toutes les instances d'un environnement sont agrégées par défaut ; un échec
  partiel est signalé au lieu de diviser silencieusement les chiffres.
- Le budget mémoire JVM est rendu entier (used, committed, max, cgroup côte à
  côte), Glowroot n'historisant que « used ».

Contenu :

- docs/glowroot-api.md — cartographie de l'API interne établie depuis les
  sources de Glowroot 0.14.7 : endpoints, convention de nommage des paramètres
  et NPE qu'elle provoque, agrégation, rollups et rétentions.
- docs/pieges.md — vingt-trois pièges de diagnostic, ce que le serveur en fait
  et ce qui reste à la charge de l'analyste.
- src/core/ — normalisation SQL, fenêtres temporelles, unités, rendu,
  fiabilité : aucun accès réseau, testable exhaustivement.
- Accès sortants derrière des interfaces injectables (Transport, PostgresApi,
  KubernetesApi) et mode simulation par rejeu d'enregistrements.
- Lecture seule PostgreSQL garantie côté serveur
  (default_transaction_read_only=on), garde-fou syntaxique en seconde barrière.
- Confirmation explicite pour les trois outils à effet visible : explain_query
  (ANALYZE sur un ordre de modification), partitioned_index_helper (DDL) et
  force_gc (pause applicative).
- 147 tests, dont les cinq investigations réelles rejouées comme critères
  d'acceptation.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>