• 發行項

本文章是由機器翻譯。

ASP.NET

利用 IIS 記錄檔排解應用程式疑難

Eduardo Sanabria

你吃過的故障或沒有見過你的代碼調試的應用程式嗎？你有過一個出現故障的應用程式和瀏覽器既提供一個有用的錯誤代碼的應用程式嗎？

很多次，遇到這兩種方案，它是個好主意，準備為他們的偶然性。我將在本文仲介紹的技術將説明您解決任何應用程式或系統運行在 IIS 下,，不管它編碼什麼平臺。這些技術也幫我解決應用程式和 Web 網站中的各種情況，特別是對 Pc 的設備 — 這些天成為一種規範的情形。在最近的一次案件中，這些技術説明我發現為什麼視頻不會顯示在蘋果設備上儘管他們完美地跑在基於 Windows 的設備上。

一些注意事項

有許多用於調試ASP.NET和其他 Web 應用程式在 IIS 下運行的有效技術。瀏覽器本身往往產生特定的錯誤或套的錯誤，不足以解決問題。

但假設的資訊還不夠嗎？這是在它變得得心應手，知道幾種額外的技術。這些最簡單也是最快和已知最佳之一 — 直接在伺服器上運行應用程式。有時伺服器不配置對於此選項，但是如果你可以做到，伺服器通常將提供更多有用的調試資訊，比外機。此行為是由 Microsoft 為安全目的顯然內置。若要獲得更多的資料伺服器的瀏覽器，請關閉"顯示友好 HTTP 錯誤訊息"的選項，你會發現在互聯網資源管理器中，在 Internet 選項 |先進。

有時你需要更多的資訊，和當日志記錄變得十分重要。Microsoft 已建成它的伺服器，將極大地説明任何故障排除的追求，前提你知道什麼，看起來，並在強大的記錄設施。

打開 IIS 日誌記錄

第一步是打開 Windows 伺服器上的記錄。有幾個方式 可做到這點。而實際步驟可以有所不同 (有時) 伺服器正在運行哪個版本的 Windows。

深入研究這些步驟或描述各自的優點與缺點是超出了本文的範圍。在這裡，我將會簡單地指出正確使用日誌記錄調試您的應用程式，您必須啟用它的實際錯誤發生之前。Windows Server 2003和 2012 年，就會在這些兩個的 MSDN 文章中找到很多有用的資訊："如何配置 Web 網站日誌記錄在Windows Server 2003(bit.ly/cbS3xZ) 和"配置日誌記錄在 IIS"(bit.ly/18vvSgT)。如果這些不能滿足您的需要，有很多其他線上文章有關對轉動的 IIS 日誌的其他版本的 Windows 伺服器。

確定適當的 ID 號

關於日誌記錄後，您需要找出你要進行故障排除的 Web 網站在 IIS 中的 ID 號。這是至關重要的因為伺服器通常承載多個網站，並且嘗試手動查找日誌資料夾可以是令人生畏。（我嘗試它運行 45 Web 網站的伺服器上，它幾乎是不可能。

打開IIS 管理員以顯示所承載的所有網站。對於此示例，假設我正試圖找出為什麼 WebSite2 突然停止工作或只間歇性地工作。

正如你可以看到在圖 1，WebSite2 的 ID 是"3"。下一步是打開對應的日誌資料夾在 Inetpub 資料夾中找到的通常 （但不是總是）。Windows 通常在根目錄 (c:) 中會創建此資料夾伺服器上，但在我的案子，在 Inetpub 資料夾是位於 d:磁碟機。行業最佳實踐建議保持代碼和操作系統磁碟機單獨用於在出現故障時容易交換。


圖 1 查找 Web 網站 ID 編號

Windows 的所有日誌記錄資料夾 W3SVC #，其中 # 是給定的 Web 網站的 ID 名稱。因為在這種情況下正在調試網站的 ID 是 3，日誌檔位於資料夾中名為 W3SVC3，如中所示圖 2。


圖 2 打開日誌檔資料夾

流覽的檔

