引导式根本原因分析 (RCA)

Omnissa Intelligence 中的引导式 RCA (gRCA) 可帮助您调试广泛的事件、应用程序崩溃、操作系统崩溃问题和缓慢引导事件。在 Omnissa Workspace ONE Experience Management 部署中使用此功能，您会发现 macOS 和 Windows 应用和设备上会出现大量异常增加的情况。

要求

• 引导式 RCA (gRCA) 功能适用于 macOS 和 Windows 应用和设备。
  • 对于使用适用于 Horizon 的 Experience Management 的 Windows 设备，gRCA 支持以下用例。
    • gRCA 功能支持适用于 Horizon 的 Experience Management 用例登录持续时间缓慢。
    • 要使此功能适用于 Horizon 用例（例如 Horizon 登录持续时间缓慢用例），您的部署必须在选定的时间范围内具有至少 25 个唯一 Horizon 会话。
    • 有关此功能的更多详细信息，请参阅关于 gRCA 登录持续时间缓慢的说明部分。
• 该功能可帮助分析应用程序崩溃、操作系统崩溃（系统崩溃）和引导缓慢事件。
• 要在运行 gRCA 后显示结果，gRCA 日期范围必须至少包含 100 个应用崩溃、系统崩溃或引导缓慢事件。有关合格事件构成的详细信息，请参阅 为什么我可以看到 100 个事件但未获取 gRCA 结果？部分。
• 要在生产环境中运行，此功能需要 100 个或更多设备。

为什么我可以看到 100 个事件但未获取 gRCA 结果？

要使 gRCA 返回结果，所选时间段必须至少包含 100 个适用于所分析衡量指标（例如，崩溃或登录缓慢的会话）的唯一合格事件。但是，系统在特定日期只为一个设备或会话注册一个唯一的合格事件。

示例

• 如果设备在一天内发生了 10 次操作系统崩溃，则 gRCA 系统会在当天为该设备注册 1 个操作系统崩溃事件。
• 如果虚拟会话在一天内发生了 3 个登录缓慢会话，则 gRCA 系统会在当天为该会话注册 1 个登录缓慢事件。

让我们来看一个可能的场景，即您可以看到 100 个事件，但没有获得任何 gRCA 结果。

• 场景：您看到了 100 次操作系统崩溃，因此您运行调查并查看 gRCA 选项卡。尽管有 100 个事件，系统没有返回任何结果。即使将 gRCA 数据范围扩展至包含 7 天，仍然看不到任何结果。
• 解释：一天内在 10 台设备上发生了 100 次操作系统崩溃。系统允许每个设备在当天注册一个唯一且合格的操作系统崩溃事件，因此当天有 10 个唯一且合格的操作系统崩溃事件。如果这 10 台设备在 7 天内未发生足够的操作系统崩溃，没有达到 100 个事件，则 gRCA 系统不会返回任何结果。

AI 营养标签

如何使用 gRCA？

使用 gRCA 帮助调试广泛的应用崩溃、系统崩溃和缓慢引导设备。引导 RCA 包括会给出有统计意义的潜在根本原因建议的算法。不能保证算法每次都会找到根本原因，但应帮助您了解在 RCA 过程中查找的内容。

有关如何创建工作流以修复根本原因结果的信息，请参见 Freestyle Orchestrator 主题。

使用高级条件调整 RCA 算法

您可以使用高级条件帮助算法查找调查的可能原因。尽管在高级条件部分中选择更大的提升值或支持值可以减少分析列表视图中的结果数量，但也可以减少无效的结果数量。

调整高级条件参数是可选操作，但适用于希望精细控制根本原因分析算法的部署。

在高级条件部分中，UI 列出了您配置的根本原因分析正在检查的功能。调整高级条件参数时，请考虑这些功能。

高级条件参数说明

• 提升值：提升值表示在特定功能（例如，OS 版本或安装的修补程序）中，算法将事件视为潜在根本原因所必须达到的统计置信度。
  • 如果提高提升值，算法可能会显示较少的结果，因为它具有较高的置信度阈值，必须满足该阈值才能认为结果有足够的意义来显示。
• 模式长度：模式长度是指算法确定的可能导致根本原因的相关功能的数量。
  • 如果选择 4，该算法将显示多达 4 个功能（功能示例：设备型号、操作系统版本、应用版本和最近安装的修补程序），这可能是根本原因。
  • 通过使用模式（而不仅仅是单个功能），您可以查看可能导致崩溃的复杂模式，例如，只有在安装了特定修补程序并运行特定应用版本时才会崩溃的特定设备型号。
• 支持：支持值是包含特定功能的所需崩溃百分比，算法会将其视为重要值并将其列为根本原因。
  • 如果选择 .05，这会指示算法在出现 5% 或更多的崩溃时将其视为显著特征。

