監視の警報8件がインシデント1件になる：Event Management のアラート相関と自動起票を PDI で再現
監視ツールからの警報メールを、1通ずつインシデントにしていないでしょうか。DB が止まると、アプリ、Web、ロードバランサーも続けて警報を出します。同じ障害のインシデントが何件も並び、どれを先に見るか分からなくなります。
Event Management は、警報をルールで親子にまとめ、親に指定したアラートだけを担当付きのインシデントにします。回復の知らせが届くと、アラートが閉じ、インシデントは Resolved になります。PDI で決済DBの障害を想定したイベントを送り、警報8件がインシデント1件になるところまで確かめました。
検証環境：Brazil PDI / OOTB＋Event Management プラグイン＋AIOps Experience / 2026-10-14〜15 確認
画面で確かめた要点
監視イベント8件（決済障害に関連する7件と、無関係な警告1件）から、インシデントは1件だけできた
DB のイベントを受けてから16秒で、担当 Database 付きのインシデントが自動作成された
後から届いた4件は、DB アラートの子アラートになった。新しいインシデントは作られていない
回復の通知から7秒で、アラート5件が Closed になり、インシデントは Resolved になった
試した規模は小さく、PDI で同じシナリオを3回流しました。画面は3回目を撮っています。起票までは16〜20秒、解決までは6〜8秒でした。この記事は、仕組みが実際に動くかを確かめた記録です。
この記事で扱う Event Management の機能
標準で用意されている部品のうち、今回の流れに関わるものを挙げます。
Event（イベント）：監視ツールから届く生の通知。1通が1件
Alert（アラート）：イベントを集約した管理単位。同じキーのイベントが再送されると、既存のアラートに集約される
Correlation Rule（相関ルール）：関連するアラートを親子にまとめる。今回は決済障害の子4件を、DB の親アラートに関連付けた
Alert Management Rule（アラート管理ルール）：条件に合うアラートからインシデントを作る。担当グループなどのテンプレートも設定できる
Priority Group（優先度グループ）：アラートに付く Urgent、High、Low などの区分。Express List の並び順に使われる
Impacted Services（影響サービス）：構成アイテムからサービスをたどって画面に出す
回復通知によるクローズ：回復の通知でアラートを閉じ、関連するインシデントが解決される
Event Management の全体像と、AIOps としての位置づけは公式ドキュメントにあります。
この中から、イベントの受信から Resolved までを通しで動かしました。
警報を1件ずつ起票した場合との比較
比較に使う「1通ごとに起票する運用」は、監視メール1通につき1件のインシデントを手で作る仮定です。実測した運用ではありません。
本文の時刻は JST です。画面に出る時刻は、デモ環境の表示設定により時差と日付が異なります。
上がビフォー（監視メール1通ごとに起票する運用の仮定）、下がアフター（Event Management の画面）です。インシデントは8件から1件に減りました。アフターの画面では、緑の枠の1行目が親の Alert0010035、2〜5行目が後から届いた子アラート4件、灰色の枠が無関係のディスク警告です。図の内容を文字でも書き出します。
06:20:49 ディスク使用率80%超の警告（無関係）：仮定の運用ではインシデント1件。Event Management では Alert0010034 だけが作られ、優先度グループは Low、起票なし
06:21:05 決済 DB の接続数上限：仮定の運用ではインシデント1件。Event Management ではイベントの16秒後に INC0010061 を自動作成し、担当は Database
06:22:06 以降 AP・Web1・Web2・LB：仮定の運用ではインシデント4件。Event Management では4件とも DB アラートの子になり、新規起票なし
06:22:27・06:22:38 Web1 の再送2回：仮定の運用ではインシデント2件。Event Management では新しいアラートが作られず、イベント数が3に増える
06:27:21 回復通知5件：仮定の運用では担当者が関連7件を手で閉じる。Event Management ではアラート5件が Closed になり、7秒後にインシデントが Resolved
仮定の運用では、インシデントは8件です。決済障害に関連する7件のうち、6件が重複になります。Event Management では、インシデントは1件でした。アラートは6件で、内訳は親1、子4、無関係1です。
決済DB障害を想定したイベントを送る
架空の EC サイトの監視通知を模したイベントを、デモ用の送信元（EC-Monitor）から投入しました。実際の決済停止の再現ではありません。DB の接続数が上限に達すると、AP、Web、ロードバランサーが続けて警報を出す想定です。
アラートの対象にした決済系の構成アイテム（サーバー）は5件です。
ec-db-01（DB サーバ）
ec-app-01（AP サーバ）
ec-web-01・ec-web-02（Web サーバ）
ec-lb-01（ロードバランサー）
これら5件と、MySQL インスタンス1件（ecpay-mysql）の計6件を、Mapped Application Service「オンライン決済サービス（デモ）」にひも付けています。Mapped Application Service は、構成アイテムを関連付けて作るアプリケーションサービスの種類です。ほかに、無関係なファイルサーバのディスク警告を1件混ぜ、重大度（severity）を付け忘れたイベントも1件検証用に送りました。
警報は次の順で届きました。
06:20:49 ファイルサーバのディスク使用率80%超の警告（無関係）
06:21:05 決済 DB の接続数が上限
06:22:06 AP の応答遅延、Web1・Web2 のエラー、LB のヘルスチェック失敗
06:22:27・06:22:38 Web1 の再送2回
06:22:49 重大度なしのイベント（検証用）
06:27:21 回復通知5件
イベントから起票までのルール
イベントからインシデントまでの判断は、3段階に分かれています。今回設定したルールは、相関ルールとアラート管理ルールの2種類です。
イベントからアラートを作る段階
監視ツールから届いたイベントは、処理を通ってアラートになります。同じキーの再送は新しいアラートにならず、既存のアラートに集約されます。
処理の仕組みは、公式ドキュメントにまとまっています。
相関ルールの設定
相関ルールは、アラートを親と子に分けます。親になる条件、子になる条件、まとめる時間幅を決めます。
親：ノードが ec-db-01 のアラート
子：AP、Web、LB の各アラート
時間幅：15分以内に届いたもの
親はルールの条件で指定しています。原因をシステムが推定した結果ではありません。階層は2段階までで、複数の親は持てません。
①の Primary Alert が親の条件で、Source が EC-Monitor、Node が ec-db-01 です。②の Secondary Alert が子の条件で、Node は AP・Web・LB の4つのいずれかです。
アラート管理ルールの設定
アラート管理ルールは、条件に合うアラートに対してインシデントの作成などを実行します。今回の条件とテンプレートは次のとおりです。
条件：source=EC-Monitor^severity=1^parentISEMPTY^incidentISEMPTY^maintenance=false
テンプレート：assignment_group が Database、category が database、state が 2
条件の parentISEMPTY が、子アラートからの起票を止めます。incidentISEMPTY は、インシデントが既にあるアラートからの二重起票を止めます。
テンプレートのうち、実際に反映されたのは assignment_group だけでした。作成されたインシデントは、category が inquiry、state が New のままでした。
ルールの実行履歴は、em_alert_management_execution で確認できます。
①の Alert0010035 から、②の INC0010061 が1回だけ作られています（Log: Automatic execution #1 out of 1）。
16秒で担当付きのインシデントができるまで
DB のイベントは 06:21:05 に届きました。
06:21:12 アラート Alert0010035 が作られた（イベントの7秒後）
06:21:21 インシデント INC0010061 が作られた（イベントの16秒後）
最初に、Service Operations Workspace の Express List を見ます。
①が決済障害に関わるアラートです。先頭の Alert0010035 が親で、番号の右の「4」が子の数で、親の下に並ぶ4行が子アラートです。②の優先度グループは、5行すべて Urgent。ロードバランサーの Alert0010038 は重大度が Minor でも、優先度グループは Urgent でした。
③のディスク警告 Alert0010034 は Low のままで、起票もされていません。この警告は、相関条件にも自動起票の条件にも一致しませんでした。
優先度は複数の値を組み合わせたスコアで決まります。公式の説明は次の2ページです。
アラートを開くと、関連する情報が1画面に出ます。
①の Task 欄の INC0010061 が、このアラートから作られたインシデントです。②の Identified issue は、親アラートの説明です。③の Alerts in group に、同じグループのアラートが並びます。
後から届いた4件は子アラートになった
AP の遅延、Web1 と Web2 のエラー、LB のヘルスチェック失敗は、DB の障害から約1分後に届きました。起票は、この4件が届く前に済んでいます。
相関ルールは、親を ec-db-01 のノード、子を AP・Web・LB の各アラートとし、15分以内に届いたものを関連付けます。4件とも、既存の Alert0010035 の子になりました。冒頭のビフォー・アフターの図では、アフターの緑の枠の2〜5行目（Alert0010038・Alert0010039・Alert0010037・Alert0010036）がこの4件です。親の Alert0010035 の下に字下げして並びます。
アラート管理ルールの条件に「親を持たないこと」を入れているため、子から新しいインシデントは作られません。Web1 の再送2回は、新しいアラートを作りませんでした。Alert0010036 のイベント数が3になりました。
イベントの一覧では、この動きが行ごとに分かります。
②の Web1 のイベント3件は、Message key が同じで、すべて Alert0010036 に紐づいています。①は重大度を付けずに送ったイベントです。State は Error で、アラートは作られませんでした。
影響を受けるサービスが画面に出る
インシデントの優先度を決めるとき、どのサービスが止まっているかを知りたくなります。アラートの Impact を開くと、構成アイテムとサービスが並びます。
①の構成アイテムは5件で、それぞれの担当グループも表示されます。②の Impacted services には「オンライン決済サービス（デモ）」が出ました。クラスは Mapped Application Service で、ビジネス重要度は「1 - most critical」です。
影響の計算は、公式ドキュメントによると Service Instance とその派生クラスが対象です。Business Service は対象外と記載されています。今回は、Mapped Application Service を作って確かめました。
自動作成されたインシデントの中身
INC0010061 の画面です。
①は影響度3、緊急度1で、優先度は「3 - Moderate」です。②の Origin から、元の Alert0010035 を開けます。③の作業メモには、どのアラート管理ルールで作られたかが残ります。説明欄には、CI の名前、メトリック名、影響サービス数が自動で入りました。担当グループは Database です。
ここから先の調査と解決は、通常のインシデント管理で進めます。
回復の知らせから7秒で Resolved
06:27:10 に Acknowledge を押し、06:27:21 に回復通知5件を送りました。7秒後の 06:27:28 に、インシデントは Resolved になりました。アラートは Closed です。
①のアクティビティに、自動の記録が残っています。
作業メモ：「The related alert Alert0010035 state is now Closed」
解決メモ：「Closed the task associated with alert: Alert0010035」
②の状態は Resolved です。今回の3回では、インシデントを手動で解決する操作は不要でした。どのアラートで閉じたかも、記録で追えます。
アラート管理ルールに必要な部品
自動起票に関係するアプリの導入順を示します。PDI で確認した順です。
sn_em_arm 18.16.4：アラート管理ルールを提供する
sn_em_tbac：タグベースのアラートクラスタリングを提供する
sn_em_ai 23.19.1（Event Management Core）：アラート管理ルールの実行基盤。sn_em_arm と sn_em_tbac に依存する
最後に sn_sow_aiops 27.2.51（AIOps Experience）が入り、Express List とアラート画面が使えるようになります。導入前は、アラートの画面が汎用の一覧と詳細だけでした。
導入前に標準ルールを有効にしても、インシデントは作られませんでした。ログには「sn_em_ai is not defined」というエラーが出ました。
アラート管理ルールの作成には evt_mgmt_admin ロール、手動実行には evt_mgmt_operator ロールが必要です。運用で使う担当者には、操作に合わせてどちらかを付けます。
標準で入っているアラート管理ルールと閉じ方の設定
アラートからインシデントを作る標準のルールは、初期状態で有効になっていません。em_alert_management_rule には標準のレコードが19件あります。そのうち「Create Incident」系の3つは、初期状態で無効です。
Create Incident：アラートからインシデントを自動作成する。無効
Create Incident for Primary Alert：親アラートからインシデントを自動作成する。無効
Create Incident on Primary Critical Alert：親かつ重大度 Critical のアラートから作成する。無効
Create Incident Manually：手動でインシデントを作る。有効
自動起票が必要なら、標準ルールを有効にするか、今回のように自分のルールを作ります。有効にする前に、条件が子アラートや無関係な警報に一致しないかを確かめます。
閉じ方は、プロパティで決まります。この PDI の値は次のとおりでした。
evt_mgmt.alert_closes_incident = resolve：アラートが閉じたときの、インシデントの扱いを決める
evt_mgmt.incident_closes_alert = true：インシデントが解決されると、関連アラートを閉じる
親アラートと時間経過による閉じ方も、設定できます。
evt_mgmt.rule_based_manual_closure = false：相関ルールの親を手で閉じたときの、子アラートの扱いを決める
evt_mgmt.alert_auto_close_interval = 0：一定時間で自動クローズする機能は無効
回復通知以外にアラートを閉じる処理がなければ、アラートは開いたまま残ります。その場合は、自動クローズの間隔を設定するか、担当者が閉じる運用を決めます。
今回、回復通知から7秒後にインシデントが Resolved になりました。この PDI では alert_closes_incident が resolve でした。
実機で気づいたこと
プラグインを入れただけでは自動起票しなかった
Event Management のプラグインとルールだけでは、インシデントは1件も作られませんでした。アラート管理ルールの実行履歴も0件です。
Store の AIOps Experience を入れた後に、ルールを評価するジョブと、アラートを閉じるジョブの動作を確認しています。環境を用意する手順には、このアプリの導入を含めます。
無料で入れられるアプリですが、直接の依存アプリが16個あり、導入には約30分かかりました。PDI を新しく作り直すたびに必要になります。
アラートの Type は参照項目だった
最初の条件には、Type が「Disk Full」であることを表示名で書きました。ルールは評価されましたが、一致は0件でした。エラーは出ません。
Type はイベント種別への参照項目です。条件には、参照先の sys_id を指定する必要がありました。直すと自動起票が動きました。起票されないときは、まず条件に使う項目の型を確かめます。
影響度はアラートから設定されなかった
撮影した3回目の画面では、影響度は3で、優先度は P3 でした。影響度はアラートから設定されず、既定値の3になっています。1回目は影響度1で起票されており、原因は特定できていません（末尾参照）。緊急度は、重大度が1か2ならそのまま入ります。
影響度をサービスから決めたい場合は、ルールやテンプレートの設定を別に確かめます。今回は試していません。
重大度のないイベントはアラートにならない
重大度を付けずに送ったイベントは、em_event の State が Error になり、アラートは作られませんでした。監視ツール側で重大度が付いていない通知は、画面にもアラートにも出ません。連携を作るときは、Error になったイベントの一覧も確認対象にします。
自分の PDI で再現する手順の概要
流れは次の図のとおりです。
濃紺は監視ツールの送信、緑は自動で動く処理、橙は1件のインシデント、灰は起票の対象外です。
再現手順は次のとおりです。
Event Management を有効にし、Store から AIOps Experience を導入する
構成アイテムを作り、Mapped Application Service にひも付ける
相関ルールで、親ノードと子の条件、時間幅を決める
アラート管理ルールで、条件とテンプレート（担当グループ）を決める
イベントを送り、アラート、インシデント、クローズの順に確かめる
ルールの作り方は、Event Management の手順書の記事で扱います。
再現するときは、先に無関係な警報を1件混ぜておきます。その警告が相関対象に入らないことを確認できます。
回復通知は5件まとめて送ります。インシデントが Resolved になるまでの秒数も測っておくと、設定を変えた後の検証で比べられます。この記事の7秒も、その方法で測りました。
検証範囲とおことわり
「1通ごとに起票する運用」は、監視メール1通につき1件を手動起票する仮定の比較です
試したのは、決済DB障害を想定したシナリオ3回です。機械学習による相関と Health Log Analytics は動かしていません
PDI で動くことは、契約でライセンスが使えることを意味しません。契約を確認してください。製品の構成と課金単位は、公式ドキュメントのITOM のサブスクリプションにあります
検証のため、evt_mgmt.alert_management_scoped_active、evt_mgmt.log_debug、標準ルール Create Incident を一時変更し、最後に元へ戻しています
インシデントの優先度は、1回目だけ P1 で、2回目と3回目は P3 でした。原因は特定できていません
自分の環境でレコードを確認するURL
この記事で触れたレコードは、自分のインスタンスでも一覧で確かめられます。URL はインスタンスの URL の後ろに付けます。パスはテーブル名から組み立てたもので、記事の執筆時に個別に開いて確かめたものではありません。
イベント：/em_event_list.do
アラート：/em_alert_list.do
相関ルール：/em_alert_correlation_rule_list.do
アラート管理ルール：/em_alert_management_rule_list.do
アラート管理ルールの実行履歴：/em_alert_management_execution_list.do
Event Management のプロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHevt_mgmt
