Lync Server 2013 中的集中日志记录服务概述

 

上次修改的主题： 2013-02-22

集中式日志记录服务旨在提供一种用于受控数据收集的方法，范围广泛或范围较窄。 可以同时从部署中的所有服务器收集数据，定义用于跟踪、设置跟踪标志的特定元素，以及从单台计算机返回搜索结果，或从所有服务器聚合所有数据。 集中日志记录服务在部署中的所有服务器上运行。 集中日志记录服务的体系结构由以下代理和服务组成：

• 集中日志记录服务代理 ClsAgent.exe是与控制器通信并接收管理员发出的控制器命令的服务可执行文件。 代理作为服务在每台 Lync Server 计算机上运行。 当代理收到命令时，它会执行命令，将消息发送到定义的组件进行跟踪，并将跟踪日志写入磁盘。 它还读取其计算机的跟踪日志，并在请求时将跟踪数据发送回控制器。 ClsAgent 侦听以下端口上的命令： TCP 50001、 TCP 50002 和 TCP 50003。

• 集中日志记录服务控制器 ClsControllerLib.dll是 Lync Server Management Shell 和 ClsController.exe 的命令执行引擎。 CLSControllerLib.dll将“开始”、“停止”、“刷新”和“搜索”命令发送到 ClsAgent。 发送搜索命令时，生成的日志将返回到ClsControllerLib.dll并进行聚合。 控制器负责向代理发送命令、接收这些命令的状态以及管理搜索日志文件数据，因为搜索日志文件数据是从搜索范围内任何计算机上的所有代理返回的，并将日志数据聚合到有意义的有序输出集中。 以下主题中的信息侧重于使用 Lync Server Management Shell。 ClsController.exe仅限于 Lync Server Management Shell 中提供的功能和函数的子集。 通过在默认目录 C：\Program Files\Common Files\Microsoft Lync Server 2013\ClsAgent 中键 ClsController 入，可在命令行中提供ClsController.exe帮助。

ClsController 与 ClsAgent 的通信

使用 Windows Server 命令行接口或 Lync Server Management Shell 发出命令。 这些命令将在您登录的计算机上执行，并将本地发送到 ClsAgent 或发送到部署中的其他计算机和池。

ClsAgent 维护其在本地计算机上具有的所有 .CACHE 文件的索引文件。 ClsAgent 将分配这些文件，使其均匀分布在由选项 CacheFileLocalFolders 定义的卷上，并且绝不会占用每个卷的 80% 以上的容量（即，可使用 Set-CsClsConfiguration cmdlet 配置本地缓存位置和百分比）。 ClsAgent 还负责从本地计算机中清除旧的缓存事件跟踪日志 (.etl) 文件。 两周之后（即，可使用 Set-CsClsConfiguration cmdlet 配置时间范围时），会将这些文件复制到一个文件共享中并从本地计算机中删除它们。 有关详细信息，请参阅 Set-CsClsConfiguration。 在收到一个搜索请求时，搜索条件将用于选择一组缓存的 .etl 文件以便根据代理所维护的索引中的值来执行搜索。

注意

从本地计算机移至文件共享中的文件可通过 ClsAgent 进行搜索。 一旦 ClsAgent 将这些文件移至文件共享中，ClsAgent 将不会维护文件的清楚和删除。 您应定义一个管理任务来监控文件共享中的文件大小，并删除这些文件或对其进行存档。

可使用多种工具读取和分析生成的日志文件，其中包括 Snooper.exe 以及任何可读取文本文件的工具（例如 Notepad.exe）。 Snooper.exe是 Lync Server 2013 调试工具的一部分，可作为 Web 下载。https://go.microsoft.com/fwlink/?LinkId=285257

与 OCSLogger 一样，集中日志记录服务具有多个要跟踪的组件，并提供用于选择标志的选项，例如TF_COMPONENT和TF_DIAG。 集中式日志记录服务还保留 OCSLogger 的日志记录级别选项。

通过命令行 ClsController 使用 Lync Server Management Shell 最重要的优势是，可以使用针对问题空间、自定义标志和日志记录级别的选定提供程序配置和定义新方案。 对 ClsController 可用的方案仅为针对可执行文件定义的方案。

在早期版本中，提供了 OCSLogger.exe 以使管理员和支持人员能够从部署中的计算机中收集跟踪文件。 尽管 OCSLogger 具有的优点不少，但它也有一个缺点。 在给定时间内，您只能在一台计算机上收集日志。 虽然可通过使用 OCSLogger 的独立副本来登录多台计算机，但最终将获得多个日志且无法轻松聚合结果。

当用户请求一个日志搜索时，ClsController 将确定将请求发送到哪些计算机（即，基于选定方案）。 它还确定是否需要将搜索发送到已保存的 .etl 文件所在的文件共享。 当搜索结果返回到 ClsController 时，控制器会将结果合并到一个呈现给用户的按时间排序的结果集中。 用户可以将搜索结果保存到其本地计算机中以供进一步分析。

启动日志记录会话时，指定与尝试解决的问题相关的方案。 可以随时运行两种方案。 这两种方案之一应该是 AlwaysOn 方案。 顾名思义，它应始终在部署中运行，收集所有计算机、池和组件上的信息。

重要

默认情况下，AlwaysOn 方案在部署中不会运行。 您必须显式启动此方案。 一旦启动此方案，它就将继续运行直到被显式停止，并且在重新启动计算机的过程中持续保持运行状态。 有关启动和停止方案的详细信息，请参阅 使用集中日志记录服务的“开始”捕获 Lync Server 2013 中的日志 ，以及 在 Lync Server 2013 中对集中日志记录服务使用停止。

在出现问题时，启动与所报告的问题相关的另一个方案。 重现该问题并停止针对该方案的日志记录。 开始与所报告的问题相关的日志搜索。 日志的聚合收集会生成一个日志文件，其中包含站点或全局范围部署中的所有计算机中的跟踪消息。 如果搜索返回的数据多于可进行可行性分析的数据（通常称为信噪比，其中噪音过高），则可使用范围更小的参数运行另一个搜索。 此时，您可以关注显示的模式并可帮助您准确了解问题。 最后，在执行一组优化搜索后，您可以找到与该问题相关的数据并指出根本原因。

提示

当在 Lync Server 中出现问题方案时，首先问问自己“我对问题了解多少？ 如果量化问题边界，可以在 Lync Server 中消除大部分操作实体。
考虑以下示例方案：您知道用户在查找联系人时未获得当前结果。 在媒体组件、企业语音、会议和其他一些组件中查找问题是没问题的。 您不知道出现问题的实际位置：是客户端上还是服务器端？ 联系人由用户复制器从 Active Directory 收集，并通过通讯簿服务器 (ABServer) 传递给客户端。 ABServer 从 RTC 数据库获取其更新（用户复制程序将更新写入该数据库），并将其收集到一个通讯簿文件中（默认情况下为 1:30 AM）。 Lync Server 客户端按随机计划检索新的通讯簿。 由于你知道该过程的工作原理，因此可以减少对与用户复制程序从 Active Directory 收集数据、ABServer 未检索和创建通讯簿文件或客户端未下载通讯簿文件相关的问题的潜在原因的搜索。