前言：
在日常项目开发中，我们时不时会遇到程序占用了很高CPU的情况，可能是程序里某些未经优化的代码或者Bug，或者是程序运行压力太大。无论是什么原因，我们总希望能看到到底是哪个方法占用了如此高的CPU。
微软为我们提供了很多性能诊断工具来达到此目的。例如在Visual Studio 2017中的性能查探器，Windows SDK中的Windows Performance Recorder (WPR) 和Windows Performance Analyzer (WPA)，XPerf，当然，还有这篇博客介绍的PerfView。
但在介绍PerfView的使用前，有一个在Windows系统及应用程序性能这个主题上扮演重要角色的技术必须被提及，这就是Event Trace for Windows (ETW)。事实上，上边提及到的性能分析工具都是基于ETW来实现的。
什么是ETW
在微软上的解释中，ETW是自Windows 2000 推出的"内核级"的事件日志实现。通过记录系统及应用程序中各类事件日志，可以监测和分析系统及程序的运行细节，例如CPU使用率，.NET程序的GC状况等。ETW的日志里，包含着非常多的有用信息，例如进程/线程信息,上下文切换，各种I/O信息，程序执行时的时间节点，甚至是函数调用等信息。通过对日志数据进行实时采集,或者分析事件日志记录文件(.etl文件)，就能轻易地检测和分析系统和程序的运行状况和性能瓶颈，而更为难得的是，ETW的性能还非常的高，据说可以达到 每秒写入20W条记录，而仅占用5%的CPU。
Windows除了在系统内核及系统组件自带了大量事件日志，ETW还为开发者提供编程接口（在 System.Diagnostics.Eventing 命名空间下），允许开发人员在项目中实现自己的事件跟踪，或者像使用log4net一样，将系统自定义的日志记录到ETW里面。这点不在这里展开了，有兴趣的可以参考Artech的文章：如何利用ETW（Event Tracing for Windows）记录日志
但话说回来，我曾经也尝试过在项目了使用ETW，但感觉在一般项目开发中，还是使用Log4net和nlog这些日志框架较为合适，毕竟一般来说业务系统的日志是给人看的，而ETW的日志数据是二进制形式保存的，更偏向于给日志消费者用的，肉眼在看起来并不那么方便，而且log4net/nlog更合适系统的业务场景的日志使用。ETW还是作为系统性能分析手段比较适合。关于这个可以参考这里
ETW VS 性能监视器
或者有人会问，Windows里已经提供了强大的性能监视器(Perfmon.exe)，和资源监视器(顺便说下，资源监视器也是基于ETW实现的。参考这里)，为什么还需要ETW和其他基于它的工具？例如使用性能监视器，添加各种性能计数器，也可以将系统在运行时的方方面面的性能数据呈现出来，那ETW及PerfView还有什么存在意义？
一个非常明显的理由就是，ETW的日志存储着非常详细的程序运行数据。利用PerfView等工具，你可以看到具体一个进程加载信息，线程的执行信息，函数的调用树，和执行时间，执行堆栈，CPU执行时间等等信息，而性能监视器只能提供各个性能指标的数据，但并不能具体地展示哪个程序引起了具体的性能问题。通常我们可以配合性能监视器和ETW相关工具的使用，可以全方位的了解系统的性能状况，并且可以直观地看到具体是那些函数导致了性能问题，达到知其然同时知其所以然的效果。
第二个理由便是，ETW日志的速度比性能监视器要快，可以在生产环境中自由地获取运行数据而不影响服务器运行。但性能监视器也是即开即用，所以我觉得这点对我来说意义不太大。
.ETL文件
.etl文件是ETW的日志文件扩。当使用PerfView等工具捕获系统日志后，便会生成此类文件。使用PerfView等ETW的分析工具，可以对文件内的日志进行各种统计与分析操作。而如果只想单纯地看日志内容，可以使用Microsoft Message Analyzer打开文件。
参考资料：
ETW (Event Tracing For Windows) – what it is and useful tools
Inside Event Tracing for Windows
Logging ETW events in C#: System.Diagnostics.Tracing.EventSource
Application Analysis with Event Tracing for Windows (ETW)
如何利用ETW（Event Tracing for Windows）记录日志
系列目录
使用PerfView监测.NET程序性能（一）：Event Trace for Windows