La gestion des logs dans Semarchy xDI

Comment fonctionnent les logs dans Semarchy xDI ?

Chaque flux (ou « Session ») exécuté sur un Runtime Semarchy xDI (que ce soit en développement, en production avec planification, etc.) va, par défaut, créer des logs d’exécution. Il est d’ailleurs obligatoire, pour faire fonctionner un Runtime, de le connecter à une base de données pour qu’il y stocke ses logs (que ce soit la base de données interne h2 ou une base de données externe).

Ces logs s’avèrent très utiles pour le debugging/monitoring, et leur génération (avec + ou – de détail) est donc essentielle à l’utilisation de l’outil. Cependant, sans action de gestion sur les logs, ces derniers vont s’accumuler au fur et à mesure du temps, et cela peut rapidement créer des problèmes de mémoire dus au volume de données au niveau des bases de données qui hébergent ces logs.

Il est donc important de convenir d’une stratégie de gestion de logs sur Semarchy xDI, notamment grâce à 2 leviers : la purge/planification de purge des logs, et le contrôle du niveau de détail des logs générés. Ce sont ces éléments et leur procédure de mise en place qui seront détaillés tout au long de cet article.

Notes :

• De Stambia jusqu’à Semarchy xDI version 5.3, Log4j1 était utilisé pour les logs. Désormais, à partir de la version 2023.1, c’est Log4j2 qui est utilisé.
• Bien que la mise en place d’une stratégie de gestion de logs soulagera forcément la base de données qui stocke les logs, il convient, comme pour n’importe quelle autre base de données, de bien surveiller l’espace disque et l’utilisation mémoire de la base de logs.

Purge des logs

Mettre en place la purge des logs est une action simple qui va permettre de limiter la saturation mémoire de la base de logs.

Planifier une purge via Analytics

 L’outil Analytics permet de créer des workflow pour effectuer des planifications de purge sur les Runtimes grâce à une interface graphique. Pour automatiser l’action, il suffit de faire un clic droit sur un Runtime connecté dans Analytics et « Open » :

Cette action va ouvrir le panneau de contrôle du Runtime. Aller dans l’onglet « Purge » :

L’écran de contrôle des purges apparaît. Il est possible de créer, modifier ou supprimer une purge planifiée. Dans notre cas, nous allons créer une nouvelle planification de purge avec « Add » :

Dans l’écran de création, 4 zones vont nous permettre de configurer notre planification de purge :

1. Sélectionner le type de purge (ne conserver qu’un certain nombre de sessions, ne conserver que les logs qui datent d’il y a moins de X jours…). Dans notre exemple, nous supprimons les logs qui ont 10 jours d’ancienneté ou plus.
2. Sélectionner quels logs supprimer (ne supprimer que les logs des sessions exécutées avec succès, ne supprimer que les logs des sessions en erreur…). Dans notre exemple, nous ne supprimons que les logs des sessions exécutées avec succès.
3. Sélectionner à quelle fréquence lancer la purge des logs (tous les X jours à X heures…). Dans notre exemple, nous lançons la commande de purge tous les jours à minuit pile.
4. Sélectionner une date de début et/ou une date de fin pour cette planification de purge. Dans notre exemple, nous n’avons précisé ni date de début ni date de fin, la planification sera donc active dès que nous l’aurons enregistré et elle tournera indéfiniment.

Dans notre exemple, nous avons donc planifié une purge des logs qui tournera indéfiniment et qui se déclenchera tous les jours à minuit. Cette purge supprimera tous les logs des actions exécutées avec succès, vieux de 10 jours ou plus.

Une fois terminée, nous pouvons enregistrer la planification de purge :

La nouvelle planification de purge apparaît alors dans l’écran de contrôle des purges du Runtime :

Attention : La commande de purge fait travailler le Runtime. Il est donc recommandé de planifier les purges à un moment où aucun flux ne tourne sur le Runtime, ou au moins aucun « gros » flux.

Purger les logs via commande de Runtime

