C# System.Diagnostics.Tracing.EventSource与System.Diagnostics.Trace

我不确定我是否理解使用System.Diagnostics.Tracing和使用System.Diagnostics.Trace的ETW之间的主要区别。我知道，使用这两种方法，我可以将事件转储到某个输出流上，并且可以使用各种侦听器来截获这些数据，包括自定义侦听器

但除了ETW的基础设施被嵌入到Windows中，我可以使用WPR和PerfView开箱即用之外，我看不出有什么区别

---

什么时候我会选择一个而不是另一个？

系统诊断。跟踪

比跟踪更完整：

• 事件由事件源分隔，这意味着您不必订阅所有事件（有利于性能）
• 在源内部，事件按名称和“EventLevel”分隔，这意味着您可以过滤更多的事件
• 事件是结构化的（它们不仅仅是一个字符串，还可以通过有效负载提供更多信息）

另一方面，

System.Diagnostic.Trace

是一个简单的记录器：您只能记录字符串，并且不能应用任何类型的筛选（它对所有消息启用，或对所有消息禁用）。但它的优点是VisualStudio调试器默认支持它（因此，当您附加到进程时，可以直接在输出窗口中看到跟踪事件）

---

我要补充的是，提供一个现成的ETW侦听器是

系统.诊断.跟踪

的一个很好的额外功能，但从技术上讲，没有什么可以阻止您为

跟踪

编写自己的ETW侦听器

我不确定您是否可以使用这两个侦听器来使用事件。如果您不愿意P/调用非托管ETW API，那么您只能生成事件。您可以将跟踪侦听器（包括自定义侦听器）添加到App.Config以使用System.Diagnostics.Tracing中的事件。关于ETW-我很确定我看过关于编写自定义消费者的教程，但我肯定可以使用PerfView等。我的错，对不起。我将

System.Diagnostics.Trace

类误认为是不同的名称空间，因此误解了您的问题。我目前的理解是，在性能关键的情况下，或者在需要实时日志记录时，您会使用ETW记录较低级别的事件（内存分配、I/O访问等）。ETW显然非常快

System.Diagnostics.Trace

等是一种特定于.NET的机制，速度不快，可能更适合记录更高级别的特定于应用程序的事件，例如管理员用来调试应用程序配置的事件。我意识到这一切都相当模糊。但这是我所知道的。好问题@鉴于stakx ETW所支持的一系列功能，它的速度非常快。对于进程内部的简单字符串日志记录，我怀疑它比

Trace

快。这将是值得测试的想法谢谢凯文-伟大的答案！当您将ETW与静态

跟踪

类进行比较时，这一切都是正确的。有些东西介于这两者之间：

System.Diagnostics.TraceSource

。这些与ETW供应商有些相似；它们还允许您记录对象，而不仅仅是字符串。然后是跟踪级别和开关，允许您过滤事件<代码>跟踪资源与ETW的比较可能比

跟踪

与ETW的比较更公平（因为它们在功能完整性方面更相似）。。。但这不是对你答案的批评，只是一个建议。