gRCA 衡量指标的类型

目前，gRCA 有助于分析应用崩溃、系统崩溃和引导缓慢事件。每个 设备可以为每个唯一应用注册一次应用崩溃、每天一次系统崩溃和每天一次引导缓慢。要运行该算法，在配置 gRCA 时选择的时间范围内，您的部署必须经历超过 100 个唯一的崩溃或引导缓慢事件。

配置见解通知

使用通知设置向您自己发送有关 见解的应用通知或电子邮件通知（或两者）。

1. 选择 Intelligence 标头中的铃铛图标。
2. 在通知面板中，选择齿轮图标以访问通知设置页面。
3. 展开 Intelligence 部分，然后选择应用内或电子邮件，作为您想要针对所列服务接收的通知类型。
   • 应用见解：通知您物理 macOS 和 Windows 计算机上的应用异常。
   • 设备见解：通知您物理 macOS 和 Windows 设备上的异常。
   • 用户见解：通知您与 Omnissa Access 产品相关的 SSO 登录异常。
   • 虚拟洞察：通知您在适用于 Horizon 的 Experience Management 部署中检测到的异常。
   • 编程引导式 RCA：在系统自动为见解运行 gRCA 时通知您。

gRCA 配置示例

此示例概述了如何为名为 Acme Analytics 的虚拟应用配置 gRCA，以尝试发现应用崩溃的原因。我们将在自定义仪表板中创建调查和分析根本原因。

1. 在 Intelligence 中创建调查。
   您不必创建调查。您可以在列表中选择调查，如示例的下一部分中所述。
   1. 转到工作区 > Experience Management > 体验评分 > 桌面应用 > 查看。
   2. 选择 + 调查。
   3. 输入应用的名称作为调查的名称，Acme Analytics。
   4. 搜索应用的名称（键入 Acme），然后选择应用以将其作为对象添加到调查。
   5. 选择创建调查。
2. 一段时间后，检查调查中的性能指标。
   1. 转到工作区 > Experience Management > 调查，然后从列表中选择 Acme Analytics 调查。
   2. 选择概览选项卡，然后转到性能指标部分。您会发现应用崩溃和应用崩溃计数事件，显示应用崩溃的增加。
3. 在调查的 RCA 选项卡中操作。使用 gRCA 创建应用崩溃诊断，供系统用于查找崩溃增加的可能原因。
   1. 转到工作区 > Experience Management > 调查，然后从列表中选择 Acme Analytics 调查。
   2. 选择 RCA 选项卡，然后在根原因分析区域中输入值。
      • 衡量指标：选择应用崩溃。
      • 范围：添加日期 Jun 17, 2025 - Jun 24, 2025。
      • 应用程序：输入 Acme 以搜索该应用，然后从结果列表中选择 Acme Analytics 应用。
   3. 选择运行分析。
   4. 分析完成后，选择选项以查看完整报告。
   5. 转到故障摘要查看结果列表，以确定导致 Acme Analytics 应用崩溃高峰的可能原因。
      • 查找要进一步分析的根本原因。查找导致大量崩溃的有用根本原因。系统根据 gRCA 配置和可用数据对根本原因进行排名的方式有所不同。
      • 在此示例中，您可以使用根本原因列表中的两个类型：应用版本和修补程序。虽然这些根本原因未显示在有用根本原因的前三位，但它们在列表中的崩溃数量最多。
      • 示例应用版本为 Acme Analytics-1.234.432.0 (11.01)。
        • 它的编号在根本原因列表中为 4。
        • 系统报告有 229 次崩溃。
        • 这是根本原因列表中的最大崩溃数。
      • 示例修补程序编号为 1ABCD23EFG4H-Acme.Analytics。
        • 它的编号在根本原因列表中为 12。
        • 系统报告有 68 次崩溃。
        • 这是根本原因列表中第二大崩溃数。
      • 您可以选择列表中的根本原因项来查找相关结果。
      • 对于您知道未导致崩溃的根本原因项，请使用无用复选框。此复选框将从列表中移除该项。
