对 System Center Operations Manager 中的灰色代理状态进行故障排除

本文介绍如何在 System Center Operations Manager (OpsMgr) 中排查代理、管理服务器或网关不可用或 灰显 的问题。

原始产品版本： Microsoft System Center 2012 Operations Manager
原始 KB 编号： 2288515

代理、管理服务器或网关可以具有以下状态之一，如 “监视 ”窗格中代理名称和图标的颜色所示。

灰色状态的原因

代理、管理服务器或网关可能由于以下任何原因而不可用：

• 检测信号失败
• 配置无效
• 系统工作流失败
• Operations Manager 数据库或数据仓库性能问题
• 管理服务器或网关服务器性能问题
• 网络或身份验证问题
• 运行状况服务未运行

问题范围

在开始排查代理灰显问题之前，应首先了解 Operations Manager 拓扑，然后定义问题的范围。 以下问题可能有助于定义问题的范围：

• 有多少代理受到影响？
• 代理是否在同一网段中遇到问题？
• 代理是否向同一个管理服务器报告？
• 代理多久进入并保持灰色状态？
• 通常如何从这种情况 (恢复，例如重启代理运行状况服务、清除缓存、依赖自动恢复) ？
• 是否为这些代理生成了检测信号失败警报？
• 此问题是否在一天中的特定时间发生？
• 如果将这些代理故障转移到另一个管理服务器或网关，此问题是否仍然存在？
• 此问题是何时开始的？
• 是否对代理、管理服务器或网关或管理组进行了任何更改？
• 受影响的代理是否为 Windows 群集系统？
• 是否从防病毒扫描中排除运行状况服务状态文件夹？

故障排除策略

故障排除策略取决于哪个组件处于非活动状态、该组件在拓扑中的位置，以及问题的广泛程度。 请考虑以下条件：

• 如果向特定管理服务器或网关报告的代理不可用，则应从管理服务器或网关级别开始进行故障排除。
• 如果向特定管理服务器报告的网关不可用，则应从管理服务器级别开始进行故障排除。
• 对于无代理系统、网络设备以及 Unix 和 Linux 服务器，故障排除应从监视这些对象的代理、管理服务器或网关开始。
• 故障排除通常从紧靠不可用组件上方的级别开始。

方案 1

只有少数代理受此问题影响。 这些代理向不同的管理服务器报告。 代理定期不可用。 尽管可以清除代理缓存以帮助暂时解决问题，但几天后问题会再次出现。

方案 1 的解决方案

若要解决此方案中的问题，请执行以下步骤：

1. 将适当的修补程序应用于受影响的操作系统。
2. 从防病毒扫描中排除代理缓存。 有关详细信息，请参阅 与 Operations Manager 相关的防病毒排除建议。
3. 停止运行状况服务。
4. 清除代理缓存。
5. 启动运行状况服务。

方案 2

只有少数代理受此问题影响。 这些代理向不同的管理服务器报告。 代理始终处于非活动状态。 虽然可以清除代理缓存，但这并不能解决问题。

方案 2 的解决方案

若要解决此方案中的问题，请执行以下步骤：

1. 确定运行状况服务是否已打开，并且当前在管理服务器或网关上运行。 如果运行状况服务已停止响应，请在服务挂起模式下生成 ADPlus 转储，以帮助确定问题的原因。 有关详细信息，请参阅 如何使用 ADPlus.vbs 对“挂起”和“崩溃”进行故障排除

