Event Management モジュールの設定

Event Managementを入れた直後、「イベントは届くのにインシデントができない」と気づく場面があります。確認した環境では、インシデントを自動作成する標準のアラート管理ルールが無効でした。設定はイベントルール・相関ルール・アラート管理ルールと、システムプロパティに分かれています。Brazil版の検証環境で、テーブル・ルール・プロパティ・ロール・スケジュールジョブを実際に開いて確かめました。

設定を触る前に押さえること

• 挙動を決めるルールは、イベントを振り分けるイベントルール、アラートを親子にまとめる相関ルール、アラートに自動で対応するアラート管理ルールです。

• アラート管理ルールのうち、インシデントを自動作成する標準ルール3つは無効のまま入っています。有効なのは手動で起票する Create Incident Manually です。

• アラートとインシデントの閉じ方の連動は、alert_closes_incident と incident_closes_alert のプロパティで決まります。

調査の範囲と方法

この資料は、Event Managementの設定が導入直後にどうなっているかを記録した調査資料です。イベントからインシデントまでの実測は、別の記事で扱います。

• 監視の警報8件がインシデント1件になる：Event Management のアラート相関と自動起票を PDI で再現

設計の判断は開発設計書に任せます。

• 環境：Brazil PDI（Patch 0）に、Event Managementプラグインと、ストアアプリ AIOps Experience を導入した状態

• 確認日：2026-10-14

• 使ったロール：admin

• 確認方法：テーブルの一覧・フォーム・システムプロパティ画面で値を参照した

• 範囲：テーブル、フィールドの公式説明、選択肢、3種類のルール、プロパティ、ロール、スケジュールジョブ、連携の起動方法

• 範囲外：機械学習系の機能、Health Log Analytics、一般利用者のロールでの確認、本番環境の挙動

標準（OOTB）と検証用の区別も先に決めておきます。名前が「デモ:」「PDI検証:」で始まるルールは、筆者が検証のために作ったルールです。件数と説明には数えず、画面に写っている場合は本文で断ります。

導入されるもの

Event Managementは、プラグインとして有効化する本体と、ストアアプリで追加する AIOps Experience で構成されます。AIOps Experience を入れると、依存するアプリも一緒に入ります。アラート管理ルールを実行する仕組み（スコープ版）は、その中の Alert Rules Management（sn_em_arm）が提供するものです。標準ルールのレコード自体は、プラグイン導入直後から存在していました。

導入後の環境では、名前が em_ で始まるテーブルを122件確認しました。そのうち em_event0000 から em_event0006 までは、イベントを時期別に分けて保存する分割テーブルです。管理者が日常で開くのは、ほとんどが次の節の7テーブルです。

公式ドキュメントは、Event Managementの全体を次のページで説明しています。

• Exploring Event Management

• Exploring ITOM AIOps

テーブル構成

設定で最初に開くテーブルは7つです。イベントとアラートは入出力のデータ、3種類のルールは設定データ、コネクタ定義とイベントタイプは周辺の参照データという役割です。

表の内容を文字でも書き出します。

• em_event（Event）：監視ツールから届いた生のイベントを記録します。継承元はありません。

• em_alert（Alert）：イベントから作られるアラートです。継承元はなく、基盤に以前からあるテーブルにEvent Managementが項目を足しています。

• em_match_rule（Event Rule）：イベントの振り分けルールです。継承元は Application File で、更新セットで移送できます。

• em_alert_correlation_rule（Alert Correlation Rule）：アラートを親子にまとめるルールです。継承元は Application File です。

• em_alert_management_rule（Alert Management Rule）：アラートへの自動対応を決めるルールです。継承元は Application File です。

• em_connector_definition（Connector Definition）：外部監視ツールとの接続定義です。継承元はありません。

• em_event_type（Event Type）：アラートの Type 項目が参照する種類です。継承元はありません。

継承元が Application File のテーブルは、更新セットで開発環境から本番環境へ移せます。つまり3種類のルールは、環境間で設定を持ち運べる対象です。一方、イベントとアラートは業務データなので、移送の対象になりません。

フィールドと選択肢

