对 System Center Operations Manager 中的空白报表进行故障排除

2024-12-14

空白报表可能是 System Center Operations Manager 的常见问题。这些是由许多不同的原因引起的。

原始产品版本： System Center 2012 Operations Manager
原始 KB 数： 2573329

在本文中，我们将讨论以下常见问题：

选择错误的实体类型作为报表目标。
未为报表目标启用生成性能数据的相应性能收集规则或脚本。
代理上的运行状况服务存在功能问题。
管理服务器无法将数据插入 OperationsManagerDW 数据库。
Data 停滞在 OperationsManagerDW 数据库中的临时表中。

报告可能返回空白的原因有其他原因，但它们不在本文的作用域之外。对于这些问题，建议使用Microsoft产品支持并获取帮助来提出支持案例。

选择错误的实体类型作为报表目标

对于此问题和其他问题，我们将专注于性能报告。它们最常见的是返回空白，相同的步骤通常也适用于其他报表。第一步是标识生成报表数据的实体和性能计数器。获取此信息的最简单方法是在监视中找到相应的性能视图。性能视图中的图例将列出实体、性能计数器和性能收集规则的名称。

例如，如果要对 Exchange 2003 管理包中的 Exchange 信息存储使用情况 报告进行故障排除，请转到 “监视 ”并打开 “IS 性能数据 ”视图。此视图的路径Microsoft Exchange Server/Exchange 2003/Components/IS Performance Data。在性能视图中，图例将显示性能数据的目标、计数器和收集规则。在 IS 性能数据 视图中，目标始终 是信息存储 ，路径始终是运行 IS 服务的服务器的名称。如果选中图例中任何行的框，该信息存储上的该计数器的性能数据将显示在图表中。如果图表中出现折线，则正在收集数据。

在此示例中，目标始终 是信息存储。这意味着，只有在运行 Exchange 信息存储使用情况报告时，才必须选择信息存储实体。除信息存储之外的任何其他实体都不会返回任何数据。因此，如果选择 Exchange 2003 角色对象，将生成空报表。若要选择 信息存储 实体作为报表目标，请选择“ 添加对象”，键入 搜索字符串的信息存储 ，然后选择“ 搜索”。将显示每个 信息存储 的列表。搜索结果中的路径值将提供承载 信息存储的服务器名称。

相同的原则适用于大多数其他报表。若要对 Exchange SMTP 使用情况报告进行故障排除，请转到“监视”，然后在 Microsoft Exchange Server/Exchange 2003/SMTP 下打开 SMTP 性能数据视图。你将看到目标始终 是 SMTP。若要对 SQL Server 2005 管理包中的 SQL Server 数据库空间报表进行故障排除，请转到“监视”，然后在“SQL Server/性能”下打开“数据库可用空间”性能视图。你将看到目标始终是数据库名称。请记住， 图例中的目标 将是搜索字符串，以及配置报表参数时必须使用的目标。

未为报表目标启用生成性能数据的性能收集规则或脚本

同样，你将依赖于监视中的性能视图。如果未收集性能数据，性能视图中会显示以下两种症状之一：

图例中未列出预期的实体。
实体列在图例中，但在选中该实体框时不会显示任何数据。

如果性能视图图例中缺少预期的实体，这可能意味着尚未发现该实体。例如，你可能在列表中未显示的代理上运行信息存储或 SQL Server 2005 数据库引擎。若要检查此问题，请打开 “我的工作区”，创建新的状态视图，并配置状态视图以显示与该实体类型相关的数据。如果预期实体未显示在视图中，则尚未发现它。然后，你可以将其作为发现问题进行故障排除，而不是作为报告问题进行故障排除。

如果性能视图图例中缺少预期的实体，这也意味着该计数器的性能收集规则未为该目标启用。如果规则已禁用，则可能会发生这种情况。某些管理包包含默认禁用的性能收集规则，需要重写才能启用它们。这在管理包指南中记录。例如，使用 Exchange 2003 管理包时，必须创建替代来启用用于邮件跟踪的性能收集规则。如果不执行此操作，则不会为 SMTP Out 和 SMTP In 报表收集数据。有关启用哪些性能收集规则以及任何手动配置步骤（如果适用）的信息，请参阅管理包指南。

如果在管理包指南中找不到答案，可在“创作”中找到性能收集规则，并验证是否为目标实体启用了该规则。查找规则的最简单方法是在性能视图图例中标识规则名称，然后使用“创作”中的搜索工具查找规则。例如，你发现无法在 Exchange 2003 管理包中始终 获取 Exchange 磁盘使用情况 报表的数据。转到 “监视 ”，并在 Microsoft Exchange Server/Exchange 2003/Server Performance 下打开 PhysicalDisk 性能视图。你注意到，某些 Exchange 服务器未列在图例中，但其他服务器也列在那里。图例中列出了以下规则名称：

平均磁盘队列长度（所有磁盘）
当前磁盘队列长度（所有磁盘）
磁盘读取数/秒（所有磁盘）
磁盘写入数/秒（所有磁盘）