Sans utiliser Analytics, nous pouvons directement purger les logs d’un Runtime à l’aide de commandes. Il est plutôt recommandé de mettre en place la purge automatique (planification), mais cette action peut s’avérer utile dans certains cas.

Attention : Ici il ne s’agit donc pas de créer une planification de purge, mais bien d’exécuter une commande de purge une seule fois en mode oneshot. Il est néanmoins possible, par exemple, d’utiliser un script batch ou un ordonnanceur externe pour planifier l’exécution de la commande de purge tous les X temps.

1. S’assurer que le Runtime que l’on veut purger est bien démarré et en train de tourner
2. Aller dans le dossier d’installation du Runtime et lancer le script racine_runtime/startcommand.bat
   
3. Cela va lancer une fenêtre de commande. À l’intérieur de cette fenêtre, renseigner la commande de connexion au Runtime :
   • connect to http://*serveur* port *port_HTTP_du_runtime* user *utilisateur* uncryptedPassword mot_de_passe_en_clair
   • Par exemple : connect to http://localhost port 42200 user admin uncryptedPassword admin-password
     
4. Une fois connecté au Runtime, nous pouvons lancer la commande purge keep. Il existe plusieurs variantes à cette commande :
   • purge keep 10 session : Supprime tous les logs, excepté ceux des 10 dernières sessions du Runtime
   • purge keep 20 session status done : Supprime tous les logs des sessions exécutées avec succès, excepté ceux des 20 dernières sessions
   • purge keep 30 session sessionname FACTURATION_% :  Supprime tous les logs des sessions dont le nom commence par FACTURATION_, excepté ceux des 30 dernières sessions
   • purge keep 5 day : Supprime tous les logs, excepté ceux des 5 derniers jours

Une fois que la commande de purge est terminée, il suffit simplement de quitter la fenêtre.

Note : Il est également possible de lancer ces commandes depuis Analytics via l’onglet Commande de l’écran de contrôle du Runtime :

Attention : Dans le cas d’une purge importante, il est recommandé de segmenter la purge.

Par exemple, prenons un cas où notre Runtime tourne très fréquemment avec beaucoup de flux et accumule des logs depuis 100 jours, et nous souhaitons purger ces logs pour ne conserver que ceux de ces 10 derniers jours. Il faudra donc d’abord lancer un purge keep 80 day, puis un purge keep 60 day, puis un purge keep 40 day, puis un purge keep 20 day, et enfin un purge keep 10 day.

Attention : La commande de purge fait travailler le Runtime, donc il faut faire attention aux exécutions des flux en parallèle pour ne pas surcharger le Runtime. 

Dans certains systèmes de bases de données, supprimer des lignes ne suffit pas à libérer la mémoire qu’elles occupaient. Il faudra donc prévoir une action en parallèle pour libérer/défragmenter cette mémoire (exemple : VACUUM en PostgreSQL).

Purger les logs manuellement via le Designer

Il est possible de manuellement purger les logs d’un Runtime depuis le Designer. Il n’est pas vraiment recommandé de purger ses logs de cette manière car nous n’avons que très peu d’options pour bien cibler les logs à supprimer.

Pour cela, en étant connecté à un Runtime dans notre Designer, nous pouvons cliquer sur le « Delete until » (Suppression des logs à partir de la date sélectionnée) :

Ou sur le « Delete all », qui comme son nom l’indique, supprime TOUS les logs du Runtime. Cette action n’est pas recommandée (heureusement, une fenêtre de validation nous empêche d’effectuer cette action par erreur) : 

Contrôler la taille des logs générés

Explications

Les flux exécutés sur les Runtimes xDI génèrent par défaut des logs avec un niveau très détaillé (niveau de log « 400 »), et donc très volumineux. Tout l’enjeu ici va donc être de limiter le niveau de détail des logs. Il est important de déterminer un point d’équilibre selon votre contexte entre un niveau de logs assez élevé pour pouvoir aisément effectuer des actions de debugging/monitoring, et assez bas pour limiter la taille des logs et donc soulager la base de données qui stocke ces logs.

