我什么时候应该使用 Tracing 与 Logger.NET、Enterprise Library、log4net 或 Ukadc.Diagnostics？
如何在标准跟踪、Logger.NET、Enterprise Library、log4net 或 Ukadc.Diagnostics 之间进行选择？
是否存在一种情况比另一种更合适？ ... 那会是什么？ （ASP.NET、控制台应用程序、Azure 云、SOHO、企业...）
有哪些优点或缺点？
我是否错过了其他主要的日志框架？
How do I choose between standard tracing, Logger.NET, Enterprise Library, log4net or Ukadc.Diagnostics?
Is there a situation where one is more appropriate than the other? ... what would that be? (ASP.NET, console app, Azure Cloud, SOHO, Enterprise...)
What are the benefits or drawbacks?
Did I miss any other major logging frameworks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这里有很多类似的问题：
你错过了几个常用的日志框架。以下是常用框架的列表，您列出了其中一些：
记录抽象：
系统。诊断插件：
其他
Codeplex 中的一些其他日志框架（我已经在 SO 上看到过）：
为什么您会选择其中一个而不是另一个？这是一项艰难的任务。很多都是个人喜好。其中一些是技术（或功能）优势。
任何日志框架（尤其是第三方日志框架）的一个明显缺点是支持质量。如果您遇到 log4net、NLog、Common.Logging 等问题怎么办？您能够从这些框架的开发人员那里获得修复吗？这可能并不是非常重要，因为这些框架的源代码可用。但是，您可能不希望仅仅为了进行修复或添加增强而“继承”源代码树。我想说的是，框架的可扩展性很强，可以通过正常的扩展点添加许多增强功能。
如果您阅读了我上面发布的链接，我认为可以公平地说，仅根据好评的数量，log4net 将是明显的“赢家”。它将被更频繁地提及，因为历史上最喜欢的日志记录以及许多人未来会选择使用它。
NLog 有它的支持者，但它似乎没有 log4net 那样的渗透力或“首要”意识，尽管它们非常相似。 NLog 的功能与 log4net 非常相似，并且它具有最近经历了重要开发周期的额外优势。
企业库经常被吹捧为一个不错的选择，但几乎同样经常被吹捧为一个糟糕的选择。也许它的一些负面声誉可能是早期版本不太好？也许现在好多了？
System.Diagnostics 通常被推荐为合理的选择，至少具有三个强大的优势：无第三方依赖性，许多 Microsoft 组件都使用 System.Diagnostics 进行检测，它易于扩展（可能是为了添加一些已经“免费”提供的功能）在 log4net 和 NLog 等框架中？）。如果您使用 System.Diagnostics，我认为共识是（正如我的建议）使用 TraceSource 对象而不是 Trace.WriteLine/Debug.WriteLine。
另请注意，System.Diagnostics 和 WCF 可以很好地协同工作。可以使用 System.Diagnostics 记录 WCF 消息流量，并且 WCF 还将跨 WCF 服务边界调用传播 System.Diagnostics 活动信息 (System.Diagnostics.CorrelationManager.ActivityId)。
我不太确定 log4net 是否应该继续保持其最受青睐的地位。 正如 SO 上其他地方所指出的，log4net 最近似乎没有进行大量开发（请注意，我认为“log4net 已死”是一种夸张），而 NLog 2.0 目前处于测试阶段，最终版本预计在 2011 年第一季度发布（更新：NLog 2.0 于 2011 年 7 月 17 日发布）。这是否使 NLog 成为明显比 log4net 更好的选择？我不知道，但我认为，相对而言，在两者之间进行选择时，NLog 至少应该得到同等的考虑，并且可能应该成为新开发的首选，至少在 log4net 开发显示出更多生命迹象之前。
log4net 和 NLog 都提供非常灵活的配置选项。它们允许您在日志记录语句的定义中具有非常细的粒度（通过按类型定义记录器的“标准”模式）。它们还允许您开发自己的“日志记录目标”对象（log4net Appender 和 NLog Targets）和“格式化”对象（log4net 模式转换器和 NLog LayoutRenderers），从而轻松扩展库。
除了日志记录框架的选择之外，一些（很多？）主张通过使用抽象层将应用程序代码与特定日志记录框架的硬依赖隔离开来。这可以采用您自己实现的 ILogger 接口的形式，也许是在现有框架之上。将来，您可以通过在不同的框架上实现 ILogger 来更改框架。或者，您可以使用 DI/IoC 将“ILogger”注入代码中。许多 DI/IoC 框架提供内置的 ILogger 抽象，可以将其配置为使用 log4net、NLog 或 Enterprise Library，或者您可以编写自己的 ILogger 实现并注入它。谁关心实施是什么？使代码免于对特定日志记录框架产生硬依赖的另一种方法是使用现有的日志记录抽象框架，例如 Common.Logging 或 SLF。好处是，您的应用程序不依赖于特定的日志记录框架。然而，有些人会说您只是将一种依赖关系（日志框架）换成了另一种依赖关系（日志抽象框架）。
关于日志记录抽象的另外两个注意事项：
良好的日志记录抽象应该允许您在同一输出文件中捕获来自不同日志记录框架的输出。 Common.Logging 将此称为“桥接”。假设您已经使用 Common.Logging 编写了一个由 NLog 支持的应用程序。现在假设您正在使用直接使用 log4net 编写的第三方类库。使用桥接系统，您可以捕获 log4net 输出（通过自定义附加程序）并通过 Common.Logging 重新路由它，以便可以在应用程序的日志输出上下文中查看第三方类库的日志输出。
使用日志抽象还允许您在开发过程中“测试驱动”日志框架。您可能一开始认为 log4net 就是这样的选择，但您希望自己愿意尝试 NLog。使用日志记录抽象，在两者之间切换相对容易。最终，您可以选择哪个日志记录框架，但与此同时，您已经能够编写大量不以任何方式依赖于特定日志记录框架的代码。
您可能选择一种框架而不是另一种框架的另一个原因是您的工作环境。如果您已经在使用企业库的一部分，那么这可能足以促使您使用企业库日志记录。
如果您在 Silverlight 中进行开发怎么办？您可能会选择使用Clog - Calcium 的一部分之类的东西。您还可以选择使用 NLog 2.0，它与 Silverlight 和 WP7 兼容。
System.Diagnostics 插件（Ukadc.Diagnostics、Essential.Diagnostics）。这些本身不是日志框架。相反，它们代表了可与现有 System.Diagnostics 框架一起使用的有用对象和扩展点的集合。在我看来，每个插件添加的最好的事情之一是格式化日志输出的能力，类似于使用 log4net 和 NLog 格式化它的方式。我没有使用过 Essential.Diagnostics，但我尝试过 Ukadc.Diagnostics，并认为它真的很酷。编写您自己的“格式化标记”甚至很容易。
我不知道这是否完全回答了你的问题（无论如何，这个问题相当广泛），但我认为这里有很多值得深思的地方。
There are many similar questions here on SO:
You missed several commonly used logging frameworks. Here is a list of commonly used frameworks, some of which you listed:
Logging abstractions:
System.Diagnostics addons:
Other
A couple of other logging frameworks from codeplex (that I have seen mentioned here on SO):
Why might you choose one over the other? That's a tough one. A lot of it is personal preference. Some of it is technical (or feature) superiority.
One obvious drawback of any logging framework (particularly third-party ones) is the quality of support. What if you have an issue with log4net, NLog, Common.Logging, etc? Will you be able to get a fix from the developers of those frameworks? This might not be tremendously important as the source code is available for these frameworks. However, you might prefer NOT to "inherit" the source tree just to make a fix or add an enhancement. I will say that the frameworks are so extensible, that many enhancements could be added via normal extension points.
If you read the links that I posted above, I think that it is fair to say, based solely on the volume of favorable mentions, that log4net would be the clear "winner". It will be mentioned more frequently as the historical logging favorite and what many people would choose to use going forward.
NLog has its supporters, it just doesn't seem to have the penetration, or "top of mind" awareness that log4net does, even though they are very similar. NLog's capabilities are very similar to log4net and it has the extra advantage of having gone through a significant development cycle recently.
Enterprise Library is often touted as a good choice, but is almost equally as often touted as a terrible choice. Maybe some of its negative reputation is maybe not so good early versions? Maybe it is better now?
System.Diagnostics is often recommended as a reasonable choice with at least three strong benefits: no third party dependency, many Microsoft components are instrumented with System.Diagnostics, it is easily extendable (presumably to add some capabilities that are already present "for free" in frameworks like log4net and NLog?). If you use System.Diagnostics, I think the consensus would be (as would my recommendation) to use TraceSource objects rather than Trace.WriteLine/Debug.WriteLine.
Note also that System.Diagnostics and WCF work well together. WCF message traffic can be logged with System.Diagnostics and WCF will also propagate System.Diagnostics activity information (System.Diagnostics.CorrelationManager.ActivityId) across WCF service boundary calls.
I'm not so sure that log4net should continue to retain its most favored status. As has been noted elsewhere here on SO, log4net does not seem to be undergoing a lot of development recently (note that I think "log4net is dead" is an exaggeration) while NLog 2.0 is currently out in beta with the final release expected in Q1 2011 (Update: NLog 2.0 was released on Jul 17, 2011). Does this make NLog an obviously better choice than log4net? I don't know, but I think that, relatively speaking, NLog should receive at least equal consideration when choosing between the two and, probably, should be the presumed favorite for new development, at least until log4net development shows more signs of life.
log4net and NLog both offer very flexible configuration options. They allow you to have very fine granularity in the definition of your logging statements (by the "standard" pattern of defining a logger per type). They also allow for easy extension of the libraries by allow you to develop your own "logging destination" objects (log4net Appenders and NLog Targets) and "formatting" objects (log4net pattern converters and NLog LayoutRenderers).
Aside from a logging framework choice, some (many?) advocate for insulating your application code from a hard dependency on a particular logging framework by use of an abstraction layer. This can take the form of your own ILogger interface that you implement, perhaps on top of an existing framework. In the future, you could change frameworks by implementing your ILogger over a different framework. Or, you could use DI/IoC to inject "ILogger" into your code. Many DI/IoC frameworks provide a built-in ILogger abstraction that can be configured to use log4net, NLog, or Enterprise Library or you could write your own ILogger implementation and inject that). Who cares what the implementation is? Another way to insulate your code from having a hard dependency on a specific logging framework is through the use of an existing logging abstraction framework such as Common.Logging or SLF. The benefit is that, again, your application is not dependent on a specific logging framework. However, some would say that you have just traded one dependency (on a logging framework) for another (logging abstraction framework).
Two more notes about logging abstraction:
A good logging abstraction should allow you to capture output from different logging frameworks in the same output file. Common.Logging calls this "bridging". Say that you have written an app using Common.Logging, backed by NLog. Now say that you are using a third party class library that is written using log4net directly. With a bridging system, you can capture the log4net output (via a custom appender) and reroute it through Common.Logging so that the third party class library's logging output can be viewed in the context of your app's logging output.
Using a logging abstraction also allows you to "test drive" logging frameworks during development. You might start out thinking that log4net is that way to go, but you want to leave yourself open to trying NLog. Using a logging abstraction it is relatively easy to switch between the two. Ultimately, you can make the choice of which logging framework, but, in the meantime, you have been able to write mountains of code that is NOT dependent in any way on a specific logging framework.
Another reason that you might choose one framework over another is the environment in which you work. If you are already using part of the Enterprise Library, that might be enough to push you into using Enterprise Library logging.
What if you are developing in Silverlight? You might choose to use something like Clog - part of Calcium. You might also choose to use NLog 2.0, which is Silverlight AND WP7 compatible.
System.Diagnostics addons (Ukadc.Diagnostics, Essential.Diagnostics). These are not logging frameworks per se. Rather, they represent collections of useful objects and extension points that can be used with the existing System.Diagnostics framework. One of the best things, in my opinion, that each of these addons adds is the ability to format your logging output, similar to how you can format it with log4net and NLog. I have not used Essential.Diagnostics, but I have experimented with Ukadc.Diagnostics and think that it is really cool. It is even easy to write your own "formatting tokens".
I don't know if this completely answered your question (which is pretty broad anyway), but I think that there is plenty of food for thought here.
我刚刚开始在 VS2010 中使用 log4net 并发现它依赖于 System.Web...这使得它与“.NET xx Client Profile”框架目标不兼容...考虑到这里有人使用以下内容发布了有关 Windows Update 的内容Client Profile 作为 .NET 可再发行版本的选择，这意味着如果您想让代码在大多数机器上运行，则 log4net 不能再成为选择的记录器...
感谢有关其他选项的信息 - 我将检查他们出去...
I just started using log4net in VS2010 and discovered that it has a dependency on System.Web... which makes it incompatible with the ".NET x.x Client Profile" framework targets... Considering what someone here has posted about Windows Update using the Client Profile as the .NET redistributable of choice, this means log4net can no longer be the logger of choice if you want to have your code running on the majority of machines...
Thanks for the info on other options - I'll be checking them out...
补充一下从 Microsoft Build 2013 会议上学到的一些东西：
Log4NET 在重负载下会写入文件，主要是因为这个过程是同步的。在某些情况下可能会出现争用和超时。这可以使用 AppDynamics 或任何其他类似工具进行验证。
NLog 没有实现排队，因此在负载下，IO 调用会堆积起来。
根据微软的说法，ETW 使用高效的内核环形缓冲区。 .NET 4.5 和事件日志框架与语义日志应用程序 Bock (AKA SLAB)< /a> 将使效率更高。
Just to add a few things learned from Microsoft's Build 2013 conference:
Log4NET under heavy load has writing to a file mainly because this process is synchronous. It is possible to get contention and timeouts in certain conditions. This can be verified using AppDynamics or any other similar tool.
NLog doesn't implement queueing so under load, the IO calls stack up.
According to Microsoft, the ETW uses kernel ring buffers which is highly efficient. .NET 4.5 and the Event Log framework combined with Semantic Logging Application Bock (AKA SLAB) will make this much more efficient.
我不喜欢 log4j 或 log4net。我喜欢 java.util.net 日志记录工具，因此我在名为 NetLog 的 github 项目上重新创建了它的大部分内容，网址为 https://github.com/greggwon/NetLog/。请随时提供反馈。我正在尝试花一些时间将基于 ConfigurationManager 的配置放入logging.properties 文件中。使用 java.util.logging，使用命令行属性设置来指定日志配置的位置总是很容易。如果您不使用 ConfigurationManager，那么使用 .net 会更加痛苦。为 CM 提供支持，将为记录器和处理程序之间的一些不同关系打开大门，这可能会使某些事情变得更好。
NetLog 包含一个 EventLogHandler，它将记录到系统事件日志中。它还将 Level.EventLog 级别设置为略低于“警告”，这将允许您有一个命名的“级别”来定位事件日志，而无需使用“警告”或“严重”。我还有一个 TCPSocketHandler，它可以让您远程登录到“日志记录”，这样您就可以在 Windows 上拥有“尾部”，而无需可用的“尾部”程序。
I am not a fan of log4j or log4net. I like the java.util.net logging facility, and so I've recreated it, for the most part, on the github project named NetLog at https://github.com/greggwon/NetLog/. Feel free to provide feedback. I am trying to make some time to put in ConfigurationManager based configuration in liu of a logging.properties file. With java.util.logging, it was always easy enough to use the command line property settings to specify where the log config was at. It's a lot more painful with .net, if you don't make use of the ConfigurationManager. Providing support for CM, will open the door for some different relationships between loggers and handlers which might make some things better.
NetLog includes an EventLogHandler which will log to the system eventlog. It also has an Level.EventLog level set to just below "warning" which will allow you to have a named "level" for targeting the EventLog without using "WARNING" or "SEVERE". I also have a TCPSocketHandler which lets you telnet into the "logging" so that you can have a "tail" on windows, without a "tail" program being available.
看一下 GitHub 上的 NetLog.Logging 包，它是我创建的。它有一个监控应用程序，并遵循 java.util.logging API 范例，因为这就是我喜欢使用的。它有一个用于访问“写入”的自旋锁，锁持有者在继续之前写入排队的所有记录，直到达到限制。这将允许日志记录减少基于 I/O 的争用，并提供良好的折衷方案。
Look at the NetLog.Logging package on GitHub, it is my creation. It has a monitoring app, and follows the java.util.logging API paradigm, because that's what I like to use. It has a spin lock for access to "writing", and the lock holder writes all of the records queued, up to a limit, before moving on. This will allow for logging to be less contention based I/O and provides a good compromise.
由于某种原因，System.Diagnostics 不支持将所有跟踪输出定向到单个侦听器的方法。如果您希望将多个源定向到同一个侦听器，则必须按名称显式列出每个源。
在具有许多依赖项的大型系统中，您可能不知道所有来源，并且您可能不关心。您只想通过输出来了解幕后发生的情况。必须为每个源单独设置侦听器使得在大型系统中使用 System.Diagnostics 变得更加困难。
log4net 不仅支持根级附加程序（侦听器），还支持分层日志记录，允许您为一组逻辑源配置日志记录。在我看来，这使得 log4net 成为明智的选择。
For some reason, System.Diagnostics does not support a way to direct all trace output to a single listener. If you want several sources to be directed to the same listener, you have to explicitly list each source by name.
In a large system with many dependencies, you may not know all of the sources and you probably don't care. You just want the output to see what is happening under the covers. Having to individually set up listeners for each source makes using System.Diagnostics significantly harder to use in large systems.
log4net not only supports a root-level appender (listener), it also supports hierarchical logging that allows you to configure logging for a logical set of sources as a group. In my mind, this makes log4net the clear choice.