2. 检查代理上的 Operations Manager 事件日志，找到以下任何事件：

   事件 ID：1102
   事件源：HealthService
   事件说明：
   无法初始化针对 id 为“%2”的实例“%3”运行的规则/监视器“%4”，并且不会加载。 管理组“%1”

   事件 ID：1103
   事件源：HealthService
   事件说明：
   摘要：%2 规则 () /monitor () 失败并已卸载，其中 %3 已达到阻止自动重新加载的失败限制。 管理组“%1”。 这是仅摘要事件，请参阅其他事件，其中包含已卸载规则 () /monitor () 的说明。

   事件 ID：1104
   事件源：HealthService
   事件说明：
   工作流“%4”中的 RunAs 配置文件，无法解析 id 为“%2”的实例“%3”运行的配置文件。 不会加载工作流。 管理组“%1”

   事件 ID：1105
   事件源：HealthService
   事件说明：
   工作流“%4”中运行实例“%3”的运行方式配置文件的类型不匹配：“%2”。 不会加载工作流。 管理组“%1”

   事件 ID：1106
   事件源：HealthService
   事件说明：
   无法访问工作流“%4”中的纯文本 RunAs 配置文件，运行 id 为“%2”的实例“%3”。 不会加载工作流。 管理组“%1”

   事件 ID：1107
   事件源：HealthService
   事件说明：
   工作流“%4”中的运行方式配置文件，未定义 id 为“%2”的实例“%3”运行。 不会加载工作流。 请将帐户与配置文件相关联。 管理组“%1”

   事件 ID：1108
   事件源：HealthService
   事件说明：
   无法解析运行方式配置文件“%7”中指定的帐户。 具体而言，该帐户在安全引用重写“%6”中使用。 %n%n 由于帐户未配置为分发到此计算机，因此可能会出现这种情况。 若要解决此问题，需要打开下面指定的运行方式配置文件，找到由其 SSID 指定的帐户条目，并根据需要选择将帐户分发到此计算机，或更改配置文件中的设置，以便目标对象不使用指定的帐户。 %n%n管理组： %1 %n运行为配置文件： %7 %nSecureReferenceOverride 名称： %6 %nSecureReferenceOverride ID： %4 %nObject 名称： %3 %nObject ID： %2 %nAccount SSID： %5

   事件 ID：4000
   事件源：HealthService
   事件说明：
   监视主机无响应或已崩溃。 主机故障的状态代码为 %1。

   事件 ID：21016
   事件源：OpsMgr 连接器
   事件说明：
   OpsMgr 无法设置到 %1 的通信通道，并且没有故障转移主机。 当 %1 可用并且允许来自此计算机的通信时，通信将恢复。

   事件 ID：21006
   事件源：OpsMgr 连接器
   事件说明：
   OpsMgr 连接器无法连接到 %1：%2。 错误代码为 %3 (%4) 。 请验证是否存在网络连接、服务器正在运行并已注册其侦听端口，以及是否有防火墙阻止流向目标的流量。

   事件 ID：20070
   事件源：OpsMgr 连接器
   事件说明：
   连接到 %1 的 OpsMgr 连接器，但在身份验证发生后，连接立即关闭。 此错误的最可能原因是代理无权与服务器通信，或者服务器未收到配置。 检查服务器上的事件日志中是否存在 20000 个事件，指示未批准的代理正在尝试连接。

   事件 ID：20051
   事件源：OpsMgr 连接器
   事件说明：
   无法加载指定的证书，因为证书当前无效。 验证系统时间是否正确，并在必要时重新颁发证书%n 证书有效开始时间： %1%n 证书有效结束时间： %2

   事件源：ESE
   事件类别：事务管理器
   事件 ID：623
   说明：HealthService (<PID>) 实例>< (“name>”<) 的版本存储已达到其值> Mb 的最大<大小。 长时间运行的事务可能会阻止清理版本存储，并导致其大小增大。 在完全提交或回滚长时间运行的事务之前，将拒绝汇报。 可能长时间运行的事务：
   SessionId： <value>
   Session-context： <value>
   会话上下文 ThreadId： <值>。
   清理： <值>

