Given that the comma ‘,’ character is the option separator, the pattern string [HH:mm:ss,SSS] will print the time in the [SSS] time zone which does not exist. Thus, the time will be printed in the default GMT timezone. If you wish to include a comma in your date pattern, then simply enclose the pattern between quotes. For example, %date{« HH:mm:ss,SSS »}.

Merci pour la remarque. La coquille est corrigée. J’avais activé une rotation à la minute pour vérifier le comportement de logback. C’est corrigé.

Cyrille

Niveau réalisation, JMX me semble mieux approprié pour modifier les logs à chaud.

Je me demandais si elle étais possible et pratique, de scinder un fichier de conf logback en 2 parties : une partie intégrée dans le war avec une configuration de log générique + 1 seconde partie en dehors du war, avec rechargement à chaud. L’intérêt étant d’être sûr de ne pas oublier le fichier de conf ni qu’il soit modifié par erreur et en même temps permettre pendant le run de sortir les traces de debug/trace d’une classe précise en cas de problème ?

> « Est ce qu’il y a un moyen de générer un identifiant pour les différents log qui sont enregistré ( pour le moment j’en génère a l’aide de combinaison (%relative %level). »

Votre besoin me rappelle les Mapped Diagnostic Context que j’ai déjà utilisé pour tracer un numéro de téléphone client chez un opérateur télécom ou un numéro de compte client dans une banque.

> « … moyen d’encapsuler (LogBack+SLF4J) pour les intégrés à toute sorte d’application sans que d’autres utilisateurs aient le droit de modifié quoi que ce soit que ca soit dans le fichier de configuration ou l’application elle même. »

Je préfère en général faire confiance aux équipes de développement et d’exploitation plutôt que de les contraindre. S’il y a un problème de confiance avec les uns ou avec les autres, je pense qu’il vaut mieux traiter sur le fond et se séparer des gens … dans la mesure où il y a réellement un problème .
J’ai travaillé dans des organisations qui ne faisaient pas confiance à telle ou telle équipe, souvent en méprisant leurs compétences et leur travail. C’était aussi désagréable qu’inefficace.

Le fonctionnement le plus efficace que j’ai vu est
1) les équipes de dév ajoutent des log dans leur code en faisant de leur mieux pour différencier trace/debug/info/warn/error . J’utilise souvent :
– warn : les comportements inattendus souvent des situations qui auraient pu mériter une IllegalStateException
– info : les messages qui me donnent une idée globale du fonctionnement de la zone
– debug : les informations détaillées dont j’ai besoin quand je troubleshoot précisément cette zone
– trace : les informations ultra détaillées que je ne devrais jamais activer mais que j’utilise quand en dernier recours pour débugger une zone de code quand je suis perdu,

2) les ops disent dans quel répertoire ils veulent ce fichier pour pouvoir le modifier à chaud
– avec Tomcat, il suffit de le placer dans WEB-INF/classes,
– avec les gros serveurs J2EE, il faut souvent sortir ce fichier des ear et war car les serveurs cachent les war « expandés » dans des répertoire que les exploitants ne savent pas trouver facilement,

3) les dév préparent le fichier de configuration des log (logback.xml, log4j.properties)
– le root logger à warn,
– les outputs xx.log/xx-troubleshooting.log/xx-audit.log et aussi souvent xx-perfs.log,
– certains logger à des niveaux inférieurs (info/debug) pour des cas particuliers,

4) les ops valident le fichier et le déploient en parallèle du war/ear s’il doit être situé à l’extérieur de l’artifact,

5) les ops peuvent modifier à chaud le fichier de configuration des logs pour changer les niveaux de logs suivant les besoins.

6) Devs et ops itèrent conjointement pour améliorer les messages

Cyrille (Xebia)

> 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

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.)

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, awk et autres expressions régulières

En 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

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

Extrait de la documentation de logback :

« Generating the line number information is not particularly fast. Thus, its use should be avoided unless execution speed is not an issue. »

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

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

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

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,

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, 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

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

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

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.

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.

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