日志記錄對於任何一個服務器來說，都是至關重要的。對於IIS服務器也不例外。在Windows7操作系統中，相比2003來說，對於IIS日志記錄來說有了很大的改進。不僅僅是日志的格式，還是其他的一些可選項上，操作系統管理員有了更多的選擇。如下圖所示，就是IIS日志記錄配置管理的基本頁面。
在Windows7操作系統中，IIS日志記錄應該視為ISS所必需的而不是可選的組件。這主要是因為日志文件對於管理IIS服務器來說具有很關鍵的作用。如在這個IIS服務器在受到安全威脅的情況下，可以利用日志文件並對其中包含的內在細節執行排疑式審查。如到IIS服務器發生故障後也可以利用這個日志文件中所記錄的信息來檢查維護過程並識別系統中的問題。筆者這裡就給大家介紹一下Windows7操作系統中IIS日志記錄相比Windows2003操作系統的一些新特性，並幫助大家部署一種得心應手的日志管理模式。
一、選擇合適的日志記錄級別。
在IIS7.0版本中，系統管理員可以根據自己的需要選擇合適的日志記錄級別。如可以在服務器級別上進行日志記錄管理，也可以在網站、WEB應用程序文件或者目錄級別上實現它。具體要在那個級別上實現，主要看系統管理員的需要。不過需要注意的是，其實現級別的不同，所支持的日志文件格式也是不同的。如在“服務器”級別實現的話，其支持的日志格式就只有兩種，分別為“W3C”格式與二進制格式。而如果選擇“網站”級別上實現日志管理的話，則其支持的日志格式有三種，分別為IIS、NCSA、W3C格式。而且系統管理員如果覺得這些格式還不滿足的話，可以通過“自定義”的方式來自定義自己需要的格式。所以在選擇日志記錄級別的時候，除了需要考慮在什麼級別上進行日志管理比較方便與安全，同時還需要結合自己喜歡的日志格式。筆者個人喜歡在網站級別上對日志進行管理。因為在一台服務器上，如果只部署IIS服務的話，可能比較浪費。也就是說，在同一台服務器上可能有多個應用服務。為了跟其他應用服務與服務器操作系統的日志區分開來，筆者就建議大家在網站級別上進行管理。當然，在哪個級別上進行日志管理，對於日志的內容沒有實際性的差異。主要是看服務器的部署以及系統管理員的工作習慣而定。
二、為日志記錄選擇合適的格式。
如果選擇網站級別來管理日志的話，這個日志的格式有多種選擇。最重要的是，系統管理員可以選擇IIS的日志記錄格式。這個IIS日志記錄格式是基於文本的日志記錄。跟W3C日志記錄格式類似，都是通過HTTP.SYS來控制的。不過這個IIS日志記錄格式是一個核心模式過程。而以前的日志記錄都是通過用戶模式來管理的。兩者之間有比較大的變化。超文本傳輸協議偵聽程序被實現為名為 HTTP.SYS的內核模式設備驅動程序。HTTP.SYS 是 Windows 網絡子系統的一個重要組成部分。在以前的版本中，當在 IIS 中創建網站時，使用 HTTP.SYS注冊站點，然後HTTP.SYS將 Web 請求傳送到正在運行網站的用戶模式進程中。同時HTTP.SYS也將響應送回客戶端。除了從其內部緩存中檢索存儲的響應以外，HTTP.SYS並不處理它所接收到的請求。因此，應用程序特定代碼永遠不會加載到內核模式中。但是有些系統管理員希望HTTP.SYS能夠以核心模式運行。此時就需要采用IIS日志格式。另外IIS是基於文本的日志記錄，跟二進制格式的日志記錄不同，直接可以通過文本浏覽器等工具來查看日志信息。所以閱讀起來也更加的方便。
當然，日志文件的格式不同，其所存儲的內容都是相同的。所以日志文件的格式並不會影響日志的實際管理價值。不過為了日後管理維護的方便，筆者建立系統管理員最好還是根據自己的工作習慣來選擇合適的日志格式。
三、選擇合適的編碼格式。
一般情況下，IIS日志文件的編碼格式有兩種，分別為UTF-8與ANSI兩種格式。在所有的字符集中，雖然ANSI比較有名。但是這個編碼格式可以說是專門為英文所設計的。用來存儲其他的語言時會出現亂碼的情況。如對於漢語就支持的不是很好。為了解決這個問題，特意提出了一種新的編碼格式，即UTF-8。這是一種UNICODEd 一種變長字符編碼。如果UNICODE字符由2個字節表示，則編碼成UTF-8很可能需要3個字節，而如果UNICODE字符由4個字節表示，則編碼成UTF-8可能需要6個字節。UTF-8編碼可以通過屏蔽位和移位操作快速讀寫。字符串比較時strcmp()和wcscmp()的返回結果相同，因此使排序變得更加容易。字節FF和FE在UTF-8編碼中永遠不會出現，因此他們可以用來表明UTF-16或UTF-32文本。 UTF-8 是字節順序無關的。它的字節順序在所有系統中都是一樣的。
這些字符集的格式對於某些系統管理員來說可能有點深奧。其實系統管理員也不需要了解的這麼清楚。只需要明白一個原則。即如果日志中顯示的如果都是英文的話，那麼采用ANSI編碼格式也不會有問題。但是如果日志中還會存在其他語言的話，則可能會出現亂碼。為此筆者建議，還是采用UTF-8的編碼格式為好。畢竟，其對於英文的支持力度也是很好的。為此還不如一勞永逸的將其設置為UTF-8格式為好。免得以後再日志閱讀中遇到亂碼的煩惱。
四、選擇合適的日志文件滾動更新機制。
如果將IIS的日志記錄都保存在一個文件中，顯然文件會很長。到時候，查看記錄的時候，會很麻煩。為此最好能夠將日志文件進行分割，分割成一個個小文件。這方便與後續的查詢與閱讀。在Windows7操作系統的IIS日志中，提供了很多的日志文件滾動更新的方法。如可以根據時間來創建新的日志文件。如可以按天、按周或者按月來實現日志文件的滾動更新。一般情況下，按月來更新即可。如果IIS服務器訪問比較頻繁，也可以適當縮短這個日志文件滾動更新的時間間隔。如可以將時間間隔調整為一周或者一天等等。這個時間間隔到底多少為好，主要是看其記錄的數量。如果日志記錄數量多的話，那麼可以適當縮短時間。相反，如果日志記錄數量不是很多的話，則可以以月為單位建立新的日志文件。
除了可以根據時間來建立新的日志文件之外，還可以根據日志文件的大小來創建新的日志文件。在IIS日志管理器中可以選擇“最大文件大小”。然後輸入一個合適的尺寸。如此的話，當這個日志文件達到指定的大小之後，系統就會自動對其進行日志切換。不過筆者並不贊同采用這種方法。雖然其可以將重做日志文件控制在一個合理的大小內，但是其會打破其內在的時間聯系。到時候，在遇到問題時查詢起來會非常的不方便。故筆者還是建立按時間來對重做日志文件進行分割。
另外管理器還提供另一個有用的選項，即是否要將本地時間用戶文件命名與翻滾。這是一個很有用途的選項。選中這個選項後，在系統自動建立的日志文件中就會反映這個時間信息。這對於系統管理員來查找日志文件，能夠提供很大的幫助。特別是如果按文件大小來分割重做日志文件的話，一定要選中這個選項，以方便後續的查找。