當您打開正確的資料夾中時，您可能會看到很多檔。IIS 通常可以保持許多不同的檔，取決於您如何佈建服務器歷史記錄或多長時間日誌記錄已上。若要查找您需要的檔，幾乎肯定打賭是滾動到清單的底部並打開最後一個檔，但如果有錯誤發生，你可以找到的檔的名稱使用的日期和時間對檔的確切時間。不管怎樣，打開的檔使用檔編輯器，如 Notepad.exe。

您可能會看到很多檔中的資料。第一眼看著資訊似乎神秘和無用的但與一個小研究你可以找到足夠的寶石埋在此資料的範圍內。我會看看一些最有用的資料元素由日誌記錄過程記錄。

IIS 和 Windows 日誌每個 HTTP 要求單獨的一行。典型的行看起來像這樣：

2013-08-28 00:01:12 128.128.128.20 GET /default.asp - 443 - 200.200.200.17 Mozilla/4.0+(compatible; +MSIE+8.0; +Windows+NT+6.1; +WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727; +.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+InfoPath.3;+MS-RTC+LM+8; +.NET4.0C;+.NET4.0E; +.NET+CLR+1.1.4322) 200 0 0 15

這是一個從實際的 IIS 日誌的行。 此處所示的資料是在一種"標準"格式。 然而，因為此選項是高度可配置的那裡是不能保證您的檔將會看起來完全一樣我的示例。 而不費力的所有資料，我要在這裡集中的元素，調試應用程式最感興趣。

在示例中的第一個粗體元素是請求的日期。 請的記住這是伺服器的日期。 如許多 Web 應用程式運行全球跨多台伺服器部署在不同的時區，此日期可能是誤導。 請確保日期準確地反映了錯誤發生的實際時間。 許多伺服器使用 GMT 時間，但您應該驗證格式。

下一步，您將看到的被訪問的 IP 位址、 HTTP 操作類型 （獲取） 和實際的檔要求或訪問。 在下面的示例行，代碼調用 default.asp 檔：

128.128.128.20 GET /default.asp

此資訊是過程的有價值的可能已經在這一階段發生的錯誤。 例如，你可能期待在此時要執行另一個檔。

在行的下一部分顯示的 IP 位址請求源自何處，以及接收埠：

443 - 200.200.200.17

此資訊也是重要的有時它是需要驗證您正在進行故障排除的請求實際上來自已知的來源。

正如您所看到的使用的實際埠也可以被引用。 尋找問題時，這位看似不重要資訊是至關重要的。 例如，防火牆可能會不正確地配置。 此資料之後的很多資訊，主要是與相關的版本：

+MSIE+8.0; +Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2; +.NET+CLR+2.0.50727; +.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729; +InfoPath.3;+MS-RTC+LM+8; +.NET4.0C

例如，您可以看到瀏覽器是否正在運行 32 位或 64 位、 （對於那些，深入到.NET 宇宙），CLR 版本和實際的.NET 版本安裝在伺服器上 （在此情況下，.NET 4 C)。

拿到東西的底部

至此，展示了該日誌檔條目的相對明顯部分。 最重要的是，你可以看到哪些瀏覽器回應的 HTTP 要求。 有時這便已足夠，因為不同的瀏覽器可能會產生不同的結果。 這裡是顯示什麼火狐和 Chrome 可能類似檔中某些部分的字串：

;+rv:17.0)+Gecko/20100101+Firefox/17.0 404 0 2 109
+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/­28.0.1500.95+Safari/537.36 200 0 0 125

它可能很難檢測到其中的幾個 HTTP 要求正在調試因為他們看起來都類似。 這是要更改瀏覽器可以來的地方方便。 通過添加一個條目從一個不同的 （和意外的） 的瀏覽器，如 Safari 或歌劇，它可以更輕鬆地找到並因此解決問題的條目。

最後，看看最後四個專案在行上：

200 0 0 15

最後一個數位，15，是 HTTP 要求的回應時間 （以毫秒為單位）。 這是資訊的一件非常有用。 瞭解請求進程花了多長時間可以説明您決定是否給定的代碼片段、 Web 服務或進程正在採取所需或"正常"的時間。