Note : Contrôler le niveau de détail des logs s’avérera particulièrement intéressant pour les flux qui s’exécutent très souvent (exemple : utilisation de la Change Data Capture), et qui vont donc très vite remplir notre base de logs.

Le tableau ci-dessous offre une vue d’ensemble des différents niveaux de log :

Dans un contexte de production, un niveau de log positionné à 100 est un très bon compromis car il permet de conserver toutes les informations d’exécution lorsque le flux est exécuté ou s’il tombe en erreur pour le debugging/monitoring. Cela tout en réduisant grandement les logs des flux exécutés avec succès et en conservant une petite trace (sont collectés uniquement les informations d’entêtes et statistiques de traitement) de ces derniers.

Dans un contexte de développement, un niveau de log positionné à 300 s’avère très pratique pour gérer les données car il permet de générer des logs assez détaillés pour observer et éviter les problèmes de faux positifs, et permet aux développeurs de bien étudier des flux assez jeunes.

Note : Il est intéressant de remarquer que le log level -1 est le seul à ne fournir aucun accès à la base de log, pouvant ainsi accélérer mécaniquement les flux. C'est risqué, mais cela peut se comprendre sur des problématiques de temps réel (comme les APIs par exemple, où l’on peut accepter de ne pas avoir de log côté Analytics pour en avoir plutôt du côté de l'API Manager).

Comment renseigner le niveau de détail des logs

Au niveau du Runtime

Les Runtimes peuvent porter l’information du niveau de log dans leur fichier de configuration properties/engineParameters.xml. Pour cela, deux paramètres vont pouvoir être définis :

• defaultSessionLogLevel, qui correspond simplement au niveau de log souhaité
  Attention : cette valeur peut être écrasée si l’on définit le niveau de log à un autre endroit, par exemple si on précise le niveau de log lors d’un déclenchement du flux via ligne de commandes)
• defaultChildSessionLogLevelInheritance, qui permet de faire hériter ou non le niveau de log du flux parent qui appellerait des flux enfants. Ce paramètre peut être laissé en « true »

Dans Analytics

Le niveau de log peut être paramétré dans Analytics directement au niveau du Delivery :

Ou même à l’intérieur d’un Schedule, pour déterminer le niveau de log à chaque exécution planifiée :

Dans le cas d'une exécution en ligne de commandes

Si l’on exécute les flux via ligne de commandes (utilisation d’un ordonnanceur externe par exemple), il est possible de rajouter un paramètre à la commande pour pouvoir directement préciser le niveau de log souhaité. La syntaxe est la suivante avec par exemple :

startdelivery.bat -name nomDelivery -logLevel 200

Directement au sein de process développé dans le Designer xDI

Il est possible de déterminer directement au niveau d’un process le niveau de log qui sera généré. Pour cela, il suffit d’utiliser l’attribut <logLevel>X</logLevel> dans l’onglet « Meta-Inf » du Process.

Par exemple :

Aller plus loin avec ses logs

Semarchy xDI utilisant Log4j2 pour le logging, il est tout à fait envisageable de créer des configurations de logging personnalisées, dans certains cas d’usage précis.

Les logs générés par Semarchy xDI sont stockés en base de données. Cela signifie que ces données sont totalement exploitables pour élaborer un reporting/monitoring plus avancé que celui proposé par l’affichage Analytics par exemple, à l’aide d’un logiciel de reporting tiers. Ou encore, il est possible de venir valoriser ces tables de logs dans des Processes xDI afin de faire du traitement de logs avancé.

Nous avons ainsi balayé toutes les options de purge et de contrôle du niveau de détail des logs, ainsi que certaines possibilités avancées. Comme nous l’avons vu, il sera préférable de planifier une purge automatique des logs et de limiter le niveau de détail des logs, en particulier pour les flux qui s’exécuteront très souvent.

Vous possédez désormais tous les éléments pour pouvoir gérer efficacement vos logs avec la solution Semarchy xDI.

Retour page précédente Retour au Wiki

Vous souhaitez aller plus loin ? Vous avez des questions ? Contactez Next Decision et ses experts en Data Integration pour toute question sur l’outil Semarchy xDI.