使用 64 位 Operations Manager 代理收集 32 位性能计数器

Article
12/26/2013

对于 System Center Operations Manager 2012，不能在 64 位服务器中安装 32 位代理。尽管－通常－ 32 位应用程序仍然可以由 64 位代理进行监控，但不能使用基于性能的标准规则和监视器收集 32 位自定义性能计数器。根据标准，我指的是可以通过控制台在“创建新规则/监视器”向导中选择“Windows 性能计数器”而创建的规则和监视器。

然而，对于一些后台操作的情况，会绕过这种限制。在本篇博文中，我将向大家介绍如何执行这方面的操作。简短的答案就是：使用基于日志的性能计数器数据源！

它证明，在性能库管理包 (System.Performance.Library) 中，我们可以找到实现目标所需的构造块。此 MP 包括标准性能计数器收集中使用的所有规则和监视器，以及基于日志的计数器收集所需的规则和监视器。这些规则和监视器可以通过分析 Windows 性能监视器 (perfmon) 日志文件来收集性能计数器数据。因此，它们称为“PerformanceLogBased”，而且一切依赖于 PerformanceLogDataProvider 数据源模块执行分析。遗憾的是，这种功能并非通过 SCOM 控制台来实现，因此才实施了“后台”操作。

需要什么？

利用性能库中定义的规则/监视器的简单自定义 MP。
Windows 性能监视器日志记录 (perfmon)。必须为每个需要收集的计数器启用日志记录。

简单示例

目标： 收集并监控代理中远程桌面会话的数量，当 2 个连续样本的远程桌面会话数量超出 4 时，将监视器的状态更改为“重要”。我们还希望将计数器值在操作数据库中存储为性能数据。

性能计数器： 终端服务/会话总数

单元监视器定义

<UnitMonitor ID="PerfLogConsecutiveSamplesMonitor" Accessibility="Public" Enabled="true" Target="SystemCenter!Microsoft.SystemCenter.Agent" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="Performance!System.Performance.PerformanceLogBased.ConsecutiveSamplesThreshold" ConfirmDelivery="false">

<Category>AvailabilityHealth</Category>

<OperationalStates>

    <OperationalState ID="Green" MonitorTypeStateID="ConditionFalse" HealthState="Success" />

    <OperationalState ID="Red" MonitorTypeStateID="ConditionTrue" HealthState="Error" />

  </OperationalStates>

<Configuration>

    <LogFileDirectory>%SystemDrive%\LogFiles\Perflogs</LogFileDirectory>

    <LogFilePattern>TerminalServices*.csv</LogFilePattern>

    <LogIsUTF8>false</LogIsUTF8>

    <Threshold>4</Threshold>

    <Direction>greater</Direction>

    <NumSamples>2</NumSamples>

  </Configuration>

</UnitMonitor>

正如看到的那样，此监视器使用 System.Performance.PerformanceLogBased.ConsecutiveSamplesThreshold 监视器类型，它准确地执行我们需要的操作：当性能计数器的值违反为连续样本数量配置的阈值时，监视器更改状态。

配置

LogFilePattern：包含性能数据的文件的名称。在此案例中，我使用通配符 (*) 来表示应查找以“TerminalServices”开头和具有 .csv 扩展名的所有文件。然后，我们需要告诉 perfmon 记录具有相同名称格式的文件。

LogFileDirectory： 监视器查找与模式匹配的文件的地方。

LogIsUTF8： 表示分析算法是否应根据 UTF-8 进行解码。

阈值： 高于或低于此值时，监视器将更改状态。

NumSamples： 在监视器更改状态之前，需要违反阈值的连续样本的数量。

收集规则定义（在 Ops DB 中存储计数器数据）

以下规则收集驻留在 %SystemDrive%\LogFiles\Perflogs 目录中的 TerminalServices*.csv 格式的文件（例如 TerminalServices01.csv、 TerminalServices02.csv）中记录的性能计数器。然后，它将收集的值在操作数据库中存储为性能数据。然后，可以通过性能视图和仪表板，像平常那样查看此数据。

<Rule ID="PerfLogBasedCollectionRule" Enabled="true" Target="SystemCenter!Microsoft.SystemCenter.Agent" ConfirmDelivery="false">

     <Category>Maintenance</Category>

     <DataSources>

       <DataSource ID="PerfLogRuleDS" TypeID="Performance!System.Performance.PerformanceLogDataProvider">

         <LogFileDirectory>%SystemDrive%\LogFiles\Perflogs</LogFileDirectory>

         <LogFilePattern>TerminalServices*.csv</LogFilePattern>

         <LogIsUTF8>false</LogIsUTF8>

         </DataSource>

       </DataSources>

       <WriteActions>

          <WriteAction ID="PerfLogRuleWA" TypeID="SystemCenter!Microsoft.SystemCenter.CollectPerformanceData"/>

       </WriteActions>

   </Rule>

Some Observations:

每个文件只有 1 个性能计数器（性能对象 + 计数器名称 + 实例的组合）。PerformanceLogDataProvider 数据源模块不支持多个计数器。例如，不能正常记录 w3wp.exe 进程的所有实例的 PrivateBytes。每个文件仅有一个实例。
文件格式应为 CSV（默认情况下，perfmon 日志为二进制格式 – 这种格式需要更改，如下所示）
不应使用循环日志记录。我建议根据大小限制或时间安排按顺序启动新文件。例如，在本案例中，我们拥有 TerminalServices1.csv、TerminalServices2.csv 等。所有文件均记录在同一目录中。
如果运行状况服务停止，然后又在以后开始，则分析应从服务关闭时停止的位置继续。但是，当计算机从维护模式恢复时，由于记录了新的条目，收集将重新开始（不收集代理处于维护状态下时生成的数据）。
您可以通过 UI 控制台为监视器定义警报，方法是进入此监视器的属性，然后设置“警报”配置。
尽管这些工作流程针对代理计算机，但您仍然可以定义自己的类型（例如特定的应用），并将该类型指定为目标类型。当然，必须创建发现类型实例的发现规则。

导入包含规则和监视器的 MP

汇编包含最终规则和监视器的 MP 文件。这里有一个创建新 MP 的选项，使用创建规则向导，导入该 MP，然后对该 MP 进行编辑，使之包括自定义规则和监视器。就绪之后，重新导入最终 MP。

启用 PerfMon 日志记录

数据开始流动之前需要完成的最后一项工作，实际上是将计数器记录到假设 Operations Manager 发现它们的位置，而且采用期望的格式。