イベントとアラートの項目には、製品が説明文（hint）を同梱しています。実務で意味を取り違えやすいものを3つ選びます。

親アラートへの参照（類似、または根本原因）です。em_alert.parent の説明で、子アラートが親を指す項目だと分かります。

イベントに一致している現在のルールです。イベントを処理したルールは処理メモに表示されます。em_event.event_rule の説明で、どのルールで処理されたかを追うときは処理メモを見ます。

削除されたイベントを含め、このアラートに紐づくイベントの総数です。em_alert.event_count の説明で、この値には削除済みのイベントも含まれます。

引用元は、フィールドの公式説明です。自分の環境では /sys_documentation_list.do?sysparm_query=nameINem_alert,em_event^hintISNOTEMPTY で同じ記述を確認できます。

状態や重大度を確認するときは、次の選択肢を参照します。値は製品が定義しています。

• アラートの状態（em_alert.state）：Open、Reopen、Flapping、Closed の4値です。Flapping は、短い間に再発を繰り返している状態を表します。

• 重大度（em_alert.severity）：1 Critical、2 Major、3 Minor、4 Warning、5 OK、0 Clear の6値です。Clear は解消の通知に使う値で、実機では severity 0 のイベントでアラートが Closed になりました。

• グループ化の由来（em_alert.group_source）：アラートがどの仕組みでまとめられたかを表します。値は次の12個です。

• Automated、Rules-based、Manual、CMDB

• Secondary、None、Text、Log Analytics

• Component-based、Tag Cluster、Network Traffic、Mixed

• イベントの処理状態（em_event.state）：Ready、Processed、Ignored、Error の4値です。重大度を付けずに送ったイベントは Error になり、アラートは作られませんでした。

今回の相関ルールで親子にしたアラートでは、親が Rules-based、子が Secondary でした。

①の行は、重大度を付けずに送った検証用のイベントです。State が Error になり、Alert 欄は空のままです。重大度の無いイベントはこの環境ではアラートにならなかったため、送信側の項目に重大度を含めておきます。

イベントルール

イベントルールは、届いたイベントをどのアラートに変換するかを決める振り分けの設定です。監視ツールの種類ごとに用意されています。

標準のイベントルールは181件あり、監視ツール別の標準コンテンツが大半を占めます。名前には Splunk、SolarWinds、AWS CloudWatch、Microsoft Azure、Cisco の SNMP トラップ、Zabbix などの監視ツールが並びます。有効なものの名前の例です。

• Host not responding（有効）

• Node response time above（有効）

• snmpV3.coldStart（有効）

• Zabbix net.tcp.port（有効）

監視ツールが標準対応であれば、まず既存のイベントルールが使えるかを確かめます。該当がなければ自社用のイベントルールを作る流れです。イベントがアラートになるまでの処理は、公式ドキュメントの次のページが参考になります。

• Processing events

相関ルール

相関ルールは、関連するアラートを親（プライマリ）と子（セカンダリ）にまとめます。画面に溢れるアラートを、親1つの下に畳むための設定です。

標準の相関ルールは18件あり、有効なものは少数です。無効のまま入っているものの大半は、Tag Based Alert Clustering Engine が作る [Tag Based] のルールです。同じノード、同じ CI、同じサブネットでまとめるものが該当します。有効なものには Dynatrace alert correlation rule と [Tag Based] Azure Monitor Correlation があり、特定の監視ツール向けです。

①は有効なので、Dynatrace 由来のアラートに実行されます。②は標準のサンプルで、無効のまま入っています。一覧にある「PDI検証:」「デモ:」で始まる行は、筆者が検証のために作ったルールです。標準の設定には数えません。

公式ドキュメントによると、相関ルールは新しいアラートのほか、閉じた・フラッピングから開いた・再オープンしたアラートにも実行されます。階層は2段階までで、子の下にさらに子が付くと平坦化されます。複数の親は持てません。

• Alert correlation rules

親を閉じたときの子の扱いは、後述する rule_based_manual_closure で決まります。

アラート管理ルール

アラート管理ルールは、アラートに対して自動で何かをする設定です。インシデント作成や修復アクションの起動、外部コンソールへのリンク表示などを、条件に合うアラートに実行します。標準のルールは19件あります。

