解决应用程序问题
AppFabric 提供了用于管理 IIS 托管的 .NET Framework v4 WCF 和 WF 服务的功能。 这些功能包括托管持久工作流服务的可靠性机制、简化的应用程序配置,以及监控 .NET Framework 4 WCF 和 WF 服务运行状况的工具。 本部分介绍如何使用监控工具解决服务疑难问题。
使用仪表板开始对 WCF 和 WF 服务进行疑难解答。 单击 IIS Manager 中 AppFabric 组的**“仪表板”**图标以显示“仪表板”页。 此混合页面提供了在 IIS 中特定作用域部署的应用程序的运行状况摘要视图,并提供了深入到更具体的疑难解答信息的链接。 如果仪表板及其相关页显示的指标没有提供您解决问题所需的详细信息,则可以使用 AppFabric 工具启用 System.Diagnostics 跟踪以解决 WCF 或 WF 应用程序的疑难问题。
使用仪表板进行疑难解答
对于分布式应用程序,隔离问题并没有查看计数器或仅使用一个工具隔离那么简单。 更确切地讲,在分布式服务环境中解决问题通常需要将不同工具或计数器中的数据关联起来,才能清楚地了解问题的真正原因。 仪表板包含三个小组件:“暂留的 WF 实例”、“WCF 调用历史记录”和“WF 实例历史记录”,您可以使用这三个小组件关联信息以解决应用程序疑难问题。 后两个小组件是历史指标,表示显示的项目受到仪表板顶部“时间段”时间选择器(“近 1 分钟”、“近 24 小时”等)的影响。
当您首次打开或查看这三个小组件之一时,会看到其指标状态的高级别摘要视图。 可以快速查看该级别是否存在问题。 例如,“暂留的 WF 实例”小组件最初会显示实时持久工作流实例的状态(这些实例已将其状态保存在暂留存储中)。 此组件显示处于活动、空闲和已挂起状态的暂留实例数的摘要状态。 这样便可以快速提示您暂留工作流级别是否存在问题。 可以单击摘要页上的链接获取关于特定摘要计数器的其他信息。
使用暂留 WF 实例指标
“暂留的 WF 实例”小组件显示实时工作流实例的状态(这些实例已将其状态保存在暂留存储中)。 此组件显示处于活动、空闲和已挂起状态的暂留实例数。 每个标题和总计数自身都是指向包含原始数据的“暂留的 WF 实例”页的链接。
若要在解决已挂起实例的疑难问题时更好地了解问题,请单击仪表板上的“已挂起的实例”链接。 “暂留的 WF 实例”页会显示所有已挂起的实例。 选择其中之一将使用已挂起实例的摘要信息填充屏幕底部的“详细信息”窗格。 “错误”选项卡显示实例挂起的原因。 如果需要其他信息,请右键单击实例,然后选择“查看跟踪事件”选项。 此操作将引导您访问“跟踪的事件”页,从而显示此挂起工作流实例的所有跟踪的事件。 默认情况下,会将最新的事件排列在前面。
使用 WCF 调用历史记录指标
“WCF 调用历史记录”小组件显示已经收到并记录在监控存储中的 WCF 调用数。 标题显示已经完成或遇到异常的调用总计数,或者达到限制的次数。 第一列显示完成调用次数最多的前五项服务。 第二列显示按错误类型分组的 WCF 错误细分。 第三列显示服务异常次数最多的前五项服务。 每个指标都链接到“跟踪的事件”页,您可以在其中查看仪表板上汇总的原始数据。
例如,若要获取有关失败调用的详细信息,请单击“调用失败”摘要计数器,转到“跟踪的事件”页。 此页包含 IIS 层次结构中选定作用域的最新失败 WCF 调用。 选择其中一个事件将填充屏幕底部的“详细信息”窗格。 “错误”选项卡包含有关失败的异常信息。 如果您需要有关失败的调用的更多上下文,请右键单击事件,然后选择“查看所有相关事件”选项。 此操作将刷新“跟踪的事件”页,并使用与此事件相关的所有事件填充此页。
备注
若要使用“查看所有相关事件”选项,必须将应用程序的监控级别设置为“端对端监控”或更高。 此级别告诉监控基础结构收集将一个端对端活动 ID (E2EActivityId) 与另一个端对端活动 ID 相关联的传输事件。
使用 WF 实例历史记录指标
“WF 实例历史记录”小组件显示已经激活、失败和完成的工作流实例数。 第一列显示激活实例数最多的前五项服务。 第二列显示失败实例数最多的前五项服务。 第三列显示已经恢复的失败实例数。 例如,如果工作流实例遇到错误导致该实例被挂起,但在后来成功继续并完成,则会在“失败”列和“已恢复”列各记一次。
使用“WF 实例历史记录”小组件中的信息进行疑难解答与使用“暂留的 WF 实例”小组件类似。 单击其中一个标题以转到“跟踪的 WF 实例”页,您可以从中查看有关该工作流实例的摘要信息。 但是,由于“WF 实例历史记录”小组件显示的工作流实例可能已经完成,因此您不会看到“暂留的 WF 实例”页中出现的实例控制操作。 在“跟踪的 WF 实例”页上,可以右键单击实例,查看其跟踪的事件以了解该实例的低级别跟踪数据。
使用 System.Diagnostics 跟踪进行疑难解答
AppFabric 在向 Windows 事件跟踪 (ETW) 子系统发出事件的 .NET Framework 4 中利用了 WCF 跟踪和 WF 跟踪的增强功能。 ETW 提供了快速事件跟踪基础结构。 但是,在某些情况下您需要查看所有可用的诊断信息。 在 AppFabric 中,可以在应用程序或站点级别启用 System.Diagnostics 跟踪。 此跟踪信息将被写入磁盘文件,并可以使用服务跟踪查看器工具进行查看。
警告
System.Diagnostics 跟踪会降低应用程序性能并生成大量跟踪文件。 只有在解决应用程序疑难问题时,才应该启用 System.Diagnostics 跟踪。
分布式 ASP.NET 应用程序疑难解答
您可以使用活动 ID(如在前面的使用 WCF 调用历史记录指标部分所述)来查找持久实例 ID 并且帮助对跨多台 AppFabric 服务器计算机与 WCF 服务通信的 ASP.NET 应用程序进行疑难解答。 为此,必须将监控级别设置为至少“端对端监控”以配置活动跟踪。下面我们拿一个示例来说明此过程。
使用 ASP 和 IIS 监控工具监控 Web 应用程序时,管理员注意到与服务通信时 ASP.NET 应用程序的超时错误增加。检查错误之后,管理员获得在发生错误时处于活动状态的活动 ID。使用 AppFabric 仪表板,管理员针对该活动 ID 创建和执行查询。返回一个事件 – 一个有关服务 X 的实例 Y 的接收事件。他查看与该事件关联的消息流,并注意到一个“已超出最大并发调用限制”事件。查看服务摘要页,管理员注意到“WCF 节流点击量”设置为 20。他还看到在过去 24 小时时间内的调用已被阻止 30 分钟。 他查看其他日期,并且注意到每天同一时间的相同事件。他得出结论,负载在每天的那些时间增加,并且应该将最大并发调用设置增加到 25。通过仔细观察,他注意到与 ASP.NET 应用程序的超时错误一样,调用 WCF 服务时限制事件的发生大大减少了。
SQL Server Agent Windows 服务作业
SQL Server Agent Windows 服务监控 SQL Server 操作,自动化部分管理任务,根据需要生成警报,以及计划和执行作业。 SQL Server 作业是由 SQL Server Agent 按顺序执行的一系列指定操作,其中包含各种与数据库相关的任务。 在将 AppFabric 配置为使用 SQL Server 时,会使用 SQL Server Agent 将事件导入监控数据存储并定期从存储中清除旧数据。
如果 SQL Server Agent 没有运行,则计划的 AppFabric 作业无法在 SQL Server 安装内执行。以下是使用 SQL Server Agent Windows 服务确保这些作业按计划执行的一些步骤:
通过检查 SQL Server Agent Windows 服务的状态确保其正在运行。 单击“管理工具”,选择“服务”、SQL Server Agent (MSSQLSVR),确保其“状态”当前显示为“已启动”。 否则,请启动该服务。
初始化存储时会创建四个 SQL Server 作业:
Microsoft_ApplicationServer_Monitoring_AutoPurge_<monitoring DB name>
Microsoft_ApplicationServer_Monitoring_ImportWfEvents_<monitoring DB name>
Microsoft_ApplicationServer_Monitoring_ImportWcfEvents_<monitoring DB name>
Microsoft_ApplicationServer_Monitoring_ImportTransferEvents_<monitoring DB name>
如果 SQL Server Agent Windows 服务已启动,但是 AppFabric 作业没有运行,请查看上次运行作业时遇到的错误。
如果作业实例成功完成但事件表中没有记录事件,请查看监控数据存储下的 ASFailedStagingTable 表。此表包含的某些列(例如 ErrorNumber 和 ErrorMessage)可以帮助您查明失败的原因。如果没有出现错误,则此表为空。
运行 AppFabric SQL Server Agent 作业所使用的 Windows 标志(所有者)不应该是登录用户的。 而是应该在预配置的 AS_MonitoringDbJobsAdmin Windows 安全帐户身份下运行。 理想情况下,此帐户应为域帐户。在 Initialize-ASMonitoringDatabase cmdlet 运行以下安装时,此帐户在监控存储中具备适当的权限。
下面说明了 SQL Server Agent 如何处理提交的 AppFabric Server 作业的不同所有者:
如果 SQL Server Agent 作业的所有者是域帐户,SQL Server 会联系域控制器检查此帐户是否有效。 如果有效,它将在该域帐户下运行。如果无效,它将尝试在本地帐户下运行。
如果 SQL Server Agent 作业的所有者是一个本地 sysadmin 帐户,SQL Server Agent 会在作业步骤中正确采用“RunAs”身份并发出“Execute user as AS_MonitoringDbJobsAdmin”命令。 这表示作业在 AS_MonitoringDbJobsAdmin 帐户身份下运行。
备注
若要在 SQL Server Management Studio 内查看作业的“RunAs”身份,请右键单击该作业,单击“属性”,然后单击“高级”选项卡。 此值应设置为 AS_MonitoringDbJobsAdmin 帐户。
如果 SQL Server Agent 作业的所有者是本地帐户但不是 sysadmin,则将忽略作业步骤中提供的“RunAs”身份。 在这种情况下,SQL Server Agent 服务会以本地所有者身份运行此作业。
在断开连接的域方案(如便携式计算机)中,如果 SQL Server 监控作业的身份是域用户,SQL Server Agent 会尝试通过联系域控制器验证帐户。如果运行 SQL Server Agent 作业的计算机从域断开连接,则此操作失败。若要缓解此失败,有两个选项可供选择:
第一个(也是两个选项中最简单的一个)是使用本地用户帐户配置作业(即,运行 Initialize-ASMonitoringDatabase cmdlet)。
第二个选项是,如果所有者使用域帐户配置了该作业,则该用户可以在稍后使用 SQL Server sp_update_job 存储过程将作业所有者更新为本地用户帐户。
最佳做法是将 SQL Server Agent Windows 服务配置为在本地登录帐户下运行。 这样,即使网络连接终止,仍可在 AppFabric 计算机上运行服务。 如果此服务在域帐户下运行但无法访问该域,则 SQL Server Agent Windows 服务无法获取凭据。 这表示无法将监控事件正确地移动到最终目标表格。 结果会导致仪表板中没有新数据显示。
SQL Server Express 作业
虽然诊断作业失败原因的步骤与 SQL Server 非常相似,但可能需要查看 SQL Server Express 的 ASJobsTable 表。此表特定于 SQL Server Express 安装,不存在于 SQL Server 安装中。 在此表中,可以查看特定作业行的 LastRunOn 和 LastRunSuccess 列值,以确定作业运行成功还是失败。
SQL Server Express 不使用 SQL Server Agent Windows 服务。 但是它使用 SQL Service Broker。Service Broker 功能中包含时间功能,该功能可设置一个超时值作为时间间隔,Microsoft_ApplicationServer_Monitoring_AutoPurge_<monitoring DB name> 作业配置为在该时间间隔内运行。 出现此超时间隔时,会向 SQL Server 作业队列发送一条消息。 此消息会激活作为 Microsoft_ApplicationServer_Monitoring_AutoPurge_<monitoring DB name> 作业的一部分运行的存储过程。 而此操作会对 SQL Server Express 存储运行自动清除功能。
以下是一些 T-SQL 查询,您可以运行这些查询以帮助监控自动存储清除功能的进度:
显示当前计划的作业:
SELECT * FROM ASJobsTable
查看 dialog_timer 列(UTC 时间)以了解计划下一次运行作业的时间:
SELECT * FROM sys.conversation_endpoints
显示当前执行的激活过程数:
SELECT * FROM sys.dm_broker_activated_tasks
了解仍处于队列中的消息数。 没有正在运行的作业时,会返回 0:
SELECT * FROM ASScheduledJobQueue
另请参阅
参考
“Windows Server AppFabric 仪表板”页
“保留的 WF 实例”页
“跟踪的 WF 实例”页
“跟踪的事件”页
2011-12-05