3. 如果找到以下特定事件，请遵循以下准则：

   • 事件 1102 和 1103：这些事件指示某些工作流无法加载。 如果这些是核心系统工作流，则这些事件可能会导致问题。 在这种情况下，请重点解决这些事件。

   • 事件 1104、1105、1106、1107 和 1108：这些事件可能导致发生事件 1102 和 1103。 通常，由于运行方式帐户配置错误，会出现这种情况。 例如，运行方式帐户配置为与错误的类一起使用，或者未配置为分发到代理。

   • 事件 4000：此事件指示 Monitoringhost.exe 进程崩溃。 如果此问题是由 DLL 不匹配或缺少注册表项引起的，则可以通过重新安装代理来解决问题。 如果问题仍然存在，请尝试使用以下方法解决此问题：

     • 运行进程监视器捕获，直到进程崩溃。 有关详细信息，请参阅 进程监视器 v3.53。
     • 在崩溃模式下生成 ADPlus 转储。 有关详细信息，请参阅 如何使用 ADPlus.vbs 对“挂起”和“崩溃”进行故障排除

   • 事件 ID 21006：此事件指示代理和管理服务器之间存在通信问题。 如果代理使用证书进行相互身份验证，请验证证书是否未过期，以及代理是否使用正确的证书。 如果使用 Kerberos，请验证代理是否可以与 Active Directory 通信。 如果身份验证正常工作，这可能意味着来自代理的数据包未到达管理服务器或网关。 尝试建立从代理到管理服务器的端口 5723 的 telnet。 此外，在重现通信失败时，在代理和管理服务器之间同时运行网络跟踪。 这有助于确定数据包是否正在到达管理服务器，以及两个组件之间的任何设备是否正在尝试优化流量或丢弃某些数据包。 有关详细信息，请参阅 使用网络监视器收集数据。

   • 事件 ID 623：此事件通常发生在管理服务器或代理计算机管理许多工作流的大型 Operations Manager 环境中。 有关详细信息，请参阅 Operations Manager 控制台中一个或多个管理服务器及其托管设备灰显。

场景 3

向特定管理服务器或网关报告的所有代理都不可用。

方案 3 的解决方案

若要解决此方案中的问题，请执行以下步骤：

1. 尝试确定管理服务器或网关正在监视的工作负荷类型。 此类工作负载可能包括网络设备、跨平台代理、综合事务、Windows 代理和无代理计算机。

2. 确定运行状况服务是在管理服务器还是网关上运行。

3. 确定管理服务器是否在维护模式下运行。 如有必要，请从维护模式中删除服务器。

4. 检查代理上的 Operations Manager 事件日志，了解 方案 2 中列出的任何事件。 如果有事件 ID 21006，请遵循 方案 2 的解决方法中所述的相同准则。 此外，在这种情况下，此事件指示管理服务器或网关无法与其父服务器通信。 对于网关，父服务器可以是任何管理服务器。 (请参阅 方案 2.) 的解决方案中的步骤 3

5. 检查 Operations Manager 事件日志中是否出现以下事件。 这些事件通常表示托管 OperationsManagerOperationsManagerDW 或 数据库的管理服务器或 Microsoft SQL Server存在性能问题：

   事件 ID：2115
   事件源：HealthService
   事件说明：
   管理组 %1 中的绑定数据源已将项目发布到工作流，但在 %5 秒内未收到响应。 这表示工作流的性能或功能问题。%n 工作流 ID ： %2%n 实例 ： %3%n 实例 ID ： %4%n

   事件 ID：5300
   事件源：HealthService
   事件说明：
   本地运行状况服务不正常。 实体状态更改流已停止并等待确认。 %n%n管理组： %2 %n管理组 ID： %1

   事件 ID：4506
   事件源：HealthService
   事件说明：Operations Manager
   由于管理组“%1”中 id 为“%4”的实例“%3”运行的规则“%2”中存在过多未完成的数据，因此删除了数据。

   事件 ID：31551
   事件源：运行状况服务模块
   事件说明：
   未能在Data Warehouse中存储数据。 将重试该操作。%rException '%5'： %6 %n%n 一个或多个工作流受此影响。 %n%n工作流名称： %2 %nInstance 名称： %3 %nInstance ID： %4 %n管理组： %1

   事件 ID：31552
   事件源：运行状况服务模块
   事件说明：
   未能在 Data Warehouse 中存储数据。%rException '%5'： %6 %n%n 一个或多个工作流受此影响。 %n%n工作流名称： %2 %nInstance 名称： %3 %nInstance ID： %4 %n管理组： %1

   事件 ID：31553
   事件源：运行状况服务模块
   事件说明：
   数据已写入Data Warehouse暂存区域，但在后续操作之一处理失败。%rException '%5'： %6 %n%n 一个或多个工作流受此影响。 %n%n工作流名称： %2 %nInstance 名称： %3 %nInstance ID： %4 %n管理组： %1

   事件 ID：31557
   事件源：运行状况服务模块
   事件说明：
   无法从 Data Warehouse 数据库中获取同步进程状态信息。 将重试该操作。%rException '%5'： %6 %n%n 一个或多个工作流受此影响。 %n%n工作流名称： %2 %nInstance 名称： %3 %nInstance ID： %4 %n管理组： %1

