アラート優先度

  • リリースバージョン: Xanadu
  • 更新日 2024年08月01日
  • 所要時間:10分
  • アラート優先度スコアに基づいてアラートを処理する順番を決定します。複数のファクターによってアラート優先度スコアが決定されます。基になるファクターが変更されると、この値も変更されます。

    マルチファクターの決定

    アラート優先度スコアの値は、カテゴリの値とその相対的な重み付けを組み合わせたものです。次のセクションで説明されているように、Category orderCategory value mappingCI type weight factor mappingに基づいて、スコアを構成するファクターを設定できます。カテゴリは、次のとおりです。
    • Accumulated categories:このカテゴリでは、ステータスや重み付けファクターが異なる可能性のある、さまざまなサブタイプのアイテムを累積します。たとえば、さまざまな重要度に従って考慮されるサービスもあれば、コストに従って考慮されるサービスもあります。
    • Choice-list categories:アイテムのリスト。任意のアイテムを異なる値にマッピングして、そのアイテムの優先度を変更できます。たとえば、デフォルトでは値が 1 の「重大」重大度を 4 にマッピングして、計算されるアラート優先度スコアの重み付けを高くすることができます。
    表 : 1. カテゴリのリスト
    カテゴリ 説明
    累積カテゴリ
    影響を受けるビジネスサービスの数 このカテゴリは、サービスのビジネス上の重要度別に考慮されます。1 つのサービスに影響を与えるアラートは、多くのサービスに影響を与えるアラートよりも優先度スコアが低くなります。たとえば、ルーターが停止すると、多くのサービスに影響を及ぼすおそれがあるため、優先度を高くすることでこのアラートが先に処理され、少数のサービスにしか影響しない別のアラートは後回しになります。重大でない多くのサービスに影響を及ぼすアラートは、優先度を使用して処理する必要があります。ただし、アラートがわずかなサービスにしか影響しなくても、それらが重大なサービスである場合、このアラートの優先度は高くなります。
    CI タイプ このカテゴリでは、さまざまな CI タイプを区別します。たとえば、CI タイプがルーターまたはスイッチになっているアラートは、サーバーやアプリケーションなどの別の CI タイプのアラートよりも優先度が高い場合があります。
    セカンダリアラートの数 通常は、メッセージキーが同じアラートなど、他のアラートと類似した特性のアラートと併せてグループ化されます。多数のセカンダリアラートを持つ親アラートは、少数のセカンダリアラートしか持たない親アラートよりも優先度が高くなります。

    親アラートのすべてのセカンダリアラートがカウントされます。セカンダリアラートがクローズされると、親アラートとの相関は解除されます。親アラートがクローズされた場合、すべてのセカンダリアラートの相関は解除され、それらの優先度値はそれに従って計算されます。

    選択リストカテゴリ
    アラートステータス Closed」ステータスのアラートの場合、優先度スコアは計算されません。デフォルト値を持つ利用可能な進捗状況は、次のとおりです。
    • オープン = マッピング値 1
    • 再オープン = マッピング値 2
    • フラッピング = マッピング値 3
    アラート重大度 優先度スコアは、基になるアラートの重大度のレベルを反映します。たとえば、重大度が「Critical」のアラートは、重大度が「Minor」のアラートより重み付け値が大きくなります。重大度が「OK」のアラートの場合、優先度は計算されません。利用可能なレベルは、次のとおりです。
    • 重大
    • メジャー
    • マイナー
    • Warning
    ロール 優先度スコアは、アラートのロールを反映しています。優先度スコアは、ロールが「Parent」になっているアラートがより高くなり、次が「None」のロールのアラートで、「Secondary」のロールのアラートには最小の重み付けが設定されます。多数のセカンダリアラートを持つ親アラートは、より少ないセカンダリアラートしか持たない親アラートよりも高い値になります。利用可能なロールは、次のとおりです。
    • なし
    • セカンダリ

    アラート優先度スコアの構造

    各カテゴリの重み付け値
    各カテゴリは、その順序と制限に従って、アラート優先度スコアにおいて独自に配置されます。後述の「アラート優先度スコアの変更」の説明に従って、順序と制限を構成できます。正の数に限られます。
    次の場合を除き、すべてのカテゴリ値が em_alert_priority_category_mapping テーブルからマップされます。
    • CI タイプ:em_alert_priority_ci_type テーブルからマップされます。
    • セカンダリ:値はセカンダリアラートの数で、いずれのテーブルからもマップされません。
    注:
    最適なメモリ保護を確保するために、1000 件を超えるアラートを含むアラートグループには正確な優先度スコアがない場合があります。
    表 : 2. 7302020.003 のアラート優先度スコアの構成例
    カテゴリ スコア
    サービス (7.0, 1000000.0)
    たとえば、次のようなビジネス上の重要性の優先度スコアに影響を受けるサービスが 2 つある場合は、次のようになります。
    • Service1:ビジネス上の重要性の優先度スコア = 3
    • Service2:ビジネス上の重要性の優先度スコア = 4
    ビジネス上の重要性の優先度スコアの合計が 7 なので、計算された優先度の値は 7,000,000 (7 * 1,000,000)
    注:
    ビジネス上の重要性の優先度スコアは、マッピング済みの値 ([マッピング後の値]) です。この値は、[アラート優先度カテゴリマッピング] テーブル (em_alert_priority_category_mapping) のアプリケーションサービスエントリにあります。
    重大度 (3.0, 100000.0)
    CI タイプ (20.0, 100.0)
    ロール (2.0, 10.0)
    セカンダリ (0, 0.01)
    状態 (3.0, 0.001)
    前出のテーブルのスコアを使用すると、アラート優先度スコアは次のように計算されます。

    (Services value * 1,000,000) + (Severity value * 100,000) + (CI type value * 100) + (Role value * 10) + (Secondary value) + (State value * 0.001)

    前出のテーブルのカテゴリの値を式に代入します。

    (7 * 1,000,000) + (3 * 100,000) + (20 * 100) + (2 * 10) + (0 * 0.001) + (3 * 0.001) = 7,302,020.003

    [追加情報 (More Information)] タブの [優先度ブレークダウン] エリアに、アラート優先度の値として 7302020.003 が表示されます。[アラート] リストには、この値が 7302 として表示されます (千単位)。
    カテゴリ制限の影響
    カテゴリに課される制限により、オーバーフロー値は、優先度順で次にランクの高いカテゴリに作用するようになります。累積カテゴリごとに、事前定義された制限があります。カウントがその制限を超えると、次に高い順位のカテゴリに 1 が加算されます。たとえば、CI タイプの数が制限を超えた場合、優先度の高い次のカテゴリ (重大度) に 1 が加算されます:yyy-zzz becomes yy(y+1) - 000

    [すべてのアラート] リストでの表示

    [すべてのアラート] リストで、[優先度] 列にアラート優先度スコア値が表示されます。表示目的でのみ、実際の計算されたアラート優先度スコアは 1000 で除算されますが、データベース内で計算とソートを目的とする場合は、計算された値全体が使用されます。

    選択されたアラートのアラート優先度の詳細な計算は、[追加情報 (More Information)] タブの [優先度ブレークダウン] エリアに表示されます。

    アラート優先度スコアの計算

    アラート優先度の計算は、グループのプライマリアラートに加えてグループのすべてのアラートにも基づきます。優先度は、次の条件に一致するアラートに対して計算されます。
    • ステータスが「クローズ済み」に等しくない
    • 重大度が「OK」に等しくない
    優先度の計算のためにキューに格納されているアラートは、em_alert_trigger_queue テーブルに一覧表示されます。スケジュール済みジョブ テーブルには、2 つの [イベント管理 - アラート優先度キュー] ジョブがあります。これら 2 つのジョブは並行して実行できます。[挿入と維持] を使用して、別のジョブを作成できます。[イベント管理 - アラート優先度キュー] ジョブは毎分 1 回実行され、1000 オープンアラート単位で優先度が一括計算されます。アラートの優先度の値を決定する複数のファクターがあります。重大度が変更されると、アラート優先度スコアの即時更新がトリガーされます。この場合、[追加情報 (More Information)] タブの [優先度ブレークダウン] エリアの重大度情報とともに、優先度の重大度部分のみが変更されます。

    再計算のトリガー

    アラート優先度スコアの再計算を実行できるトリガーは、次のとおりです。
    表 : 3. 再計算トリガーのリスト
    トリガー アラート優先度スコアへの影響
    新規アラート 新しいアラートが生成されると、アラート優先度スコアの計算がトリガーされます。
    「クローズ済み」から他のステータスに変わった既存のアラート クローズ済みアラートの優先度は計算されないため、アラートステータスが現在の「クローズ済み」ステータスから「オープン」、「再オープン」、または「フラッピング」に変わると、その変更によってアラート優先度スコアの再計算がトリガーされます。
    プライマリ、セカンダリ、なしの間でのロールの変更 ロールが変更されると、アラート優先度スコアの再計算がトリガーされます。例:
    • アラートのタイプが「プライマリ」に変更されると、アラート優先度スコアの再計算がトリガーされます。
    • アラートのタイプが「なし」に変更されると、アラート優先度スコアの再計算がトリガーされます。
    • アラートのタイプが「セカンダリ」に変更されると、アラート優先度スコアの再計算がトリガーされます。
    CI タイプ CI がアラートにバインドされると、その変更によってアラート優先度スコアの再計算がトリガーされます。優先度の再計算を実行するこのトリガーは、CI がアラートにバインドされたときに 1 回だけ発生します。
    セカンダリアラートの数の変更 セカンダリアラートの数が変更されると、アラート優先度スコアの再計算がトリガーされます。
    重大度 重大度が変わると、アラート優先度スコアの再計算がトリガーされます。たとえば、 「OK」から「メジャー」に変わると、スコアの再計算がトリガーされます。上述の他のトリガーとは異なり、重大度が変わると、アラート優先度スコア計算の重大度部分の即時更新がトリガーされます。

    アラート優先度スコアの変更

    アラートの優先度の一部のカテゴリの重要性を変更するには、以下に説明するとおりに、順序や重み付けを変更します。たとえば、影響を受けるサービスの数よりも CI タイプの方が重要である場合は、それぞれの順序を変更できます。その結果、サービスの数には 100 が乗算され、CI タイプには 1000000 が乗算されます。
    注:
    この高度な手順で変更を加えると、アラート優先度スコアのデフォルトの計算方法が変更されます。通常であればスコアが高くならないアラートでも、これらの構成可能な値を変更することで、アラート処理の順序の決定方法を変更できます。
    カテゴリの順序の変更
    em_alert_priority_category_order テーブルに移動します。[順序] 列で、必要なカテゴリの順序を変更できます。
    カテゴリ値のマッピング
    em_alert_priority_category_mapping テーブルには、カテゴリの選択肢ごとの設定値が表示されます。カテゴリのドロップダウンリストの各値は、このテーブルを設定することで、別の値に再マッピングできます。
    CI タイプの重み付けファクターのマッピング
    em_alert_priority_ci_type テーブルに移動します。DualCoreCPU などの新しい CI を追加し、[優先度] 列で、必要なカテゴリの優先度を変更できます。さらに、既存のタイプを編集し、その優先度の値を変更することもできます。このテーブルは、各 CI タイプの値をマッピングするために使用されます。たとえば、CI_type が cmdb_ci_mainframe のメインフレームの優先度を 80 にし、CI タイプが cmdb_ci_server のサーバーの優先度を 60 にすることができます。マッピングによって、さまざまな CI タイプの優先度をカスタマイズできます。