System.Diagnostics.Debug命名空间与其他日志记录解决方案(log4net，MS Enterprise Library等) [英] System.Diagnostics.Debug namespace vs Other logging solutions (log4net, MS Enterprise Library, etc.)

问题描述

我目前正在研究.net项目的各种日志记录可能性，但我无法在System.Diagnostics.Debug/Trace功能和第三方库(例如log4net，MS Enterprise Library，NLog等)之间进行选择.
目前，我发现了这一点:

I'm currently investigating various logging possibilities for .net projects and I can't decide between System.Diagnostics.Debug/Trace features and third party libraries like log4net, MS Enterprise Library, NLog, etc.
At the moment I have found out this:

• System.Diagnostics的配置和使用相当困难，因为您需要显式配置所有侦听器，过滤器，源等.似乎它也缺少向数据库的大容量插入(考虑写入100'000日志)每个条目都有自己的插入内容，令人恐惧，不是吗?).但是有些人认为不使用额外的库来进行Logging这样的基本"操作是很酷的"(当然，在某些时候，减少项目所依赖的第三方库的数量是有意义的，我想这不是这次)
• 第三方功能强大得多，通常更快，更易于使用，但是配置有时也会很痛苦，而且这些库的可靠性通常较差(例如EntLib突然停止日志记录等)
• Common.Logging呢?是否值得尝试(因为据我所知，它提供了插入各种日志记录框架的功能，就像应用程序和所需的lib之间的接口一样?)

如果有人能指出我正确的方向或对以上给出的比较进行纠正(或添加一些内容)，我将不胜感激！也许，如果您鼓励我使用第三方，则可以建议一些特定的第三方(考虑到我们的应用程序很可能不需要像UDP，滚动文件等任何奇特的东西-只需纯文件，电子邮件，数据库和事件记录日志)?
预先感谢！

I would be really grateful if somebody could point me to the right direction or correct (or add something) to my comparison given above! Maybe if you would encourage me to use 3rd parties, you could advise some particular one (taking into account that our applications most probably won't need any fancy stuff like UDP, rolling files, etc.- just plain file, email, DB and eventlog)?
Thanks in advance!

推荐答案

在一般情况下，您都可以在StackOverflow上找到有关log4net和NLog的大量信息.

You can find plenty of information about log4net and NLog either here on StackOverflow on by more generally googling.

您还可以找到许多有关System.Diagnostics的信息.关于System.Diagnostics需要注意的一件事，我认为您会在StackOverflow上找到许多有关使用Debug.Write/WriteLine和Trace.Write/WriteLine的引用.一种可以说是更好"的方法是使用TraceSources. TraceSources类似于log4net和NLog中的记录器. TraceSources可以使您的日志记录消息具有更高的粒度，从而可以更轻松地打开和关闭某些日志记录(除了按级别以外，还可以按类或类别).与log4net和NLog相比，TraceSource具有一个缺点，因为您在代码中创建的每个TraceSource必须在app.config中显式配置(如果您希望它实际记录).

You can also find a lot of info about System.Diagnostics. One thing to note about System.Diagnostics, I think that you will find a lot of references here on StackOverflow about using Debug.Write/WriteLine and Trace.Write/WriteLine. An arguably "better" way is to use TraceSources. TraceSources are analogous to loggers in log4net and NLog. TraceSources allow you to have a higher degree of granularity for your logging messages, making it easier to turn some logging on and some off (by class or category, in addition to by level). TraceSources to have a drawback, as compared to log4net and NLog, in that each TraceSource that you create in your code must be explicitly configured in the app.config (if you want it to actually log).

log4net和NLog具有分层的概念，如果未明确配置所需的确切记录器，则检查其祖先"以查看是否配置了任何祖先"，如果是，则请求的记录器继承"那些设置.祖先只是记录器名称中由."分隔的部分. (因此，如果您请求一个名为"ABC.DEF.GHI"的记录器，则其祖先将是"ABC.DEF"和"ABC").还可能(必需?)在app.config中具有根"记录器配置，如果未明确配置所有记录器且未配置祖先，则所有记录器请求都将回退.因此，您可以仅将"root"记录器配置为在某个级别进行记录，而您代码中的所有记录器都将在该级别进行记录.或者，您可以将根"记录器配置为关闭"，然后显式打开一个或多个记录器(或通过配置祖先).这样，没有记录器会记录已配置的记录器.

log4net and NLog have a hierarchical concept where if the exact logger you asked for is not explicitly configured, its "ancestry" is checked to see if any "ancestors" are configured and, if so, the requested logger "inherits" those settings. Ancestors are simply the portions of the logger name delimited by ".". (So, if you request a logger called "ABC.DEF.GHI", the ancestors would be "ABC.DEF", and "ABC"). It is also possible (required?) to have a "root" logger configuration in the app.config that ALL logger requests will fall back to if they are not explicitly configured and no ancestors are configured. So, you could configure only a "root" logger to log at a certain level and all of your loggers in your code would log at that level. Alternatively, you could configure the "root" logger to be "off" and then turn on one or more loggers explicitly (or by configuring an ancestor). In this way, NO loggers would log EXCEPT for those that are configured.

如果您在此处，您将在System.Diagnostics TraceSources周围找到一个有趣的包装，该包装提供了与log4net和NLog非常相似的继承功能.

If you look here, you will find an interesting wrapper around System.Diagnostics TraceSources that provides an inheritance capability very similar to log4net and NLog.

说明:

log4net和NLog中记录器的常见用法是获得这样的记录器:

A common usage pattern for loggers in log4net and NLog is to get a logger like this:

//log4net
static ILog logger = LogManager.GetLogger(
                     System.Reflection.MethodBase.GetCurrentMethod().DeclaringType); 

//NLog
static Logger logger = LogManager.GetCurrentClassLogger();

在两种情况下，记录器的名称均为标准类型名称.

In both cases the logger's name will be the fully qualified type name.

如果需要，可以在app.config文件中配置"root"记录器，并且两个记录器都将继承root记录器的设置(级别，附加程序/目标等).或者，您可以为某些名称空间配置记录器.在该名称空间中定义了类型的所有记录器都将继承这些记录器设置.

In the app.config file, you can, if you desire, configure just the "root" logger and both loggers would inherit the root logger's settings (level, appenders/targets, etc). Alternatively you could configure a logger for some namespace. Any loggers whose type is defined in that namespace will inherit those logger settings.

足够使用log4net和NLog，您可能已经知道它们如何工作.

Enough of log4net and NLog, you probably already know how they work.

上面的链接说明了基于TraceSource的包装器，该包装器允许进行类似的配置.因此，如果您愿意，您可以在课堂上做类似的事情:

The link above illustrates a TraceSource-based wrapper that allows similar configuration. So, if you wanted, you could do something like this in your classes:

static TraceSource ts = new TraceSource(
               System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

使用上面的包装器，您可以在较高级别(级别上是类/命名空间，而不是级别)上配置TraceSource，并在较低级别的记录器中继承这些设置.

With the wrapper linked above, you could configure a TraceSource at a higher level (class/namespace hierarchy-wise, not level) and inherit those settings in lower level loggers.

因此，如果您的标准类型名称是这样的:ABC.DEF.GHI，则可以为ABC或ABC.DEF(命名空间级别)配置TraceSource，并且类"GHI"将继承设置.这确实可以减少您要做的配置量.

So, if your full-qualified type name is something like this: ABC.DEF.G then you can configure a TraceSource for ABC or ABC.DEF (namespace level) and class "GHI" would inherit the settings. This could really reduce the amount of configuration that you have to do.

请注意(使用这些日志平台中的任何一种)，您不限于使用类的类型或类型名称来获取记录器.您可以根据功能区域(通信"，通信.发送"，通信.接收"等)定义自己的记录器命名方案.同样，您可以要求(或不希望)具有最高粒度的logger/TraceSource，然后以任何有意义的粒度级别进行配置.

Note that you are not limited (with any of these logging platforms) to using the class's type or type name to get the logger. You could define your own logger naming scheme, possibly based on functional areas ("Communication", "Communication.Send", "Communication.Receive", etc). Again, you could request a logger/TraceSource at the highest degree of granualarity (or not) and then configure at whatever level of granularity makes sense.

因此，您可以像这样在代码中请求记录器:

So, you could request loggers in your code like this:

ILog logger = LogManager.GetLogger("Communication.Receive");
ILog logger = LogManager.GetLogger("Communication.Send");

Logger logger = LogManager.GetLogger("Communication.Receive");
Logger logger = LogManager.GetLogger("Communication.Send");

TraceSource ts = new TraceSource("Communication.Receive");
TraceSource ts = new TraceSource("Communication.Send");

如果在app.config文件中仅配置通信"，则所有记录器都将继承这些设置(因为它们是通信"的后代).如果仅配置通讯.接收"，则仅通讯.接收"记录器将记录日志. 通讯.发送"记录器将被禁用.如果同时配置了"Communication"和"Commuincation.Receive"，则"Communication.Receive"记录器将记录在"Communication.Receive"设置中，而"Communication.Sender"记录器将记录在"Communication"设置中.在log4net和NLog中，对继承的作用远不止于此，但我对继承的了解还不够.

If you configure only "Communication" in your app.config file, then all loggers will inherit those settings (since they are descendents of "Communication"). If you configure only "Commuincation.Receive", then only the "Communication.Receive" loggers will log. The "Communication.Send" loggers will be disabled. If you configure both "Communication" and "Commuincation.Receive", then the "Communication.Receive" loggers will log at the "Communication.Receive" settings while the "Communication.Sender" loggers will log at the "Communication" settings. In log4net and NLog there can be more to inheritance than that, but I don't know enough to go into it.

使用System.Diagnostics时，您会错过的一件事就是灵活地格式化日志输出格式.有一个第三方库，可为基于TraceSource的日志记录提供非常好的可配置格式.您可以在此处找到.

One thing that you miss when using System.Diagnostics is the flexibility to format your logging output format very easily. There is a third party library that provides very nice configurable formatting for TraceSource-based logging. You can find it here.

我使用了 Common.Logging 一些.主要用于原型制作，但我可能会在下一个项目中使用它.它工作得很好，并且编写自己的日志记录抽象要插入它相对容易(例如，如果您想编写与我上面链接的类似的TraceSource抽象).现在，Common.Logging缺少两个重要的东西(尽管他们的网站说他们计划在下一个"版本中发布)是日志记录上下文(例如log4net和NLog NDC/MDC/GDC对象以及System.Diagnostics.CorrelationManger.LogicalOperationStack )和Silverlight兼容性.在使用Common.Logging时，您仍然可以在代码中与log4net或NLog上下文对象进行交互，但是这种方法违背了它的目的，不是吗.

I have used Common.Logging some. Mainly in prototyping, but I might use it in our next project. It works pretty well and it is relatively easy to write your own logging abstraction to plug into it (such as if you wanted to write a TraceSource abstraction similar to what I linked above). Two important things that are missing from Common.Logging right now (although their website says that they are scheduled for the "next" release) are logging contexts (like log4net and NLog NDC/MDC/GDC objects and System.Diagnostics.CorrelationManger.LogicalOperationStack) and Silverlight compatibility. You can still interact with the log4net or NLog context objects in your code while using Common.Logging, but that kind of defeats the purpose of it, doesn't it.

我不知道我是否帮忙！

以下是关于log4net，NLog和TraceSource的一些要点:

Here are some main points that I would make about log4net, NLog, and TraceSource:

log4net-非常流行，可能需要一些更新-至少是在.NET 4.0上构建的，最近一次发布是几年前的，非常灵活.

log4net - very popular, probably in need of some updates - at least being built on .NET 4.0, last release a few years ago, very flexible.

NLog-在许多方面与log4net非常相似，现在是新版本(NLog 2.0的beta版刚刚问世)

NLog - very similar to log4net in many respects, new version now (beta of NLog 2.0 just came out)

TraceSource-没有第三方依赖性，无需您(或某人)花费一些精力，不如log4net或NLog强大(关键缺陷-记录器层次结构，输出格式-均可通过上面的链接轻松解决)，Microsoft检测了很多通过System.Diagnostics对它们的组件进行配置，因此您可以获得Microsoft的日志记录输出和您的日志记录输出是交错的. (通常，在其他日志记录系统中捕获System.Diagnostics很容易，因此可能不是一个大问题.)

TraceSource - no third party dependency, without some effort on your part (or someone's) not as powerful as log4net or NLog (key deficiencies - logger hierarchy, output formatting - both easily addressable via a links above), Microsoft instruments a many of their components with System.Diagnostics so you can get Microsoft's logging output and your logging output interleaved. (Generally, it is easy enough to capture System.Diagnostics in other logging systems so might not be huge issue).

虽然我没有使用过log4net或NLog，但在两者之间我倾向于使用NLog，主要是因为刚刚发布了新版本(测试版).我认为，TraceSource也是一个合理的选择，尤其是如果您实现记录器层次结构并使用上面链接的Ukadc.Diagnostics库，则是更基本的选择.

While I have not used either log4net or NLog a lot, between the two I would lean towards NLog, mainly because of the new version that just came out (beta). I think that TraceSource is also a reasonable, if more rudimentary, choice, especially if you implement the logger hierarchy and use the Ukadc.Diagnostics libary linked above.

或者，使用Common.Logging，您可以避免或延迟为基础的日志记录平台做出决定，直到准备就绪为止.无论如何，对我来说，Common.Logging的一个非常有用的方面是，您可以在开发产品时测试驱动"日志记录平台，而不必每次都更改任何应用程序代码.您不必等到决定在特定的日志记录平台上将日志记录添加到代码中后再进行操作.现在通过Common.Logging api添加它.即将交付时，您应该缩小日志记录平台的选择范围.随同该平台一起交付(如果您重新分发日志记录平台)，就可以完成.以后仍然可以更改.

Or, use Common.Logging and you can avoid or delay making the decision for your underlying logging platform until you are ready. One very useful aspect of Common.Logging, to me anyway, is that you can "test-drive" logging platforms as you are developing your product without every having to change any of your application code. You don't have to wait until you have decided on a specific logging platform to add logging to your code. Add it now via the Common.Logging api. When you get close to delivery, you should have narrowed down your logging platform choice. Deliver with that platform (if you redistribute the logging platform) and you are done. You can still change later on if you want to.

这篇关于System.Diagnostics.Debug命名空间与其他日志记录解决方案(log4net，MS Enterprise Library等)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！