打开 “创作 ” 并使用“搜索” 命令查找名为 “平均磁盘队列长度”（所有磁盘）的规则。打开规则属性并发现此规则已禁用，并且有一个替代，用于仅对所选 Exchange 服务器组启用规则。这解释了为什么某些 Exchange 服务器不为此报表生成数据。必须调整规则配置以面向所有 Exchange 服务器而不是自定义组。

代理上的运行状况服务存在功能问题

在某些情况下，预期实体可能在性能视图图例中列出，但选中其框时不会显示任何数据。这可能表示代理的性能或功能问题。例如，代理上的运行状况服务可能未运行，或者代理可能无法连接到其管理服务器。尝试增加性能视图的时间范围，以返回几天。这有助于确定何时停止收集性能数据。此外，请检查相应代理上的 Operations Manager 事件日志，并查找运行状况服务和运行状况服务模块错误。具体而言，查找指示缺少性能计数器的事件。此外，请检查运行状况服务脚本 6026 或 6024 事件。当运行状况服务超出专用字节或句柄计数的阈值并重新启动时，将记录这些事件。出现此问题时，性能数据收集可能存在差距。

管理服务器无法将数据插入 OperationsManagerDW 数据库

如果一个或多个管理服务器无法写入 OperationsManagerDW 数据库，症状会有所不同且不可预知。对于使用一个管理服务器的代理，你可能有报告数据，但对于使用另一台管理服务器的代理，则没有报告数据。在所有情况下，报告可能都是现成的。

识别这些问题的第一步是检查所有管理服务器上的 Operations Manager 事件日志。 HealthService 2115 事件是数据库访问问题的常见症状。当服务器收集数据时，管理服务器上的运行状况服务记录这些事件。操作数据和报告数据可能会发生这种情况。通常，事件说明中列出的工作流 ID 将指示收集的数据类型。 ID 中具有 DataWarehouse 的工作流与报告数据相关。排查此类问题作为数据库连接或数据库性能问题。记录事件 ID 2115 中记录了此错误的一个已知原因，管理服务器在 System Center Operations Manager 2007 中生成“无法将数据写入数据仓库”警报。

如果未看到 2115 个事件，请在事件日志上配置筛选器，以显示源运行状况服务模块和类别数据仓库中的警告和错误事件。当任何数据仓库工作流在管理服务器上失败时，会记录这些日志。这些事件的说明通常包括返回的 SQL Server 错误和工作流名称。工作流名称可能会提供有关受影响任务的一些上下文。名为 Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData 的工作流收集用于报告的性能数据，并将数据插入数据库中。

Data 停滞在 OperationsManagerDW 数据库中的临时表中

首先检查管理服务器上的 Operations Manager 事件日志，以获取事件 ID 31552，并在事件说明中列出的以下工作流名称：

Microsoft.SystemCenter.DataWarehouse.StandardDataSetMaintenance

StandardDataSetMaintenance 是整理、优化和聚合数据仓库中的数据的工作流（也称为规则）。如果此工作流失败，数据可能会停滞在临时表中。此规则在 OperationsManagerDW 名为 StandardDatasetMaintenance数据库中运行存储过程，该存储过程调用其他存储过程来处理暂存、聚合、优化和整理标准数据集。所有存储过程名称以 StandardDataset 开头。默认情况下，规则每 60 秒运行一次。如果看到 31553 或其他错误事件，这可能表示事件中列出的数据集出现问题。请继续阅读，了解有关此操作的详细信息和故障排除步骤。

管理服务器将原始报告数据插入数据库中的 OperationsManagerDW 临时表。然后运行另一组工作流，将数据从临时表移动到每小时和每日表。这些表用于报表。因此，如果性能数据停滞在临时表中，报表将无法返回数据。若要检查暂存表中的性能数据，请对 OperationsManagerDW 数据库运行以下查询：

Use OperationsManagerDW
Select
   DateTime
From
   Perf.PerformanceStage
Order By
   DateTime

此表中日期超过一两天的记录可能表示数据未按预期移动到每日和每小时表。现在，在继续之前，让我们来谈谈数据库中的维护。维护分为所谓的 数据集。运行维护时，我们会针对数据库中的每个数据集运行它。若要了解这一点，请运行以下查询：

Use OperationsManagerDW;
With AggregationInfo As
(
   Select
      AggregationType =
      Case
         When
            AggregationTypeId = 0
         Then
            'Raw'
         When
            AggregationTypeId = 20
         Then
            'Hourly'
         When
            AggregationTypeId = 30
         Then
            'Daily'
         Else
            NULL
      End
   ,AggregationTypeId, MIN(AggregationDateTime) As 'TimeUTC_NextToAggregate'
   ,SUM(Cast (DirtyInd As Int)) As 'Count_OutstandingAggregations', DatasetId
   From
      StandardDatasetAggregationHistory
   Where
      LastAggregationDurationSeconds Is Not NULL
   Group By
      DatasetId, AggregationTypeId
)
   Select
      SDS.SchemaName,
      AI.AggregationType,
      AI.TimeUTC_NextToAggregate,
      Count_OutstandingAggregations,
      SDA.MaxDataAgeDays,
      SDA.LastGroomingDateTime,
      SDS.DebugLevel,
      AI.DataSetId
   From
      StandardDataSet As SDS WITH(NOLOCK)
      Join
         AggregationInfo As AI WITH(NOLOCK)
         On SDS.DatasetId = AI.DatasetId
      Join
         dbo.StandardDatasetAggregation As SDA WITH(NOLOCK)
         On SDA.DatasetId = SDS.DatasetId
         And SDA.AggregationTypeID = AI.AggregationTypeID
   Order By
      SchemaName Desc

