ガイド付き根本原因の分析 (RCA)

Omnissa Intelligence のガイド付き RCA (gRCA) は、広範なアプリケーション クラッシュ、OS クラッシュの問題、スロー ブート イベントのデバッグを支援します。macOS および Windows アプリケーションやデバイス上でイベントが大量かつ異常に増加していることに気付いた場合に、Omnissa Workspace ONE Experience Management 環境でこの機能を使用します。

要件

• ガイド付き RCA (gRCA) 機能は、 macOS および Windows アプリケーションとデバイスで動作します。
  • Horizon 向け Experience Management を使用するWindows デバイスの場合、gRCA は次のユースケースをサポートします。
    • gRCA 機能は、Horizon 向け Experience Management のユースケース「ログインに時間がかかる」をサポートしています。
    • この機能を Horizon のユースケース（Horizon のログインに時間がかかるなど）に使用するには、選択した時間範囲内に、環境内で少なくとも 25 の一意の Horizon セッションが実行されている必要があります。
    • この機能の詳細については、「 低速ログイン期間 gRCA の説明 」セクションを参照してください。
• この機能は、アプリケーション クラッシュ、OS クラッシュ (システム クラッシュ)、スローブート イベントを分析するのに役立ちます。
• gRCA の実行後に結果を表示するには、gRCA の日付範囲に 100 以上のアプリケーション クラッシュ、システム クラッシュ、またはスロー ブート イベントを含める必要があります。適格なイベントを構成する内容の詳細については、「 100 個のイベントが表示されるのに gRCA 結果が表示されない理由」セクションを参照してください。
• この機能が本番環境で機能するには、100 台以上のデバイスが必要です。

100 個のイベントが表示されるのに gRCA 結果が表示されない理由

gRCA が結果を返す場合、選択した時間枠には、分析対象のメトリックに対して 100 個以上の適格なユニーク イベント (クラッシュやスロー ログイン セッションなど) が含まれている必要があります。ただし、システムは、特定の日のデバイスまたはセッションに対して適格なユニーク イベントを 1 つだけ登録します。

例

• デバイスで 1 日に 10 個の OS がクラッシュした場合、gRCA システムはその日のデバイスに対して 1 つの OS クラッシュ イベントを登録します。
• 仮想セッションで 1 日に 3 回スロー ログイン セッションが発生した場合、gRCA システムはその日のセッションに対して 1 回のスロー ログイン イベントを登録します。

100 個のイベントが表示されるのに gRCA の結果が表示されないシナリオを見てみましょう。

• シナリオ：100 個の OS がクラッシュしているため、調査を実行して [gRCA] タブを確認します。100 個のイベントがあっても、結果は返されません。gRCA データ範囲を拡張して 7 日間を含めても、結果は表示されません。
• 説明：1 日に 10 台のデバイスで 100 個の OS がクラッシュしました。システムにより、各デバイスはその日のユニークで適格な OS クラッシュ イベントを登録できるため、その日の OS クラッシュ イベントは 10 個に限定されます。10 台のデバイスで、7 日間に 100 個のイベントと同等の OS クラッシュが発生しない場合、gRCA システムは結果を返しません。

AI 栄養ラベル

gRCA の使用方法

gRCA を使用して、広範なアプリケーション クラッシュ、システム クラッシュ、スロー ブート デバイスをすべてデバッグします。ガイド付き RCA には、統計的に重要な潜在的根本原因を示唆するアルゴリズムが含まれます。アルゴリズムが毎回根本原因を見つける保証はありませんが、RCA プロセス中に何を探すべきかを知るのに役立ちます。

根本原因の調査結果を修正するワークフローを作成する方法については、Freestyle Orchestrator のトピックを参照してください。

高度な基準を使用して RCA アルゴリズムを調整する

高度な基準を使用すると、調査でアルゴリズムが考えられる原因を見つけるのに役立ちます。[高度な基準] セクションで リフト値またはサポートの大きい方の値を選択すると、分析リスト ビューで結果の数が減る場合がありますが、役立たない結果の数を減らすこともできます。

高度な基準パラメータの調整はオプションですが、根本原因分析アルゴリズムを細かく制御する環境に対して提供されます。

高度な基準 セクションでは、ユーザー インターフェイスに構成済みの根本原因分析で確認されている 機能 が一覧表示されます。高度な基準パラメータを調整するときは、機能を考慮してください。

高度な基準パラメータの説明

• リフト値：リフト値は、イベントを潜在的な根本原因と見なすために、特定の機能（OS バージョンまたは最近インストールしたパッチなど）に対してアルゴリズムにどれだけの統計的信頼度がある必要があるかを表わします。
  • リフト値を上げると、表示するのに十分な意味があると見なされるために結果が満たす必要のある信頼性のしきい値が高くなるため、アルゴリズムの結果が少なく表示される可能性があります。
