Gestion des logs applicatifs

Présentation générale

K-Portal s'appuie sur l'API SLF4J et sur la librairie Logback pour gérer les logs et tracer tous les messages techniques renvoyés par l'application.
 

Niveaux de log

Il y a 5 niveaux de log utilisables sur l'application :

• ERROR : seules les erreurs sont tracées
• WARN : les erreurs et avertissements sont tracés
• INFO : les erreurs, avertissements et messages d'information sont tracés
• DEBUG : les messages pour diagnostiquer un problème sur l'application, et tous les autres niveaux de message sont tracés
• TRACE : Ces messages permettent de voir

Le niveau de log recommandé en production est WARN.
 

Appenders

Les appenders sont les différents composants qui sont chargés de réceptionner et écrire les messages de logs. Il en existe différents types : ConsoleAppender, FileAppender, SMTPAppender, DBAppender, ...
Pour plus d'informations, consultez la documentation officielle.
 

Configuration activée par défaut sur l'application

Le fichier de configuration par défaut est le fichier logback.xml dans le dossier /WEB-INF.
 

Niveaux de log

Le niveau de log par défaut est INFO mais il est possible de le modifier par paramétrage, notamment pour avoir un niveau de log différent pour chacun de vos environnements d'exécution (voir ci-après pour modifier cette configuration).
 

Appenders

Par défaut, un seul appender est présent dans l'application : WEBAPP-SIFING-APPENDER. Cet appender génère les fichiers "default-webapp.log" et "default-webapp.log.{date}" dans le dossier de logs configuré.
L'appender défini est de type SiftingAppender. Ce type d'appender permet de logger dans différents fichiers en fonction du MDC défini lors de l’exécution de l'application.
 

Format des noms de fichier

Les noms de fichiers sont configurés pour avoir comme pattern : [jvmRoute]-[contexte].log

• La jvmRoute permet d'identifier le nœud du cluster utilisé. Si aucun cluster n'est défini, la valeur default est retournée.
• Le contexte permet de définir la source du log (Application globale, Job spécifiques, ...)

Emplacement

L'emplacement des fichiers de logs est défini par la propriété « logs.path » de votre fichier env.properties. Par défaut, c'est le dossier storage/logs qui est prévu (voir ci-après pour modifier cette configuration).
 

Rotation et purge

La rotation est paramétrée pour créer un fichier de log par jour. Le fichier sera alors renommé pour être suffixé par la date du jour au format yyyy-MM-dd. Cette rotation peut être modifiée en surchargeant l'appender par défaut de l'application.
Par défaut, l'application garde les logs pendant 182 jours soit environ 6 mois. Cette valeur peut être surchargée dans les propriétés de l'application via « logs.maxDateHistory » (voir ci-après pour modifier cette configuration).
 

Surcharge de la configuration

Il est possible de créer sa propre configuration :

• En créant un fichier application_logback.xml (positionné dans le classpath de l'application, webapp/WEB-INF/classes) : à utiliser si vous souhaitez que cette configuration soit partagée sur tous les environnements d'exécution de votre application
• Ou bien en créant un fichier env_logback.xml (positionné dans le répertoire de configuration de l'application, storage/conf) : à utiliser si vous souhaitez définir une configuration particulière pour un environnement donné (par exemple, activé le niveau de log DEBUG pour votre environnement de développement)

Vous pouvez ensuite modifier les appenders, le format du nom des fichiers, etc. Voici les modifications les plus courantes :

• Modifier le niveau de log : modifiez l'attribut "level" dans votre fichier application_logback.xml ou env_logback.xml :

  <root level="DEBUG">

• Modifier le répertoire des fichiers de logs : Editez le fichier env.properties de votre application (placé sous storage/conf), et modifiez le paramètre logs.path.
• Modifier la durée de conservation des logs : Editez le fichier env.properties de votre application (placé sous storage/conf), et ajoutez le paramètre logs.maxDateHistory. La valeur doit être exprimée en jours.

  Ajout d'un appender

Lors du diagnostic, il peut-être intéressant déclarer un nouvel appender pour écrire les logs d'un traitement spécifique dans un fichier dédié. Les traces applicatives ne seront alors pas polluées par le reste des traitements.
Ci-dessous, un exemple d'ajout d'un appender pour écrire les logs du package com.kosmos.search.query.service dans un fichier dédié.

<!-- Déclaration d'un pattern de log -->
<property name="defaultPatternApp"
         value="%d{yyyy-MM-dd_HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n" />


<!-- Déclaration du nouvel appender-->
<appender name="FILE-ELASTIC" class="ch.qos.logback.core.FileAppender">
    <file>${logs.path}/${jvmRoute:-default}-query-elastic.log</file>
    <layout class="ch.qos.logback.classic.PatternLayout">
        <Pattern>${defaultPatternApp}</Pattern>
    </layout>
</appender>

<!-- Ajout d'un logger -->
<logger name="com.kosmos.search.query.service" level="DEBUG">
    <appender-ref ref="FILE-ELASTIC" />
</logger>

 

Liste des fichiers de log

Pour le fonctionnement courant de l'application, il y a deux fichiers de log :

Nom du fichier de log	Composant correspondant
default-webapp.log	Application globale
default-messaging.log	Moteur de recherche Elastic

Ensuite, chaque script génère son propre fichier de log :

Nom du fichier de log	Script automatisé correspondant
default-sitemapjob.log	Génération des fichiers sitemap
default-cleanbatch.log	Nettoyage des tables de batch
default-scansite.log	Mise à jour de l'application
default-mediauploadjob.log	Upload automatique des médias
default-batchsynchrogroupfromldap-xxx.log	Synchronisation des groupes depuis le LDAP. Note : le fichier est suffixé par l'alias défini dans la configuration (plusieurs synchronisations peuvent en effet être déclarées dans la configuration)
default-batchsynchrouserfromldap-xxx.log	Synchronisation des utilisateurs depuis le LDAP. Note : le fichier est suffixé par l'alias défini dans la configuration (plusieurs synchronisations peuvent en effet être déclarées dans la configuration)
default-bulkindexerjob.log	Indexation complète des contenus
default-indexeursitesweb.log	Indexation des sites externes
default-synchronisergroupesdynamique.log	Synchronisation des groupes dynamiques
default-importxml-[xxx].log	Synchronisation de contenu externe (import XML). Note : le fichier est suffixé d'un identifiant pour distinguer le cas où le script serait exécuté plusieurs fois dans la même journée.
default-purgenewsletterjob.log	Script de maintenance des newsletters
default-updateindexdbjob.log	Mise à jour des indexes de la base de données
default-generatethumbnailjob.log	Génération des vignettes de médias (type photo)
default-dumpmonitor-threads.log	Dump des threads et connexion de l'application
default-scanfiche.log	Analyse des contenus

A noter : sur une architecture distribuée comportant plusieurs serveurs applicatifs, un fichier de log est généré pour chaque serveur, et le nom du fichier de log est modifié : "default" est remplacé par le nom défini dans la configuration pour chaque serveur (jvmRoute).