Supervision — vue d'ensemble
La visibilité sur une installation NomaUBL en production se répartit sur quatre surfaces — trois dans l'interface web, une sur l'hôte. Cette page sert de carte : quelle surface répond à quelle question opérationnelle, quand regarder où, ce qui manque et où raccorder une supervision externe.
| Surface | Ce à quoi elle répond | Où |
|---|---|---|
| Tableau de bord technique | KPI en direct — factures traitées aujourd'hui, en cours, en échec ; état de soumission par PA ; activité de l'ordonnanceur. | Application → Tableau de bord technique (page existante). |
| Journal de traitement | Trace par document — chaque étape de chaque facture, avec le timing, le résultat XSD/Schematron, l'appel à la PA. | Gestion → Journal de traitement (page existante). |
| Fichier de log du service | Le stderr / stdout de la JVM — démarrage, chargement de configuration, ticks de l'ordonnanceur, erreurs base de données. | <APP_HOME>/nomaubl-<env>.log sur l'hôte. |
| Points HTTP | Build info et état de licence au format machine. | /api/build-info et /api/license sur le service en cours d'exécution. |
Les deux surfaces de l'interface web forment la vue opérateur ; le fichier de log et les points HTTP forment la vue infrastructure (load balancers, supervision externe, smoke tests CI).
Quand regarder où
| Situation | Surface |
|---|---|
| « Le batch du jour s'est-il bien passé ? » | Tableau de bord technique — panneau des factures traitées aujourd'hui. |
| « Quel est le statut de la facture #12345 ? » | Journal de traitement — recherche par numéro de document. |
| « Pourquoi la facture #12345 est-elle bloquée ? » | Journal de traitement — descendre dans la trace par étape. |
| « Pourquoi l'ordonnanceur ne se déclenche-t-il pas ? » | Fichier de log du service — chercher les lignes scheduler tick. |
| « La JVM s'est-elle arrêtée brutalement ? » | Fichier de log du service + ./nomaubl.sh status (Linux / macOS) ou nomaubl.cmd status (Windows). |
| « La base est-elle joignable ? » | Fichier de log du service — chercher Connected to db-nomaubl au démarrage. |
| « La PA est-elle joignable ? » | Fichier de log du service — chercher les lignes pa-default API call. |
| « La licence est-elle encore valide ? » | curl /api/license — renvoie valid / expired / restricted. |
| « Quelle version est en service ? » | curl /api/build-info — renvoie la version et l'horodatage de build. |
| « Un redémarrage de processus a-t-il eu lieu cette nuit ? » | ./nomaubl.sh status / nomaubl.cmd status montre le PID courant ; le fichier de log montre la bannière de démarrage. |
Les deux premières lignes passent par l'interface ; tout ce qui suit passe par la CLI ou par un curl. La page suivante (Service et logs) détaille le côté CLI.
Permissions
Visibilité :
| Surface | Permission |
|---|---|
| Tableau de bord technique | Disponible pour tout utilisateur connecté — mais les KPI eux-mêmes respectent le filtre de données de chaque utilisateur (ex. portée par société). |
| Journal de traitement | Restreint aux rôles disposant de la permission processing-log (typiquement opérateurs + administrateurs). |
| Fichier de log du service / points HTTP | Accessibles à quiconque dispose d'un accès SSH / RDP / HTTP à l'hôte. À restreindre via le pare-feu et le reverse proxy — /api/build-info et /api/license ne sont pas authentifiés. |
Les deux points HTTP non authentifiés ne divulguent aucun secret (pas de mots de passe, pas de jetons, uniquement des métadonnées de build et un résumé de licence), mais ils révèlent la version de NomaUBL en service. Pour les installations exposées publiquement, il convient de les filtrer derrière le reverse proxy ou le VPN si ce point est sensible.
En un coup d'œil
Ce que NomaUBL ne met PAS à disposition
Connaître ces manques évite de chercher au mauvais endroit :
| Manquant | Où l'obtenir à la place |
|---|---|
Prometheus /metrics | Non intégré. Scraper l'hôte avec node_exporter ; extraire des compteurs applicatifs depuis le fichier de log ; ou bâtir un petit exporteur JMX au-dessus de la JVM. |
| Traces OpenTelemetry | Non intégrées. Le pipeline de traitement émet des logs structurés par étape — les rediriger vers un système de tracing log-based pour obtenir des vues en cascade. |
| Histogrammes de latence par requête | Le Tableau de bord technique affiche les agrégats ; pour les percentiles et le détail requête par requête, placer un APM devant le reverse proxy. |
| Stats heap / GC | JMX JVM standard — connecter VisualVM ou JConsole en JMX, ou exposer JMX via un exporteur JMX-to-Prometheus. |
| Métriques live du pool de connexions BD | NomaUBL utilise un modèle de connexion simple par appel, sans pool. Le nombre de connexions est fonction des requêtes en cours — observable via V$SESSION d'Oracle ou pg_stat_activity de PostgreSQL. |
La plupart des besoins de supervision externe se résument à : scraper l'hôte avec les outils standard, extraire depuis le fichier de log, placer un APM en amont. Le framework lui-même reste centré sur les surfaces in-app.
Supervision day-zero
Une posture de supervision minimale prête pour la production sur une installation mono-hôte :
- Démarrage automatique via systemd avec
Restart=on-failure— voir Service et systemd. - Rotation des logs avec logrotate (
copytruncate) — même page. - Sonde de vivacité depuis le load balancer / l'outil de monitoring d'uptime qui interroge
/api/build-infotoutes les 30 secondes. - Alerte de licence — un petit script qui interroge
/api/licensechaque jour et lève une alerte sivalid: false. - Transfert de logs — rediriger
nomaubl-<env>.logvers le stockage central de logs (Loki, ELK, Datadog Logs). Le framework écrit en stderr/stdout standard — tout shipper de logs ligne par ligne le capte. - Supervision base de données — l'outillage natif du moteur (Oracle :
V$SESSION, AWR ; PostgreSQL :pg_stat_activity,pg_stat_statements; ou les tableaux de bord déjà en place chez le DBA).
Les éléments 3, 4 et 5 sont les gains rapides qui couvrent 80 % des incidents de production.
Ce qui est fait concrètement — carte rapide
| Objectif | À lire |
|---|---|
| Parcourir les cartes du Tableau de bord technique. | Application → Tableau de bord technique. |
| Investiguer une facture bloquée ou en échec. | Gestion → Journal de traitement. |
Utiliser status du wrapper + suivi des logs pour les incidents (Linux ou Windows). | Service et logs. |
| Raccorder une supervision externe (sondes LB, alerting, transfert de logs). | Service et logs. |
Et ensuite
- Service et logs — la couche CLI + points HTTP en détail.
- Application → Tableau de bord technique — la vue live in-app.
- Gestion → Journal de traitement — trace par document.