它可能會驚奇您發現相對較簡單的步驟，在一個進程中正在意外的處理時間。 在最近的情況下，應用程式有時登錄和有時無法登錄，而不會產生可捕獲瀏覽器錯誤 — 或任何錯誤，所有。 它只被失敗。 審閱後在日誌中的回應時間，開發人員發現的 web.config 檔中此屬性：

<add name="CacheProfile1" duration="30" />

此參數，很顯然無害地設置為 30 秒的值只是太大。 它減少了，一旦應用程式工作像預期的那樣。

現在 （為清楚起見重複的行在這裡） 我會零從集中在審閱最重要的參數之一。 第一個專案，200，是實際的 HTTP 回應從 IIS：

200 0 0 15

 

HTTP 回應代碼，200，意味著成功。 通常情況下，你會遇到一個已知的錯誤類型，如 404 (未找到) 或 500 （內部伺服器錯誤），可能會給你足夠的資訊來診斷和解決問題。 官方 HTTP 狀態碼的清單，請訪問 bit.ly/17sGpwE。

我現在會涉及一個更多真實的案例 — 居然提示我要分享這篇文章的那個。 我有一個 Web 網站，工作並在 Pc 上完美地執行但是只要使用者訪問他們的 iPad 設備上的網站，視頻流根本不能用。 使事情更糟的是，沒有錯誤代碼 ； 視頻只被拒絕功能。

這是哪裡使用日誌進行故障診斷證明是非常寶貴的。 通過檢查日誌並驗證的 HTTP 要求正在取得從 Safari (以隔離要求），我發現伺服器報告了一個 404 錯誤。 令人困惑的錯誤訊息和錯誤本身似乎令人難以置信，為 PC 版本，工作得很好的網站。

雖然日誌被報告不被找到的物件，我知道很好檔在的地方。 這提示我審查了不同的方式 iOS 和 Windows 處理和存儲的檔。 當我探索的原始程式碼的載入視頻，我發現視頻檔的實際路徑已硬式編碼源中和的路徑不存在在 iPad 的 iOS 設備。 這是 404 的原因。

它是重要的是要在這裡請注意所有的症狀指出其他地方。 例如，此類問題通常通過檢查存在不支援的媒體類型 （或多用途 Internet 郵件擴展 [默劇]） 在 IIS 中解決。 但是，如果問題是缺少的 MIME 類型，本來 HTTP 415 （不支援的媒體類型） 或一個類似的錯誤，錯誤代碼和日誌不報告的。 使用 IIS 調試日誌證明有助於找到問題。 我所看到的實際錯誤代碼和調查它，而不是追著什麼最初似乎更有可能保存耗費大量的時間。 再次，知道如何讀取日誌保存一天。

总结

日誌檔可以是一個強大工具進行調試和故障排除的應用程式，即使在"盲"的情況下，提供你知道在哪裡可以找到他們和這些資料的含義。 調查在日誌中的資料是最簡單的一個 — 尚未成熟和完整 — 你會找到方法來解決問題。

它需要一點點實踐和當然有一些紀律，但一旦你熟悉這些技術，您應該能夠調試和解決大多數應用程式和 IIS 問題。 我已經把這些技術放到好用的和你也可以。

Eduardo Sanabria 是服務交付顧問四為惠普企業服務在德克薩斯州埃爾帕索。那裡他提供品質結果這一事項，作為.NET 主題專家 (SME) 他當前專案中。薩納布裡亞帶來到惠普公司 超過 25 年的完整週期應用程式開發體驗。他的招牌菜是.NET、 資料庫應用程式、 資料處理和 Web 開發。薩納布裡亞也可以撥打 EdSanabria@Yahoo.com。

由於以下的技術專家對本文的審閱：羅傑 · 霍金斯 (惠普)
羅傑 · 霍金斯是在惠普，所有美洲和傑出的技術專家和 HP 研究員為公司的首席技術官。 "