首先開篇引用《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對少部分譯文作了校對工作。非常感謝。
參考文章
https://msdn.microsoft.com/zh-cn/library/bb386420.aspx
https://blogs.msdn.microsoft.com/webdev/2013/07/16/tracing-in-asp-net-mvc-razor-views/
http://stackoverflow.com/questions/3328678/asp-net-mvc-tracing-issues
