Meilleures pratiques pour l'utilisation des marqueurs dans SLF4J/Logback

Question

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 loggers basés sur des classes simples et pas de trucs fantaisistes 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 le fait de savoir où, pourquoi et comment on peut utiliser [1] Marqueurs pour l'exploitation forestière. Ils me semblent être une fonctionnalité intéressante pour ajouter un contexte sémantique à la journalisation - par exemple, alors qu'une classe peut gérer de multiples préoccupations, on peut utiliser des marqueurs spécifiques aux tâches et aux préoccupations pour distinguer les déclarations de journalisation.

Quelles peuvent être les meilleures pratiques, conventions ou stratégies pour créer et utiliser des marqueurs dans l'exploitation forestière.

Mise à jour : Je suppose que ce que je cherche vraiment n'est pas tant pourquoi d'utiliser des marqueurs, mais plutôt le comment partie - existe-t-il des bonnes pratiques pour nommer les marqueurs (par exemple, utiliser du texte brut avec des espaces ou des noms de style mot-clé délimité par des tirets/underscore/punctuation), devrait-il y avoir une sorte de pool de "noms standard", nommant les choses en fonction des fonctions commerciales. Je peux probablement répondre moi-même à ces questions, mais si je veux utiliser ces fonctionnalités de manière systématique et les présenter à une équipe de développeurs, il est logique d'avoir un ensemble de directives formalisables...

---

[1] - En demandant comment utiliser marqueurs Je ne demande pas vraiment comment utiliser l'API (c'est vraiment très simple) - je me réfère plutôt au niveau plus général de comment mettre en place la journalisation autour de l'utilisation des marqueurs de manière cohérente.

Answer 1

D'abord, comme l'a dit @darioo :

• Le MDC est utilisé pour associer de multiples événements à 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 selon laquelle vous voulez utiliser le MDC pour cela. Les marqueurs servent à mettre en évidence des événements "spéciaux" - à filtrer, si vous voulez - plutôt qu'à "découper". Par exemple, vous pourriez découper en tranches en fonction d'un utilisateur particulier, mais filtrer en fonction de toute exception inattendue. Dans ce cas, vous créerez un Utilisateur dimension MDC et une UnexpectedException Marqueur.

---

Mais cela ne répond apparemment pas à la question que vous aviez à l'esprit. Vous faites "plutôt référence au niveau plus général de la façon dont on pourrait mettre en place une journalisation autour de l'utilisation cohérente des marqueurs." Alors répondons à cette question :

MDC est pour couper en tranches et en dés et les marqueurs sont pour filtrage . Ces activités sont réalisées pendant les essais et en production. . En tant que tel, vous devez décider quelles dimensions vous pensez qu'il peut être utile de découper les données du journal, et quels cas il pourrait être utile de filtrer contre, lorsque le test/production arrive. Chaque dimension reçoit une dimension MDC. Chaque cas reçoit un marqueur. C'est aussi simple que cela.

Les développeurs n'ont pas à prendre de décision ici. Une seule personne ou une seule équipe doit décider, au moment de la conception Il s'agit de savoir quel type de découpage en tranches, de découpage en dés et de filtrage doit être pris en charge. Pour ce faire, il faut imaginer le type de tâches d'analyse que l'on s'attend à devoir effectuer.

Cette même personne ou équipe doit décider de la convention de dénomination. C'est entièrement arbitraire . Choisissez quelque chose d'esthétiquement plaisant, auto-descriptif (le plus important), et suffisamment précis pour ne pas entrer en conflit avec des ajouts ultérieurs. Traits d'union vs. L'utilisation de l'underscores est extrêmement pointilleuse et n'a rien à voir avec le sujet, mais il faut noter qu'il peut être moins déroutant pour les employés anglophones de lire les underscores (au moins par rapport à la casse camel) ; en même temps, cela semble gêner certains développeurs en raison de la difficulté à atteindre les touches requises.

