問題描述

經過如何排查應用程序網關返回 HTTP Code 502 或客戶端得到應用程序網關響應慢的問題(一)中的排查步驟，可以判斷出是由於 Web 服務器自身問題導致的響應異常。

那麽可以在 IIS 中開啟 failed request tracing (以下以 FRT 代稱) 功能來跟蹤並分析此響應異常的原因。

具體步驟參考如下（本文以 Windows Server 2012 為例）：

1. 在系統管理工具中開啟 FRT。

2. 開啟後，可以在 IIS manager 中對應的 sites 的面板中看到 Failed Request Tracing 選項，再在右側的 action 面板中配置 FRT 的 rule。

3. 配置 rule 之前，先開啟並配置 trace file 最大數量：

   

4. 配置 FRT rule:

   1. 配置匹配請求內容後綴：

      

      這裏為了盡量縮小診斷範圍，可以考慮針對有問題的 URL 的請求配置匹配文件後綴名。

   2. 配置匹配條件：

      

      這裏有三種，status code，Timetaken，以及 event severity，這裏的條件之間是與的關系，例如可以使針對 HTTP Response Code 200 但是 Timetaken 時間超過 5 秒的請求做 tracing.

   3. 配置跟蹤提供程序：

      

   4. 配置完成後:

      

5. 一旦問題出現，%SystemDrive%\inetpub\Logs\FailedReqLogFiles\

   下面會有 .xml 文件生成，一個 .xml 文件對應一次請求的 tracing,請根據時間戳判斷要分析的是哪一個請求。

6. 建議使用瀏覽器打開，如果要此 .xml 文件復制到其他 server 上分析，建議連通 freb.xsl 一起復制過去，因為此文件是 FRT log 的格式文件，當使用瀏覽器打開時，會按照此文件中的格式編排，可讀性比較好。

7. 打開任務管理器，記錄當前 IIS 進程的 PID：

   

   如果是多站點，可以根據應用程序池的名字來判斷有問題的站點的進程的 PID。

8. 再打開 FRT 的 .xml，可以根據 PID 來確認：

   

9. 接下來可以點擊 Request Details 來分析具體是哪一個環節 timetaken 長導致的延遲響應，從而鎖定問題範圍：

   

以上可以看到，trace 信息中將此請求的每一個細部均列出，並計算出每一步所花費的時間即 Timetaken，以及請求和返回信息的細節，如 header，handler 信息：

通過 trace 信息，可以幫助應用開發人員判斷問題出在哪裏，是否需要調整應用代碼，或是調整哪部分代碼，為最終解決此 web 應用本身的問題提供了必要信息。

如何排查應用程序網關返回 HTTP Code 502 或客戶端得到應用程序網關響應慢的問題(二)