alert-analysis

アラート分析

概要

このスキルでは、ServiceNow ITOM Event Management の運用アラートを分析するための体系的なアプローチを紹介します。次の内容を扱います。

• 重大度と状態によるアクティブなアラートのクエリとフィルタリング
• アラートのパターンと繰り返し発生するノイズの特定
• アラートのグループ化と相関ルールの設定
• アラート疲れを軽減するための抑制ルールの作成
• 相関アラートをたどって根本原因の兆候を追跡
• CI のビジネス上の重要度に照らしたアラート重大度の評価

使用する場面： 運用チームが大量のアラートをトリアージし、繰り返し発生するノイズを特定し、関連するアラートを相関付ける場合、またはイベント管理ルールを調整する場合に使用します。

必要なプラグイン： com.snc.event_management

前提条件

• ロール： evt_mgmt_admin、evt_mgmt_user、または itil
• アクセス権： em_alert、em_event、evt_mgmt_alert_actions テーブルへの読み取り／書き込み権限
• 知識： ITOM Event Management の概念、アラートのライフサイクル状態、CI の関係に関する知識
• プラグイン： com.snc.event_management が有効化されていること

手順

ステップ 1：重大度別にアクティブなアラートをクエリする

現在オープンになっているアラートを取得し、運用状況を把握します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: state!=Closed^ORDERBYDESCseverity
  fields: sys_id,number,description,severity,state,source,node,ci,group_source,acknowledged,sys_created_on
  limit: 50

REST API を使用する場合：

GET /api/now/table/em_alert?sysparm_query=state!=Closed^ORDERBYDESCseverity&sysparm_fields=sys_id,number,description,severity,state,source,node,ci,group_source,acknowledged,sys_created_on&sysparm_limit=50

重大度の参照値：

値	ラベル	説明
1	Critical	直ちに対応が必要
2	Major	大幅な性能低下
3	Minor	影響は限定的。注意深く監視
4	Warning	問題が発生する可能性あり
5	Info	情報提供のみ。対応不要
0	Clear	以前に発生したアラートが解消済み

ステップ 2：アラートのパターンとノイズを特定する

ソースおよびノード別にアラート頻度を分析し、ノイズの多いアラートソースを検出します。

MCP を使用する場合：

Tool: SN-Execute-Background-Script
Parameters:
  description: Identify top noisy alert sources in the last 24 hours
  script: |
    var ga = new GlideAggregate('em_alert');
    ga.addQuery('sys_created_on', '>=', gs.daysAgo(1));
    ga.addQuery('state', '!=', 'Closed');
    ga.addAggregate('COUNT');
    ga.groupBy('source');
    ga.groupBy('node');
    ga.orderByAggregate('COUNT', false);
    ga.setLimit(20);
    ga.query();

    gs.info('=== TOP NOISY ALERT SOURCES (Last 24h) ===');
    while (ga.next()) {
      var count = ga.getAggregate('COUNT');
      var source = ga.source.toString();
      var node = ga.node.toString();
      gs.info('Source: ' + source + ' | Node: ' + node + ' | Count: ' + count);
    }

REST API を使用する場合：

GET /api/now/stats/em_alert?sysparm_query=sys_created_on>=javascript:gs.daysAgo(1)^state!=Closed&sysparm_count=true&sysparm_group_by=source,node&sysparm_orderby=COUNT&sysparm_limit=20

ステップ 3：アラートの相関グループを分析する

アラートがどのようにグループ化されているかを確認し、関連する問題を検出します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: group_source!=NULL^state=Open
  fields: sys_id,number,description,severity,group_source,ci,node,source
  limit: 30

特定の相関グループに含まれるすべてのアラートを検索するには：

Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: group_source=[parent_alert_sys_id]
  fields: sys_id,number,description,severity,node,ci,source,sys_created_on

アラートのメトリック相関を確認する：

Tool: SN-Query-Table
Parameters:
  table_name: em_alert_metric_correlation
  query: alert=[alert_sys_id]
  fields: sys_id,alert,metric_name,ci,correlation_strength,sys_created_on

ステップ 4：抑制ルールを確認して作成する

既存の抑制ルールを確認し、特定したノイズに対する新しいルールを作成します。

既存のアラートアクションルールを一覧表示する：

