49、IIS 7.0 故障诊断与追踪全解析

IIS 7.0 故障诊断与追踪全解析

在 IIS 7.0 的使用过程中，故障诊断和追踪是确保网站稳定运行的关键环节。本文将详细介绍 IIS 7.0 中的状态码含义、失败请求追踪（Failed Request Tracing）、日志记录（Logging）以及 ASP.NET 追踪（ASP.NET Tracing）等重要功能，帮助你更好地维护和操作 IIS 7.0 服务器。

状态码含义

在 HTTP 请求和响应中，状态码起着至关重要的作用，它能够向客户端传达请求处理的结果。以下是常见状态码类型及其含义：
- 1xx - 积极初步回复 ：表示某个操作已成功启动，但客户端在继续执行新命令之前，期望收到另一个回复。
- 2xx - 积极完成回复 ：表示操作已成功完成，客户端可以执行新命令。
- 3xx - 积极中间回复 ：命令执行成功，但服务器需要客户端提供额外信息才能完成请求处理。
- 4xx - 临时负面完成回复 ：命令执行失败，但错误是临时的。如果客户端重试该命令，可能会成功。
- 5xx - 永久负面完成回复 ：命令执行失败，且错误是永久性的。如果客户端重试该命令，将收到相同的错误。

失败请求追踪（Failed Request Tracing）

失败请求追踪是 IIS 7.0 中备受欢迎的功能之一，它能让你获取任何页面请求的详细信息，并根据自定义的标准捕获数据。这不仅是开发环境中的实用工具，更是生产环境中解决故障的有效方法。

该功能由 IIS 开发团队正式命名为 FREB（Failed Request Event Buffering），用于监控所有符合特定标准的传入请求，并将整个页面请求的详细信息以易于阅读的 XML 格式保存到磁盘。

要开始将 FREB 日志记录到磁盘，需要完成以下三个步骤：
1. 确保服务器上安装了追踪功能 ：
- 打开“开始”菜单，在搜索框中输入“Server Manager”，然后按回车键。
- 展开左侧的“角色”部分，右键单击“Web 服务器 (IIS)”，选择“添加角色服务”。
- 在“健康与诊断”部分勾选“追踪”。
- 点击“下一步”，然后点击“安装”完成安装。
2. 创建新的追踪规则 ：详细步骤将在“失败请求追踪规则设置”部分介绍。
3. 启用 FREB ：
- 进入站点级别，双击“失败请求追踪规则”图标。
- 在“操作”窗格中，点击“编辑站点追踪”。
- 勾选默认处于关闭状态的“启用”复选框，然后点击“确定”。

失败请求追踪规则设置

在繁忙的生产服务器上，将所有请求保存到磁盘是不现实的，因此需要缩小范围以捕获确切的问题页面。FREB 提供了过滤选项，可显著缩小范围。在 IIS 管理器的向导中，设置规则需要三个步骤：
1. 指定要追踪的内容 ：
- 第一步允许你选择所有内容或特定类型的内容，包括“所有内容”、“ASP.NET”、“经典 ASP”或“自定义”。
- 如果你想缩小到单个失败页面，选择“自定义”并输入页面名称。对于多个页面，必须为每个页面设置新规则。“自定义”字段不允许输入多种内容类型，但允许使用星号 ( ) 作为通配符。例如，“staff .aspx”将捕获以“staff”开头且扩展名为“aspx”的所有页面，如“staff.aspx”、“staff_edit.aspx”等。
- 点击“下一步”进入下一步。
2. 定义追踪条件 ：
- 第二步设置状态码、请求耗时和事件严重性。状态码字段允许选择多种状态码类型，用逗号分隔。例如，要选择所有 500 错误，只需输入“500”；若要缩小到 500 和 401.5 错误（ISAPI/CGI 应用程序授权失败），可在“状态码”框中输入“401.5,500”。
- HTTP 200 状态码也允许选择。尽管该工具名为“失败”请求追踪，但它也会保存成功页面，这是了解代码运行速度和找出代码中处理时间最长部分的好方法。
- “请求耗时”字段允许设置页面完成所需的最短时间（以秒为单位），只有达到该时间才会记录追踪信息。这是一个可选设置，若需要，勾选复选框并输入相应秒数。设置的值应足够低以捕获问题，同时足够高以减少无关页面的记录。
- 点击“下一步”进入下一步。
3. 选择追踪提供程序 ：
- 最后一步是选择追踪提供程序和详细程度。默认有四个提供程序：ASP、ASP.NET、ISAPI 和 WWW 服务器，与 IIS 中的其他功能一样，这些提供程序可以扩展或添加。
- 有些提供程序会相互重叠，有些则相互排斥。例如，WWW 服务器提供程序会获取每个页面请求的信息，而 ASP 和 ASP.NET 提供程序不会同时捕获同一请求的信息。
- 默认配置会选择所有提供程序，并将详细程度设置为“详细”，这将捕获所有可能的信息，但你可以关闭不需要的内容以减少捕获的信息量。
- 完成选择后，点击“完成”。如果尚未启用追踪，完成向导不会自动启用它。你需要从“失败请求追踪规则”屏幕中点击“编辑站点追踪”，在弹出的屏幕中启用追踪，并设置追踪文件的保存路径和最大数量。追踪默认是禁用的，这样在全局级别设置某些追踪规则时，除非你有意启用，否则不会开始为所有网站记录追踪信息。

