Event Management モジュールの概要
同じ障害に関連する監視通知が、複数のツールから続けて届くことがあります。通知が増えるほど、重複の整理と関連性の確認に時間がかかり、どのサービスから着手するかの判断が遅れます。
Event Management は、監視ツールの通知を「イベント」「アラート」「インシデント」の3段に整理する ServiceNow の機能です。アラートの優先度は、人が入力する影響度や緊急度とは別に、製品が計算して優先度グループとして表示します。Brazil の開発検証環境で決済システムの障害を再現し、画面で確かめました。
検証環境：Brazil PDI / OOTB＋Event Management プラグイン＋AIOps Experience / 2026-10-14〜15 確認
押さえておくこと
通知はイベント、アラート、インシデントの順に整理される
アラートには ITSM の優先度とは別に、優先度グループが表示される。今回のデモでは、重大度が Minor のロードバランサーのアラートも Urgent でした
影響サービスの表示には CMDB のアプリケーションサービスが必要で、自動起票には Store アプリの AIOps Experience（無料）の導入が必要でした
試した規模は小さく、PDI のデモデータで同じ障害を3回再現しただけです。画面は3回目を撮影しました。起票までは16〜20秒、解決までは6〜8秒でした。監視ツールとの実接続は試していません。この記事では、画面と公式ドキュメントからモジュールの全体像を位置づけます。
Event Management が解決する課題
監視ツールは、異常を見つけるたびに通知を送ります。DB の接続数が上限に達すると、その DB を使うアプリケーションや Web、ロードバランサーも続けて異常を報告する、という流れです。1つの障害が数件から数十件の通知になり、通知を1通ずつインシデントにすれば、同じ障害のインシデントが並ぶことになります。
監視ツールの数が増えるほど、この重複は大きくなります。通知の件数だけでなく、通知同士の関連を人が判断する負担も増えていきます。
原因を調べる前に、重複の整理が必要になります。Event Management は、この整理を製品の中で行う機能です。同じキーの通知は1件のアラートに集約し、設定した相関ルールで関連するアラートを親子にまとめます。条件を設定したアラート管理ルールが、アラートからインシデントを作成する流れです。回復の通知が届くと、アラートが閉じ、関連するインシデントが解決されます。
警報8件がインシデント1件になる時系列は、続編監視の警報8件がインシデント1件になる：Event Management のアラート相関と自動起票を PDI で再現で扱います。この記事は、その仕組みを構成要素ごとに説明します。
導入の価値は、件数の削減だけでなく、対応の順番が変わる点にもあります。通知を1通ずつ確認する運用では、届いた順や報告の声の大きさで着手が決まりがちです。Event Management では、優先度グループと影響サービスを一覧で確認でき、親アラートから関連する警報をたどれます。障害の状況を調べる手間が減り、復旧作業へ早く移れます。
ITSM のインシデント管理と Event Management は、優先度の付け方が異なります。
図の内容を文字でも書き出します。
ITSM の優先付け：利用者が電話・ポータル・メールで1件ずつ申告する。サービスデスクが影響度と緊急度を選び、優先度が決まる。担当チームが調査・解決する
ITOM のトリアージ：監視イベント8件が、同じ警報の再送をまとめてアラート6件になる。ルールで DB を親、巻き添えの4件を子にし、グループ1つと単独1件になる。インシデントは1件が自動作成され、担当は Database。この後は ITSM で扱う
右側の8件がアラート6件、インシデント1件になる流れは、筆者が PDI で流した記録です。
ITOM の中での位置づけ
ITOM は IT Operations Management の略です。公式ドキュメントは、Visibility（検出と CMDB の充実）、AIOps（イベントやメトリクスによる監視と予兆検知）、Optimization（クラウドの管理）などに分けて説明しています。Event Management は ITOM AIOps の中核で、監視ツールの通知を集約し、サービスへの影響を把握します。
ITOM 全体の構成は、親記事ITOM のサブモジュールと契約区分の全体像にまとめています。Event Management は、CMDB とインシデント管理に接続します。
CMDB（構成管理データベース）：アラートの対象になるサーバーやロードバランサーを CI として持ちます。CI が登録されていないと、アラートを機器に結び付けられません
アプリケーションサービス：CI が属するアプリケーションサービス（Mapped Application Service など Service Instance 系のクラス）を CMDB で定義します。影響サービスの表示と優先度グループの材料になります
ITSM のインシデント管理：Event Management が作ったインシデントは、通常のインシデントと同じ画面で扱います
契約の面では、公式ドキュメントが ITOM AIOps のパッケージに Event Management を含めています。計数の単位は、アラートやイベントを取る CI の数です。
イベント・アラート・インシデントの3段
通知はイベントとして届き、アラートに集約され、条件に合うアラートからインシデントが作られます。段ごとの処理を次の図にまとめます。
起点は監視ツール、緑は Event Management が自動で行う処理、橙は人が対応するインシデント、水色は参照する前提データです。
イベント
イベントは、監視ツールから届く生の通知です。1通が1件で、テーブルは em_event です。公式ドキュメントによると、イベントは MID Server、スクリプト、SNMP トラップ、メールなどで届き、イベントルールなどの処理を経てアラートになります。
製品に同梱されたフィールドの説明では、送信元は「The source/monitor that generates events」、監視対象は「The physical device or virtual entity that is being monitored」と書かれています。
（訳: 送信元はイベントを生成する監視ツール、ノードは監視対象の物理デバイスまたは仮想的な実体）
引用元: /sys_documentation_list.do?sysparm_query=nameINem_alert,em_event^hintISNOTEMPTY
PDI では、重大度を省いて送ったイベントの処理状態が Error になり、アラートは作られませんでした。必要な項目を満たさないイベントは、アラートにならずに残ります。
アラート
アラートは、イベントを集約した管理単位で、テーブルは em_alert です。今回の PDI では、同じキーでイベントを再送したところ、アラートは増えず、既存のアラートの重大度が更新されました。アラートに紐づくイベントの数は、イベント数の項目に積み上がります。
運用担当はアラートを確認します。状態は Open、Reopen、Flapping、Closed の4つで、Flapping は短時間に再発を繰り返している状態です。重大度は Critical から Warning、OK までと、解消を表す Clear の値を持ちます。デモでは、Clear の通知を契機にアラートが Closed になり、関連するインシデントが Resolved になりました。
相関（アラートグループ）
相関は、関連するアラートを親子にまとめる処理です。公式ドキュメントでは、相関ルールがアラートを主（プライマリ）と従（セカンダリ）に分けて関係を作ると説明されています。階層は2段階までで、1つのアラートが複数の親を持つことはできません。
今回のデモでは、DB を親、アプリケーション・Web・ロードバランサーを子とする相関ルールを作りました。15分以内に届いた関連アラートを、DB のアラートの子として関連づけます。親子にまとめる条件はルールとして定義します。OOTB の相関ルールにはタグを基準にしたものなどがありますが、多くは有効化が前提です。ルールの内容は、第2巻の「設定」で扱います。
インシデントへの連携
アラートからインシデントを作る処理は、アラート管理ルールが担当します。公式ドキュメントによると、アラート管理ルールはインシデントの作成のほか、ナレッジやタスクの作成、修復アクションの起動なども行い、条件に合うアラートだけを処理します。
今回確認した標準の Create Incident 系のルールは、PDI では無効でした。有効だったのは、手動で起票する Create Incident Manually です。デモでは、条件に合う親アラートから、担当グループ Database 付きのインシデントを作るルールを自分で作成しました。
回復の通知が届いたときの動きは、システムプロパティで決まります。アラートを閉じたときのインシデントの扱いと、インシデントを解決したときのアラートの扱いは、別々の設定です。設定値の一覧は、第2巻で扱います。
優先度グループと ITSM の優先度
Event Management のアラートには、ITSM のインシデントとは別に、優先度グループが表示されます。この機能で混同しやすい点です。
インシデントの優先度は、影響度と緊急度から決まります。一方、アラートの優先度は製品が計算する値です。重大度や影響サービス、CI の種類などが材料で、その結果が Urgent、High、Low などの優先度グループとして表示されます。
表の内容を文字でも書き出します。
優先度の材料：ITSM のインシデントは影響度と緊急度。EM のアラートは重大度・影響サービス・CI の種類など
表示の例：ITSM は P1、P3。EM は Urgent、High、Low
今回の例：ITSM は自動作成のインシデントが P1（1回目）と P3（2・3回目）。EM は決済関連の5件が Urgent、ディスク警告が Low
公式ドキュメントでは、優先度は複数のカテゴリの値と重みを組み合わせた複合スコアで決まり、優先度グループは計算された優先度を4つのカテゴリに分けて表示すると説明されています。
決済 DB の障害を再現した直後の Express List で確かめます。
①は決済 DB の親アラート（Alert0010035）と、その子アラート4件です。②は優先度グループの列で、①の5件はすべて Urgent でした。重大度が Minor のロードバランサー（Alert0010038）も Urgent です。決済サービスと無関係なファイルサーバーのディスク警告（Alert0010034）は、重大度が Warning で、優先度グループは Low でした。
観測できたのは、重大度とは異なる区分で優先度グループが表示される点です。要因の内訳までは切り分けていません。公式ドキュメントが説明するとおり、複数のカテゴリと重みによる計算なので、重大度だけでは説明できない結果になります。
運用では、この計算の材料を自社の業務に合わせて設定します。カテゴリの順序、値のマッピング、CI の種類ごとの重みが設定の対象です。
アプリケーションサービスと影響
優先度グループや影響サービスの表示には、CMDB のアプリケーションサービスと CI の関係が必要です。CMDB の Business Service は、影響計算の対象外です。Event Management は、アラートの CI からサービスをたどり、影響対象のサービスを画面に表示します。
①はアラートの要約で、優先度グループ Urgent、重大度 Critical、紐づくインシデントが並びます。②の Impacted services には、影響対象のアプリケーションサービスとして、オンライン決済サービスが Critical で表示されています。表示された影響対象と、関連づけたアラートを、1画面で確認できる点が利点です。業務が実際に止まっているかは、別の確認が必要です。
今回のデモでは、CI を Linux Server 5件、Load Balancer 1件、MySQL Instance 1件の計7件登録しました。そのうち6件の CI を、決済サービスとして Mapped Application Service にまとめています。ディスク警告の対象のファイルサーバーは、この6件に含まれません。Calculated 型のサービスを先に作ったときは、CI の関連が空で影響が出なかったため、Mapped 型に作り直しました。
公式ドキュメントの影響計算の説明では、影響は CI、サービス、アラート、アラートグループに対する障害の大きさを示します。影響ルールや CI 間の関係をもとに計算し、対象は Service Instance とその派生クラスです。
影響表示を使うには、対象の CI とサービスの関連が登録されているかを確認します。
導入に必要なもの
Event Management の導入では、次の構成を確認します。
プラグイン：有効にすると、イベントとアラートのテーブル、ロール、REST の受信口が現れます
Store アプリ AIOps Experience（無料）：アラート管理ルールの実行と、運用担当向けの画面を提供します
CMDB のアプリケーションサービス：影響サービスの表示と優先度グループの材料になります
PDI の導入前の状態は次のとおりです。プラグインを有効にした直後は、イベントの受信とアラートの作成、相関ルールによる親子化まで動きました。アラート管理ルールによる自動起票は動かず、Express List の画面も存在しませんでした。AIOps Experience の導入後は、ルールを評価するスケジュールジョブが追加されています。
AIOps Experience は、Store で価格区分が free、ライセンスの強制が none でした。公式ドキュメントには、AIOps 向けの前提として、ITOM AIOps とそのプラグインが入っていることの確認が挙げられています。
導入を検討する際は、次の3点を先に整理すると後戻りが減ります。
イベントの送信方法：監視ツールが REST、MID Server、メールなどのどれでイベントを送れるか
CMDB の整備状況：アラートの対象機器が CI として登録され、アプリケーションサービスに結び付いているか
インシデントの受け手：自動で作られるインシデントを、どのグループが受け取るか
運用担当が使う画面
運用担当が日常的に開くのは、Service Operations Workspace の Express List です。AIOps Experience を導入すると使えます。発生中のアラートが一覧に並び、優先度グループの列を確認できます。親アラートの ▼ を押すと子アラートが展開される作りで、先ほどの画像が Express List です。
SOW のホームでは、アラートに関する指標と担当の割り当て状況が一覧できます。
①のカードには、AI あり・なしのアラートの平均復旧時間（MTTR）と、節約できた時間が並びます。②の Workload status は、アラートとインシデントが担当に割り当て済みか未割り当てかを示します。このデモでは担当者（Assigned to）を誰にも割り当てていないため、すべて Unassigned でした。担当グループ（Database）の有無とは別の集計と見られますが、集計の基準は確かめていません。
一覧から親アラートを開くと、関連するアラートをまとめて確認できます。
①の要約には、優先度グループ Urgent、重大度 Critical、グループの種類 Rules-based が並び、Task に自動作成されたインシデントが表示されます。②の Alerts in group には、相関ルールでまとめられたアラートが並びます。原因の DB と、関連するアプリケーションやロードバランサーのアラートが、1画面に並ぶ構成です。アラートからインシデントへ移った後の調査と解決は、通常の ITSM のインシデント管理で進めるのが基本です。
優先度グループの確認画面
Express List では、優先度グループの列に Urgent、High、Low が表示されます。画面の列は、フィルターの項目からも選べます。デモでは、決済関連のアラートが Urgent、ディスク警告が Low でした。運用開始後は、この列とアプリケーションサービスの関係を定期的に見直し、優先度が運用の感覚と合っているかを確認します。
公式ドキュメントによると、優先度グループの閾値はシステムプロパティ evt_mgmt.top_priority_group_threshold で決まり、この値を超えると Urgent になります。合っていない場合は、前節のカテゴリの順序や重みを調整するのが基本です。調整後は、同じ条件のアラートを再び発生させて、並びの変化を確認してください。
実機で気づいたこと
自動起票の導入条件
プラグインを有効にした直後の PDI では、標準の Create Incident 系のルールが無効で、自動起票は動きませんでした。AIOps Experience を導入しても、そのままでは起票されませんでした。今回の PDI では、導入後にルールの条件を修正して、自動起票を確認しています。
ルールの条件に、アラートの項目を参照する形式の指定を誤ると、一致が0件になります。自動起票を期待して導入するなら、Store アプリの導入に加えて、ルール条件の検証が必要です。条件の書き方は、第2巻の「設定」で扱います。
自動作成インシデントの優先度
自動作成されたインシデントの緊急度は、アラートの重大度が Critical のとき、その値が使われました。処理の内容からは Major も同様です。影響度は設定されません。優先度は、1回目のデモだけが P1 で、2回目と3回目は P3 でした。作成後に影響度や優先度を変更した履歴は、監査記録にありません。
アラートの優先度グループが Urgent でも、インシデントの優先度は P3 でした。2つの優先度は別々に決まります。自動作成インシデントの優先度をどう扱うかは、設計の論点です。第4巻の開発設計書で扱います。
このシリーズの構成
Event Management モジュールは、次の5巻で扱います。
概要（この記事）
設定：テーブル、ロール、システムプロパティ、ルールなど標準で入っているもの
運用手順書：担当者が操作する手順
開発設計書：どう構成するかの設計
運用設計書：誰が何を判断して運用するかの設計
検証範囲とおことわり
検証環境は Brazil Patch 0 の PDI で、同じシナリオの障害を3回再現しました。画面は3回目を撮影しています
相関ルールとアラート管理ルールのうち、DB を親にする相関ルールと、Database グループへ起票するルールは、デモ用に自分で作成したものです
監視ツールの実接続、Metric Intelligence、Health Log Analytics、機械学習による相関は扱っていません
アプリケーションサービスの影響表示は、Mapped 型のサービスで確認しました。Calculated 型は CI の関連が空で、影響が出ませんでした
システムプロパティの値は、PDI の現在値です。製品の既定値との一致は未確認です
公式ドキュメントは Australia 版を参照しています。Brazil 版との差は未確認です
PDI で動くことは、契約で使えることを意味しません。契約区分は営業窓口でご確認ください