6. 也可能由于运行方式帐户配置不正确或缺少运行方式帐户的权限而记录事件 ID 3155X。

方案 4

向特定管理服务器报告的所有代理在正常状态和灰色状态之间间歇性交替。 或者，环境中的所有代理在正常状态和灰色状态之间间歇性交替。

方案 4 的解决方案

若要解决此问题，请先确定问题的原因。 临时服务器不可用的常见原因包括：

• 代理的父服务器暂时脱机。
• 代理使用操作数据（例如警报、状态、发现等）淹没管理服务器。 这可能会导致 Operations Manager 数据库和 Operations Manager 服务器上的系统资源使用量增加。
• 网络中断导致父服务器和代理之间的临时通信失败。
• 管理包 (MP) 发生更改。 在 Operations Manager 控制台中，这些更改需要 Operations Manager 配置和 MP 重新分发到代理。 如果更改影响更大的代理基础，这可能会导致 Operations Manager 数据库和 Operations Manager 服务器上的系统资源使用量增加。

在这些方案中进行故障排除的关键是了解服务器不可用的持续时间及其发生时间。 这有助于快速缩小问题的范围。

管理服务器和网关性能故障排除

管理服务器

在由 MP 导入和发现) 引起的配置更新突发 (期间，典型的瓶颈是 CPU，其次是 Operations Manager 安装磁盘 I/O。 管理服务器负责将配置文件转发到目标代理。

对于操作数据收集，瓶颈通常是由 CPU 引起的。 磁盘 I/O 可能也处于最大容量，但不太可能。 管理服务器负责解压缩和解密传入的操作数据，并将其插入操作数据库中。 它还会在收到操作数据后将确认 (ACK) 发回代理或网关，并使用磁盘队列临时存储这些传出 ACK。

网关

网关同时受 CPU 限制和 I/O 绑定。 当网关中继大量数据时，CPU 和 I/O 操作可能显示高使用率。 大多数 CPU 使用率是由传入数据的解压缩、压缩、加密和解密以及该数据的传输引起的。 网关从代理接收的所有数据都存储在磁盘上的持久队列中，网关运行状况服务将读取数据并将其转发到管理服务器。 这可能会导致磁盘使用率过高。 当网关暂时脱机，然后必须处理代理生成并尝试在网关仍处于脱机状态时发送的累积代理数据时，此用法可能很重要。

若要排查这种情况中的问题，请为每个受影响的管理服务器或网关收集以下信息：

• 确切的 Windows 版本、版本和内部版本号

• 处理器数量

• RAM 量

• 包含“运行状况服务状态”文件夹的驱动器

• 是否将防病毒软件配置为排除运行状况服务存储

  注意

  有关详细信息，请参阅 与 Operations Manager 相关的防病毒排除建议。

• 运行状况服务状态使用的驱动器的 RAID 级别 (01、、 50+1 或 1+0)

• 用于 RAID 的磁盘数

• 是否在阵列控制器上启用电池备份的写入缓存

排查SQL Server性能问题

操作数据库 (OperationsManager)

OperationsManager对于数据库，最有可能的瓶颈是磁盘阵列。 如果磁盘阵列未达到最大 I/O 容量，则下一个最有可能的瓶颈是 CPU。 数据库将偶尔遇到速度减慢和操作数据风暴， (事件、警报和性能数据或状态更改的较高事件、警报和性能数据或状态更改，这些事件、警报和性能数据或状态更改会持续相对较长的时间) 。 短时间突发通常不会在较长的一段时间内造成任何重大延迟。

在操作数据插入期间，数据库磁盘主要用于写入。 CPU 使用率是由SQL Server变动引起的。 当你有大型和复杂的查询、大量的数据插入以及整理大型表 (默认情况下发生在午夜) 时，可能会发生这种情况。 通常，整理大型事件和性能数据表也不会消耗过多的 CPU 或磁盘资源。 但是，对于大型表，对警报和状态更改表的整理可能会占用大量 CPU。

数据库在处理配置重新分发突发（由 MP 导入或大型实例空间更改导致）时，也会受到 CPU 限制。 在这些情况下，Config 服务会查询数据库以查找新的代理配置。 这通常会导致在服务将配置更新发送到代理之前，数据库上出现 CPU 峰值。

数据仓库 (OperationsManagerDW)

OperationsManagerDW对于数据库，最有可能的瓶颈是磁盘阵列。 这通常是由于大型操作数据插入而发生的。 在这些情况下，磁盘大多忙于执行写入。 通常，磁盘执行很少的读取，除了处理手动生成的报表视图，因为这些查询在数据仓库上运行。

CPU 使用率是由SQL Server变动引起的。 在重分区活动 (，当表变大，然后) 分区、生成复杂报表以及数据库中大量警报（数据仓库必须与这些警报同步）时，可能会发生 CPU 峰值。

一般疑难解答

若要排查这种情况中的问题，请为每个受影响的管理服务器或网关收集以下信息：

• 确切的 Windows 版本、版本和内部版本号

• 处理器数量

• RAM 量

• 分配给SQL Server的内存量

• SQL Server是否为 32 位且是否已启用 AWE

  可以在 SQL Server Management Studio 或 SQL Server Enterprise Manager 中找到大部分此信息。 为此，请打开服务器的 “属性” 窗口，然后选择“ 常规 ”和“ 内存 ”选项卡。 “常规”选项卡包括SQL Server版本、Windows 版本、平台、RAM 量和处理器数。 “内存”选项卡包括分配给SQL Server的内存。 在 Microsoft SQL Server 2008 中，“内存”选项卡还包括 AWE 选项。

  如果 OS 为 32 位且 RAM 为 4 GB 或更大，检查 Boot.ini 中是否存在 /pae 或 /3gb 开关。 文件。 如果服务器最初是通过具有 4 GB 或更少的 RAM 安装的，并且后来升级了 RAM，则这些选项的配置可能会不正确。

  对于具有 4 GB RAM 的 32 位服务器，/3gbBoot.ini 中的交换机将SQL Server可以处理 (的内存量从 2 GB 增加到 3 GB) 。 对于 RAM 超过 4 GB 的 32 位服务器，/3gbBoot.ini 中的交换机实际上可能会限制SQL Server可以寻址的内存量。 对于这些系统，请将 /pae 开关添加到 Boot.ini，然后在 SQL Server 中启用 AWE。

  在多处理器系统上，检查 MAXDOP) 设置 (最大并行度。 在 SQL Server 2008 中，此选项位于服务器的“属性”对话框中的“高级”选项卡上。

  默认值为 0，这意味着将使用所有可用的处理器。 对于具有 8 个或更少处理器的服务器，设置为 0 即可。 对于具有 8 个以上处理器的服务器，SQL Server协调所有处理器的使用所需的时间可能会适得其反。 因此，对于具有 8 个以上处理器的服务器，通常应将 “最大并行度” 设置为 值 8。 为此，请在 SQL 查询分析器中运行以下命令：

  sp_configure 'show advanced options', 1
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  sp_configure 'max degree of parallelism', 8
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  

• 包含数据仓库、Operations Manager DB 和 Tempdb 文件的驱动器号

• 是否将防病毒软件配置为排除 SQL 数据和日志文件， (使用防病毒软件扫描SQL Server数据库文件可能会降低性能。)

• 包含数据仓库、Operations Manager DB 和 Tempdb 文件的驱动器上的可用空间量

• 存储类型 (SAN 或本地)

• RAID 级别 (0、1、5、0+1 或 1+0) SQL Server

• 如果使用 SAN 存储：每个 LUN 上使用的轴数SQL Server

• 如果正在使用或曾经使用过转换的 Exchange 2007 管理包：Operations Manager 数据库中表和EventPublisher数据仓库数据库中表的行LocalizedText数

  若要确定行量，请运行以下命令：

  USE OperationsManager SELECT COUNT(*) FROM LocalizedText
  USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher
  

用于识别内存压力的计数器

用于标识磁盘压力的计数器

为包含 SQL 数据或日志文件的所有驱动器捕获这些物理磁盘计数器：

• 空闲时间百分比：报告的磁盘空闲时间。 低于 50% 的任何内容都可能表示磁盘瓶颈。

• 平均磁盘队列长度：此值不应超过 LUN 上轴数的两倍。 例如，如果 LUN 有 25 个轴，则值 50 是可接受的。 但是，如果 LUN 有 10 个轴，则值 25 太高。 可以根据 RAID 配置中的 RAID 级别和磁盘数使用以下公式：

  • RAID 0：所有磁盘都在 RAID 0 集中执行工作

  • 平均磁盘队列长度<= 数组中的 # (磁盘) *2

  • RAID 1：一半的磁盘正在执行工作;因此，其中只有一半可以计入磁盘队列

  • 平均磁盘队列长度<= 数组中的 # (磁盘/2) *2

  • RAID 10：一半的磁盘正在“工作”;因此，其中只有一半可以计入磁盘队列

  • 平均磁盘队列长度<= 数组中的 # (磁盘/2) *2

  • RAID 5：所有磁盘都在 RAID 5 集中执行工作

  • 平均磁盘队列长度<= 数组中的 # 磁盘 *2

  • 平均磁盘秒/传输：完成一个磁盘 I/O 所需的秒数

  • 平均磁盘秒/读取：从磁盘读取数据的平均时间（以秒为单位）

  • 平均磁盘秒/写入：将数据写入磁盘的平均时间（以秒为单位）

    此列表中的最后三个计数器应始终具有大约 0.020 (20 毫秒) 或更低的值，并且不应超过 0.050 (50 毫秒) 。 以下是SQL Server性能故障排除指南中所述的阈值：

    • 小于 10 毫秒：非常好
    • 介于 10 - 20 毫秒之间：正常
    • 20 - 50 毫秒：速度缓慢，需要注意
    • 大于 50 毫秒：严重的 I/O 瓶颈

  • 磁盘字节数/秒：每秒在磁盘之间传输的字节数

  • 磁盘传输/秒：每秒输入和输出操作数 (IOPS)

  当 空闲时间百分比 较低 () 10% 或更少时，这意味着磁盘已充分利用。 在这种情况下，此列表中的最后两个计数器 (磁盘字节数/秒 和 磁盘传输/秒 ，) 可以很好地指示驱动器的最大吞吐量（以字节为单位）和 IOPS。 SAN 驱动器的吞吐量变化很大，具体取决于轴的数量、驱动器的速度和通道的速度。 最佳选择是与 SAN 供应商检查，以了解驱动器应支持的字节数和 IOPS。 如果 空闲时间百分比 较低，并且这两个计数器的值不符合驱动器的预期吞吐量，请与 SAN 供应商联系进行故障排除。

SQL Server性能故障排除指南提供了对SQL Server性能故障排除的更深入见解。

Operations Manager 性能计数器

以下部分介绍可用于监视 Operations Manager 性能并对其进行故障排除的性能计数器。

网关服务器角色

总体性能计数器

这些计数器指示网关的整体性能：

Operations Manager 进程通用性能计数器

这些计数器指示网关上的 Operations Manager 进程的总体性能：

Operations Manager 特定的性能计数器

这些计数器是特定于 Operations Manager 的计数器，用于指示网关上 Operations Manager 特定方面的性能：

管理服务器角色

总体性能计数器

这些计数器指示管理服务器的整体性能：

Operations Manager 进程通用性能计数器

这些计数器指示管理服务器上 Operations Manager 进程的整体性能：

Operations Manager 特定的性能计数器

这些计数器是特定于 Operations Manager 的计数器，用于指示管理服务器上 Operations Manager 特定方面的性能：