Pour ce qui est de décider d'une politique, cela signifie simplement que définir dans quels cas un marqueur ou une dimension MDC donnés doivent être employés . Maintenez ce processus rigoureux (centralisé, délibéré), mais permettez aux développeurs de réagir s'ils estiment que l'ensemble des dimensions et des marqueurs est insuffisant pour la tâche à accomplir. Révisez/ajoutez des dimensions et/ou des attributs si nécessaire.

Comprendre cette politique sera presque nécessairement spécifique au projet . Tous les projets ne nécessitent pas le même type d'analyse d'enregistrement. Imaginez quelques scénarios cauchemardesques. Puis imaginez comment vous aimeriez pouvoir analyser les logs 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 de ce type nécessaires sous forme de dimensions et de marqueurs, et épargnez-vous une partie des tracas si quelque chose ne va pas.

Answer 2

D'abord, le MDC.

MDC est vraiment utile dans un environnement où vous avez une "entité" associée à un certain comportement. Un exemple typique : un utilisateur qui interagit avec une application web. Supposons que de nombreux utilisateurs utilisent votre application Web. En utilisant MDC, vous pouvez facilement les suivre sans trop de difficultés. 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 grep 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 dans des circonstances "spéciales", comme l'envoi d'un courrier électronique à un administrateur pour certaines erreurs sérieusement critiques. Toutes les erreurs n'entrent pas toujours dans la même catégorie ; certaines doivent être traitées de manière appropriée.

Ou encore, lorsqu'un utilisateur quitte votre service, l'événement est généralement consigné dans un journal INFO, mais vous pouvez également utiliser un marqueur pour ces cas, si vous souhaitez que des événements comme celui-ci soient consignés dans un fichier journal distinct, afin de pouvoir le surveiller plus facilement pour établir des statistiques sur les utilisateurs qui quittent le service.

Règle générale :

• MDC est utilisé pour associer de multiples événements à quelques "entités".
• les marqueurs sont utilisés pour les événements "spéciaux" que vous souhaitez voir filtrer des événements habituels.

Answer 3

Les marqueurs peuvent être utilisés pour couleur ou marquer un simple déclaration de journal. Ce que vous faites de ces couleurs, c'est-à-dire des marqueurs, vous appartient entièrement. Cependant, deux modèles semblent être communs (le premier plus commun que le second) pour l'utilisation des marqueurs.

1. Déclenchement : Un appender pourrait recevoir l'instruction d'effectuer une action en présence d'un certain marqueur. Par exemple, SMTPAppender peut être configuré pour envoyer un courriel chaque fois qu'un événement de journalisation est marqué avec l'icône NOTIFY_ADMIN quel que soit le niveau du journal. Voir déclenchement basé sur des marqueurs dans la documentation de logback. Vous pouvez également combiner les niveaux de journalisation et les marqueurs pour le déclenchement.

2. Filtrage : Vous pourriez par exemple colorer/marquer tous vos logs liés à la persistance (dans des fichiers de classe divers et multiples) avec la couleur "DB". Vous pourriez ensuite filtrer pour "DB" : désactiver la journalisation sauf pour les déclarations de journal marquées avec DB. Voir le chapitre sur les filtres dans la documentation de logback pour plus d'informations (recherchez MarkerFilter).

Answer 4

En guise d'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 journalisation spécifique. C'est plus cohérent et plus facile à analyser que de les 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

Answer 5

L'avantage des MDC est qu'ils sont renseignés dans le thread : prenons le cas d'une méthode pour laquelle un log est envoyé à la fin. Tout au long de la méthode et de l'appel des sous-méthodes, vous pouvez remplir le MDC avec les informations recueillies au cours du programme. Lorsque le log est lancé à la fin, il contient le MDC et toutes les informations que l'on aurait pu y mettre. Avec le patron approprié, nous pouvons récupérer les informations du MDC.

D'autre part, le marqueur est directement associé au journal.