標準の起票系ルールは、名前から読み取れる動きを次に挙げます。条件の中身までは確認していません。

• ① Create Incident on Primary Critical Alert：親で、かつ重大度が Critical のアラートからインシデントを作ります。標準では無効です。

• ② Create Incident for Primary Alert：親アラートからインシデントを作ります。標準では無効です。

• ② Create Incident：全アラートからインシデントを作ります。標準では無効です。

• ③ Create Incident Manually：担当者が画面から手動で起票するときに使います。標準で有効です。

①のルールのフォームを開くと、有効でない旨のメッセージが出ます。

つまり導入直後は、アラートが届いても、インシデントが自動では作られません。担当者が手動で起票するか、自動起票ルールを有効にするか、自作するかの判断が先に要ります。

自動起票を使う場合は、標準ルールの有効化と、新規のルール作成が選択肢になります。どちらを採用するか、条件をどう設計するかは、開発設計書で決めます。

条件に Type を書くときの注意

アラートの Type 項目は、em_event_type テーブルへの参照です。今回、条件式を type=Disk Full と直接指定すると、一致するアラートは0件でした。エラーは出ませんでした。

この条件の自作ルールではインシデントが作られず、実行履歴も0件でした。同じ条件を sys_id で指定すると7件に一致し、Alert0010015 からインシデントが自動作成されました。

アラート管理ルールの条件に参照項目を使うときは、保存する前に、同じ条件で一覧を開いて一致件数を確かめます。

Alert automation の画面

Service Operations Workspace の Alert automation には、自動化の分類を選ぶ画面があります。

①の Automation types には、Ignore、Enrich、Group、Respond の分類があります。Ignore を選ぶと、②の Active が True の自動化3件が並び、③の Source には OMi・Hyperic・OBM とあります。

• Ignore：不要なアラートを一覧に出さない

• Enrich：情報を足す

• Group：アラートをまとめる

• Respond：対応を起動する

画面は Ignore を選んだ状態で、OMi Sitescope や OBM 向けのルールが有効で並んでいます。

公式ドキュメントは、アラート管理ルールの作り方を次のページで説明しています。ルールの作成には evt_mgmt_admin、手動実行には evt_mgmt_operator のロールが必要です。

• Alert management rules

• Alert priority

• Alert priority groups

システムプロパティ

挙動の調整は、名前が evt_mgmt で始まるシステムプロパティに集まっています。導入後の環境で119件ありました。運用で見ることが多いものを、役割ごとに並べました。値は検証環境の現在値です。

アラートとインシデントの連動

• evt_mgmt.alert_closes_incident = resolve（①）：アラートを閉じたときのインシデントの扱いを決めます。値は resolve です。

• evt_mgmt.incident_closes_alert = true（②）：インシデントを解決すると、関連するアラートを閉じます。

• evt_mgmt.alert_reopens_incident = new：アラートを再オープンしたときの扱いです。値は new です。

• evt_mgmt.rule_based_manual_closure = false：手動またはルールで親を閉じたとき、子のアラートを開いたまま残すかを決めます。親子アラート間の扱いを決める項目です。

アラートとインシデントの閉じ方の連動は、alert_closes_incident と incident_closes_alert が決めます。再オープンは alert_reopens_incident、親子アラートの閉鎖は rule_based_manual_closure が別に決めます。

閉じる条件と再開

• evt_mgmt.alert_auto_close_interval = 0：開いたアラートを自動で閉じる間隔（時間）です。0 のため、この時間設定による自動クローズは無効です。

• evt_mgmt.active_interval = 14400：閉じたアラートを再開できる期間（秒）です。4時間以内に同じイベントが届くと、閉じたアラートが開き直ります。

• evt_mgmt.alert_ack_on_close = true：手動で閉じるとき、アラートを確認済みにします。

フラッピングの判定

フラッピングは、短時間に正常と異常を繰り返す状態です。

• evt_mgmt.flap_interval = 120：フラッピングを判定する期間（秒）です。

• evt_mgmt.flap_frequency = 10：期間内にこの回数以上再発すると、フラッピング状態にします。

