Supervision — vue d'ensemble
La visibilité sur une installation NomaUBL en production se répartit sur plusieurs surfaces : trois pages de l'interface web, le fichier journal sur l'hôte et deux points HTTP. 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 | Indicateurs en direct — factures traitées aujourd'hui, en cours, en échec ; état de soumission par PA ; activité de l'ordonnanceur ; vérification de la configuration. | Navigation → Tableau de bord IT — voir Tableau de bord IT. |
| Diagnostic | Ce qui a échoué et ce que le serveur a consigné, en quatre vues : erreurs d'intégration, journal des traitements (chaque étape de chaque fichier, avec ses durées), anomalies (tous les échecs dans une seule liste, non résolus par défaut), journal serveur (le fichier journal, filtré par niveau et par module). | Navigation → Diagnostic — voir Diagnostic. |
| Tâches planifiées | Chaque tâche d'arrière-plan avec son état, sa dernière exécution, sa durée, son résultat et sa prochaine exécution, ainsi que l'historique de ses exécutions. | Synchronisation → Tâches planifiées — voir Tâches planifiées. |
| 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 pages 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. |
| « Qu'est-ce qui a échoué et reste ouvert ? » | Diagnostic → Anomalies — non résolues seulement, les plus récentes d'abord. |
| « Quel est le statut de la facture #12345 ? » | Diagnostic → Journal des traitements — recherche par numéro de document. |
| « Pourquoi la facture #12345 est-elle bloquée ? » | Diagnostic → Journal des traitements — détail de la trace par étape. |
| « La tâche de nuit s'est-elle exécutée ? » | Tâches planifiées — dernière exécution, résultat et historique des exécutions. |
| « Pourquoi l'ordonnanceur ne se déclenche-t-il pas ? » | Tâches planifiées pour l'état de chaque tâche, puis la vue Journal serveur ou le fichier journal. |
| « 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 ? » | Diagnostic → Journal serveur (module PA) ou le fichier journal — 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 questions sur les factures, les anomalies et les tâches 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é). |
| Diagnostic | Chaque vue s'accorde séparément sur la page Rôles — Erreurs d'intégration, Journal des traitements, Anomalies, Journal serveur. |
| Tâches planifiées | Le droit de page Tâches planifiées ; lancer, suspendre ou enregistrer une tâche demande aussi l'action Lancer les traitements. |
| 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 journaux — intégrée au serveur : au-delà du Log size cap (100 Mo par défaut), le journal est copié en
.1puis tronqué, et cinq copies sont conservées (global → Logs). Logrotate n'est utile que si le serveur est lancé par un autre lanceur. - 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. | Diagnostic → Journal des traitements. |
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.
- Diagnostic → Journal des traitements — trace par document.