• パターンの長さ：パターンの長さは、根本原因に関係している可能性があるとアルゴリズムによって特定されている、関連機能の数を指します。
  • 4 を選択すると、アルゴリズムには、組み合わせると根本原因となる可能性のある最大 4 つの機能（例えば、デバイス モデル、OS バージョン、アプリケーション バージョン、および最近インストールしたパッチ）が表示されます。
  • 個々の機能だけでなくパターンを使用することで、特定のパッチがインストールされ、特定のアプリケーション バージョンを実行している場合にのみクラッシュする特定のデバイス モデルのようなクラッシュを引き起こす可能性のある複雑なパターンを確認できます。
• サポート：サポート値とは、アルゴリズムが特定の機能を重要と見なし、根本原因としてリストアップするために必要となる、特定の機能が含まれるクラッシュの割合 (%) です。
  • .05 を選択すると、5% 以上のクラッシュで表示された場合に、機能を重要と見なすようにアルゴリズムに指示します。

gRCA メトリックのタイプ

現在、g RCA は、アプリケーション クラッシュ、システム クラッシュ、スロー ブート イベントの分析に役立ちます。各 デバイスは、固有のアプリケーションごとに 1 回のアプリケーション クラッシュ、1 日に 1 回のシステム クラッシュ、および 1 日に 1 回のスロー ブートを登録できます。アルゴリズムを実行するには、gRCA を構成したときに選択した期間に、これらの固有のクラッシュまたはスロー ブート イベントが 100 を超えて発生する必要があります。

インサイトに関する通知を構成

通知設定を使用して、 インサイトに関するアプリ内または E メール通知 (またはその両方) を自分に送信します。

1. Intelligence ヘッダーのベル アイコンを選択します。
2. [通知] パネルで、歯車アイコンを選択して [通知設定] ページにアクセスします。
3. Intelligence セクションを展開し、リストされたサービスに対して受信する通知のタイプとして [アプリケーション内] または [E メール] を選択します。
   • アプリケーション インサイト：macOS および Windows 物理マシン上のアプリケーションのアノマリについて通知します。
   • デバイス インサイト：macOS および Windows 物理マシン上のアノマリについて通知します。
   • ユーザー インサイト：Omnissa Access 製品に関連する SSO ログイン アノマリについて通知します。
   • 仮想インサイト：Horizon 環境の Experience Management で検出されたアノマリについて通知します。
   • プログラムによるガイド付き RCA：システムがインサイトの gRCA を自動的に実行するときに通知します。

gRCA 構成の例

この例では、アプリケーションがクラッシュしている理由を検出するために、Acme Analytics という架空のアプリケーションに gRCA を構成する方法の概要を示します。調査の作成から、カスタム ダッシュボードでの根本原因の分析まで行います。

1. Intelligence で調査を作成します。
   調査を作成する必要はありません。例の次のセクションで説明するように、リストで調査を選択できます。
   1. [ワークスペース] > [エクスペリエンス管理] > [エクスペリエンス スコア] > [デスクトップ アプリ] > [表示] の順に移動します。
   2. [+ 調査] を選択します。
   3. インシデントの名前としてアプリの名前 (Acme Analytics) を入力します 。
   4. アプリの名前を検索し（「Acme」と入力）、調査にオブジェクトとして追加するアプリを選択します。
   5. [+ 調査] を選択します。
2. しばらくしてから、調査のパフォーマンス インジケータを確認します。
   1. [Workspace] > [エクスペリエンス管理] > [調査] の順に移動し、リストから Acme Analytics 調査を選択します。
   2. [概要] タブを選択し、パフォーマンス インジケータ セクションに移動します。アプリのクラッシュ イベント、およびアプリのクラッシュ数イベントで、アプリのクラッシュが増加していることを確認できます。
