Gestion des loggers Log4j

Administration Supervision

Ajustez les traces de votre plateforme depuis l'administration : ajoutez un logger, changez son niveau, choisissez où il écrit sans ouvrir log4j.xml ni redémarrer le serveur.

Les bénéfices

Diagnostiquer un incident sur une instance JPlatform suppose aujourd'hui d'accéder au serveur, d'éditer le fichier WEB-INF/data/log4j.xml à la main, puis d'attendre que la plateforme le relise quand on a l'accès système pour le faire. Ce module fait de cette opération un écran d'administration accessible directement depuis l'application.

Autonomie : l'ajustement des traces ne demande plus d'accès au système de fichiers du serveur.
Effet immédiat : les niveaux et les appenders sont appliqués aux loggers déjà en mémoire dès l'enregistrement, sans redémarrage.
Configuration d'origine préservée : un logger livré par Jalios repris depuis l'écran retrouve exactement son état d'origine dès qu'on le retire de la liste.

Les fonctionnalités

L'administration se fait directement depuis les propriétés du module. Il n'enregistre qu'une propriété : le fichier log4j.xml et les loggers en mémoire sont ensuite mis à jour sur chaque instance du site, ce qui rend le module compatible JSync.

Édition des loggers : ajouter, modifier ou retirer un logger et son niveau, parmi les huit niveaux log4j (OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL).
Reprise des loggers du fichier : les loggers déjà déclarés dans log4j.xml mais non gérés par le module sont proposés sous le formulaire ; un clic les reprend dans la liste avec leur niveau et leurs appenders, sans avoir à retaper leur nom.
Sélection des appenders : une colonne par appender déclaré dans le fichier, et une case à cocher par logger : un logger écrit dans autant d'appenders que voulu (ou aucun) et hérite alors de ceux de son logger parent.
Application à chaud : niveaux et appenders prennent effet immédiatement sur les loggers déjà instanciés. Un appender déclaré dans le fichier mais porté par aucun logger ne peut pas être attaché à chaud : sa colonne le signale, et le rattachement prend effet au redémarrage.
Protection de la configuration livrée : un logger créé depuis l'écran est marqué dans le fichier par un commentaire, et lui seul est supprimable. Un logger préexistant conserve son élément : seuls son niveau et ses appender-ref sont pilotés, et son état d'origine (niveau, appenders, additivité) est mémorisé dans le fichier pour lui être rendu tel quel au retrait.
Restauration au démarrage : la configuration est réappliquée au démarrage de chaque instance, le fichier log4j.xml pouvant avoir été remis dans son état livré par une montée de version de JPlatform.
Contrôles à la saisie : JSON invalide, nom de logger ou niveau incorrect, logger déclaré deux fois, appender inconnu du fichier, fichier non modifiable : chaque cas est refusé avec un message explicite plutôt qu'appliqué à moitié.
Écriture sûre du fichier : l'écriture passe par un fichier temporaire renommé (un log4j.xml tronqué empêcherait le démarrage) et une copie log4j.xml.bak est écrite avant chaque modification.

Captures d'écran

Les clients aiment

Paramétrages flexibles et simples.

Diagnostic sans redémarrage nécessaire.

Récupération automatique des loggers existants.

Informations détaillées

Prérequis techniques

Compatibilité JSync

Module compatible JSync. La propriété des loggers est répliquée entre les instances ; le fichier log4j.xml et les loggers en mémoire, qui sont locaux à chaque instance, sont mis à jour par un listener notifié sur chacune d'elles.

Configuration du module

Ajouter ce module via le gestionnaire de modules depuis l'administration technique et redémarrer JPlatform.

Le paramétrage se fait ensuite depuis les propriétés du module, qui présente l'écran de gestion des loggers à la place de l'éditeur de propriétés standard.

Note d'exploitation : l'enregistrement n'écrit que la propriété. Sur une instance distante, une erreur d'écriture du fichier n'est pas remontée à l'écran de saisie, elle est tracée dans les logs de l'instance concernée.

Les propriétés jcmsplugin.log4jmanagement.log4j-file et jcmsplugin.log4jmanagement.backup ne sont pas éditables depuis l'administration : elles se positionnent dans custom.prop.

Nom technique jcmsplugin.log4jmanagement.loggers
Description Liste des loggers gérés par le module.

Nom technique jcmsplugin.log4jmanagement.log4j-file
Description Chemin du fichier de configuration log4j, relatif au répertoire WEB-INF. Valeur par défaut data/log4j.xml. Propriété non éditable en administration, à positionner dans custom.prop.

Nom technique jcmsplugin.log4jmanagement.backup
Description Écrit une copie log4j.xml.bak avant chaque modification du fichier. Valeur par défaut true. Propriété non éditable en administration, à positionner dans custom.prop.

Évolutions

Une colonne par appender déclaré dans log4j.xml, et une case à cocher par logger : un logger peut être rattaché à autant d'appenders que voulu, ou à aucun.
Un logger créé par le module et rattaché à au moins un appender devient non additif, sinon le logger racine réécrirait chaque message dans les siens. L'additivité d'un logger livré par Jalios n'est pas pilotée : com.jalios.jcms.mail est volontairement additif tout en portant déjà deux appenders.
Les appender-ref d'un logger livré par Jalios suivent désormais les cases de l'écran, l'élément <logger> restant lui-même intact
Appenders appliqués à chaud comme les niveaux. Un appender déclaré dans le fichier mais porté par aucun logger en mémoire ne peut pas être attaché à chaud : sa colonne le signale, le rattachement prend effet au redémarrage.
Un logger préexistant repris par l'écran retrouve exactement son état d'origine quand on le retire de la liste : niveau, appender-ref et additivité. Cet état est mémorisé dans le commentaire de marquage posé devant lui, le fichier portant ainsi de quoi défaire ce que l'écran a fait.
Les colonnes d'appenders sont réunies sous un bandeau « Appenders », et le niveau passe à droite d'elles : on lit le nom du logger, ce dans quoi il écrit, puis à quel niveau.
La propriété JSON gagne un champ appenders facultatif : une valeur enregistrée avant cette version se relit sans appender, aucune reprise n'est nécessaire.

Correction

Le retrait d'un appender ne le ferme plus : removeAllAppenders() appelle close() sur les instances retirées, or elles sont partagées avec le logger racine et les loggers de Jalios. Décocher un appender rendait toute l'instance muette jusqu'au redémarrage, avec un log4j:ERROR « Attempted to append to closed appender » à chaque message.