读取 XML 追踪日志

设置好文件并捕获数据后，你可以通过导航到日志文件夹来查看 XML 追踪文件。这些文件按顺序编号，文件名中的日期戳显示了捕获的确切时间。使用你喜欢的 XML 查看器（如 Internet Explorer）打开所需的 XML 文件。

追踪文件包含了关于页面请求的大量信息，从请求耗时到每个事件中出现的失败情况。Windows Server 2008 附带的“freb.xsl”文件有多个选项卡，其中“性能视图”选项卡按每个事件的耗时对页面生命周期的每个事件进行排序，显示详细信息。

第一次在 Internet Explorer 中尝试查看 FREB 追踪文件时，你可能会收到内容被阻止的警告。你需要将“about:internet”添加到“本地 Intranet”或“受信任的站点”区域，否则会收到“安全设置不允许在此样式表中执行脚本代码”的错误消息，因为“freb.xsl”文件包含脚本，Internet Explorer 需要特定授权才能运行。

如果你启用了用户账户控制（UAC），可能在警告对话框中看不到“添加”按钮，此时你需要手动通过“工具” -> “Internet 选项” -> “安全”来添加。

通过这些信息，你可以确定导致问题的页面（如果你之前不知道的话）、页面的运行时间以及页面生命周期中哪个事件耗时最长。XML 输出文件的第一行显示了用于发起请求的 URL，如果原始请求未包含默认文档名，它不会自动包含。例如，“http://yoursite.com/”通常是对默认文档（通常是“default.aspx”）的请求。XML 文件的其他部分包含了该特定页面请求的有价值信息。

失败请求追踪是 IIS 7.0 中的新功能，对于许多试图解决挂起、超时、资源密集和性能缓慢等问题的系统管理员来说，它可能会成为首选工具。

日志记录（Logging）

任何 Web 服务器都离不开对每个服务器请求的详细日志记录，这不仅包括页面请求，还包括图像、文件、HEAD 请求以及几乎所有对 Web 服务器的请求。IIS 一直具备日志记录功能，IIS 7.0 也不例外。

与以前的版本相比，日志文件的默认位置发生了变化，现在位于“%SystemDrive%\inetpub\logs\LogFiles”。默认情况下，每个网站都有自己的日志集，但可以将其更改为按服务器记录日志。

按站点记录的日志会放在以站点 ID 命名的文件夹中。例如，站点 ID 为 10 的网站，其日志文件默认会保存到“%SystemDrive%\inetpub\logs\LogFiles\w3svc10\”。

你可以在 IIS 管理器的服务器、站点、应用程序或文件级别更改日志设置，但并非所有设置都适用于所有级别。例如，只有在服务器级别才能设置编码类型以及日志是按站点还是按服务器记录。

要更改日志设置，可在 IIS 管理器中双击“日志记录”图标。大多数设置在主“日志记录”窗格中进行设置，而启用和禁用日志记录则在右侧的“操作”窗格中设置。

在“格式”下拉列表旁边有一个“选择字段”按钮，它允许你指定要记录到磁盘的字段。我们建议启用三个默认未启用的字段：“发送的字节数”、“接收的字节数”和“引用页”（在 IIS 6.0 中，“请求耗时”也是一个不错的设置，而在 IIS 7.0 中它已成为默认设置）。这些字段可以被大多数统计程序读取，并提供有价值的信息，值得在每次新服务器构建时添加。

日志文件可以通过多种方式读取，为故障排除提供有价值的信息。网站设计团队和营销团队也可以利用日志了解有多少人访问了网站、他们在哪些页面停留、如何到达网站以及使用了什么浏览器或工具来查看网站。以下是一些常见的读取日志文件的方法：
- 使用第三方程序 ：如 Google Analytics、SmarterTools SmarterStats、WebTrends Analytics 等。
- 以原始格式查看文件 ：使用 Notepad、WordPad 或 UltraEdit 等工具。
- 使用日志读取工具 ：如 Log Parser。

日志数据文件不仅可用于营销和了解访客使用网站的情况，还可用于跟踪黑客攻击尝试、找出服务器资源高峰时访问的页面或收集其他有价值的信息。

日志记录流程

