IIS日誌-網站營運的好幫手

閱讀目錄 開始 IIS日誌包含了哪些資訊 IIS日誌的配置 如何分析IIS日誌 推薦的IIS日誌分析方法 IIS日誌中的異常記錄 再談 scwin32status=64 尋找效能問題 尋找可改進的目標 程式架構對IIS日誌分析過程的影響

對於一個需要長期維護的網站來說，如何讓網站長久穩定運行是件很有意義的事情。 有些在開發階段沒有暴露的問題很有可能就在營運階段出現了，這也是很正常的。 還有些時候，我們希望不斷地最佳化網站，讓網站更快速的響應使用者請求， 這些事情都發生在開發之後的營運階段。

與開發階段不同的，營運階段不可能讓你去偵錯工具，發現各類問題， 我們只能通過各種系統日誌來分析網站的健全狀態， 對於部署在IIS上的網站來說，IIS日誌提供了最有價值的資訊，我們可以通過它來分析網站的響應情況，來判斷網站是否有效能問題， 或者存在哪些需要改進的地方。 回到頂部 IIS日誌包含了哪些資訊

我前面說到【IIS日誌提供了最有價值的資訊】，這些資訊有哪些呢。看看這個截圖吧：

這裡面記錄了：
1. 請求發生在什麼時刻，
2. 哪個用戶端IP訪問了服務端IP的哪個連接埠，
3. 用戶端工具是什麼類型，什麼版本，
4. 請求的URL以及查詢字串參數是什麼，
5. 請求的方式是GET還是POST，
6. 請求的處理結果是什麼樣的：HTTP狀態代碼，以及作業系統底層的狀態代碼，
7. 請求過程中，用戶端上傳了多少資料，服務端發送了多少資料，
8. 請求總共佔用伺服器多長時間、等等。

這些資訊在分析時有什麼用途，我後面再說。先對它有個印象就可以了。 回到頂部 IIS日誌的配置

預設情況下，IIS會產生記錄檔，不過，還是有些參數值得我們關注。 IIS的設定介面如下（本文以 IIS 8 的介面為例）。

在IIS管理器中，選擇某個網站，雙擊【日誌】表徵圖，請參考下圖：

此時（主要部分）介面如下：

在截圖中，日誌的建立方式是每天產生一個新檔案，按日期來組建檔案名（這是預設值）。
說明：IIS使用UTC時間，所以我勾選了最下面的複選框，告訴IIS用本地時間來組建檔案名。

點擊【選擇欄位】按鈕，將出現以下對話方塊：

注意：【發送的欄位數】和【接收的位元組數】預設是沒有選擇的。建議勾選它們。
至於其它欄位，你可以根據需要來決定是否要勾選它們。 回到頂部 如何分析IIS日誌

如果你按照我前面介紹的方法設定了IIS日誌參數，那麼IIS在處理請求後（的一段時間之後），會產生IIS日誌。
我們可以在【日誌介面】的右邊地區【操作】中點擊【查看記錄檔】快速定位到IIS日誌的根目錄， 然後到目錄中尋找相應的記錄檔（預設會根據應用程式集區序號來區分目錄）。

比如：我找到了我需要的日誌：

這個檔案一大堆密密麻麻的字元，現在我該如何分析它呢。

有個叫 Log Parser 的工具就可以專門解析IIS日誌，我們可以用它來查看日誌中的資訊。
比如我可以運行下面的命令列（說明：為了不影響頁面寬度我將命令文本換行了）：

"C:\Program Files\Log Parser 2.2\LogParser.exe" -i:IISW3C -o:DATAGRID "SELECT c-ip,cs-method,s-port,cs-uri-stem,sc-status,sc-win32-status,sc-bytes,cs-bytes,time-taken FROM u_ex130615.log"

現在就可以以表格形式來閱讀IIS日誌了：

說明：我不推薦用這種方法來分析IIS日誌，原因有二點：
1. 慢：當記錄檔稍大一點的時候，用它來分析就比較浪費時間了（尤其是需要多次統計時）。
2. 不方便：它支援的查詢文法不夠豐富，沒有像SQL Server針對資料表查詢那樣全面。 回到頂部 推薦的IIS日誌分析方法

雖然Log Parser支援將解析的IIS日誌以表格形式供人閱讀，但是有時候我們需要再做一些細緻分析時，可能會按不同的方式進行【多次】查詢， 對於這種需求，如果每次查詢都直接運行Log Parser，你會浪費很多時間。 幸運的是，Log Parser支援將解析結果以多種格式匯出（以下為協助文檔截圖）：

在此，我建議選擇輸出格式為 SQL 。
注意：這裡的SQL並不是指SQLSERVER，而是指所有提供ODBC提供者的資料庫。
我可以使用下面的命令將IIS日誌匯入到SQLSERVER中（說明：為了不影響頁面寬度我將命令文本換行了）：

"C:\Program Files\Log Parser 2.2\logparser.exe"  "SELECT  *  FROM  'D:\Temp\u_ex130615.log'  to MyMVC_WebLog" -i:IISW3C -o:SQL -oConnString:"Driver={SQL Server};server=localhost\sqlexpress;database=MyTestDb;Integrated Security=SSPI" -createtable:ON

