Java en Production – Les fichiers de logs
Tout a déjà été dit sur les logs. Pour preuve, ce n'est plus un sujet chaud, les équipes d'exploitation sont très contentes avec les logs de nos applications 
.
D'accord, l'envers du décor est moins reluisant et il reste une marge de progression. Nous avions proposé dans Les 10 commandements des logs applicatives des suggestions focalisées sur le contenu des fichiers de logs ; voici aujourd'hui des propositions pour gérer les fichiers eux-mêmes. Même si le sujet peut sembler trivial, ces bonnes pratiques peuvent grandement simplifier le quotidien des équipes de production et améliorer les relations tumultueuses entre exploitants et développeurs.
Au risque de surprendre certains, les exemples de ce billet utilisent Logback plutôt que le standard de-facto Log4j car certaines bonnes pratiques que je proposerai sont impossibles à mettre en oeuvre avec Log4j. Aujourd'hui, je préfère utiliser Logback à Log4j pour gérer les logs de mes applications ... même si je suis nostalgique du format '.properties' pour la configuration de ces dernières .
Bien que Logback ne soit pas le sujet de ce billet, j'ai ajouté à l'article initial un paragraphe "Pourquoi je préfère Logback à Log4j" pour expliquer ce choix.
Différents fichiers de logs pour différents besoins
On utilise souvent un seul fichier mon-application.log pour écrire toutes les logs : les informations d'audit, les logs d'exception avec des stack traces sans fins aussi bien que les informations de diagnostique/troubleshooting. Ce fichier se remplit de centaines de lignes par minute, et c'est alors la déception pour tous ses utilisateurs :
- l'exploitant est incapable de dire si une application a un problème en regardant les logs sans un astucieux système de '
grep' et d'expressions régulières, - l'administrateur système et les responsables de la collecte des logs sont incapables de dimensionner les disques pour des logs dont la taille explose au moindre grain de sable à coup de stack traces dont il est pourtant inutile de conserver le détail,
- les équipes de diagnostique/troubleshooting sont noyées dans la masse des informations lorsqu'elles doivent intervenir.
Au final, c'est l'échec de la transmission de l'application du développement à la production et les exploitants prennent les développeurs pour des inconscients. Je ne saurais leur donner tort sur ce problème et voici ma proposition de découpage des fichiers de logs.
Les logs applicatives
Ce fichier ne trace que les dysfonctionnements, il n'est pas censé se remplir quand l'application fonctionne normalement et est archivé pendant plusieurs années par l'exploitant.
Ses caractéristiques sont :
- seuls les messages de dysfonctionnement (ie >= WARN) y apparaissent,
- ce fichier tourne ('est rotationné' en franglais) chaque jour pour être archivé,
- les stack traces seront compactes pour éviter de saturer le système de fichiers. Compacter à deux lignes par cause d'une exception est un bon compromis entre le niveau de détail utile au diagnostic et la taille occupée sur disque.
Remarques :
- que faire si l'exploitant utilise l'augmentation de la taille du fichier de logs comme indicateur de disponibilité de l'application ? Cette technique de monitoring me semble très discutable sur le fond et je proposerai dans un autre billet d'utiliser des compteurs JMX pour ce besoin. Cependant, si votre exploitant tient absolument à suivre l'augmentation de la taille d'un fichier de logs, je vous propose de l'orienter vers le fichier d'audit décrit plus bas.
- ajouter le nom de l'instance dans le préfixe de chaque message de logs ? Cette technique est parfois utilisée pour agréger les logs provenant de plusieurs serveurs. Cependant, je préfère que le script de collecte reporte le nom d'instance dans le nom des fichiers collectés. Cela consomme moins de disque et, de toutes façons, la fusion de fichiers de logs en conservant la chronologie est très délicate car toutes les lignes de nos fichiers ne sont pas préfixées (stack traces, sauts de ligne dans les message, etc).
Exemple de fichier logback.xml avec un fichier de logs filtré à WARN, à rotation quotidienne et dont les stack traces sont compactées à 2 lignes par cause d'une exception :
<file>my-application.log</file>
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<!-- only log problems, not debugging info -->
<level>WARN</level>
</filter>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- rotate every day for log collection and archiving -->
<fileNamePattern>my-application.%d{yyyyMMdd-HHmm}.log</fileNamePattern>
</rollingPolicy>
<encoder>
<!-- only log 2 lines of stack trace per cause of an exception -->
<pattern>%d{yyyy/MM/dd HH:mm:ss,SSS} [%thread] %-5level %logger{36} - %m %throwable{2}%n</pattern>
</encoder>
</appender>
Les logs de diagnostic/troubleshooting
Ce fichier est destiné aux équipes de diagnostic/troubleshooting qui peuvent ajouter ou retirer des informations de debug selon leurs besoins. Ces logs ne sont pas archivées et doivent être très détaillées sans pour autant saturer le système de fichiers.
Ses caractéristiques sont :
- aucun filtrage sur le niveau de log (TRACE, ...),
- reconfiguration à chaud du framework de log pour ajouter/supprimer des informations selon les besoins,
- rotation avec écrasement des fichiers pour éviter de saturer le système de fichiers.
Exemple de fichier logback.xml avec un rechargement de la configuration toutes les 30 secondes et un fichier de logs de troubleshooting
...
<appender name="troubleshooting-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>my-application-troubleshooting.log</file>
<!-- 10x10Mo files to limit size on disk -->
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
<fileNamePattern>my-application-troubleshooting.%i.log</fileNamePattern>
<maxIndex>10</maxIndex>
</rollingPolicy>
<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<maxFileSize>10MB</maxFileSize>
</triggeringPolicy>
<encoder>
<pattern>%d{yyyy/MM/dd HH:mm:ss,SSS} [%thread] %-5level %logger{36} - %m%n</pattern>
</encoder>
</appender>
</configuration>
Logs d'audit
Ce fichier est destiné à l'audit de sécurité, on y trace "qui a fait quoi à quelle heure", il grossit donc en permanence et peut dépasser le Go chaque jour.
Ses caractéristiques sont :
- seuls les messages d'audit y apparaissent,
- ce fichier tourne chaque jour pour être archivé.
Remarques :
- Certains estiment que le framework de logs n'a pas vocation à gérer les informations d'audit. Bien que je comprenne la théorie, je trouve en pratique bien plus simple de gérer simultanément les deux pour les raisons suivantes:
- l'audit doit tracer toutes les erreurs pour permettre d'analyser les problèmes de sécurité, il faudrait donc tracer les exceptions à la fois dans les logs et dans l'audit,
- les frameworks de logging sont très efficaces pour gérer l'écriture de gros volumes de messages sur disque,
- bien qu'il existe théoriquement un risque qu'une équipe de diagnostic fasse une erreur de configuration et désactive l'audit, je n'ai jamais entendu parler de ce genre de bourde.
- Faut-il augmenter la fréquence de rotation pour prévenir une dégradation des performances lorsque les fichiers d'audit dépassent le Go chaque jour ? Je ne pense pas : j'ai travaillé récemment sur une application Linux RHEL 5 / JVM Hotspot 6 / Tomcat / Log4j qui générait plus d'un Go de logs d'audit chaque jour. L'impact sur les performances était négligeable et l'augmentation de la fréquence de rotation n'a eu aucun impact. En revanche, en cas d'écriture massive sur disque, il faut collaborer avec l'administrateur système pour qu'il vérifie ses configurations OS et disques (c.f. RAID 1) ; les administrateurs sont habitués à ces problèmes avec les fichiers de logs des bases de données.
Exemple de fichier logback.xml avec un fichier d'audit avec rotation quotidienne qui ne traite que les loggers ayant la racine 'fr.xebia.audit' :
<file>${LOGS_FOLDER}/my-application-audit.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- rotate every day -->
<fileNamePattern>/my-application-audit.%d{yyyyMMdd-HHmm}.log.zip</fileNamePattern>
</rollingPolicy>
<encoder>
<!-- don't output the date or the logger name because the auditing framework handles this -->
<pattern>%m %throwable{0}%n</pattern>
</encoder>
</appender>
<!-- route the 'fr.xebia.audit' log messages to the audit-file -->
<logger name="fr.xebia.audit" additivity="false" level="TRACE">
<appender-ref ref="audit-file" />
</logger>
Un répertoire dédié pour les fichiers de logs archivés
Une fois nos fichiers bien séparés, nous pouvons encore faciliter le travail des équipes d'exploitation avec une astuce très simple : stocker dans un autre répertoire les fichiers qui ont tourné. Il suffit de déclarer un répertoire logs-to-collect à côté de notre répertoire logs. Les bénéfices sont nombreux :
- Le script de collecte des logs (compression et transfert sur un serveur de backup) est grandement simplifié. Il n'est plus nécessaire d'utiliser un astucieux mécanisme de pattern sur le nom des fichiers pour exclure ceux qui sont en cours d'utilisation. Tous les fichiers du répertoires
logs-to-collectpeuvent être collectés à n'importe quel moment.
- L'équipe de collecte de logs peut conserver autant de fichiers de logs d'archive sur le serveur sans nuire à la lisibilité du répertoire
logsen y laissant des centaines d'entrées.
- Il n'y a plus de risques de perdre les fichiers créés dans des circonstances exceptionnelles (opération de diagnostic, etc) et dont le nom ne correspondrait pas aux patterns du script de collecte, il suffit de déplacer ces fichiers dans le répertoire
logs-to-collect.
Remarque : seules les logs applicatives et d'audit ont vocation à être reversées dans ce répertoire. Les logs de diagnostic/troubleshooting ne sont pas archivées et restent donc dans le répertoire logs.
Structure de répertoires avec un répertoire logs-to-collect dédié aux fichiers à archiver
Exemple de configuration avec logback
<file>logs/my-application.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- roll every day in a dedicated non-active folder -->
<fileNamePattern>logs-to-collect/my-application.%d{yyyyMMdd}.log</fileNamePattern>
</rollingPolicy>
...
</appender>
Compresser les fichiers lors de leur rotation
Dernière astuce pour faire plaisir aux équipes d'exploitation en limitant la consommation d'espace disque : nos frameworks de logs savent maintenant compresser les fichiers (zip ou gzip) lors des rotations. Cette compression n'a en général aucun impact sur les performances de nos applications grâce aux CPU multi-cœurs, cela simplifiera encore le script de collecte des logs.
Pour la recherche dans des fichiers compressés, il faut garder en tête zcat et gzcat qui permettent d'extraire simplement les informations utiles.
Exemple de fichier logback.xml avec un fichier d'audit avec rotation quotidienne qui ne traite que les loggers ayant la racine 'fr.xebia.audit' :
...
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- rotate and zip every day -->
<fileNamePattern>my-log-file.%d{yyyyMMdd-HHmm}.log.zip</fileNamePattern>
</rollingPolicy>
...
</appender>
Un fichier de configuration de logs prêt pour la production
Voici un fichier de configuration logback.xml prêt pour la production qui reprend toutes les bonnes pratiques de ce billet; il tient en 50 lignes .
<property name="LOGS_FOLDER" value="${catalina.base}/logs" />
<property name="LOGS_TO_COLLECT_FOLDER" value="${catalina.base}/logs-to-collect" />
<appender name="log-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOGS_FOLDER}/my-application.log</file>
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>WARN</level>
</filter>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${LOGS_TO_COLLECT_FOLDER}/my-application.%d{yyyyMMdd-HHmm}.log</fileNamePattern>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy/MM/dd HH:mm:ss,SSS} [%thread] %-5level %logger{36} - %m %throwable{0}%n</pattern>
</encoder>
</appender>
<appender name="audit-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOGS_FOLDER}/my-application-audit.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${LOGS_TO_COLLECT_FOLDER}/my-application-audit.%d{yyyyMMdd-HHmm}.log.gzip</fileNamePattern>
</rollingPolicy>
<encoder>
<pattern>%m %throwable{0}%n</pattern>
</encoder>
</appender>
<appender name="troubleshooting-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOGS_FOLDER}/my-application-troubleshooting.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
<fileNamePattern>${LOGS_FOLDER}/my-application-troubleshooting.%i.log</fileNamePattern>
<maxIndex>10</maxIndex>
</rollingPolicy>
<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<maxFileSize>10MB</maxFileSize>
</triggeringPolicy>
<encoder>
<pattern>%d{yyyy/MM/dd HH:mm:ss,SSS} [%thread] %-5level %logger{36} - %m%n</pattern>
</encoder>
</appender>
<logger name="fr.xebia.audit" additivity="false" level="TRACE">
<appender-ref ref="audit-file" />
</logger>
<root level="WARN">
<appender-ref ref="log-file" />
<appender-ref ref="troubleshooting-file" />
</root>
</configuration>
Pourquoi je préfère Logback à Log4j
Au delà du comparatif Reasons to prefer logback over log4j que maintient le projet Logback avec un zest de chauvinisme, je trouve que le compactage des stack traces en préservant les causes d'une exception est vraiment différenciant. Je ne vois pas de solution pour le faire avec Log4j sans hacker la librairie. J'ai proposé le patch "Bug 48902 - log4j-extras - Enhancement : add %throwable{compact} to EnhancedPatternLayout" mais la gestion des causes de l'exception n'a pas été intégrée.
Conservation de la cause d'une exception avec Logback et le pattern "%thread %-5level %logger{36} - %msg %throwable{1}%n"
at fr.xebia.test.LoggerTest.callingMethod(LoggerTest.java:52)
at fr.xebia.test.LoggerTest.testLogback(LoggerTest.java:38)
Caused by: java.lang.RuntimeException: Ze cause
at fr.xebia.test.LoggerTest.nestedMethod(LoggerTest.java:45)
at fr.xebia.test.LoggerTest.callingMethod(LoggerTest.java:50)
Perte de la cause d'une exception avec Log4j et le pattern "%t %5p %c - %m %throwable{3}%n" :
at fr.xebia.test.LoggerTest.callingMethod(LoggerTest.java:52)
at fr.xebia.test.LoggerTest.testLog4j(LoggerTest.java:28)
J'apprécie aussi le fichier de configuration de test logback-test.xml, l'activation du rafraichissement de la configuration avec scan="true" et bien d'autres détails de Logback qui pourraient faire l'objet d'un prochain billet.
Bonjour,
Excellent billet comme toujours. Comme quoi, tout n'a pas été dit sur les logs
Juste un bémol. Il me semble que ce n'est pas à l'application de décider de la rotation ou non des logs et quand elle doit se faire. Il s'agit plutôt d'une tâche d'exploitation sur laquelle l'administrateur système doit avoir la main sans avoir à modifier l'application (ou un fichier du classpath ou que celui-ci puisse se trouver). C'est pour cela qu'il est fortement conseillé d'utiliser "logrotate" (http://fr.gentoo-wiki.com/wiki/Logrotate) et non pas un framework applicatif.
@Waddle,
Merci pour votre retour d'expérience. Je vous rejoins sur le fait que la gestion des logs relève de l'équipe d'exploitation mais je crains d'avoir une opinion différente sur l'ajout a logrotate à nos applications Java
.
Je préfère demander aux équipes de développement et d'exploitation de s'accorder sur la configuration du framework de logs plutôt que d'ajouter une couche intermédiaire logrotate/cronolog dont le comportement est subtile et souvent mal compris.
Comment se comporte un fichier de log géré par un processus java quand une autre application essaie d'en modifier le contenu ? En plus de dépendre du système d'exploitation, ce comportement variera selon que nous demandons à logrotate de faire un move+create ou un copy+truncate ... On entre dans l'art des systèmes de fichiers
.
Je suis surement échaudé par ma dernière expérience dans ce domaine : la rotation du fichier catalina.out de Tomcat avec cronolog. En théorie assez banal (1). Durant les deux années que j'ai passé sur cette plateforme, cette rotation n'a jamais été fiable et nous avons régulièrement perdu des journées entières de logs
.
Vous semblez avoir été plus chanceux que moi ; à chaque situation ses solutions
.
Cyrille
(1) http://www.tomcatexpert.com/knowledge-base/rotating-catalinaout-log-files
Effectivement, l'expérience de chacun rend plus ou moins méfiant à certains outils ou techniques, c'est tout ce qu'il y a de plus naturel. Simplement, je trouve plus logique de regrouper la stratégie de rotation au niveau système surtout si plusieurs technos et/ou applications cohabitent. De plus, les équipes d'exploitations doivent savoir utiliser les outils comme logrotate. Si ce n'est pas le cas, je vous invite à m'envoyer un mail, nous faisons de l'hébergement (entre autre), et nos équipes sont très qualifiées
@Waddle
Un Contegix à la française ??? Un hébergeur qui sait lire des stack traces ? Il faut nous en dire plus ... et proposer une soirée au Paris JUG sur Java vu par un hébergeur. Plutôt que de vous envoyer un email privé, c'est une demande publique
.
Pour revenir à "logrotate over java", comment se passe la concurrence d'accès en écriture sur le fichier ? Simplifions en nous limitant à Linux avec un file appender Logback ou Log4j. Faut-il utiliser logrotate en copy+create ou move+create ?
Cyrille
Concernant l'utilisation des logs pour suivre la dispo de l'appli (par contrôle de l'autgmentation de la taille), ça m'a valu une de mes plus grosse rigolade professionnelle (jaune, la rigolade). Le système comparait la taille des logs à 5 mins d'intervalle, et si cette taille n'avait pas augmenté, une relance des serveurs était effectuée.
La conséquence : entre 1h du mat et 5 h du mat, une relance toutes les 5 minutes...
En conclusion, cette solution est un pur hack, et franchement un hack complètement crétin. Sin on a besoin de vérifier qu'une application est présente, il y a des outils pour cela (patrol, etc...)
Sinon, un autre type de logs est très intéressant à mettre en place : le log d'utlisation de resources partagées. Par exemple, un log pour les connexion à une base de données, de serveur LDAP, etc. cela permet d'évaluer les pics de charge sur ces resources. Pratique.
Je préfère pas faire de pub publique dans les commentaires de votre blog puisque nous sommes concurrents sur d'autres aspects
mais si vous êtes intéressé, je suis dispo pour vous donner des infos.
Pour logrotate, il faut le configurer en copytruncate. Attention, s'il y a vraiment plein de lignes de logs, pendant une fraction de seconde, quelques lignes peuvent être perdues. Rien de rédhibitoire normalement.
Merci pour cet article. En ce qui concerne le format des fichiers de configuration, logback supporte depuis peu le format groovy qui est plutôt agréable à utiliser. Pour plus d’infos voir http://logback.qos.ch/manual/groovy.html
S’agissant des exceptions, logback peut inclure des informations sur le packaging qui peut être parfois extrêmement utile : http://logback.qos.ch/manual/layouts.html#xThrowable
--
Ceki
Évaluer la charge d'une application ou d'une ressource (SGBD, JMS, LDAP) par rapport à ses logs ne me semble pas être une méthode appropriée.
JMX et les agents de monitoring sont d'avantages préconisés.
@Waddle,
Votre pudeur vous honore
je vous envoie de ce pas un email pour vous offrir un verre pour discuter de vive voix. Que les personnes intéressées par ce débat m'envoient un email 
> quelques lignes peuvent être perdues. Rien de rédhibitoire normalement.
J'ai récemment travaillé sur un site web qui permettait notamment d'uploader des photos. Il n'était pas possible de perdre quelques logs d'audit. Surtout si le but / la justification était de se dispenser de faire collaborer deux équipes pour écrire ensemble un fichier de configuration de logs.
Mon coeur s'incline toujours vers la rotation des fichiers de logs grâce à nos frameworks logback/log4j
Cyrille
@Ceki,
Merci, c'est un honneur d'avoir un commentaire d'une personne qui a autant impacté notre quotidien de javaiste.
Pour la configuration en groovy, comme je l'ai dit dans mon billet, je suis nostalgique de nos fichiers de configuration au format '.properties'. Pas tellement pour mes goûts personnels mais parce que mes interlocuteurs de l'exploitation préfèrent ce format à XML.
J'ai peur que groovy ne soit pas plus "sysadmin friendly" que ne l'est XML aux yeux des exploitants
Cyrille
@Sébastien,
Je suis bien d'accord avec vous ! J'ai été choqué la première fois que j'ai vu un exploitant évaluer la disponibilité d'une application java en faisant un 'ps'.
Finalement, la supervision de la disponibilité en regardant l'augmentation de la taille des fichiers de logs est beaucoup plus high-tech
Sur le fond, je vous rejoins totalement et nous travaillons à un billet concernant JMX.
Cyrille
Merci pour cet article qui exprime les besoins de l’exploitation. C’est toujours très intéressant de se placer du point de vue de l’exploitation.
S’agissant du format des fichiers de configuration, pour une personne capable de programmer, le format Groovy comparé au formats XML et properties offre une puissance d’expression très largement supérieure. Il me semble que dans la majorité des cas, une fois qu’on goutte à ce nouveau format (logback.groovy), on ne peut plus revenir en arrière mais on n’a pas encore suffisamment de recul sur le sujet.
Vivement le prochain article,
@Cyrille
Toujours dispo pour une discussion autour d'un verre
J'ai également travaillé sur un site dernièrement pour un assureur ou certaines traces devaient être conservées et avaient en outre une valeur légale. Nous avons opté dans ce cas pour un stockage de ces "logs" en base plutôt que dans un fichier, mais on s'éloigne du sujet
Question pseudo-technique :
Quelle est l'impact de garder les numéros de ligne dans les logs ?
(impact en terme de perf, de compilation)
Pour info, le format donnerait : %method\(%line\
Je pense que cela a une certaine valeur quand le code n'est pas forcément écrit (grosses méthodes...).
Merci,
Tom
@Tom,
L'affichage du numéro de ligne de code java qui a généré le message de log est très couteux et ne devrait pas être activé en production si les performances sont importantes. Ce coût provient du fait que le framework de logs doit générer une stack trace puis parser la chaine de caractère pour en extrait le numéro de ligne.
Extrait de la documentation de logback :
Un refactoring simple et rapide pour comprendre quelle ligne de code a émis un message de log est de s'assurer que chaque message est différent. En plus d'être un "quick win", cette tactique améliorera la qualité des logs en les rendant plus explicites.
Dans un deuxième temps, le refactoring des méthodes obèses peut être entrepris si c'est compatible avec les enjeux du projet ...
Cyrille
@Waddle,
Ecrire des logs dans une base, je crains d'avoir une fois de plus une sensibilité différente
Je n'en dévoile pas plus aujourd'hui car la gestion de l'audit est le sujet de mon prochain billet.
Pour boire un verre, faute de session du Paris JUG en Aout, le touilleur-express a évoqué un apéro geek cet été, ce poourrait-être l'occasion
Cyrille
@Ceki ,
groovy vs. xml vs. properties
Je crois qu'il est nécessaire que j'ajoute une deuxième partie à ce billet pour essayer la configuration groovy !
Réflexion faite, je vois deux raisons pour lesquelles les exploitants pourraient préférer groovy à XML pour configurer nos logs :
* les configurations sous forme de DSL se banalisent : Varnish Cache, lighthttpd, etc
* ils détestent tellement XML qui est tellement unfriendly à
grep,sed,awket autres expressions régulièresEn plus de xml et groovy, voyez vous une place pour une configuration de logback au format '.properties' ?
Information de packaging dans les stack traces ("xException{length}")
Ces informations sont biens pratiques pour diagnostiquer les problèmes de class loader et de jar qui embarquent 'la terre entière' dans des versions obsolète.
Connaissez-vous le cout en performances de l'ajout de cette information ?
Est-il raisonnable d'activer l'ajout d'information de packaging dans les stack trace en production ou est-ce à éviter en production comme le numéro de ligne du code source java ?
Cyrille
Pour faire bref, vu la faiblesse syntaxique du format .properties, je crois qu'il n'y aura pas de support pour logback.properties.
Concernant les informations de packaging dans les stack trace, cette information est activée par défaut car même si le coût d'extraction est élevé. En d’autres termes, le convertisseur %xEx est automatiquement ajouté sauf si l’utilisateur spécifie explicitement le convertisseur %ex ou %nopex. Le surcout de %xEx est payé qu'en cas d'exception, ce qui est par définition exceptionnel et devrait jamais impacter la performance.
A ce stade, je voudrais mentionner le convertisseur %caller qui peut s’avérer très pratique pour debugger certains problèmes survenant en production. (Attention, vu le surcoût, à activer que sélectivement.)
@Ceki
> vu la faiblesse syntaxique du format .properties ...
Faiblesse que ne dissuade pas les gens de régulièrement projeter des structures de données arborescentes ou orientées object dans du clef-valeur avec des clefs composées à grand renfort de '_', de numéros d'index et d'autres délices du genre
Je fais mon "coming out", je reconnais avoir il y a bien longtemps projeté une configuration arborescente dans un fichier properties avec jakarta commons-configuration. Je confesse aussi avoir propagé entre des pages web un shopping cart complet avec des champs cachés à la
"<input type='hidden' name='cart_item_3_id' ... />".Que celui qui n'a jamais fauté me jette la première pierre
.
Dans le même registre mais avec des technologies à la mode, avez-vous déjà entendu les propositions de no-sqliens casssendristes pour projeter un shopping cart dans du column-oriented ? On retrouve le style ".properties flamboyant" saupoudré d'un zeste d'expressions régulières sur les clefs ; un vrai régal
.
Malgré toutes ces hérésies, je suis assez d'accord avec vous sur le fond. Nous avons beaucoup plus riche que le format .properties en 2010.
Cyrille