3. 調査の [RCA] タブで作業します。gRCA を使用して、システムがクラッシュ増加の考えられる原因を見つけるために使用するアプリケーション クラッシュ診断を作成します。
   1. [Workspace] > [エクスペリエンス管理] > [調査] の順に移動し、リストから Acme Analytics 調査を選択します。
   2. [RCA] タブを選択し、根本原因分析領域に値を入力します。
      • メトリック：[アプリのクラッシュ] を選択します。
      • 範囲：日付 Jun 17, 2025 - Jun 24, 2025 を追加します。
      • アプリケーション： Acme と入力してアプリを検索し、結果リストから Acme Analytics アプリを選択します。
   3. [分析の実行] を選択します。
   4. 分析が完了したら、詳細なレポートを表示 オプションを選択します。
   5. 結果のサマリに移動して、Acme Analytics アプリケーションのクラッシュの急増の考えられる原因を特定する結果のリストを表示します。
      • さらに調査する根本原因を見つけます。クラッシュ回数が多い有用な根本原因を探します。根本原因は、gRCA 構成と使用可能なデータに応じてランク付けが異なります。
      • この例では、根本原因リストの 2 つの タイプ（アプリケーションのバージョン および パッチ）を操作します。これらの根本原因は、有用な根本原因の上位 3 つには表示されませんが、リスト内のクラッシュ数が最も多くなります。
      • アプリケーションのバージョンの例は Acme Analytics-1.234.432.0 (11.01) です。
        • 根本原因リストの番号は 4 です。
        • システムは 229 のクラッシュが発生したと報告しています。
        • これは、根本原因リストのクラッシュの最大数です。
      • パッチ番号の例は 1ABCD23EFG4H-Acme.Analytics です。
        • 根本原因リストの番号は 12 です。
        • システムは 68 のクラッシュが発生したと報告しています。
        • これは、根本原因リストの 2 番目に多いクラッシュ数です。
      • リストで根本原因項目を選択すると、関連する結果 を検索できます。
      • リスト内の根本原因項目で、クラッシュの原因でないことが分かっているものには、有用ではないのチェック ボックスを使用します。このチェック ボックスによって、リストから項目が削除されます。
4. カスタム ダッシュボードを作成して、これらのイベントがアプリケーション クラッシュの急増を引き起こしているかどうかを分析します。
   1. [Workspace] > [エクスペリエンス管理] > [調査] の順に移動し、Acme Analytics 調査を選択します。
   2. [概要] タブを選択し、[関連するダッシュボード] セクションに移動します。
   3. [カスタム ダッシュボードの作成] を選択します。
   4. ダッシュボードで省略記号 (...) を選択し、[ウィジェットを追加] を選択します。
   5. [カスタム ウィジェットを追加] を選択します。
      カスタム ダッシュボードに 3 つのウィジェットを追加します。[従業員のエクスペリエンス] > [アプリケーション] カテゴリからウィジェットを 2 つ作成し、[従業員のエクスペリエンス] > [OS 更新] カテゴリから別のウィジェットを作成します。
   6. [従業員のエクスペリエンス] > [アプリケーション] の [カテゴリ] オプションを使用して、ウィジェットを 1 つまたは 2 つ作成します。
      1. [名前] > [アプリケーションの起動およびアプリケーションのフォアグラウンド] を使用して、最初のウィジェットを作成します。
         • チャート タイプ > [縦棒] を選択します。
         • 測定：[その他] > [イベント ID] の [数] を選択します。
         • グループ別：[その他] > [アプリケーションのバージョン] の順に選択します。
         • グループごとの結果：[10] を入力します。
         • 日付範囲：2025 年 6 月 17 日午前 12:00 ~ 2025 年 6 月 24 日午後 11:59 の範囲で [カスタム] を選択します。
         • 頻度：1 日を選択します。
         • フィルタ：2 つのルールを追加します。
           1. [その他] > [アプリケーション名] には Acme Analytics が含まれます
           2. [その他] > [イベント名] にはアプリケーションの起動およびアプリケーションのフォアグラウンドが含まれます
      2. [名前] > [アプリのバージョンによるアプリのクラッシュ] を使用して、2 つ目のウィジェットを作成します。
         • チャート タイプ > [縦棒] を選択します。
         • 測定：[その他] > [イベント ID] の [数] を選択します。
         • グループ別：[その他] > [アプリケーションのバージョン] の順に選択します。
         • グループごとの結果：[10] を入力します。
         • 日付範囲：2025 年 6 月 17 日 12:00 AM ~ 2025 年 6 月 24 日午後 11:59 の範囲で [カスタム] を選択します。
         • 頻度：1 日を選択します。
         • フィルタ：3 つのルールを追加します。
           1. [その他] > [アプリケーション名] には Acme Analytics が含まれます
           2. [その他] > [イベント名] にはアプリケーションのクラッシュが含まれます
           3. [その他] > [イベント ステータス]には完了が含まれます
      3. [従業員のエクスペリエンス] > [OS 更新] のカテゴリ オプションを使用して、3 つ目のウィジェットを作成します。
         • 名前：「Problem Patch」と入力します。
         • チャート タイプ > [縦棒] を選択します。
         • 測定：[その他] > [イベント ID] の [個別のカウント] を選択します。
         • グループ別：[デバイス] > [デバイス モデル] の順に選択します。
         • グループごとの結果：[10] を入力します。
         • 日付範囲：2025 年 6 月 17 日 12:00 AM ~ 2025 年 6 月 24 日午後 11:59 の範囲で [カスタム] を選択します。
         • 頻度：1 日を選択します。
         • フィルタ：2 つのルールを追加します。
           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 からリストされたデータ属性を使用します。