enterprise-library - Quand devrais-je utiliser Tracing vs Logger.NET, Enterprise Library, log4net ou Ukadc.Diagnostics?




nlog system.diagnostics (6)

Comment choisir entre le traçage standard, Logger.NET, Enterprise Library, log4net ou Ukadc.Diagnostics?

Y at-il une situation où l’un est plus approprié que l’autre? ... ce serait quoi? (ASP.NET, application de la console, Azure Cloud, SOHO, Enterprise ...)

Quels sont les avantages ou les inconvénients?

Ai-je oublié d'autres grands cadres de journalisation?


Answers

Regardez le paquet NetLog.Logging sur GitHub, c'est ma création. Il possède une application de surveillance et suit le paradigme de l'API java.util.logging, car c'est ce que j'aime utiliser. Il dispose d'un verrou rotatif permettant d'accéder à «l'écriture» et le détenteur du verrou écrit tous les enregistrements en file d'attente, dans la limite d'une limite, avant de poursuivre. Cela permettra à la consignation d’être moins d’entrées / sorties à base de conflits et constitue un bon compromis.


Il y a beaucoup de questions similaires ici sur SO:

Vous avez manqué plusieurs frameworks de journalisation couramment utilisés. Voici une liste des frameworks couramment utilisés, dont certains que vous avez listés:

Abstractions de journalisation:

Additifs System.Diagnostics:

Autre

Quelques autres cadres de journalisation de codeplex (que j'ai vu mentionnés ici sur SO):

Pourquoi pourriez-vous choisir l'un sur l'autre? C'est un dur. C'est en grande partie une préférence personnelle. Une partie est de la supériorité technique (ou caractéristique).

Un inconvénient évident de tout cadre de journalisation (en particulier de tiers) est la qualité du support. Que faire si vous avez un problème avec log4net, NLog, Common.Logging, etc.? Serez-vous capable d'obtenir un correctif de la part des développeurs de ces frameworks? Cela n’est peut-être pas extrêmement important car le code source est disponible pour ces frameworks. Cependant, vous pourriez préférer NE PAS "hériter" de l'arborescence source uniquement pour apporter une correction ou pour ajouter une amélioration. Je dirai que les frameworks sont si extensibles que de nombreuses améliorations pourraient être ajoutées via des points d'extension normaux.

Si vous lisez les liens que j'ai postés ci-dessus, je pense qu'il est juste de dire, en se basant uniquement sur le nombre de mentions favorables, que log4net serait clairement le "gagnant". Il sera mentionné plus fréquemment comme le favori de l'exploitation forestière historique et ce que beaucoup de gens choisiraient d'utiliser à l'avenir.

NLog a ses partisans, il ne semble tout simplement pas avoir la pénétration, ou la conscience "prioritaire" de celle de log4net, même s'ils sont très similaires. Les capacités de NLog sont très similaires à celles de log4net et présentent l’avantage supplémentaire d’avoir traversé un cycle de développement important récemment.

Enterprise Library est souvent présentée comme un bon choix, mais presque aussi souvent que comme un choix terrible. Peut-être qu'une partie de sa réputation négative n'est peut-être pas aussi bonne que les premières versions? Peut-être que c'est mieux maintenant?

System.Diagnostics est souvent recommandé comme choix raisonnable avec au moins trois avantages importants: aucune dépendance vis-à-vis de tiers, de nombreux composants Microsoft sont équipés de System.Diagnostics, il est facilement extensible (probablement en ajoutant certaines fonctionnalités déjà présentes "gratuitement"). dans des cadres tels que log4net et NLog?). Si vous utilisez System.Diagnostics, je pense que le consensus serait (tout comme ma recommandation) d'utiliser des objets TraceSource plutôt que Trace.WriteLine / Debug.WriteLine.

Notez également que System.Diagnostics et WCF fonctionnent bien ensemble. Le trafic de messages WCF peut être enregistré avec System.Diagnostics et WCF propage également les informations d'activité System.Diagnostics (System.Diagnostics.CorrelationManager.ActivityId) entre les appels de limite de service WCF.

Je ne suis pas sûr que log4net continue de conserver son statut le plus favorisé. Comme il a été noté ailleurs dans SO, log4net ne semble pas faire l'objet de nombreux développements récemment (notez que je pense que "log4net is dead" est une exagération) alors que NLog 2.0 est actuellement en version bêta, la version finale étant attendue au premier trimestre. 2011 (Mise à jour: NLog 2.0 est sorti le 17 juillet 2011). Cela fait-il de NLog un meilleur choix que log4net? Je ne sais pas, mais je pense que, relativement parlant, NLog devrait recevoir au moins une considération égale lors du choix entre les deux et devrait probablement être le favori présumé du nouveau développement, du moins jusqu'à ce que le développement de log4net montre davantage de signes de vie.

