Les meilleures méthodes d’utilisation des marqueurs dans SLF4J / Logback

Nous utilisons la combinaison SLF4J + Logback dans notre projet depuis un certain temps et nous en sums tout à fait satisfaits, mais notre stratégie de journalisation est assez simple: elle utilise des enregistreurs simples basés sur des classes et aucun outil sophistiqué 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 / filtrage.

Je suis particulièrement intéressé par où, pourquoi et comment utiliser [1] Markers for logging. Ils me semblent une fonctionnalité très intéressante pour append un contexte sémantique dans la journalisation – par exemple, pendant qu’une classe peut gérer plusieurs problèmes, on peut utiliser des marqueurs spécifiques aux tâches / préoccupations pour discriminer les instructions du 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 suis vraiment, ce n’est pas vraiment pourquoi utiliser des marqueurs, mais plutôt comment les nommer (par exemple, utiliser du texte brut avec des espaces ou des noms de mots-clés délimités ), devrait-il y avoir une sorte de pool de “noms standards”, nommant des éléments en fonction des fonctions métier. Les questions que je peux probablement résoudre pour 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 de disposer d’un ensemble de directives formelles concernant …


[1] – En demandant comment utiliser les marqueurs, je ne demande pas vraiment comment utiliser les API (c’est vraiment simple) – je fais plutôt référence au niveau plus général de la façon dont on configure la connexion 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 à quelques “entités”
  • [Marqueurs] sont utilisés pour les événements “spéciaux” que vous souhaitez filtrer par rapport aux événements habituels

Donc, votre assertion que vous voulez utiliser MDC pour cela. Les marqueurs servent à mettre en évidence les événements “spéciaux” – le filtrage, si vous voulez – plutôt que le “découpage en tranches”. 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 User MDC et un marqueur UnexpectedException .


Mais apparemment, cela ne répond 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 se connecte en utilisant systématiquement des marqueurs». Alors abordons cela:

MDC est utilisé pour le découpage en tranches et les dés et les marqueurs pour le filtrage . Ces activités sont réalisées lors des essais et de la production . En tant que tel, vous devez décider quelles dimensions vous souhaitez utiliser pour découper les données de journal, et quels cas il peut être utile de filtrer, lorsque les tests / la production sont effectués. Chaque dimension reçoit 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 une seule équipe devrait décider, au moment de la conception , quel type de découpage, de découpe et de filtrage doit être pris en charge. Cela devrait être informé en imaginant le type de tâches d’parsing auxquelles on peut s’attendre.

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

En ce qui concerne le choix d’une politique, cela signifie simplement définir dans quels cas une dimension de marqueur ou de MDC donnée doit être utilisée . Gardez cela serré (centralisé, délibéré), mais tenez compte des commentaires des développeurs s’ils estiment que l’ensemble des dimensions et des marqueurs sont insuffisants pour la tâche à accomplir. Réviser / append des dimensions et / ou des atsortingbuts, le cas échéant.

Comprenez que cette politique sera presque nécessairement spécifique au projet . Tous les projets n’ont pas besoin du même type d’parsing de journalisation. Imaginez des scénarios de cauchemar. Imaginez ensuite comment vous souhaitez pouvoir parsingr 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, non? Encodez ce que ces informations sont nécessaires en tant que dimensions et marqueurs, et évitez les problèmes si quelque chose ne va pas.

Tout d’abord, MDC.

MDC est vraiment utile dans un environnement où vous avez une “entité” associée à un comportement. Un exemple typique: utilisateur interagissant avec une application Web. Alors, disons que vous avez beaucoup d’utilisateurs qui déconnent avec votre application Web. En utilisant MDC, vous pouvez facilement les suivre sans trop de soucis. 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 organiser une 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 courrier électronique à un administrateur pour des erreurs graves. 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 son 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 se trouvent dans un fichier journal distinct, afin de pouvoir 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 à quelques “entités”
  • les marqueurs sont utilisés pour les événements “spéciaux” que vous souhaitez filtrer par rapport aux événements habituels

Les marqueurs peuvent être utilisés pour colorer ou marquer un seul relevé 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 des marqueurs.

  1. Déclenchement : Certains utilisateurs peuvent être invités à agir en présence d’un certain marqueur. Par exemple, SMTPAppender peut être configuré pour envoyer un courrier électronique chaque fois qu’un événement de journalisation est marqué avec le marqueur NOTIFY_ADMIN quel que soit le niveau de journalisation. Voir le déclenchement basé sur les marqueurs dans la documentation de récupération. Vous pouvez également combiner les niveaux de journal et les marqueurs pour le déclenchement.

  2. Filtrage : Vous pouvez par exemple colorer / marquer tous les journaux liés à la persistance (dans des fichiers de classes différents et multiples) avec la couleur “DB”. Vous pouvez ensuite filtrer pour “DB”: désactivez la journalisation à l’exception des instructions de journal marquées avec DB. Reportez-vous au chapitre sur les filtres dans la documentation de consignation pour plus d’informations (recherchez MarkerFilter).

En guise d’addenda, si vous utilisez logstash et que json logging est activé, Marker peut être utilisé pour consigner des variables à associer à un message de journal spécifique. Ceci est plus cohérent et plus facile à parsingr 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