Business Connectivity Services 中的诊断日志记录概述 (SharePoint Foundation 2010)

适用于： SharePoint Foundation 2010

上一次修改主题： 2016-11-30

通过使用客户端或服务器上的事件日志和跟踪日志，您可以解决发生在运行 Microsoft SharePoint Foundation 2010 的服务器上的与 Microsoft Business Connectivity Services 相关的疑难问题。另外，事件日志或跟踪日志上的每个条目都具有一个与之相关联的活动 ID，可以使用此活动 ID 将服务器问题跟踪到外部数据源。

备注

除了本主题中论述的日志记录方法外，您还可以使用 Microsoft System Center Operations Manager 管理包来监视基于 Microsoft Business Connectivity Services 的解决方案。有关如何配置 System Center Operations Manager 管理包的详细信息，请参阅管理包中的手册，管理包下载地址为 Microsoft SharePoint 2010 产品管理包 (https://go.microsoft.com/fwlink/?linkid=184971&clcid=0x804)。

本文内容：

Business Connectivity Service 中的诊断日志记录

对于基于 Microsoft Business Connectivity Services 的解决方案，诊断日志记录会出现在运行 Microsoft SharePoint Foundation 的服务器上。日志有两种类型：事件日志和跟踪日志。这两种日志都记录 Microsoft Business Connectivity Services 生成的诊断信息。事件日志记录错误信息。跟踪日志包含更多详细信息，如堆栈跟踪和信息消息。通常，跟踪日志比事件日志提供更多详细信息。

每个信息记录项目都包含一个活动 ID，该活动 ID 是一个唯一的 GUID 值。在某个项目上进行创建、升级或删除操作时，还可以将活动 ID 值发送到外部系统中。通过使用活动 ID，可以从服务器或客户端到外部数据源对某一操作进行跟踪。有关活动 ID 的详细信息，请参阅关于活动 ID。

您可以为事件日志和跟踪日志设置诊断日志记录级别。这样可以限制写入每个日志的信息类型和数量。下表定义了事件日志和跟踪日志可用的日志记录级别：

事件日志级别

级别	定义
无	未发生日志记录。
严重	此消息类型表示在解决方案中导致重大故障的严重错误。
错误	此消息类型表示紧急状态。应调查所有错误事件。
警告	此消息类型表示需要注意的潜在问题。应随时检查警告消息并跟踪其模式。
信息	信息消息不需要任何操作，但它们可以提供监控解决方案状态的有价值的数据。
详细	此事件日志级别对应于冗长的事件或消息。

跟踪日志级别

级别	定义
无	未写入跟踪日志。
异常	此级别用来记录导致解决方案停止处理的相关事件的消息。如果将日志设置在此级别，日志将仅包括这一级别的事件。
可监控	此级别用来记录有关限制解决方案功能但不停止应用程序的不可恢复事件的消息。如果将日志设置在此级别，日志将包括严重错误（异常级别）。
高	此级别用来记录不停止解决方案处理过程的任何异常事件。如果将日志设置在此级别，日志将包括警告、错误（可监控级别）和严重错误（异常级别）。
中	当设置为此级别时，跟踪日志包括除详细消息外的所有日志。此级别用来记录有关已执行操作的所有高级别信息。在这一级别，将记录足够多的详细信息来构建数据流和操作序列。管理员或技术支持人员可以使用此级别的日志记录来排除故障。
详细	当日志设置为此级别时，日志包括所有其他级别的消息。使用这一级别时，几乎所有已执行操作都会被记录。详细跟踪会生成很多日志消息。一般仅当在开发环境中进行调试时才使用此级别。

在开发环境和生产环境中，诊断日志都很有用，但根据环境的不同，对日志记录级别的要求可能也将有所不同。当计划在 Microsoft Business Connectivity Services 中使用诊断日志记录时，请在设置日志记录级别前考虑业务需要和环境生命周期阶段。

例如，在解决方案设计过程中，出于调试的目的，您可能会将两种日志记录级别设置为“详细”来获取生成的所有系统状态相关消息。相反，在生产环境中，您可能只想获取跟踪日志中的“高”、“可监控”和“异常”类别消息以及事件日志中的“严重”和“错误”类别消息。这将节省日志记录的磁盘空间并限制所有对日志记录性能的负面影响。

关于活动 ID

系统将针对基于 Microsoft Business Connectivity Services 的解决方案中外部数据的每一个创建、更新或删除操作生成唯一的 GUID 值（称为“活动 ID”）。跟踪日志或事件日志中所记录操作的所有相关信息都包括各自的活动 ID 值。

重要

在服务器上的事件日志和跟踪日志文件中，活动 ID 值标记为“CorrelationId”值。

为创建、更新或删除操作所生成的活动 ID 值会与此操作相关的其他信息一同发送到外部系统中。如果外部系统具有日志记录机制，则可以在该系统中捕获并记录该活动 ID 值。所以，如果操作导致向 SharePoint 日志中写入了条目，那么可以使用该操作的活动 ID 值跟踪到外部系统中的同一操作。这有利于端对端的故障排除。

一个操作（如创建）经常导致向日志中写入多个事件。发生这种情况时，对此操作记录的所有事件将会使用同一活动 ID 值。由于活动 ID 的重复值有助于我们找到执行某一特定操作的所有事件，因此这对我们进行故障排除很有用。相反，同一类型的操作重复发生时，系统将为每个操作实例生成唯一的活动 ID 值。例如，如果一个外部内容类型项更新了两次，那么每次更新操作将与唯一的活动 ID 值相关联。

提示

在某些情况下，如果 Business Data Connectivity Service 无法连接外部系统，它将重试某项操作。在此种情况下，重试的操作将使用同一活动 ID。

服务器上的诊断日志记录

默认情况下，在 SharePoint Foundation 服务器上将启用Microsoft Business Connectivity Services 日志记录。默认日志记录级别为：

事件日志：严重和错误
跟踪日志：中等

如果 Microsoft Business Connectivity Services 的诊断日志记录是禁用状态，在 SharePoint Foundation 管理中心的“诊断日志记录”页上通过选择“业务连接服务”来启动日志记录。您也可以使用 Windows PowerShell 在服务器上配置事件日志和跟踪日志。例如，您可以更改写入日志记录的驱动器，并且可以设置日志记录的详细级别。

有关 SharePoint Foundation 2010 中日志记录的详细信息（例如，如何设置日志文件位置），请参阅配置诊断日志记录 (SharePoint Foundation 2010)。

您可以使用 Windows PowerShell 来查看服务器上的事件日志，并可以导出日志，例如，将其导出到电子表格程序中。有关详细信息，请参阅查看诊断日志 (SharePoint Foundation 2010)。

Microsoft Business Connectivity Services 将两种类型输出到 SharePoint Foundation 前端 Web 服务器上的跟踪日志中：BDC_Shared_Services 和SS_Shared_Service。您可以使用“事件查看器”打开跟踪日志，并且可以通过搜索“SPS_BusinessData”（用于 Microsoft Business Connectivity Services 输出）和“SPS_SecureStoreService”来筛选相关日志条目。

示例：使用诊断日志记录

此小型的简化方案阐述生产环境中诊断日志记录的使用情况。某企业部署了一个基于 Microsoft Business Connectivity Services 的新考勤卡提交方案。本解决方案使用外部系统来存储员工的考勤卡信息（例如假期和病假），并用于在员工申请休假时，与员工和工资系统进行交互。员工使用 Web 部件与该系统进行交互。

在服务器场中，日志记录级别会设置为 Microsoft Business Connectivity Services 的默认值：

事件日志：严重和错误
跟踪日志：中等

本方案中，员工提交一个病假小时数值，但员工和他的经理都没收到报告已成功提交病假时间的电子邮件确认消息。此时员工可以呼叫内部技术支持服务并报告此问题。

技术支持人员意识到此考勤卡应用程序基于 Microsoft Business Connectivity Services。她检查事件日志但是没有发现与用户提交考勤卡请求时的用户标识相关联的错误。然后该技术支持人员检查跟踪日志，发现活动的证据：相应时间上与此用户相关联的一个“更新”操作。技术支持人员记下跟踪日志中的此更新操作所包含的活动 ID 值。

技术支持人员知道外部系统也支持日志记录。她使用活动 ID 在外部系统中找到了记录项，同时发现了更新操作结束时写入到日志中的一条错误：更新失败，因为员工已用完所有分配的病假时间。技术支持人员还注意到没有日志条目可以确认更新操作发生后外部系统立即生成了电子邮件消息。技术支持人员因此得出结论：考勤卡应用程序中存在逻辑错误。虽然在员工用完分配的病假时间时，此应用程序正确地未分配病假工资，但是却未能就此生成电子邮件消息通知员工。技术支持人员向创建此应用程序的开发团队报告了此问题，开发团队更新了此应用程序。

通过