log4net et NLog offrent des options de configuration très flexibles. Ils vous permettent d’avoir une granularité très fine dans la définition de vos instructions de consignation (par le modèle "standard" de définition d’un consignateur par type). Ils permettent également une extension facile des bibliothèques en vous permettant de développer vos propres objets "destination de journalisation" (log4net Appenders et NLog Targets) et "formatage" (convertisseurs de modèles log4net et NLog LayoutRenderers).

Outre le choix d'un cadre de journalisation, certains (beaucoup?) Préconisent d'isoler votre code d'application d'une dépendance stricte à un cadre de journalisation particulier en utilisant une couche d'abstraction. Cela peut prendre la forme de votre propre interface ILogger que vous implémentez, éventuellement par-dessus un framework existant. À l'avenir, vous pourrez changer de framework en implémentant votre ILogger sur un autre framework. Vous pouvez également utiliser DI / IoC pour injecter "ILogger" dans votre code. De nombreux frameworks DI / IoC fournissent une abstraction ILogger intégrée qui peut être configurée pour utiliser log4net, NLog ou Enterprise Library ou vous pouvez écrire votre propre implémentation ILogger et l'injecter). Qui se soucie de ce que la mise en œuvre est? Un autre moyen d'éviter que votre code ait une dépendance forte à un framework de journalisation spécifique consiste à utiliser un framework d'abstraction de journalisation existant tel que Common.Logging ou SLF. L'avantage est que, encore une fois, votre application ne dépend pas d'un cadre de journalisation spécifique. Cependant, certains diraient que vous venez d'échanger une dépendance (sur un cadre de journalisation) contre une autre (cadre d'abstraction de journalisation).

Deux autres remarques sur l'abstraction de la journalisation:

  1. Une bonne abstraction de journalisation devrait vous permettre de capturer la sortie de différents frameworks de journalisation dans le même fichier de sortie. Common.Logging appelle cela le "pontage". Supposons que vous avez écrit une application à l'aide de Common.Logging, soutenu par NLog. Supposons maintenant que vous utilisez une bibliothèque de classe tierce écrite directement à l'aide de log4net. Avec un système de pontage, vous pouvez capturer la sortie log4net (via un appender personnalisé) et la rediriger via Common.Logging afin que la sortie de journalisation de la bibliothèque de classes tierce puisse être visualisée dans le contexte de la sortie de journalisation de votre application.

  2. L'utilisation d'une abstraction de journalisation vous permet également de «tester» les infrastructures de journalisation pendant le développement. Vous pouvez commencer par penser que log4net est ce chemin-là, mais vous voulez vous laisser tenter par le NLog. En utilisant une abstraction de journalisation, il est relativement facile de basculer entre les deux. En fin de compte, vous pouvez choisir quel framework de journalisation, mais entre-temps, vous avez été en mesure d'écrire des montagnes de code qui ne dépend en aucune manière d'un framework de journalisation spécifique.

Une autre raison pour laquelle vous pouvez choisir un framework plutôt qu'un autre est l'environnement dans lequel vous travaillez. Si vous utilisez déjà une partie de la bibliothèque d'entreprise, cela peut être suffisant pour vous pousser à utiliser la journalisation de la bibliothèque d'entreprise.

Et si vous développez dans Silverlight? Vous pouvez choisir d'utiliser quelque chose comme Clog - une partie de Calcium . Vous pouvez également choisir d’utiliser NLog 2.0, qui est compatible Silverlight ET WP7.

Additifs System.Diagnostics (Ukadc.Diagnostics, Essential.Diagnostics). Ce ne sont pas des cadres de journalisation en tant que tels. Ils représentent plutôt des collections d'objets utiles et de points d'extension pouvant être utilisés avec la structure System.Diagnostics existante. Une des meilleures choses, à mon avis, que chacun de ces addons ajoute est la possibilité de formater votre sortie de journalisation, de la même manière que vous pouvez le formater avec log4net et NLog. Je n'ai pas utilisé Essential.Diagnostics, mais j'ai expérimenté avec Ukadc.Diagnostics et je pense que c'est vraiment cool. Il est même facile d'écrire vos propres "jetons de formatage".

Je ne sais pas si cela a complètement répondu à votre question (qui est quand même assez large), mais je pense qu’il ya matière à réflexion.


Je ne suis pas un fan de log4j ou de log4net. J'aime la fonction de journalisation java.util.net et je l'ai donc recréée pour la plupart sur le projet github nommé NetLog à l' https://github.com/greggwon/NetLog/ . N'hésitez pas à donner votre avis. J'essaie de gagner du temps pour mettre en place une configuration basée sur ConfigurationManager dans un fichier logging.properties. Avec java.util.logging, il était toujours assez facile d'utiliser les paramètres de propriété de ligne de commande pour spécifier l'emplacement de la configuration du journal. C'est beaucoup plus pénible avec .net si vous n'utilisez pas ConfigurationManager. Fournir un soutien pour CM ouvrira la porte à des relations différentes entre les enregistreurs et les gestionnaires, ce qui pourrait améliorer certaines choses.

NetLog inclut un EventLogHandler qui se connectera au journal des événements du système. Il a également un niveau Level.EventLog défini juste en dessous de "warning" ce qui vous permettra de nommer un "niveau" pour cibler EventLog sans utiliser "WARNING" ou "SEVERE". J'ai également un TCPSocketHandler qui vous permet de telnet dans la "journalisation" afin que vous puissiez avoir une "queue" sur les fenêtres, sans qu'un programme "queue" soit disponible.


Je viens de commencer à utiliser log4net dans VS2010 et j'ai découvert qu'il dépendait de System.Web ... ce qui le rend incompatible avec les cibles du cadre ".NET xx Client Profile" ... Compte tenu de ce que quelqu'un a posté sur Windows Update à l'aide de la Si le profil client est le choix redistribuable .NET, cela signifie que log4net ne peut plus être le consignateur de choix si vous souhaitez que votre code s'exécute sur la majorité des machines ...

Merci pour l'info sur les autres options - je vais les vérifier ...


Juste pour ajouter quelques éléments tirés de la conférence Build 2013 de Microsoft:

  • Log4NET sous forte charge a écrit dans un fichier principalement parce que ce processus est synchrone. Il est possible d'obtenir des conflits et des délais d'attente dans certaines conditions. Cela peut être vérifié en utilisant AppDynamics ou tout autre outil similaire.

  • NLog n'implémentant pas la mise en file d'attente, les appels d'E / S s'empilent sous charge.

  • Selon Microsoft, ETW utilise des tampons en anneau du noyau, ce qui est très efficace. .NET 4.5 et la structure de journal des événements combinée au bock d’application de journalisation sémantique (AKA SLAB) le rendront beaucoup plus efficace.


J'ai récemment été chargé de «prototyper un peu de loggin» pour un projet à venir. Je n'avais aucune expérience de cadre de journalisation. J'ai fait des recherches, réalisé des didacticiels, créé des applications de jeu, etc. sur Log4Net, NLog et Enterprise Library pendant quelques jours. Revenus 3-4 semaines plus tard et les mettre ensemble dans une démo cohérente. J'espère que cela vous sera utile.

Ma recommandation pour notre projet est la suivante:

  1. Utilisez une façade de journalisation (par exemple Common.Logging , SimpleLoggingFacade ) pour éviter les dépendances directes.
  2. Si nous finissons par utiliser Enterprise Library pour d'autres fonctionnalités, utilisez-le également pour la journalisation.
  3. Si nous finissons par utiliser quelque chose avec une dépendance sur Log4Net, utilisez Log4Net.
  4. Si rien de ce qui précède, utilisez NLog. Ce que je préférerais.

C'est basé sur ces résultats (opinions!):

  • Tous les 3 cadres sont capables et peuvent faire des choses sophistiquées. Nous voulons une solution de qualité, mais franchement, nous n'avons pas besoin de très haute performance ou de 60 types de récepteurs d'événements.
  • Tous les 3 ont des concepts de base très similaires.
  • Chacun a ses propres trucs sympas, comme le routage vraiment avancé, ou les noms de fichiers de journaux dynamiques, la troncature de fichiers, etc.
  • Tous les trois sont assez bien documentés à leur manière.
  • Pour un newb complet comme moi, ils étaient tous un peu maladroits au départ. Pas de différences drastiques ici pour les bases. Je m'en suis remis.
  • Lors de la révision des choses quelques semaines plus tard, NLog était clairement la plus facile à reprendre. J'avais besoin de très peu de soins. Avec Log4Net, j'ai dû revoir quelques exemples en ligne pour y aller. Avec EntLib, j'ai abandonné et recommencé les tutoriels à partir de zéro - j'étais complètement perdu.
  • Je ne pouvais pas comprendre comment EntLib faire certaines choses comme se connecter à la base de données. Ce pourrait être facile, mais c'était au-delà de ma limite de temps.
  • Log4Net et NLog ont une petite empreinte dans le code. EntLib est spammé, mais j'utiliserais une façade de toute façon.
  • J'ai accidentellement mal configuré EntLib et il m'a dit au moment de l'exécution. Log4Net n'a pas. Je n'ai pas eu une mauvaise configuration accidentelle avec NLog.
  • EntLib est livré avec un éditeur sympa app.config, dont vous avez besoin à 100%. NLog a un schéma de fichier de configuration pour que vous obteniez "intellisense". Log4Net est livré avec nada.

Donc, évidemment, j'aime NLog jusqu'à présent. Pas assez pour l'utiliser en dépit d'avoir une autre solution disponible, cependant.







.net log4net enterprise-library nlog system.diagnostics