Tool: SN-Query-Table
Parameters:
  table_name: evt_mgmt_alert_actions
  query: active=true
  fields: sys_id,name,description,type,order,active,filter_conditions
  limit: 50

REST API を使用して抑制ルールを作成する：

POST /api/now/table/evt_mgmt_alert_actions
Content-Type: application/json

{
  "name": "Suppress disk space warnings on dev servers",
  "type": "Suppress",
  "active": true,
  "order": 100,
  "filter_conditions": "source=Nagios^descriptionLIKEdisk space^nodeLIKEdev-",
  "description": "Suppress low-severity disk space warnings from development servers"
}

ステップ 5：CI の関係を通じて影響を評価する

アラートを CI のビジネス上の重要度およびサービスへの影響と照合します。

MCP を使用する場合：

Tool: SN-Execute-Background-Script
Parameters:
  description: Enrich critical alerts with CI business context
  script: |
    var gr = new GlideRecord('em_alert');
    gr.addQuery('state', 'Open');
    gr.addQuery('severity', '<=', 2);  // Critical and Major
    gr.query();

    gs.info('=== CRITICAL ALERT IMPACT ANALYSIS ===');
    while (gr.next()) {
      var alertNum = gr.number.toString();
      var ciId = gr.ci.toString();
      var severity = gr.severity.getDisplayValue();

      if (ciId) {
        var ci = new GlideRecord('cmdb_ci');
        if (ci.get(ciId)) {
          var criticality = ci.business_criticality.getDisplayValue() || 'Not Set';
          var supportGroup = ci.support_group.getDisplayValue() || 'Unassigned';

          // Check service associations
          var svcCount = 0;
          var svcAssoc = new GlideRecord('service_ci_assoc');
          svcAssoc.addQuery('ci_id', ciId);
          svcAssoc.query();
          svcCount = svcAssoc.getRowCount();

          gs.info(alertNum + ' | Severity: ' + severity +
            ' | CI: ' + ci.name + ' | Criticality: ' + criticality +
            ' | Support: ' + supportGroup + ' | Services Affected: ' + svcCount);
        }
      } else {
        gs.info(alertNum + ' | Severity: ' + severity + ' | CI: NOT MAPPED');
      }
    }

ビジネスサービスへの影響について em_impact を確認する：

Tool: SN-Query-Table
Parameters:
  table_name: em_impact
  query: alert=[alert_sys_id]
  fields: sys_id,alert,business_service,impact_level,ci

ステップ 6：アラートの状態を確認して管理する

分析が完了したら、アラートの状態を更新します。

アラートを確認する：

Tool: SN-Update-Record
Parameters:
  table_name: em_alert
  sys_id: [alert_sys_id]
  data:
    acknowledged: true
    work_notes: "Alert reviewed during operational analysis. Root cause traced to [description]. Monitoring."

解決済みのアラートをクローズする：

Tool: SN-Update-Record
Parameters:
  table_name: em_alert
  sys_id: [alert_sys_id]
  data:
    state: Closed
    close_notes: "Root cause resolved. Disk space freed on node prod-web-03."

ツールの使用方法

MCP ツールのリファレンス

ツール	使用する場面
SN-Query-Table	アラート、イベント、抑制ルールのクエリ
SN-Get-Record	単一のアラート詳細の取得
SN-Update-Record	アラートの確認、クローズ、または更新
SN-Natural-Language-Search	自然言語によるアラート検索
SN-Execute-Background-Script	集計、パターン分析、CI 情報の拡充

REST API のリファレンス

エンドポイント	メソッド	目的
/api/now/table/em_alert	GET	アラートのクエリ
/api/now/table/em_alert/{sys_id}	PATCH	アラート状態の更新
/api/now/table/em_event	GET	生イベントのクエリ
/api/now/table/evt_mgmt_alert_actions	GET/POST	抑制ルールの管理
/api/now/table/em_alert_metric_correlation	GET	メトリック相関の確認
/api/now/table/em_impact	GET	ビジネスへの影響の確認

ベストプラクティス

