Meilleures pratiques d'utilisation des marqueurs dans SLF4J / Logback

Nous utilisons la combinaison SLF4J + Logback dans notre projet depuis un certain temps maintenant et nous en sommes assez satisfaits, mais notre stratégie de journalisation est assez simple, utilisant des enregistreurs simples basés sur des classes et pas de trucs sophistiqués comme MDC ou Markers.

Ce que je veux savoir, c'est si quelqu'un dans la communauté utilise réellement ces fonctionnalités et comment elles sont utilisées pour améliorer la journalisation / le filtrage.

Je suis particulièrement intéressé par où, pourquoi et comment utiliser ^{[1] les} marqueurs pour la journalisation. Ils me semblent une fonctionnalité assez intéressante pour ajouter un contexte sémantique dans la journalisation - par exemple, alors qu'une classe peut gérer plusieurs problèmes, on peut utiliser des marqueurs spécifiques à une tâche / préoccupation pour discriminer les instructions de journal.

Quelles peuvent être les meilleures pratiques, conventions ou stratégies pour créer et utiliser des marqueurs dans la journalisation.

Mise à jour: Je suppose que ce que je recherche vraiment n'est pas tant pourquoi utiliser des marqueurs, mais plutôt la partie comment - y a-t-il quelques bonnes pratiques pour nommer les marqueurs (par exemple, utiliser du texte brut avec des espaces ou des noms de style de mot-clé délimités par tiret / soulignement / ponctuation ), devrait-il y avoir une sorte de pool de "noms standard", nommant des éléments basés sur les fonctions métier. Les questions que je peux probablement résoudre moi-même, mais si je veux utiliser ces fonctionnalités systématiquement et les présenter à une équipe de développeurs, il est logique d'avoir un ensemble de directives formalisables autour de ...

^[1] - En demandant comment utiliser les marqueurs, je ne demande pas vraiment comment utiliser l'API (c'est vraiment assez simple) - je fais plutôt référence au niveau plus général de la façon dont on pourrait configurer la journalisation en utilisant des marqueurs de manière cohérente

Tout d'abord, comme l'a dit @darioo:

• MDC est utilisé pour associer plusieurs événements avec quelques "entités"
• Les [marqueurs] sont utilisés pour les événements "spéciaux" que vous souhaitez filtrer des événements habituels

Donc, votre affirmation que vous souhaitez utiliser MDC pour cela. Les marqueurs servent à mettre en évidence les événements "spéciaux" - filtrage, si vous voulez - plutôt qu'à "découper". Par exemple, vous pouvez découper en fonction d'un utilisateur particulier, mais filtrer en fonction des exceptions inattendues. Dans ce cas, vous créeriez une dimension MDC utilisateur et un marqueur d'exception UnexpectedException .

Mais cela ne répond apparemment pas à la question que vous aviez en tête. Vous faites "plutôt référence au niveau plus général de la façon dont on mettrait en place la journalisation en utilisant des marqueurs de manière cohérente". Alors abordons cela:

MDC est pour le tranchage et le découpage en dés , et les marqueurs sont pour le filtrage . Ces activités sont réalisées pendant les tests et en production . En tant que tel, vous devez décider des dimensions auxquelles vous vous attendez qui peuvent être utiles pour découper les données du journal, et par quels cas il peut être utile de les filtrer, lors des tests / de la production. Chaque dimension obtient une dimension MDC. Chaque cas reçoit un marqueur. C'est aussi simple que ça.

Les développeurs n'ont pas besoin de prendre de décision ici. Une seule personne ou équipe doit décider, au moment de la conception , du type de découpage, de découpage en dés et de filtrage à prendre en charge. Cela devrait être éclairé en imaginant le type de tâches d'analyse que l'on s'attend à ce qu'on leur demande d'exécuter.

Cette même personne ou équipe doit décider de la convention de dénomination. C'est entièrement arbitraire . Choisissez quelque chose qui est esthétique, auto-descriptif (le plus important) et suffisamment spécifique pour ne pas entrer en conflit avec des ajouts ultérieurs. Les traits d'union et les traits de soulignement sont extrêmement pointilleux et alarmants, mais notez qu'il peut être moins déroutant pour les employés d'ESL de lire les traits de soulignement (du moins par rapport à CamelCase); dans le même temps, cela agacerait certains développeurs en raison de la difficulté à atteindre les clés requises.

