首先开篇引用《MVC2 2 in action》里面一段关于这个跟踪服务的话

When you called Trace.Write() in Web Forms, you were interacting with the Trace- Context class. This exists on your ViewPage in ASP.NET MVC, but this isn't where you would want to write tracing statements. By the time you've passed the baton over to the view, there's no logic there that you'd need to trace. Instead, you'd like to trace the logic embedded in your controllers. You might try to leverage the TraceContext class in your controller, but these statements won't ever make their way to the list of messages in the trace log (on your page or on Trace.axd). Instead, you can use System.Diagnostics.Trace and set up your own TraceListeners to inspect the activity in your controllers. Alternatively, you can leverage a more mature logging framework such as log4net or NLog:

You debug ASP.NET MVC applications just as you would any .NET application. Tracing, however, doesn't offer as much for MVC. Instead, you can lean on the built-in TraceListeners in .NET, or utilize a good logging library like those mentioned earlier. Another aspect of error logging is health monitoring.

来自 <http://stackoverflow.com/questions/3328678/asp-net-mvc-tracing-issues>

当你在WebForm中调用Trace.Write()，你正在和跟踪上下文的类进行交互。这些跟踪信息存在于你的ASP.NET的ViewPage里面，但这并不是你期望输出跟踪语句的地方。等到你已经把这些信息传递到View的时候，那里并没有你需要的逻辑。反而你想将跟踪逻辑植入到你的Controller里面。你或者尝试在你的Controller里面使用TraceContext,但这些语句从不&*@#@@#（这里不会翻译make their way）以消息列表的形式存在于跟踪日志里面（或者在你的页面或者在Trace.axd）。反而你可以使用System.Diagnostics.Trace来设置你自己的TraceLinteners以观察你的Controller的活动。或者你可以更改使用其他更成熟的框架，例如log4net 或者NLog；

就如你调试.NET 应用程序一样调试ASP.NET MVC应用程序。但是跟踪服务并没有对MVC提供更多支持。你可以依靠.NET内置的TraceListener或者利用上文提到的一些优秀的日志库。异常日志的另一方面的用途就是健康监控。

小弟的英文水平确实不好，大学没过四级。但至少发现Trace最好的应用场景是WebForm里面，在ASP.NET MVC里面最好还是用其他方式了。所以看到这里对跟踪服务没兴趣的同学可以出门转左了。

那继续看下来的同学都是对这个有兴趣的。下面则直接出效果。

在一个ASP.NET WebForm的项目的配置文件中添加以下配置

然后随便访问一个WebForm页面就会看到界面上多了一堆内容

上面这个页面只要多刷几次，跟踪信息就不会存在，因为跟踪记录存储的个数是有限的，默认是10个，可以在web.config/system.web/trace的requestLimit中设置。上面的图我实际上省略来控件树的内容，被跟踪的内容还是不少，至少发现原来就算一个简单的TextBox里面也包含来那么的子控件。下面则列举一下被跟踪的内容

请求详细信息：包含会话 ID，请求的时间，请求编码，请求类型，状态代码，响应编码；

跟踪信息：显示页级事件流。如果创建了自定义跟踪消息，这些消息也将显示在"跟踪信息"部分。

控件树：显示有关在页中创建的 ASP.NET 服务器控件的信息。

会话状态：显示有关存储在会话状态中的值（如果有的话）的信息。

应用程序状态：显示关于存储在应用程序状态中的值（如果有的话）的信息。这就是ApplicationState

Cookie 集合:显示对于每个请求和响应在浏览器与服务器之间传递的 Cookie 的有关信息。该部分既显示持久性 Cookie，也显示会话 Cookie。

标头集合:显示关于请求和响应消息的标头名称/值对（提供关于消息体或所请求的资源的信息）的信息。就是头部信息Header。

窗体集合：显示名称/值对，这些名称值/对显示在 POST 操作（回发）期间的请求中提交的窗体元素值（控件值）。就是往服务器提交表单元素的值。

Querystring 集合：显示服务器相关的环境变量的集合和请求标头信息。

服务器变量：显示服务器相关的环境变量的集合和请求标头信息。

对于<trace>配置节的属性，如下所示

每个属性的作用可以参考MSDN下的文档

https://msdn.microsoft.com/zh-cn/library/6915t83k.aspx

实际上跟踪信息可以通过Trace.axd（跟踪查看器）去查看。跟踪查看器的使用方式是如果应用程序的URL 为http://localhost/SampleApplication ，请定位到http://localhost/SampleApplication/trace.axd 查看该应用程序的跟踪信息。也就是说当前测试地址是http://localhost:8081,那想进入跟踪查看器查看的话就通过这个URL:http://localhost:8081/trace.axd。

在这里可进入到每个具体的请求，内容就有点类似于前面跟踪信息的截图。只是少了页面的实际内容。就是那几个Label和TextBox。

跟踪信息可以在页面上输出是因为调用了一个叫WebPageTraceListener的类，他是继承TraceListener的一个子类。其余子类如下图

凡是继承了这个类的，都可以通过不同子类对应的实现方式来输出跟踪信息。比如TextWriteRaceLintener它可以把跟踪内容输出到一个txt文件中去。

可以通过这个小例子

在Global.asax中添加代码

通过往跟踪监听器集合中添加两个监听器。

然后在页面代码中调用Trace输出两条跟踪信息

假设不调用这个Flush方法，跟踪信息不会输出到文本中。

在ASP.NET MVC中，同样调用Trace类去记录一些跟踪信息，结果会如何？

单纯在Action方法中添加代码，然后访问对应的URL

结果发现页面上毛都没有。进入跟踪查看器是能发现有一条跟踪信息，进去查看发现对比起WebForm的就少了控件树和页级事件流的跟踪信息，Trace.Write的内容应该在显示跟踪信息一栏中。但是这个并没有出现。由此也证明了对跟踪服务的配置在WebForm和MVC中已有差别。为了能让跟踪信息在页面上显示，需要手动添加一个Listener。即时这样，也只能在跟踪查看器中查看到Trace输出的内容，并不能在原有页面上看到跟踪信息，就是trace配置节的pageOutput已失效。

确实这个跟踪服务到现在来说确实会遭淘汰了，像通过Trace.Write这样输出跟踪信息可以通过写日志的形式取代，查看请求头，Cookie等跟请求相关的可以通过浏览器的开发人员工具去查看。但如果懒得去看按F12去打开开发人员工具和远程到服务器去打开日志文件的，还是可以把这个跟踪服务启用。

最后特别鸣谢china autumn对少部分译文作了校对工作。非常感谢。