Métriques & audit
Supervision technique de la plateforme (à distinguer des statistiques d'usage, qui relèvent du module Statistiques) et traçabilité des actions d'administration.
Métriques
/admin/metrics — métriques JVM et système du Dashboard Admin et du Launcher ENT : mémoire
(heap / non-heap, memory pools), garbage collector, threads, CPU et mémoire OS, runtime
JVM et chargement des classes. Utile pour le diagnostic et le suivi de la santé de la plateforme.
Audit
/admin/audit — traçabilité des événements de la plateforme (connexions, accès, créations,
suppressions, accès refusés…). Deux vues complémentaires, sélectionnables en haut de page.
Vue d'ensemble
Tableau de bord visuel synthétisant l'activité sur la période choisie (24 h / 7 j / 30 j). Tous les graphiques sont calculés en direct à partir des événements d'audit réels de la période (aucune donnée simulée) :
- Indicateurs clés : nombre total d'événements, connexions, sessions/accès, utilisateurs actifs (comptes distincts) et requêtes suspectes (voir « Clients & sécurité » ci-dessous).
- Activité par heure — courbe des connexions et des autres actions par heure de la journée, avec repérage automatique du pic d'activité.
- Répartition par type d'action (LOGIN, ACCESS, CREATE, ACCESS_DENIED…) et par profil (enseignant, élève, parent, personnel, ADML), sous forme de camemberts.
- Modules les plus sollicités (barres).
- Carte d'activité jour × heure (heatmap) — intensité relative de l'activité, pour repérer les usages hors horaires scolaires (soirée, week-end).
- Utilisateurs les plus actifs sur la période (identités résolues depuis l'annuaire).
Clients & sécurité
Cette carte classe les requêtes selon leur User-Agent et signale les clients automatisés :
| Catégorie | Exemple de User-Agent | Marquage |
|---|---|---|
| Navigateur web | Mozilla/… Chrome/… Firefox/… Safari/… | fiable |
| Application mobile | okhttp, CFNetwork, Dalvik | fiable |
curl | curl/8.5.0 | à vérifier |
| Script | Python-urllib, wget, Go-http-client | à vérifier |
| Client inconnu | User-Agent absent | à vérifier |
| Autre client | non reconnu (ex. node) | à vérifier |
Le marquage « à v érifier » est une heuristique basée sur le User-Agent : il ne signifie pas
qu'une requête est malveillante. Ces clients correspondent souvent à des usages légitimes
(intégrations API, scripts d'administration, sondes de supervision, appels internes entre modules).
Le bandeau d'alerte invite simplement à vérifier que ces accès sont attendus. Le User-Agent étant
déclaratif, il peut par ailleurs être falsifié : à recouper avec l'IP, l'utilisateur et les
actions (notamment les ACCESS_DENIED) du journal détaillé.
Journal détaillé
Le journal des événements brut, filtrable par action, période (de / à), utilisateur et recherche libre ; chaque entrée indique la date, l'action, le module, l'utilisateur, le profil, l'IP et le User-Agent. Le détail complet de chaque événement est consultable au clic.
Les accès des sondes d'infrastructure du cluster (User-Agent kube-probe/…, GoogleHC/…,
ELB-HealthChecker/…) sont écartés du journal : ce sont les tests de vie des pods, sans valeur
d'audit.
Volumétrie & nettoyage
Réservé au super-administrateur. Cet onglet affiche la taille réelle du journal — nombre d'événements, volume de données et espace disque occupé, collection par collection, avec la date du plus ancien et du plus récent événement — et permet deux nettoyages :
- Accès des sondes : supprime les événements laissés par les sondes du cluster.
- Événements anciens : supprime tout ce qui est antérieur à une durée de rétention choisie (par défaut 90 jours).
Le journal d'audit n'a pas d'expiration automatique : sans purge, il grossit indéfiniment. Chaque action peut d'abord être simulée pour connaître le nombre d'événements concernés ; la suppression, elle, est définitive.