• 重大度の高いアラートから優先的にトリアージする： 重大（1）および高（2）のアラートには、重大度の低いアラートに取りかかる前に必ず対処します
• アラートを CI にマッピングする： マッピングされていないアラートはビジネスコンテキストを失います。イベントルールでの CI マッピングを優先してください
• 毎週ノイズを確認する： 抑制ルールを維持するため、主要なアラート発生元を毎週確認する予定を設定します
• 抑制する前に相関させる： 関連するアラートを相関させればシグナルを維持できますが、抑制するとシグナルが隠れてしまいます
• 抑制の理由を記録する： 今後の監査に備え、抑制ルールを作成した理由を必ず記録します
• 重大度の整合性を検証する： アラートの重大度が CI のビジネス上の重要度と一致していることを確認します。Tier-1 サービスの「警告」は、エスカレーションが必要な場合があります

トラブルシューティング

コンソールにアラートが表示されない

原因： イベントが処理されてアラートに変換されていません 解決策： 生のイベントについて、em_event テーブルを確認します。evt_mgmt_alert_actions のイベントルールで、イベントが正しくアラートにマッピングされていることを確認します。

重複アラートが多すぎる

原因： アラートのグループ化ルールがない、または正しく設定されていません 解決策： アラート相関ルールを確認します。group_source フィールドのロジックが、source、node、type の組み合わせで一致することを確認します。

抑制ルールが適用されない

原因： ルールの順序が競合しているか、フィルター条件が一致していません 解決策： order フィールドを確認します。数値が小さいものから実行されます。同じエンコード済みクエリで em_alert を検索し、フィルター条件をテストします。

CI がアラートにリンクされていない

原因： イベントペイロードに ci_identifier がないか、検索ルールが一致していません 解決策： CI 識別フィールドについてイベントペイロードを確認します。Event Management の設定で CI 検索ルールを確認します。

例

例 1：重大アラートの急増をトリアージする

# 1. Find all Critical alerts from the last hour
Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: severity=1^sys_created_on>=javascript:gs.hoursAgo(1)
  fields: sys_id,number,description,source,node,ci,state
  limit: 50

# 2. Group by source to identify if it is a single source flooding
Tool: SN-Execute-Background-Script
Parameters:
  description: Group critical alerts by source
  script: |
    var ga = new GlideAggregate('em_alert');
    ga.addQuery('severity', 1);
    ga.addQuery('sys_created_on', '>=', gs.hoursAgo(1));
    ga.addAggregate('COUNT');
    ga.groupBy('source');
    ga.query();
    while (ga.next()) {
      gs.info('Source: ' + ga.source + ' | Count: ' + ga.getAggregate('COUNT'));
    }

# 3. If single source, consider temporary suppression or investigation

例 2：ノイズ削減レポートを作成する

# 1. Aggregate alerts by source, type, and node over the last 7 days
Tool: SN-Execute-Background-Script
Parameters:
  description: Weekly noise report
  script: |
    var ga = new GlideAggregate('em_alert');
    ga.addQuery('sys_created_on', '>=', gs.daysAgo(7));
    ga.addAggregate('COUNT');
    ga.groupBy('source');
    ga.groupBy('description');
    ga.orderByAggregate('COUNT', false);
    ga.setLimit(15);
    ga.query();

    gs.info('=== WEEKLY NOISE REPORT ===');
    gs.info('Top 15 recurring alert types (last 7 days):');
    var rank = 1;
    while (ga.next()) {
      gs.info(rank + '. Source: ' + ga.source +
        ' | Description: ' + ga.description +
        ' | Count: ' + ga.getAggregate('COUNT'));
      rank++;
    }

例 3：単一の CI のアラートを相関させる

# 1. Find all alerts for a specific CI
Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: ci=[ci_sys_id]^state!=Closed^ORDERBYDESCsys_created_on
  fields: sys_id,number,description,severity,state,source,sys_created_on
  limit: 20

# 2. Check metric correlations
Tool: SN-Query-Table
Parameters:
  table_name: em_alert_metric_correlation
  query: ci=[ci_sys_id]
  fields: alert,metric_name,correlation_strength

関連スキル

• itom/alert-investigation - 個々のアラートを詳細に調査します
• itom/service-mapping - アラートの背後にあるサービスの依存関係を把握します
• itom/health-log-analytics - 異常検知とログベースのアラート通知を行います
• itom/observability-integration - 外部監視ツールからアラートを取り込みます
• cmdb/impact-analysis - アラート対象の CI がビジネスに与える影響を評価します

参考資料

• ServiceNow Event Management
• アラート相関
• Event Management のベストプラクティス