• evt_mgmt.flap_quiet_interval = 300：フラッピング状態から抜けるための無通知の時間（秒）です。

処理の量と速度

• evt_mgmt.events_processing_delay_sec = 5：受信したイベントを処理するまでの待ち時間（秒）です。

• evt_mgmt.fetch_limit = 500：イベント処理ジョブが1回に取得する Ready のイベントの上限です。

• evt_mgmt.max_events_processing_per_job = 5000：1回のジョブで処理するイベントの上限です。

• evt_mgmt.event_processor_job_count = 1：イベント処理のスケジュールジョブの数です。

大量のイベントが遅れて処理される場合は、この4つが調整の対象になります。

機能の有効と無効

• evt_mgmt.enable_alert_correlation = true：アラートの相関計算を有効にします。

• evt_mgmt.alert.management.activated = true：アラート管理ルールの実行を有効にします。

• evt_mgmt.alert_management_scoped_active = true：スコープ付きのアラート管理ルールを有効にします。導入時に作られた設定です。

• evt_mgmt.self_health_active = true：Event Management の自己監視を有効にします。

• evt_mgmt.log_debug = false：デバッグログの出力です。調べるときだけ true にします。

導入時に作られたプロパティを6つ確認しました。名前と現在値は次のとおりです。

• evt_mgmt.alert_management_scoped_active = true

• evt_mgmt.impact_filter_services_ready = true

• evt_mgmt.impact_filter_services_queries_enabled = true

• evt_mgmt.impact_filter_services_dashboard_enabled = true

• evt_mgmt.unknown_nodes_removed = true

• evt_mgmt.alert.management.enable_legacy_alert_action_rules = false

ロール

Event Managementのロールは evt_mgmt_ で始まる8つです。いずれも標準です。誰に何を付けるかは、次のように決められます。

• evt_mgmt_admin：プロパティとルールを設定・構成できます。設計担当に付けます。

• evt_mgmt_operator：アラートを閉じる、確認するなどの操作ができます。運用担当に付けます。

• evt_mgmt_user：アラートのライフサイクルを管理できます。

• evt_mgmt_integration：イベントの生成とノードの登録ができます。REST で送信する連携用のアカウントに付けます。

• evt_mgmt_connector_instance_read / create / write / delete：コネクタインスタンスの読み取り・作成・更新・削除を、操作ごとに分けています。

①は設定、②はイベントの送信、③はアラートの操作に使うロールです。

イベントの送信用（evt_mgmt_integration）と、アラートの操作用（evt_mgmt_operator）は分かれています。外部の監視ツールに付ける権限を、画面を操作する権限と混ぜずに済みます。

AIOps 側には evt_aiops_manager があります。NOC チームを管理し、人のオペレータと AIOps の AI スペシャリストを監督する役割です。ロールの作成日は Event Management の導入前の日付です。

権限の割り当て先と、一般利用者に見えるデータの範囲は、この調査では確認していません。

スケジュールジョブ

Event Management の処理は、スケジュールジョブで動きます。名前に Event Management を含むジョブは76件で、有効なものが大半です。

主要なものを間隔つきで並べます。

• Event Management - Alert Crawler（13秒、有効）

• Event Management - Close alerts when incident resolved（13秒、有効）：インシデントを解決すると、関連するアラートが閉じられることを実機で確認しています。

• Event Management - Evaluate Scoped Alert Rules Management0（約11秒、有効）：アラート管理ルールの実行履歴が記録されることを確認しています。Management1 は無効です。

• Event Management - Monitor Tag Based Correlation Rules（30秒、有効）

• Event Management - close flapping alerts（5分、有効）

• Event Management - auto close alerts（10分、有効）

• Event Management - Calculate Alert Priority Grouping（30分、有効）

• Event Management - Impact Calculator Trigger（6秒、有効）

ルールを作ってもすぐ起票されないときは、Evaluate Scoped Alert Rules Management0 が有効かを確認します。同じ名前のジョブが複数あるものもあるため、フォームの内容も見ます。

影響計算の仕組みは、公式ドキュメントが次のページで説明しています。対象は Service Instance とその派生クラスで、Business Service は対象外です。CMDBのサービスの扱いは、サービスのCI（cmdb_ci_service） の記事に整理しています。

