MVC
使用 IIS 日志进行应用程序故障排除
您是否曾在未看到代码的情况下对应用程序进行故障排除或调试？ 您的应用程序是否曾出现故障，并且浏览器或该应用程序均无法提供有用的错误代码？
这两种情况我都遇到过多次，最好对这些可能发生的情况做好准备。 我在本文中描述的这些方法将帮助您对在 IIS 下运行的任何应用程序或系统进行故障排除，无论对其进行编码时使用的平台是什么。 这些方法已经在各种情况下帮助我对应用程序和网站进行了故障排除，尤其是在非 PC 的设备上 — 目前这种情况正变得司空见惯。 在最近的示例中，这些方法帮助我发现了在 Apple 设备上不显示视频的原因，尽管它们在基于 Windows 的设备上完美运行。
一些注意事项
调试在 IIS 下运行的 ASP.NET 和其他 Web 应用程序有许多有效方法。 该浏览器本身经常生成足以解决这些问题的特定错误或错误集。
但假设这些信息还不够？ 以此为出发点很容易得知一些额外方法。 其中最简单的方法也是最快速、最有名的一种方法 — 直接在服务器上运行应用程序。 有时没有针对该选项对服务器进行配置，但如果您能够执行此操作，服务器通常将提供比外部机器更有用的调试信息。 此行为明显是 Microsoft 出于安全目的而内置的。 要在服务器的浏览器上获得更多数据，关闭“显示友好 HTTP 错误消息”选项，该选项位于 Internet Explorer 中的“Internet 选项”|“高级”下。
有时您将需要更多信息，这时日志记录变得非常重要。 Microsoft 已在其服务器中内置了强大的日志工具，如果您知道要寻找什么，以及在哪里寻找，这些工具将在进行任何故障排除时提供极大帮助。
打开 IIS 日志记录
第一步是在服务器上打开 Windows 日志记录。 有多种方法可以做到这一点。 实际步骤可能因正在运行的 Windows Server 版本而不同（有时大相径庭）。
钻研这些步骤或者描述每个步骤的优劣势不在本文的讨论范围之内。 在这里我要指出的是，要正确使用日志记录来调试您的应用程序，您必须在实际错误出现前打开此功能。 您将在针对 Windows Server 2003 和 2012 的以下两篇 MSDN 文章中找到许多有用的信息：“如何在 Windows Server 2003 中配置网站日志记录”(bit.ly/cbS3xZ) 和“在 IIS 中配置日志记录”(bit.ly/18vvSgT)。 如果这些信息无法满足您的需求，还有大量与针对其他版本的 Windows Server 在 IIS 中打开日志记录相关的其他在线文章。
确定正确 ID 号
打开日志记录后，您需要弄清您正在进行故障排除的网站在 IIS 中的 ID 号。 这非常关键，因为服务器一般托管多个网站，尝试手动查找日志文件夹会让人望而却步。 （我在运行 45 个网站的服务器上尝试了一下，发现这几乎是不可能的。）
打开 IIS 管理器，显示托管的所有网站。 对于此示例，假设我正在尝试弄清 WebSite2 为什么突然停止工作或者仅间歇工作。
正如您在图 1 中所看到的，WebSite2 的 ID 是“3”。下一步是打开相应的日志文件夹，它一般（但并非始终）位于 Inetpub 文件夹中。 Windows 通常会在服务器的根目录 (C:) 中创建此文件夹，但在我的示例中，Inetpub 文件夹位于 D:驱动器。 行业最佳做法建议使代码和 OS 驱动器保持分开，以便在出现故障时可轻松交换。
.png)
图 1 查找网站 ID 号
Windows 将所有日志记录文件夹均命名为 W3SVC#，其中 # 为给定网站的 ID。 因为该示例中正在调试的站点的 ID 是 3，因此日志文件位于名为 W3SVC3 的文件夹中，如图 2 所示。
.png)
图 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 操作类型 (GET) 以及请求或访问的实际文件。 在以下示例行中，此代码正在调用 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 位、CLR 版本（针对那些深入钻研 .NET 领域的人），以及服务器上安装的实际 .NET 版本（在该示例中为 .NET 4 C）。
直入正题
到目前为止，我已经展示了日志文件条目相对明显的部分。 最重要的是，您能够看到哪个浏览器正在响应 HTTP 请求。 有时这就够了，因为不同浏览器可能产生不同结果。 以下是显示 Firefox 和 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 或 Opera，查找可疑条目从而对其进行故障排除会更加轻松。
最后，看看该行的最后四项：
200 0 0 15
最后一个数字 15 是 HTTP 请求的响应时间（毫秒）。 这是一条非常有用的信息。 知道处理请求所用的时间长短可帮助您确定给定代码段、Web 服务或进程是否正在耗用所需或“标准”的时间量。
您可能惊讶的发现某一过程中相对简单的步骤所用的处理时间异常。 最近有一个案例，应用程序有时成功登录，有时不能登录，并且没有生成可捕获的浏览器错误 — 或者根本不生成错误。 就是失败。 查看日志中的响应时间后，开发人员在 web.config 文件中发现了该属性：
<add name="CacheProfile1" duration="30" />
此参数值（很明显设置为 30 秒是无害的）太大。 将其减小后，该应用程序按预期方式工作。
现在（为了更加明确，在这里重复该行）我将关注我正在查看的集合中的最重要参数之一。 第一个项 200 是来自 IIS 的实际 HTTP 响应：
200 0 0 15
此 HTTP 响应代码 200 意思是成功。 通常您将遇到已知错误类型，例如 404（未找到）或 500（内部服务器错误），这可给您足够的信息进行故障排除并解决问题。 有关 HTTP 状态代码的正式列表，请访问 bit.ly/17sGpwE。
我现在将再讲述一个真实示例 — 实际上提示我分享此文章的一个示例。 我有一个网站在 PC 上工作且执行地很好，但用户在他们的 iPad 设备上一访问该站点，视频流就不工作。 更糟糕的是，没有错误代码；视频只是拒绝运行。
这个实例说明了日志在进行故障排除时是无价之宝。 通过检查日志并验证 HTTP 请求是否是从 Safari 发出的（旨在隔离该请求），我发现服务器报告了 404 错误。 该错误消息令人困惑，并且该错误本身似乎并不可信，因为该站点的 PC 版本工作地很好。
尽管这些日志正在报告未找到对象，但我很清楚地知道这些文件就在原地。 这提示我查看 iOS 和 Windows 处理及保存文件的不同方式。 当我探究加载该视频的源代码时，我发现到这些视频文件的实际路径已在源中进行了硬编码，而该路径在 iOS iPad 设备中不存在。 这就是 404 的原因。
在这里值得注意的是，所有这些症状还指向了其他方面。 例如，这种问题一般是通过查看 IIS 中是否存在不支持的媒体类型（或多用途 Internet 邮件扩展 [MIME]）加以解决的。 但如果此问题是缺失 MIME 类型，则错误代码将为 HTTP 415（不支持的媒体类型）或类似错误，并且日志不报告此错误。 使用 IIS 进行调试证明有助于发现此问题。 通过查看实际错误代码并进行调查，而不是追寻最初似乎更可能出现的情况，我节省了大量时间。 再次说明，知道如何读取日志节省了一整天的时间。
总结
假定您知道在哪里找到日志文件以及这些数据的含义，日志文件可成为用于对应用程序进行调试和故障排除的强大工具，即使在“盲目”的情况下也是如此。 调查日志中的数据是我认为解决问题的最简单 — 但更高级且更全面的 — 方法之一。
这需要一些练习，当然也需要一些学科知识，但如果您掌握了这些方法，您应能够调试并解决大部分应用程序和 IIS 问题。 我已经很好地利用了这些方法，您也能够如此。
Eduardo Sanabria 是位于得克萨斯州 El Paso 的 HP Enterprise Services 的服务交付顾问 IV。在那里他提供了非常重要的高质量成果，在其当前项目中他担任 .NET 主题专家 (SME)。Sanabria 为 Hewlett-Packard Co. 带来了超过 25 年的全周期应用程序开发经验。他的专长是 .NET、数据库应用程序、数据处理和 Web 开发。可通过 EdSanabria@Yahoo.com 与 Sanabria 联系。
衷心感谢以下技术专家对本文的审阅：Roger Hawkins (Hewlett-Packard)
Roger Hawkins 是 Hewlett-Packard 负责所有美洲地区的首席技术官，并且是该公司杰出的技术人员和 HP 员工。"