M-PS Log Verbosity 8.0 Win/Unix

Inventaire et besoin

Inventaire

Aujourd’hui tous les messages de logs produits par M-Processing Server sont inscrits dans un fichier binaire consultable après un export en texte ou via l’interface Web. Ces messages sont rangés dans plusieurs catégories selon qu’ils indiquent une erreur, un avertissement, une information générale ou une information de débogage. Leur niveau sert à identifier la sévérité des messages et à filtrer leur consultation.

Il est déjà possible de ne pas écrire les messages de niveau système (identifiés par le tag « SYST ») en indiquant un niveau de log égal à 0 dans la configuration de M-Processing Server (LOGS > LOG_LEVEL). Cependant, ce réglage ne concerne pas les messages de niveau utilisateur (« USER »). À un niveau encore plus bas, dans la configuration de chaque Workflow, l’utilisateur peut décider de documenter son exécution ou pas selon si la case « Activation de la Log » est cochée. Cette option, apparemment peu connue des clients, peut déjà servir à alléger l’utilisation d’espace disque.

Besoin

Cette écriture complète des logs ne convient pas à un utilisateur qui aurait peu d’espace disque disponible et beaucoup de traitements documentés. Pour ce genre d’utilisateurs, il faudrait que le niveau de log inscrit dans la configuration du serveur indique ce qui doit être écrit plutôt que ce qui doit être affiché.  

Solution

Les niveaux

Quatre niveaux de log sont disponibles. Voici leur description : ERROR (EE) = Niveau 1 WARNING (WW) = Niveau 2 INFORMATION (OK) = Niveau 3 DEBUG (OK) = Niveau 4 Commandes et traitements qui ont échoué Avertissements • Commandes lancées • Ajouts de spools • Actions sur les spools • Actions sur les files d’attente • Actions sur les imprimantes • Ajouts Fichiers dans le Scanfolder • Traitement de fichiers par un Scanfolder • Paramètres des commandes • Conditions workflows • Réponses serveurs • Fonctions appelées • Paramètres des fonctions

Avec l’historique du produit, et l’ensemble des messages de log écrits, il ne faut pas hésiter à indiquer s’il reste des messages spécifiques écrits à un niveau inadéquat ou si une catégorie de messages n’est pas affectée au bon niveau. Par exemple, s’il reste un « HOLD Queue XXXX » dans les messages debug, une fois le message identifié, le correctif ne sera pas lourd. De même si à l’usage, on trouve que l’écriture des « Commandes lancées » a plus sa place au niveau DEBUG qu’au niveau INFORMATION, l’information doit être remontée au service R&D.

Changement des usages

Jusqu’à aujourd’hui, tous les messages ayant été écrits, il suffisait de consulter les logs pour trouver la description complète des traitements. Désormais, si le niveau de message n’est pas assez important, il faudra remonter le niveau (qui est pris en compte à chaud, sans redémarrage du spooler) et relancer le traitement à observer avant de trouver les informations. Avec la définition des niveaux présentés ci-dessus, un niveau de log à 3 (=INFORMATION) semble être le bon compromis entre la concision et le détail dans le cas d’une utilisation quotidienne. Un utilisateur qui veut retrouver le comportement précédant cette évolution indiquera un niveau de log (LOG_LEVEL) de 4.