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

Question

Nous utilisons la combinaison SLF4J + Logback dans notre projet depuis un certain temps et nous en sommes plutôt satisfaits, mais notre stratégie de journalisation est assez simple, utilisant des enregistreurs basés sur les classes simples et sans fantaisie. comme MDC ou Marqueurs. 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 utiliserait-on ^[1] Marqueurs pour la connexion. Ils me semblent être une caractéristique assez intéressante pour ajouter un contexte sémantique dans la notation - par ex. alors qu'une classe peut gérer plusieurs problèmes, on peut utiliser des marqueurs spécifiques de 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, ce que je suis vraiment après est pas tant pourquoi d'utiliser des marqueurs, mais plutôt comment partie — est-il des bonnes pratiques de marqueurs de nommage (par exemple en utilisant le texte brut avec des espaces ou dash/underscore/noms de style de mot clé délimités par des signes de ponctuation), devrait-il y avoir une sorte de pool de "noms standards", nommant des choses basées sur les fonctions business. Les questions que je peux sans doute comprendre pour moi, 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 lignes directrices formalizeable autour de ...

---

^[1] - En demandant comment utiliser marqueurs Je ne demande pas vraiment comment utiliser l'API (c'est vraiment assez simple) - je me réfère plutôt au niveau plus général de la façon dont on se connecterait en utilisant des marqueurs uniformément

Answer 1

d'abord, comme @darioo dit:

• MDC est utilisé pour associer plusieurs événements avec quelques « entiti es »
• [marqueurs] sont utilisés pour des « événements spéciaux » que vous voulez avoir filtré habituelles

Ainsi, votre affirmation que vous voulez utiliser MDC pour cela. Les marqueurs servent à mettre en évidence les événements «spéciaux» - filtrage, si vous préférez - plutôt que «tranchage». Par exemple, vous pouvez découper en fonction d'un utilisateur particulier, mais filtrer en fonction des exceptions inattendues. Dans ce cas, vous devez créer une dimension MDC User et une marqueuse 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 pourrait se connecter en utilisant des marqueurs de manière cohérente». Donc nous allons aborder que:

MDC est pour découpage en tranches et couper en dés et marqueurs sont pour filtrage. Ces activités sont effectuées pendant les essais et en cours de production. En tant que tel, vous devez décider quelles dimensions vous pensez être utiles pour découper les données du journal, et dans quels cas il peut être utile de le filtrer, lorsque le test/production arrive. Chaque dimension obtient une dimension MDC. Chaque cas obtient un marqueur. C'est aussi simple que ça.

Les développeurs n'ont pas besoin de prendre de décisions ici. Une seule personne ou une seule équipe doit décider, au moment du design, quel type de découpage, de découpage en dés et de filtrage doit être pris en charge. Cela devrait être informé en imaginant quel type de tâches d'analyse on s'attend à ce qu'ils peuvent être invités à effectuer.

Cette même personne ou équipe devrait décider de la convention de nommage. C'est entièrement arbitraire. Choisissez quelque chose qui est esthétique, auto-descriptif (le plus important), et assez spécifique pour ne pas entrer en conflit avec des ajouts ultérieurs. Hyphens vs souligne est extrêmement nitpicky et alarmant à côté du point, mais notez qu'il peut être moins déroutant pour les employés ESL de lire les traits de soulignement (au moins par rapport à CamelCase); dans le même temps, cela aurait gêné certains développeurs en raison de la maladresse d'atteindre les clés nécessaires.

En ce qui concerne la définition d'une politique, cela signifie simplement , définissant dans quels cas une dimension Marqueur ou MDC donnée doit être utilisée. Gardez ceci serré (centralisé, délibéré), mais tenez compte des commentaires des développeurs s'ils sentent que l'ensemble des dimensions et des marqueurs sont insuffisants pour la tâche à accomplir. Réviser/ajouter des dimensions et/ou des attributs selon le cas.

Comprendre 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. Ensuite, imaginez 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 moment, n'est-ce pas? Encodez toutes les informations nécessaires en termes de dimensions et de marqueurs, et évitez les tracas si quelque chose ne va pas.

Answer 2

D'abord, MDC. MDC est vraiment utile dans un environnement où vous avez une "entité" qui est associée à un certain comportement. Un exemple typique: l'utilisateur interagit avec une application web. Ainsi, disons que vous avez de nombreux utilisateurs à jouer 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 grep la session d'un utilisateur pour voir tout ce qu'ils ont fait.

Deuxièmement, les marqueurs. Les marqueurs sont généralement utilisés pour des circonstances "spéciales", telles que l'envoi d'un courrier électronique à un administrateur pour des erreurs critiques majeures. Toutes les erreurs ne tombent 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 se rend généralement dans un journal INFO, mais vous pouvez également utiliser un marqueur pour de telles instances, si vous souhaitez que des événements comme celui-ci apparaissent dans un fichier journal distinct, vous pouvez le surveiller plus facilement pour la collecte statistique des utilisateurs qui quittent.

Règle générale:

• MDC est utilisé pour associer plusieurs événements avec quelques « entités »
• marqueurs sont utilisés pour des événements « spéciaux » que vous voulez avoir filtré habituelles

Answer 3

Les marqueurs peuvent être utilisés pour couleur ou marquer une seule déclaration 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 commun que le second) pour l'utilisation de marqueur.

1. Déclencher: Certains appender pourrait être chargé de prendre une mesure en présence d'un certain type de marqueur. Par exemple, SMTPAppender peut être configuré pour envoyer un e-mail chaque fois qu'un événement de journalisation est marqué avec le marqueur NOTIFY_ADMIN, quel que soit le niveau de journalisation. Voir marker-based triggering 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 couleur/marquer tous vos journaux liés à la persistance (dans divers et plusieurs fichiers de classe) avec la couleur « DB ». Vous pouvez ensuite filtrer pour "DB": désactiver la journalisation à l'exception des instructions de journal marquées avec DB. Voir le chapter on filters dans la documentation de logback pour plus d'informations (recherche de MarkerFilter).

Answer 4

Tout comme un supplément, si vous utilisez logstash et que vous avez l'enregistrement JSON est activée, il y a une autre utilisation potentielle de marqueur - pour les variables d'exploitation forestière à associer à un message de journal spécifique. Ceci 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