graph LR
    A[打开IIS管理器] --> B[双击日志记录图标]
    B --> C[设置常规日志设置]
    C --> D[选择字段按钮设置记录字段]
    C --> E[操作窗格启用或禁用日志]

日志读取方式表格

读取方式	具体工具
第三方程序	Google Analytics、SmarterTools SmarterStats、WebTrends Analytics 等
原始格式查看	Notepad、WordPad、UltraEdit 等
日志读取工具	Log Parser

IIS 7.0 故障诊断与追踪全解析

ASP.NET 追踪（ASP.NET Tracing）

ASP.NET 追踪是在排查动态代码问题时获取有价值信息的强大工具。虽然在 IIS 7.0 中这部分追踪功能没有新特性，但它是必须掌握的关键工具。

ASP.NET 追踪能为每个运行的页面提供详细信息。与失败请求追踪将信息以 XML 格式保存到磁盘不同，页面级追踪可以直接在页面内显示、通过 ASP.NET 追踪查看器查看或通过代码查看。这使得开发人员或系统管理员能够轻松查看整个页面请求的详细信息，包括所有页面事件的精确时间戳、cookie 和会话状态信息、请求和响应以及头部信息等大量内容。

例如，图 20 - 17 展示了页面级追踪的一小部分，该追踪信息会添加到现有页面的底部，位于正常内容之下。这在开发阶段非常理想，但显然不适合生产环境，因为详细信息会嵌入页面供所有人查看。在图 20 - 17 的页面中添加了以下代码：

‘ Trace.Write information before the pause.
Trace.Write(“Custom”, “We are Sleeping for 1000 milliseconds”)
‘ Pause/Sleep for 1 second.
System.Threading.Thread.Sleep(1000)
‘ Trace.Write to show when the pause has completed.
Trace.Write(“Custom”, “Done sleeping, time to wake up.”)

从这段代码可以看到，页面中的自定义信息会显示在追踪报告中，包括 1 秒暂停前后的时间。注意到“From First(s)”列增加了 1 秒，这正是我们指令页面执行的操作。由此可见，追踪功能可以帮助你排查页面各部分的运行时间，有可能发现你所排查网站的性能问题。借助 ASP.NET 追踪，你可以更轻松地判断页面加载缓慢是由 Web 服务调用、数据库调用、自定义图像渲染时间还是代码中的其他因素导致的。

启用 ASP.NET 追踪

页面级和应用程序级追踪默认都是禁用的，因此需要手动启用才能使用。ASP.NET 追踪可以通过多种方式启用：
- 页面级启用 ：最直接的方法是在 ASP.NET 页面代码的顶部添加以下指令：

<%@ Page Trace=”true” %>

这将在页面级启用追踪，并将追踪输入添加到页面底部。页面指令还可以设置 traceMode 属性，该属性可以设置为 SortByCategory 或 SortByTime ，默认值为 SortByTime 。
- 应用程序级启用 ：你也可以在 web.config 文件中在应用程序级别启用 ASP.NET 追踪。在 <system.web> 部分添加 <trace /> 属性，示例如下：

<system.web>
    <trace enabled=”true” pageOutput=”true” localOnly=”true” />
  ... 
</system.web>

在这个示例中，通过 enabled 属性启用了追踪。 pageOutput 属性将追踪数据添加到每个页面的底部，这在开发或非生产环境的故障排查中很有用。 localOnly 属性指示 ASP.NET 追踪查看器仅在本地服务器上可用，其他计算机无法访问。

以下是 ASP.NET 追踪可能的属性及其值的表格：
| 属性 | 描述 |
| — | — |
| Enabled | 可选布尔属性。读写值，指定是否为应用程序或页面启用追踪。默认值为 false。 |
| localOnly | 可选布尔属性。指定 ASP.NET 追踪查看器是否仅在主机 Web 服务器上可用。如果为 false，则可以从任何计算机访问。默认值为 true。 |
| mostRecent | 可选布尔属性。当为 true 时，显示最近的页面请求，最旧的请求会从底部移除。当为 false 时，仅保存 requestLimit 设置的请求数量。如果达到 requestLimit ，新请求将被丢弃。默认值为 false。 |
| pageOutput | 可选布尔属性。当为 true 时，追踪输出将在每个页面的末尾呈现。当为 false 时，仅可从 ASP.NET 追踪查看器获取，页面输出不受影响。默认值为 false。 |
| requestLimit | 可选 Int32 属性。指定服务器上要存储的追踪请求数量。请参阅 mostRecent 属性描述，了解达到 requestLimit 值时如何更改行为。最大值为 10,000。默认值为 10。 |
| traceMode | 可选 TraceDisplayMode 属性。此属性设置“排序依据”值，供 ASP.NET 追踪查看器使用。有两个可能的值： SortByCategory 和 SortByTime 。默认值为 SortByTime 。 |
| writeToDiagnosticsTrace | 可选布尔属性。这个新的 .NET v2.0 属性可以设置为 true，将追踪消息转发到 System.Diagnostics 追踪基础结构以实现进一步的追踪功能。 |