• Impact calculation

連携

外部の監視ツールからイベントを受け取る方法は複数あります。MID Server、スクリプト、SNMP トラップ、メールが公式の挙げる経路です。

• Inbound Event API：REST で /api/global/em/jsonv2 に POST します。evt_mgmt_integration のロールを持つアカウントで送信します。

• コネクタ定義：Azure Monitor、Datadog、IBM Netcool、Nagios XI などの定義が標準で38件入っています。

• MID Server：社内ネットワークの監視ツールとつなぐときに使います。

この検証環境から外部へイベントやメールを送信した操作はありません。連携の実測は、PDI の中でイベントを自作して送った範囲に限っています。

所見

実機で気づいたこと

以下の3点です。

標準の起票ルールは無効のまま入っている

標準のアラート管理ルールの起票系は、Create Incident Manually を除いて無効でした。インストールしただけでは、アラートはインシデントになりません。

有効化するか、どの条件で起票させるかは、開発設計書で決める事項です。

条件の Type は表示名で書くと一致しない

Type を Disk Full と書いたルールは、一致0件でもエラーを出しませんでした。ルールが動かないとき、条件の書き方を疑う手がかりが画面に出ません。実行履歴（em_alert_management_execution）が0件のときは、条件の一致件数、依存アプリの導入状況、実行ジョブの有効状態を順に確認します。参照項目の条件は、一覧で一致件数を確かめてから使います。

導入日付きの標準コンテンツがある

プラグイン導入の日に作られた標準コンテンツがあります。作成日が導入日だからといって、自作とは限りません。自作かどうかは、名前や作成の経緯で判断します。この資料では、名前が「デモ:」「PDI検証:」で始まるものだけを自作として扱いました。

検証範囲とおことわり

• 確認したこと：テーブル、フィールドの説明、選択肢、3種類のルール、プロパティ、ロール、スケジュールジョブを、管理者の画面で参照しました。

• 環境：Brazil PDI（Patch 0）です。参照した公式ドキュメントは Australia 版で、Brazil 版との差は確認していません。

• 未確認：イベントルールの条件式、コネクタの有効・無効を管理する設定箇所、group_source の値7が欠番の理由、説明欄が途中で切れているプロパティ（alert_closes_incident、alert_reopens_incident）の全文。

• 未確認：プロパティの既定値（記載の値はこの環境の現在値で、製品の既定値とは別の可能性があります）と、impact_filter_services_* の具体的な機能。

• 未確認：ジョブ Close alerts when incident resolved の作成日と、導入後に追加された記録との食い違いの理由。

• 範囲外：機械学習系の機能、Health Log Analytics、一般利用者のロールでの確認、本番環境の挙動。

付録

自分の環境で確認するURL

この記事で引用した説明文は、製品が同梱しているドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。

• /sys_documentation_list.do?sysparm_query=nameINem_alert,em_event^hintISNOTEMPTY：フィールドの公式説明

• /sys_properties_list.do?sysparm_query=nameSTARTSWITHevt_mgmt^descriptionISNOTEMPTY：プロパティの公式説明

• /em_match_rule_list.do：イベントルール

• /em_alert_correlation_rule_list.do：相関ルール

• /em_alert_management_rule_list.do：アラート管理ルール

• /sys_user_role_list.do?sysparm_query=nameSTARTSWITHevt_mgmt：ロール

• /sysauto_script_list.do?sysparm_query=nameLIKEEvent Management：スケジュールジョブ

• /em_alert_management_execution_list.do：アラート管理ルールの実行履歴

用語集

• イベント：監視ツールからの通知です。

• アラート：イベントから作られる、対応が必要な事象の記録です。

• 親アラート（プライマリ）：相関ルールでまとめたときの代表のアラートです。

• フラッピング：短い間に正常と異常を繰り返す状態です。

関連記事

• 起票までの実測：監視の警報8件がインシデント1件になる：Event Management のアラート相関と自動起票を PDI で再現

• 概要：Event Management モジュールの概要

• サービスのCI：サービスのCI（cmdb_ci_service）