--- sourceDocument: Xanadu IT Operations Management sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/it-operations-management Release : - xanadu ft:locale : - ja-JP ft:publication_title : - Xanadu IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # アラート優先度 # アラート優先度 {#ariaid-title1} * リリースバージョン: Xanadu * * 更新日 2024年08月01日 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：10分 アラート優先度スコアに基づいてアラートを処理する順番を決定します。複数のファクターによってアラート優先度スコアが決定されます。基になるファクターが変更されると、この値も変更されます。 ## マルチファクターの決定 {#alert-priority__section_aqk_2cb_mbb} アラート優先度スコアの値は、カテゴリの値とその相対的な重み付けを組み合わせたものです。次のセクションで説明されているように、Category order、Category value mapping、CI type weight factor mappingに基づいて、スコアを構成するファクターを設定できます。カテゴリは、次のとおりです。 * Accumulated categories：このカテゴリでは、ステータスや重み付けファクターが異なる可能性のある、さまざまなサブタイプのアイテムを累積します。たとえば、さまざまな重要度に従って考慮されるサービスもあれば、コストに従って考慮されるサービスもあります。 * Choice-list categories：アイテムのリスト。任意のアイテムを異なる値にマッピングして、そのアイテムの優先度を変更できます。たとえば、デフォルトでは値が 1 の「重大」重大度を 4 にマッピングして、計算されるアラート優先度スコアの重み付けを高くすることができます。 {#alert-priority__ul_xy1_3k5_hcb} {#alert-priority__table_wsm_v5d_sbb__entry__2} | カテゴリ | 説明 | |-|-| | 累積カテゴリ || | 影響を受けるビジネスサービスの数 | このカテゴリは、サービスのビジネス上の重要度別に考慮されます。1 つのサービスに影響を与えるアラートは、多くのサービスに影響を与えるアラートよりも優先度スコアが低くなります。たとえば、ルーターが停止すると、多くのサービスに影響を及ぼすおそれがあるため、優先度を高くすることでこのアラートが先に処理され、少数のサービスにしか影響しない別のアラートは後回しになります。重大でない多くのサービスに影響を及ぼすアラートは、優先度を使用して処理する必要があります。ただし、アラートがわずかなサービスにしか影響しなくても、それらが重大なサービスである場合、このアラートの優先度は高くなります。 | | CI タイプ | このカテゴリでは、さまざまな CI タイプを区別します。たとえば、CI タイプがルーターまたはスイッチになっているアラートは、サーバーやアプリケーションなどの別の CI タイプのアラートよりも優先度が高い場合があります。 | | セカンダリアラートの数 | 通常は、メッセージキーが同じアラートなど、他のアラートと類似した特性のアラートと併せてグループ化されます。多数のセカンダリアラートを持つ親アラートは、少数のセカンダリアラートしか持たない親アラートよりも優先度が高くなります。 親アラートのすべてのセカンダリアラートがカウントされます。セカンダリアラートがクローズされると、親アラートとの相関は解除されます。親アラートがクローズされた場合、すべてのセカンダリアラートの相関は解除され、それらの優先度値はそれに従って計算されます。 | | 選択リストカテゴリ || | アラートステータス | 「Closed」ステータスのアラートの場合、優先度スコアは計算されません。デフォルト値を持つ利用可能な進捗状況は、次のとおりです。 * オープン = マッピング値 1 * 再オープン = マッピング値 2 * フラッピング = マッピング値 3 {#alert-priority__ul_amk_nwl_gcb} | | アラート重大度 | 優先度スコアは、基になるアラートの重大度のレベルを反映します。たとえば、重大度が「Critical」のアラートは、重大度が「Minor」のアラートより重み付け値が大きくなります。重大度が「OK」のアラートの場合、優先度は計算されません。利用可能なレベルは、次のとおりです。 * 重大 * メジャー * マイナー * Warning {#alert-priority__ul_jsy_zc2_sbb} | | ロール | 優先度スコアは、アラートのロールを反映しています。優先度スコアは、ロールが「Parent」になっているアラートがより高くなり、次が「None」のロールのアラートで、「Secondary」のロールのアラートには最小の重み付けが設定されます。多数のセカンダリアラートを持つ親アラートは、より少ないセカンダリアラートしか持たない親アラートよりも高い値になります。利用可能なロールは、次のとおりです。 * 親 * なし * セカンダリ {#alert-priority__ul_ppc_nd2_sbb} | [表 : 1. カテゴリのリスト] {#alert-priority__table_wsm_v5d_sbb} ## アラート優先度スコアの構造 {#alert-priority__section_n13_pyl_gcb} 各カテゴリの重み付け値 : 各カテゴリは、その順序と制限に従って、アラート優先度スコアにおいて独自に配置されます。後述の「[アラート優先度スコアの変更](https://servicenow-prod.fluidtopics.net/PlQZOku1dZO7XMLnXqwdBw#alert-priority__section_modify)」の説明に従って、順序と制限を構成できます。正の数に限られます。 : 次の場合を除き、すべてのカテゴリ値が em_alert_priority_category_mapping テーブルからマップされます。 * CI タイプ：em_alert_priority_ci_type テーブルからマップされます。 * セカンダリ：値はセカンダリアラートの数で、いずれのテーブルからもマップされません。 {#alert-priority__ul_xjf_lvd_f4b} 注: 最適なメモリ保護を確保するために、1000 件を超えるアラートを含むアラートグループには正確な優先度スコアがない場合があります。 {#alert-priority__table_lr4_bcs_gcb__entry__2} | カテゴリ | スコア | |-|-| | サービス | (7.0, 1000000.0) たとえば、次のようなビジネス上の重要性の優先度スコアに影響を受けるサービスが 2 つある場合は、次のようになります。 * Service1：ビジネス上の重要性の優先度スコア = 3 * Service2：ビジネス上の重要性の優先度スコア = 4 {#alert-priority__ul_u4y_qfj_qlb}ビジネス上の重要性の優先度スコアの合計が 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) | [表 : 2. 7302020.003 のアラート優先度スコアの構成例] {#alert-priority__table_lr4_bcs_gcb}前出のテーブルのスコアを使用すると、アラート優先度スコアは次のように計算されます。 (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` ## \[すべてのアラート\] リストでの表示 {#alert-priority__section_display} \[すべてのアラート\] リストで、\[優先度\] 列にアラート優先度スコア値が表示されます。表示目的でのみ、実際の計算されたアラート優先度スコアは 1000 で除算されますが、データベース内で計算とソートを目的とする場合は、計算された値全体が使用されます。 選択されたアラートのアラート優先度の詳細な計算は、\[追加情報 (More Information)\] タブの \[優先度ブレークダウン\] エリアに表示されます。 ## アラート優先度スコアの計算 {#alert-priority__section_calculate} アラート優先度の計算は、グループのプライマリアラートに加えてグループのすべてのアラートにも基づきます。優先度は、次の条件に一致するアラートに対して計算されます。 * ステータスが「クローズ済み」に等しくない * 重大度が「OK」に等しくない {#alert-priority__ul_ibj_y1m_gcb}優先度の計算のためにキューに格納されているアラートは、`em_alert_trigger_queue` テーブルに一覧表示されます。スケジュール済みジョブ テーブルには、2 つの `[イベント管理 - アラート優先度キュー]` ジョブがあります。これら 2 つのジョブは並行して実行できます。\[挿入と維持\] を使用して、別のジョブを作成できます。`[イベント管理 - アラート優先度キュー]` ジョブは毎分 1 回実行され、1000 オープンアラート単位で優先度が一括計算されます。アラートの優先度の値を決定する複数のファクターがあります。重大度が変更されると、アラート優先度スコアの即時更新がトリガーされます。この場合、\[追加情報 (More Information)\] タブの \[優先度ブレークダウン\] エリアの重大度情報とともに、優先度の重大度部分のみが変更されます。 ## 再計算のトリガー {#alert-priority__section_i5d_kj5_hcb} アラート優先度スコアの再計算を実行できるトリガーは、次のとおりです。 {#alert-priority__table_oc1_4km_gcb__entry__2} | トリガー | アラート優先度スコアへの影響 | |-|-| | 新規アラート | 新しいアラートが生成されると、アラート優先度スコアの計算がトリガーされます。 | | 「クローズ済み」から他のステータスに変わった既存のアラート | クローズ済みアラートの優先度は計算されないため、アラートステータスが現在の「クローズ済み」ステータスから「オープン」、「再オープン」、または「フラッピング」に変わると、その変更によってアラート優先度スコアの再計算がトリガーされます。 | | プライマリ、セカンダリ、なしの間でのロールの変更 | ロールが変更されると、アラート優先度スコアの再計算がトリガーされます。例： * アラートのタイプが「プライマリ」に変更されると、アラート優先度スコアの再計算がトリガーされます。 * アラートのタイプが「なし」に変更されると、アラート優先度スコアの再計算がトリガーされます。 * アラートのタイプが「セカンダリ」に変更されると、アラート優先度スコアの再計算がトリガーされます。 {#alert-priority__ul_o3j_cy4_hcb} | | CI タイプ | CI がアラートにバインドされると、その変更によってアラート優先度スコアの再計算がトリガーされます。優先度の再計算を実行するこのトリガーは、CI がアラートにバインドされたときに 1 回だけ発生します。 | | セカンダリアラートの数の変更 | セカンダリアラートの数が変更されると、アラート優先度スコアの再計算がトリガーされます。 | | 重大度 | 重大度が変わると、アラート優先度スコアの再計算がトリガーされます。たとえば、 「OK」から「メジャー」に変わると、スコアの再計算がトリガーされます。上述の他のトリガーとは異なり、重大度が変わると、アラート優先度スコア計算の重大度部分の即時更新がトリガーされます。 | [表 : 3. 再計算トリガーのリスト] {#alert-priority__table_oc1_4km_gcb} ## アラート優先度スコアの変更 {#alert-priority__section_modify} アラートの優先度の一部のカテゴリの重要性を変更するには、以下に説明するとおりに、順序や重み付けを変更します。たとえば、影響を受けるサービスの数よりも 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 タイプの優先度をカスタマイズできます。