.net - System.Diagnostics.Debug命名空间与其他日志记录解决方案(log4net，MS Enterprise Library等)

Question

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


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



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

Answer 1

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

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

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

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

为了显示：

log4net和NLog中记录器的常见用法是获得如下记录器：

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

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

在这两种情况下，记录器的名称都是完全限定的类型名称。

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

足够的log4net和NLog，您可能已经知道它们如何工作。

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

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

通过上面的包装器，可以在较高级别（类/命名空间层次结构，而不是级别）上配置TraceSource，并在较低级别的记录器中继承这些设置。

因此，如果您的标准类型名称是这样的：ABC.DEF.GHI，则可以为ABC或ABC.DEF（命名空间级别）配置TraceSource，并且类“ GHI”将继承设置。这实际上可以减少您必须进行的配置。

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

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

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.Send”记录器将被禁用。如果同时配置了“ Communication”和“ Commuincation.Receive”，则“ Communication.Receive”记录器将记录在“ Communication.Receive”设置中，而“ Communication.Sender”记录器将记录在“ Communication”设置中。在log4net和NLog中，对继承的作用远不止于此，但我还不了解它。

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

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

我不知道我是否帮忙！

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

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

NLog-在很多方面与log4net非常相似，现在是新版本（NLog 2.0的beta版刚刚发布）

TraceSource-无第三方依赖性，无需您（或某人）付出一些努力，不如log4net或NLog强大（关键缺陷-记录器层次结构，输出格式-均可通过上面的链接轻松解决），Microsoft会检测许多组件与System.Diagnostics一起使用，因此您可以获得Microsoft的日志记录输出和您的日志记录输出交错。 （通常，在其他日志记录系统中捕获System.Diagnostics很容易，因此可能不是一个大问题）。

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

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