web-dev-qa-db-fra.com

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

Nous utilisons la combinaison SLF4J + Logback depuis quelque temps déjà dans notre projet et nous en sommes assez satisfaits, mais notre stratégie de journalisation est relativement simple: nous utilisons des enregistreurs simples basés sur les classes et aucun élément 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] Marqueurs pour la journalisation. Ils me paraissent être une fonctionnalité intéressante pour ajouter un contexte sémantique à la journalisation - par exemple. Bien qu'une classe puisse gérer plusieurs problèmes, elle peut utiliser des marqueurs spécifiques à une tâche/à un problème 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 recherche vraiment n’est pas tellement pourquoi 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 de mots-clés délimités par des tirets/soulignements/ponctuations), devrait-il y avoir une sorte de pool de "noms standard", nommant des choses basées sur les fonctions de l'entreprise. Les questions que je peux probablement résoudre moi-même, 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 de disposer d'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 plus niveau général de la façon dont on mettrait en place la journalisation en utilisant des marqueurs de manière cohérente

javaloggingslf4jlogbackmarkers
114
Roland Tepp

Tout d'abord, comme @darioo a dit:

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

Donc, votre affirmation 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". Par exemple, vous pouvez découper en fonction d'un utilisateur particulier, mais filtrer en fonction de toute exception inattendue. Dans ce cas, vous créeriez une dimension MDC utilisateur et une UnexpectedException . Marqueur.

Mais ceci ne répond apparemment pas à la question que vous aviez en tête. Vous "parlez plutôt du niveau plus général de la manière dont on pourrait configurer la journalisation en utilisant des marqueurs de manière cohérente". Alors abordons cela:

MDC est pour trancher et couper en dés , et les marqueurs sont pour filtrer . Ces activités sont effectuées pendant les tests et en production. En tant que tel, vous devez déterminer les dimensions qui, selon vous, peuvent être utiles pour fractionner les données de journal et les cas dans lesquels il peut être utile de les filtrer, lors du prochain test/production. Chaque dimension reçoit une dimension MDC. Chaque cas obtient un marqueur. C'est aussi simple que cela.

Les développeurs n'ont pas besoin de prendre de décision ici. Une seule personne ou équipe devrait décider, au moment de la conception Le découpage, le découpage en dés et le filtrage doivent être pris en charge. Ceci devrait être éclairé en imaginant quel type de tâches d'analyse on s'attend à ce qu'on puisse leur demander de réaliser.

Cette même personne ou équipe devrait 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 être en conflit avec des ajouts ultérieurs. Les traits d'union et les soulignements sont extrêmement maigres et alarmants, mais notez qu'il peut être moins déroutant de lire les soulignements (au moins par rapport à CamelCase). ) dans le même temps, cela aurait agacé certains développeurs en raison de la difficulté à atteindre les clés requises.

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 cette position serrée (centralisée, délibérée), mais permettez aux développeurs d’obtenir des informations en retour s’ils estiment que les dimensions et les repères sont insuffisants pour la tâche à accomplir. Réviser/ajouter des dimensions et/ou des attributs selon les besoins.

Comprenez cette politique sera presque nécessairement spécifique à un 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 souhaitez pouvoir analyser les journaux dans ce scénario. Vous ne voulez probablement pas avoir à écrire un script compliqué pour essayer de savoir quel message appartient à quel contexte et quel état correspond à quel moment, n'est-ce pas? Encodez toutes les informations nécessaires, telles que les dimensions et les marqueurs, et évitez les tracas si quelque chose ne va pas.

89
user359996

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. Supposons donc que de nombreux utilisateurs s'amusent 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'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 certaines 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 votre service, il se connecte 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 insérés dans un fichier journal séparé, afin de pouvoir le surveiller. plus facilement pour la collecte statistique des utilisateurs qui abandonnent.

Règle de base:

  • 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 des habituels
67
darioo

Les marqueurs peuvent être utilisés pour color ou marquer une instruction single log. Ce que vous faites avec ces couleurs, c’est-à-dire les marqueurs, vous appartient entièrement. Cependant, deux modèles semblent être communs (le premier plus commun que le second) pour l’utilisation de marqueurs.

  1. Déclenchement : Il pourrait être demandé à certains appender d'effectuer une action en présence d'un marqueur donné. Par exemple, SMTPAppender peut être configuré pour envoyer un courrier électronique chaque fois qu'un événement de journalisation est marqué avec le NOTIFY_ADMIN marqueur quel que soit le niveau de journalisation. Voir déclenchement basé sur un marqueur dans la documentation de consignation. Vous pouvez également combiner des niveaux de journalisation 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 classe) de la couleur "DB". Vous pouvez ensuite filtrer pour "DB": désactivez la journalisation sauf pour les instructions de journal marquées avec DB. Voir le chapitre sur les filtres dans la documentation de logback pour plus d'informations (recherchez MarkerFilter).

29
Ceki

Tout comme un addendum, si vous utilisez logstash et que vous avez activé la journalisation json, il existe une autre utilisation potentielle de Marker: la journalisation des variables à associer à un message de journalisation spécifique. Cela 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

7
Mark D