这将显示所有 数据集 类型及其相关信息。下面是有关你看到的列的一些信息：

SchemaName：这是数据集的名称（例如，性能、状态、其他一些自定义数据集等）。你会注意到，警报和事件不会在此处显示，这是因为这些数据集没有聚合表。
AggregationType：数据集可以聚合到不同的粒度级别，此查询显示每种类型的聚合的结果（例如每小时、每日）。
TimeUTC_NextToAggregate：这是要聚合的下一个时间间隔的 UTC 格式的时间戳。对于每日聚合类型，只需查看 YYYY-MM-DD 值并忽略其余值。
Count_OutstandingAggregations：这是数据集所隐藏的聚合数。如果看到值介于 1 和 3 之间，则实际上已赶上。如果（与上述状态一样），你会看到更大的数字，你落后了。
MaxDataAgeDays：这是为给定数据集的聚合设置的保留策略。
LastGroomingDateTime：相当直截了当。
DebugLevel：可以打开数据集上的调试级别，并获取诸如跟踪以诊断问题之类的内容。此处的关键要点是，你只想在短时间内启用此功能，如果发现数据集上的值高于 0 ，则不会调查，然后将其设置回 0。
DataSetId：这是数据集的 GUID，稍后会派上用场。

通过上述信息，我们现在可以看到我们的任何数据集是否落后。我们再次将在此处的示例使用性能数据集。让我们运行此查询：

Use OperationsManagerDW
Select
   AggregationDateTime,
   LastAggregationDurationSeconds
From
   StandardDatasetAggregationHistory AS AH
   Inner Join
      StandardDataSet As DS
      On AH.DatasetId = DS.DatasetId
Where
   DS.SchemaName = 'Perf'
Order By
   AggregationDateTime Desc

如果未看到具有当前日期的记录，则表示未发生聚合。指示聚合速度缓慢的高值 LastAggregationDurationSeconds 。这些类型的问题通常表示 SQL Server 配置或性能问题。检查 SQL Server 错误日志和 SQL Server 性能分析是一个很好的开始位置。

或者，可以检查什么是所谓的 DirtyInd 条目。 DirtyInd 条目表示数据聚合时出现略有不同的问题，但过程可以跟上的数据多。默认情况下，性能聚合一次只移动 100,000 行，因此，如果存在大量性能数据，可能会落后，从而导致空白或不完整的报告。若要检查 Dirtyind 条目，请运行以下查询：

Declare @DataSet as uniqueidentifier
Set
   @DataSet =
   (
      Select
         DataSetId
      From
         StandardDataSet
      Where
         SchemaName = 'Perf'
   )
   Select
      *
   From
      StandardDataSetAggregationHistory
   Where
      DataSetId = @DataSet
      And DirtyInd = 1

如果上述查询中看到的条目超过 4-5 个，可能需要手动运行维护。在手动运行它或执行后续步骤之前，需要关闭默认维护规则。若要关闭规则，请转到控制台，打开 “创作”，选择“ 规则”。将范围更改为 标准数据集。替代 Perf 数据集的规则（或要进行故障排除的数据集）。现在，请等待管理服务器获取确认已应用新配置的 1210 事件，并继续执行后续步骤。

若要手动运行维护，请运行以下查询：

Declare @DataSet uniqueidentifier
Set
   @DataSet =
   (
      Select
         DataSetId
      From
         StandardDataset
      Where
         SchemaName = 'Perf'
   )
   Exec StandardDataSetMaintenance @DataSet

继续运行上述项，直到只有 1-3 个条目（这是正常的，每个聚合类型的一个条目）。如果看到许多条目（超过 100 个），可能需要运行以下项：

Declare @i int
Set
   @i = 0
   Declare @DataSet uniqueidentifier
   Set
      @DataSet =
      (
         Select
            DataSetId
         From
            StandardDataset
         Where
            SchemaName = 'Perf'
      )
      While(@i <= 500)
      Begin
         Exec StandardDataSetMaintenance @DataSet
         Set
            @i = @i + 1 Waitfor Delay '00:00:05'
      End

这将根据你设置 While(@i<=500)的值在循环中运行维护。可以将此值设置为所需的任何值，但不建议超过 500。可以通过再次运行 Dirtyind 查询来检查循环的进度，该查询在循环进行时应返回更少的行。脚本完成后，再次检查 Dirtyind 条目，如果现在为当前条目，请测试报告。如果仍有太多条目，请继续运行脚本，直到聚合保持最新状态。