網(wǎng)絡(luò)運維管理的好幫手：IIS日志

申請免費試用、咨詢電話：400-8352-114

 對于一個需要長期維護(hù)的網(wǎng)站來說，如何讓網(wǎng)站長久穩(wěn)定運行是件很有意義的事情。 有些在開發(fā)階段沒有暴露的問題很有可能就在運維階段出現(xiàn)了，這也是很正常的。 還有些時候，我們希望不斷地優(yōu)化網(wǎng)站，讓網(wǎng)站更快速的響應(yīng)用戶請求， 這些事情都發(fā)生在開發(fā)之后的運維階段。

推薦專題：大型網(wǎng)站運維之道漫談 與開發(fā)階段不同的，運維階段不可能讓你去調(diào)試程序，發(fā)現(xiàn)各類問題， 我們只能通過各種系統(tǒng)日志來分析網(wǎng)站的運行狀況， 對于部署在IIS上的網(wǎng)站來說，IIS日志提供了最有價值的信息，我們可以通過它來分析網(wǎng)站的響應(yīng)情況，來判斷網(wǎng)站是否有性能問題， 或者存在哪些需要改進(jìn)的地方。 IIS日志包含了哪些信息 我前面說到【IIS日志提供了最有價值的信息】，這些信息有哪些呢？ 這里面記錄了： 1. 請求發(fā)生在什么時刻， 2. 哪個客戶端IP訪問了服務(wù)端IP的哪個端口， 3. 客戶端工具是什么類型，什么版本， 4. 請求的URL以及查詢字符串參數(shù)是什么， 5. 請求的方式是GET還是POST， 6. 請求的處理結(jié)果是什么樣的：HTTP狀態(tài)碼，以及操作系統(tǒng)底層的狀態(tài)碼， 7. 請求過程中，客戶端上傳了多少數(shù)據(jù)，服務(wù)端發(fā)送了多少數(shù)據(jù)， 8. 請求總共占用服務(wù)器多長時間、等等。 這些信息在分析時有什么用途，我后面再說。先對它有個印象就可以了。 IIS日志的配置 默認(rèn)情況下，IIS會產(chǎn)生日志文件，不過，還是有些參數(shù)值得我們關(guān)注。 IIS的設(shè)置界面如下（本文以 IIS 8 的界面為例）。 在IIS管理器中，選擇某個網(wǎng)站，雙擊【日志】圖標(biāo)： 此時（主要部分）界面如下： 日志的創(chuàng)建方式是每天產(chǎn)生一個新文件，按日期來生成文件名（這是默認(rèn)值）。 說明：IIS使用UTC時間，所以我勾選了最下面的復(fù)選框，告訴IIS用本地時間來生成文件名。 點擊【選擇字段】按鈕，將出現(xiàn)以下對話框： 注意：【發(fā)送的字段數(shù)】和【接收的字節(jié)數(shù)】默認(rèn)是沒有選擇的。建議勾選它們。 至于其它字段，你可以根據(jù)需要來決定是否要勾選它們。 如何分析IIS日志？ 如果你按照我前面介紹的方法設(shè)置了IIS日志參數(shù)，那么IIS在處理請求后（的一段時間之后），會生成IIS日志。 我們可以在【日志界面】的右邊區(qū)域【操作】中點擊【查看日志文件】快速定位到IIS日志的根目錄， 然后到目錄中尋找相應(yīng)的日志文件（默認(rèn)會根據(jù)應(yīng)用程序池序號來區(qū)分目錄）。 比如：我找到了我需要的日志： 這個文件一大堆密密麻麻的字符，現(xiàn)在我該如何分析它呢？ 有個叫 Log Parser 的工具就可以專門解析IIS日志，我們可以用它來查看日志中的信息。 比如我可以運行下面的命令行（說明：為了不影響頁面寬度我將命令文本換行了）： "C:Program FilesLog Parser 2.2LogParser.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"  現(xiàn)在就可以以表格形式來閱讀IIS日志了： 說明：我不推薦用這種方法來分析IIS日志，原因有二點： 1. 慢：當(dāng)日志文件稍大一點的時候，用它來分析就比較浪費時間了（尤其是需要多次統(tǒng)計時）。 2. 不方便：它支持的查詢語法不夠豐富，沒有像SQL Server針對數(shù)據(jù)表查詢那樣全面。 推薦的IIS日志分析方法 雖然Log Parser支持將解析的IIS日志以表格形式供人閱讀，但是有時候我們需要再做一些細(xì)致分析時，可能會按不同的方式進(jìn)行【多次】查詢， 對于這種需求，如果每次查詢都直接運行Log Parser，你會浪費很多時間。 幸運的是，Log Parser支持將解析結(jié)果以多種格式導(dǎo)出（以下為幫助文檔截圖）：   在此，我建議選擇輸出格式為 SQL 。 注意：這里的SQL并不是指SQLSERVER，而是指所有提供ODBC訪問接口的數(shù)據(jù)庫。 我可以使用下面的命令將IIS日志導(dǎo)入到SQLSERVER中（說明：為了不影響頁面寬度我將命令文本換行了）： "C:Program FilesLog Parser 2.2logparser.exe"  "SELECT  *  FROM  'D:Tempu_ex130615.log'  to MyMVC_WebLog" -i:IISW3C -o:SQL  -oConnString:"Driver={SQL Server};server=localhostsqlexpress;database=MyTestDb;Integrated Security=SSPI"  -createtable:ON  導(dǎo)入完成后，我們就可以用熟悉的SQLSERVER來做各種查詢和統(tǒng)計分析了，例如下面的查詢： SELECT cip,csmethod,sport,csuristem,scstatus,scwin32status,scbytes,csbytes,timetaken  FROM dbo.MyMVC_WebLog  如果如下： 注意： 1. IIS日志在將結(jié)果導(dǎo)出到SQLSERVER時，字段名中不符合標(biāo)識符規(guī)范的字符將會刪除。 例如：c-ip 會變成 cip， s-port 會變成 sport 。 2. IIS日志中記錄的時間是UTC時間，而且把日期和時間分開了，導(dǎo)出到SQLSERVER時，會生成二個字段：   date, time這二個字段看起來很不舒服，對吧？ 我也很反感這個結(jié)果，下面來說說的二種解決方法： 1. 在SQLSERVER中增加一列，然后把UTC時間換成本地時區(qū)的時間，T-SQL腳本如下： alter table MyMVC_WebLog add RequestTime datetime  go  update MyMVC_WebLog set RequestTime=dateadd(hh,8,convert(varchar(10),date,120)  + ' ' + convert(varchar(13),time,114))  2. 直接在導(dǎo)出IIS日志時，把時間轉(zhuǎn)換過來，此時要修改命令： "C:Program FilesLog Parser 2.2logparser.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:Tempu_ex130615.log'  to  MyMVC_WebLog2"  -i:IISW3C -o:SQL  -oConnString:"Driver={SQL Server};server=localhostsqlexpress;database=MyTestDb;Integrated Security=SSPI"  -createtable:ON  再看這三列： select RequestTime, date, time from MyMVC_WebLog2  這樣處理后，你就可以直接把date, time這二列刪除了（你也可以在導(dǎo)出IIS日志時忽略它們，但要明確指出每個字段名）。 IIS日志中的UTC時間問題就說到這里 IS日志中的異常記錄 IIS日志中記錄了每個請求的信息，包括正常的響應(yīng)請求和有異常的請求。 這里所說的【異?！颗c .net framework 中的異常沒有關(guān)系。 對于一個ASP.NET程序來說，如果拋出一個未捕獲異常，會記錄到IIS日志中（500），但我所說的異常不僅限于此。 本文所說的異?？煞譃樗膫€部分： 1. （ASP.NET）程序拋出的未捕獲異常，導(dǎo)致服務(wù)器產(chǎn)生500的響應(yīng)輸出。 2. 404之類的請求資源不存在錯誤。 3. 大于500的服務(wù)器錯誤，例如：502，503 4. 系統(tǒng)錯誤或網(wǎng)絡(luò)傳輸錯誤。 前三類異?？梢杂孟旅娴牟樵儷@得： select scStatus, count(*) AS count, sum(timetaken * 1.0) /1000.0 AS sum_timetaken_second  from MyMVC_WebLog with(nolock)  group by scStatus  order by 3 desc  IIS日志中有一列：sc-win32-status ，它記錄了在處理請求過程中，發(fā)生的系統(tǒng)級別錯誤，例如網(wǎng)絡(luò)傳輸錯誤。 正常情況下，0 表示正常，出現(xiàn)非零值意味著出現(xiàn)了錯誤。我們可以這樣統(tǒng)計這類錯誤： 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 > 0  group by scWin32Status  order by 2 desc  下表列出了比較常見的與網(wǎng)絡(luò)相關(guān)的錯誤及解釋： 所有狀態(tài)碼都可以通過下面的命令來獲取對應(yīng)的解釋： D:Temp>net helpmsg 64  指定的網(wǎng)絡(luò)名不再可用。  關(guān)于scwin32status與scStatus，我還想補充說明一下：它們沒有關(guān)聯(lián)。 比如請求這個地址：http://www.abc.com/test.aspx 有可能scStatus=200，但scwin32status=64，此時表示ASP.NET已成功處理請求，但是IIS在發(fā)送響應(yīng)結(jié)果時，客戶端的連接斷開了。 另一種情況是：scStatus=500，但scwin32status=0，此時表示，在處理請求過程中發(fā)生了未捕獲異常，但異常結(jié)果成功發(fā)送給客戶端。 再談 scwin32status=64 記得以前看到 scStatus=200，scwin32status=64 這種情況時很不理解，于是搜索了互聯(lián)網(wǎng)，各種答案都有，有的甚至說與網(wǎng)絡(luò)爬蟲有關(guān)。 為了驗證各種答案，我做了一個試驗。我寫一個ashx文件，用它來模擬長時間的網(wǎng)絡(luò)傳輸，代碼如下： 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}rn", "Start", DateTime.Now));  context.Response.Flush();  System.Threading.Thread.Sleep(1000 * 2);  for( int i = 0; i < 20; i++ ) {  context.Response.Write(string.Format("{0}, {1}rn", i, DateTime.Now));  context.Response.Flush();  System.Threading.Thread.Sleep(1000 * 1);  }  context.Response.Write("End");  }  這段代碼很簡單，我不想做過多的解釋，只想說一句：我用Thread.Sleep與Response.Flush這二個方法來模擬一個長時間的持續(xù)發(fā)送過程。 我們可以在瀏覽器中看到這樣的輸出 我把這個測試做了8次，只有2次是全部顯示完成了，其余6次我提前關(guān)閉了瀏覽器窗口。 根據(jù)IIS日志并結(jié)合我自己的操作可以發(fā)現(xiàn)： 1. 當(dāng)我提前關(guān)閉瀏覽器窗口時，就會看到scStatus=200，scwin32status=64 2. 如果請求內(nèi)容全部顯示完成，我就會看到scStatus=200，scwin32status=0 從這個試驗我們還可以發(fā)現(xiàn)：timeTaken 包含了網(wǎng)絡(luò)傳輸時間。 根據(jù)這個試驗的結(jié)果，你是否想過一個問題： 如果你的網(wǎng)站的IIS日志中出現(xiàn)了大量的scStatus=200，scwin32status=64， 而且請求是由用戶的瀏覽器發(fā)起的。 這是什么原因造成的呢？ 我的【猜想】是：用戶在訪問這個網(wǎng)站時已經(jīng)不愿意再等待了，他們把瀏覽器窗口關(guān)掉了。 換句話說：可以從scwin32status=64的統(tǒng)計結(jié)果看出網(wǎng)站的響應(yīng)速度是否能讓用戶滿意。/

閱讀推薦】
    ◆網(wǎng)管軟件專區(qū)

◆網(wǎng)絡(luò)管理維護(hù)經(jīng)驗:常見ADSL錯誤代碼解析下

◆網(wǎng)絡(luò)管理維護(hù)經(jīng)驗:常見ADSL錯誤代碼解析上

◆網(wǎng)管員必備技巧：如何隱藏上網(wǎng)行為管理系統(tǒng)

◆上網(wǎng)行為運維管理專區(qū)

本文來自互聯(lián)網(wǎng)，僅供參考