ASP.NET 追踪查看器

当在应用程序级别启用 ASP.NET 追踪时，就可以使用 ASP.NET 追踪查看器。访问 ASP.NET 追踪查看器很简单，默认情况下，你只能在本地主机服务器上查看它，但可以通过前面讨论的属性覆盖默认设置。

要访问 ASP.NET 追踪查看器，导航到应用程序根目录，并在 URL 末尾添加 trace.axd 。例如： http://www.sitename.com/trace.axd 。

如果你不确定应用程序根目录，可以使用以下简单方法找出 ASP.NET 追踪查看器的路径：

<%= “Trace Viewer Path: “ & Request(“SERVER_NAME”) _
& “:” & Request(“SERVER_PORT”) _
& Request.ApplicationPath _
& “/trace.axd” %>

trace.axd 文件是一个虚拟文件，由框架配置文件夹的根 web.config 文件中的 HTTP 处理程序处理。即使它实际上并不存在，ASP.NET 引擎也会将其视为真实文件进行处理。

ASP.NET 追踪查看器提供的信息与 pageOutput 追踪信息相同，但它不会干扰网页本身，因为它是通过单独的工具提供的。从 ASP.NET 追踪查看器的列表页面中，点击页面即可查看其追踪报告。追踪报告提供的信息与 pageOutput 追踪信息相同，优点是不会影响页面外观，而是将信息保存到报告中供系统管理员查看。

保护 ASP.NET 追踪查看器

如果你将 localOnly 属性设置为 false，允许从任何计算机访问 ASP.NET 追踪查看器，那么保护它以防止未经授权的人员访问敏感信息就很重要。你可以在应用程序根目录的 web.config 文件中使用 <location> 元素对特定文件或文件夹进行密码保护，示例如下：

<location path=”trace.axd”>
    <system.web>
        <authorization>
            <allow users=”BillGates” />
            <deny users=”*” />
        </authorization>
    </system.web>
</location>

你可以添加任意数量的 <allow> 行。 <allow> 的属性有 users 和 roles 。例如，你可以设置 <allow roles=”admin” /> 以允许所有属于 admin 角色的用户访问 trace.axd 。请确保将此设置放在当前 <system.web> 部分之外，位于主 <configuration> 部分之下。

当在 web.config 中使用 Windows 身份验证时，用户名和密码将是 Windows 或 Active Directory 用户。使用表单身份验证时，你必须使用 ASP.NET 用户名和密码。

通过密码保护的 ASP.NET 追踪查看器，你可以查看访问者浏览页面的完整追踪信息，而他们无法查看这些敏感信息。需要注意的是，ASP.NET 追踪查看器的信息存储在 IIS 工作进程中，因此当应用程序池回收或应用程序域重启时，这些信息将丢失。这也意味着对 web.config 的任何更改都会导致之前的 ASP.NET 追踪查看器数据丢失。

扩展输出数据

ASP.NET 追踪查看器或页面级的 pageOutput 属性可以扩展以包含你提供的信息。这类似于开发人员常用的 Response.Write ，但有几个优点。

当调试信息输出到追踪报告时，可以快速轻松地关闭或对普通用户隐藏，但仍可在追踪报告中使用。这允许你在网站处于生产环境时保留追踪输出，而不会影响性能。当需要深入了解应用程序时，可以启用 ASP.NET 追踪查看器并查看输出信息。

有两种输出追踪信息的方法： Trace.Write 和 Trace.Warn 。唯一的区别是 Trace.Write 输出的文本为黑色，而 Trace.Warn 输出的文本为红色。示例代码如下：

‘ Write key information to the trace output
Trace.Write(“The querystring information is: ” _
& Request.Querystring)
If Request.Querystring = “” Then
    Trace.Warn(“No valid querystring is set.”)
End If

运行时，这些信息将显示在追踪报告中。

你可以通过检查 Tracecontext.Enabled 或 Context.Trace.IsEnabled 属性以编程方式确定是否已启用追踪。这将允许你有条件地输出非追踪信息。例如，如果你只想在启用追踪时显示表格，可以这样做：

If Context.Trace.IsEnabled Then
    ' 显示表格的代码
End If

综上所述，IIS 7.0 中的这些故障诊断和追踪功能为系统管理员和开发人员提供了强大的工具，帮助他们确保网站的稳定运行、优化性能并及时解决各种问题。无论是通过失败请求追踪捕获详细的页面请求信息，还是利用 ASP.NET 追踪深入了解动态代码的执行情况，都能为网站的维护和改进提供有力支持。