匯入完成後，我們就可以用熟悉的SQLSERVER來做各種查詢和統計分析了，例如下面的查詢：

SELECT cip,csmethod,sport,csuristem,scstatus,scwin32status,scbytes,csbytes,timetaken FROM dbo.MyMVC_WebLog

如果如下：

注意：
1. IIS日誌在將結果匯出到SQLSERVER時，欄位名中不符合標識符規範的字元將會刪除。
   例如：c-ip 會變成 cip， s-port 會變成 sport 。
2. IIS日誌中記錄的時間是UTC時間，而且把日期和時間分開了，匯出到SQLSERVER時，會產生二個欄位：
   

date, time這二個欄位看起來很不舒服，對吧。
我也很反感這個結果，下面來說說的二種解決方案：

1. 在SQLSERVER中增加一列，然後把UTC時間換成本地時區的時間，T-SQL指令碼如下：

alter table MyMVC_WebLog add RequestTime datetimegoupdate MyMVC_WebLog set RequestTime=dateadd(hh,8,convert(varchar(10),date,120)             + ' ' + convert(varchar(13),time,114))

2. 直接在匯出IIS日誌時，把時間轉換過來，此時要修改命令：

"C:\Program Files\Log Parser 2.2\logparser.exe"  "SELECT TO_LOCALTIME(TO_TIMESTAMP(ADD(TO_STRING(date, 'yyyy-MM-dd '), TO_STRING(time, 'hh:mm:ss')), 'yyyy-MM-dd hh:mm:ss')) AS RequestTime, *  FROM  'D:\Temp\u_ex130615.log'  to  MyMVC_WebLog2" -i:IISW3C -o:SQL -oConnString:"Driver={SQL Server};server=localhost\sqlexpress;database=MyTestDb;Integrated Security=SSPI"-createtable:ON

再看這三列：

select RequestTime, date, time from MyMVC_WebLog2

這樣處理後，你就可以直接把date, time這二列刪除了（你也可以在匯出IIS日誌時忽略它們，但要明確指出每個欄位名）。

IIS日誌中的UTC時間問題就說到這裡，但願每個人都懂了~~~~~~~~~~~ 回到頂部 IIS日誌中的異常記錄

IIS日誌中記錄了每個請求的資訊，包括正常的響應請求和有異常的請求。

這裡所說的【異常】與 .net framework 中的異常沒有關係。
對於一個ASP.NET程式來說，如果拋出一個未捕獲異常，會記錄到IIS日誌中（500），但我所說的異常不僅限於此。

本文所說的異常可分為四個部分：
1. （ASP.NET）程式拋出的未捕獲異常，導致伺服器產生500的響應輸出。
2. 404之類的請求資源不存在錯誤。
3. 大於500的伺服器錯誤，例如：502，503
4. 系統錯誤或網路傳輸錯誤。

前三類異常可以用下面的查詢獲得：

select scStatus, count(*) AS count, sum(timetaken * 1.0) /1000.0 AS sum_timetaken_secondfrom MyMVC_WebLog with(nolock)group by scStatusorder by 3 desc

IIS日誌中有一列：sc-win32-status ，它記錄了在處理請求過程中，發生的系統層級錯誤，例如網路傳輸錯誤。
正常情況下，0 表示正常，出現非零值意味著出現了錯誤。我們可以這樣統計這類錯誤：

declare @recCount bigint;select @recCount = count(*) from MyMVC_WebLog with(nolock)select scWin32Status, count(*) AS count, (count(*) * 100.0 / @recCount) AS [percent] from MyMVC_WebLog with(nolock)where scWin32Status > 0group by scWin32Statusorder by 2 desc

下表列出了比較常見的與網路相關的錯誤及解釋：

scWin32Status	含義
64	用戶端串連已關閉（或者斷開）
121	傳輸逾時
1236	本網中斷

所有狀態代碼都可以通過下面的命令來擷取對應的解釋：

D:\Temp>net helpmsg 64指定的網路名稱不再可用。

關於scwin32status與scStatus，我還想補充說明一下：它們沒有關聯。
比如請求這個地址：http://www.abc.com/test.aspx
有可能scStatus=200，但scwin32status=64，此時表示ASP.NET已成功處理請求，但是IIS在發送響應結果時，用戶端的串連斷開了。
另一種情況是：scStatus=500，但scwin32status=0，此時表示，在處理請求過程中發生了未捕獲異常，但異常結果成功發送給用戶端。 回到頂部 再談 scwin32status=64

記得以前看到 scStatus=200，scwin32status=64 這種情況時很不理解，於是搜尋了互連網，各種答案都有，有的甚至說與網路爬蟲有關。 為了驗證各種答案，我做了一個實驗。我寫一個ashx檔案，用它來類比長時間的網路傳輸，代碼如下：

public class Test_IIS_time_taken : IHttpHandler {        public void ProcessRequest (HttpContext context) {        context.Response.ContentType = "text/plain";        System.Threading.Thread.Sleep(1000 * 2);                context.Response.Write(string.Format("{0}, {1}\r\n", "Start", DateTime.Now));        context.Response.Flush();                System.Threading.Thread.Sleep(1000 * 2);        for( int i = 0; i <