4. 创建自定义仪表板，以分析这些事件是否导致应用崩溃高峰。
   1. 转到工作区 > Experience Management > 调查，然后选择 Acme Analytics 调查。
   2. 选择概览选项卡，然后转到相关仪表板部分。
   3. 选择创建自定义仪表板。
   4. 在仪表板中，选择省略号 (...)，然后选择添加小组件。
   5. 选择添加自定义小组件。
      向自定义仪表板添加三个小组件。从员工体验 > 应用类别创建两个小组件，然后从员工体验 > 操作系统更新类别中创建另一个小组件。
   6. 使用员工体验 > 应用中的类型选项创建第一个和第二个小组件。
      1. 使用名称 > 应用程序启动和应用程序前台创建第一个小组件。
         • 图表类型：选择垂直。
         • 度量：选择其他 > 事件 ID 的计数。
         • 分组依据：选择其他 > 应用版本。
         • 每组的结果数：输入 10。
         • 日期范围：选择自定义范围 2025 年 6 月 17 日上午 12：00 - 2025 年 6 月 24 日下午 11：59。
         • 频率：选择 1 天。
         • 筛选器：添加两条规则。
           1. 其他 > 应用名称包括 Acme Analytics
           2. 其他 > 事件名称包括应用程序开始和应用程序前台
      2. 使用**名称 > 应用崩溃（按应用版本）**创建第二个小组件。
         • 图表类型：选择垂直。
         • 度量：选择其他 > 事件 ID 的计数。
         • 分组依据：选择其他 > 应用版本。
         • 每组的结果数：输入 10。
         • 日期范围：选择自定义范围 2025 年 6 月 17 日上午 12：00 - 2025 年 6 月 24 日下午 11：59。
         • 频率：选择 1 天。
         • 筛选器：添加三条规则。
           1. 其他 > 应用名称包括 Acme Analytics
           2. 其他 > 事件名称包括应用程序崩溃
           3. 其他 > 事件状态包括完成
      3. 使用员工研 > 操作系统更新中的类别选项创建第三个小组件。
         • 名称：输入问题修补程序。
         • 图表类型：选择垂直。
         • 度量：选择其他 > 事件 ID 的不同计数。
         • 分组依据：选择设备 > 设备型号。
         • 每组的结果数：输入 10。
         • 日期范围：选择自定义范围 2025 年 6 月 17 日上午 12：00 - 2025 年 6 月 24 日下午 11：59。
         • 频率：选择 1 天。
         • 筛选器：添加两条规则。
           1. 其他 > 标题包括修补程序的名称，1ABCD23EFG4H-Acme.Analytics
           2. 其他 > 事件状态包括完成
   7. 筛选并查看自定义仪表板中的小组件，以进一步分析 Acme Analytics 应用崩溃的原因。
      • 按应用版本 Acme Analytics-1.234.432.0 (11.01) 筛选应用程序启动和应用程序前台小组件。
        您注意到，用户于 9 月 14 日开始使用此版本的应用。
      • 筛选按应用版本划分的应用崩溃小组件以仅显示应用版本 Acme Analytics-1.234.432.0 (11.01)。
        您注意，此应用版本报告崩溃事件的最大数量。
      • 检查问题修补程序小组件，该小组件可标识获取 1ABCD23EFG4H-Acme.Analytics 修补程序的设备。
        您注意到，许多设备在 9 月 14 日左右收到此修补程序。此日期是应用版本 Acme Analytics-1.234.432.0 (11.01) 开始崩溃的日期，如应用程序启动和应用程序前台小组件所报告。
      • 考虑将此版本的应用回滚以从设备中移除修补程序版本的可能修复。
   8. 使用工作流修复 gRCA 中的结果，并使用操作移除应用的修补版本。

关于 gRCA 登录持续时间缓慢的说明

对于那些想要了解 Omnissa 如何开发针对事件的引导式根本原因分析 (gRCA) 的用户，让我们来看一下在适用于 Horizon 的 Experience Management 的登录持续时间缓慢场景中如何运用 gRCA。其他 gRCA 也遵循类似的方法，包括通过相关数据属性来标识模式。

注意：此说明不包括用于 Horizon First-Gen 产品的属性。尽管使用的属性和计算相似，但它们并不完全匹配。

登录持续时间缓慢 gRCA 有什么作用？

引导式 RCA 使用算法，在 Horizon 会话数据中查找可能指示登录持续时间问题根本原因的模式。示例模式是"池"和"其他服务加载时间"属性。

示例： 缓慢登录持续时间模式 = "池"属性 + "其他服务加载时间"属性

系统会标识重要的模式。与正常会话相比，如果某个模式在受影响会话中的发生次数在统计上非常显著，则该模式被视为重要。

重要性与提升值相关

提升值（高级标准）控制 gRCA 引擎将模式视为重要模式所需的统计置信度。较低的提升值会增加引擎发现重要模式的概率。较高的提升值则会降低引擎发现重要模式的概率。

例如，如果为登录持续时间缓慢 gRCA 设置较低的提升值阈值，则会将 gRCA 引擎配置为在确定重要模式时只需较低的统计置信度。如果统计阈值较低，引擎可能会发现更多可能重要的模式。

登录持续时间缓慢属性

登录持续时间缓慢 gRCA 使用适用于 Horizon 的 Experience Management 部署中列出的数据属性。