Pour ce qui est de décider d'une politique, cela signifie simplement définir dans quels cas un marqueur ou une dimension MDC donné doit être utilisé . Gardez cela serré (centralisé, délibéré), mais permettez aux développeurs de recevoir des commentaires s'ils estiment que l'ensemble de dimensions et de marqueurs est insuffisant pour la tâche à accomplir. Révisez / ajoutez des dimensions et / ou des attributs selon les besoins.

Comprenez que cette politique sera presque nécessairement spécifique au projet . Tous les projets n'ont pas besoin du même type d'analyse de journalisation. Imaginez des scénarios de cauchemar. Imaginez ensuite comment vous aimeriez pouvoir analyser les journaux dans ce scénario. Vous ne voulez probablement pas avoir à écrire un script compliqué pour essayer de suivre quel message appartient à quel contexte, et quel état est quel à quel moment, non? Encodez toutes les informations nécessaires en tant que dimensions et marqueurs, et évitez les tracas en cas de problème.

Tout d'abord, MDC.

MDC est vraiment utile dans un environnement où vous avez une "entité" associée à un comportement. Un exemple typique: l'utilisateur interagit avec une application Web. Alors, disons que vous avez de nombreux utilisateurs qui jouent avec votre application Web. En utilisant MDC, vous pouvez facilement les suivre sans trop de tracas. Exemple simplifié:

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

Ici, vous utilisez MDC à deux endroits: pour le nom d'utilisateur et pour l'ID de session. De cette façon, vous pouvez facilement greper la session d'un utilisateur pour voir tout ce qu'il a fait.

Deuxièmement, les marqueurs.

Les marqueurs sont généralement utilisés pour des circonstances «spéciales», telles que l'envoi d'un e-mail à un administrateur pour des erreurs sérieusement critiques. Toutes les erreurs n'entrent pas toujours dans la même catégorie; certains doivent être traités de manière appropriée.

Ou, lorsqu'un utilisateur quitte votre service, il accède généralement à un journal INFO, mais vous pouvez également utiliser un marqueur pour de telles instances, si vous souhaitez que des événements tels que celui-ci soient placés dans un fichier journal séparé, afin que vous puissiez le surveiller. plus facilement pour la collecte statistique des utilisateurs qui abandonnent.

Règle de base:

• MDC est utilisé pour associer plusieurs événements avec quelques "entités"
• les marqueurs sont utilisés pour les événements "spéciaux" que vous souhaitez filtrer des événements habituels

Les marqueurs peuvent être utilisés pour colorer ou marquer une seule instruction de journal. Ce que vous faites avec ces couleurs, c'est-à-dire les marqueurs, dépend entièrement de vous. Cependant, deux modèles semblent être communs (le premier plus courant que le second) pour l'utilisation des marqueurs.

1. Déclenchement : certains appendeurs peuvent être invités à effectuer une action en présence d'un certain marqueur. Par exemple, SMTPAppenderpeut être configuré pour envoyer un e-mail chaque fois qu'un événement de journalisation est marqué avec le NOTIFY_ADMINmarqueur quel que soit le niveau de journalisation. Voir le déclenchement basé sur des marqueurs dans la documentation de logback. Vous pouvez également combiner des niveaux de journal et des marqueurs pour le déclenchement.

2. Filtrage : vous pouvez par exemple colorer / marquer tous vos journaux liés à la persistance (dans divers fichiers de classes multiples) avec la couleur "DB". Vous pouvez ensuite filtrer pour "DB": désactiver la journalisation sauf pour les instructions de journal marquées avec DB. Consultez le chapitre sur les filtres dans la documentation de connexion pour plus d'informations (recherchez MarkerFilter).

Tout comme un addendum, si vous utilisez logstash et que la journalisation json est activée, il existe une autre utilisation potentielle de Marker - pour les variables de journalisation à associer à un message de journal spécifique. C'est plus cohérent et plus facile à analyser que de l'inclure dans le corps du message. Très utile, si cela convient à votre cas d'utilisation.

Voir les détails ici:

https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event