observability-integration

可観測性の統合

概要

このスキルでは、サードパーティの可観測性プラットフォームをServiceNow ITOM Event Managementと統合するための体系的な手法を提供します。以下の内容を扱います。

• Datadog、Dynatrace、New Relic用のイベント管理コネクターの設定
• ServiceNowの重要度および優先度の基準に合わせた受信アラートの正規化
• 外部メトリクスとServiceNowのメトリクス定義のマッピング
• ノイズを削減し、関連イベントをグループ化するアラート相関ルールの作成
• 外部監視からServiceNowアラートまでのエンドツーエンドのデータフローの検証
• 破損した統合や設定ミスのトラブルシューティング

使用する場面： 運用チームが、統合アラート管理、インシデント作成、サービス健全性ダッシュボードのために、複数の可観測性プラットフォームからの監視データをServiceNowに一元化する必要がある場合に使用します。

必要なプラグイン： com.snc.em（Event Management）

前提条件

• ロール： evt_mgmt_admin、evt_mgmt_integration、またはadmin
• アクセス権： em_event、em_alert、em_connector_instance、em_match_ruleへの読み取り／書き込み権限
• 知識： Event Managementの概念、コネクターのアーキテクチャ、対象となる可観測性プラットフォームのWebhook／API機能に関する知識
• プラグイン： com.snc.emが有効化されている必要があります。プル型コネクターではMID Serverを設定してください。
• 外部要件： Datadog、Dynatrace、またはNew RelicのAPIキーまたはWebhook認証情報

手順

ステップ1：既存のコネクターインスタンスを確認する

現在のイベント管理コネクターを一覧化し、すでに統合されているものを把握します。

MCPを使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: em_connector_instance
  query: active=true^ORDERBYname
  fields: sys_id,name,connector_type,status,last_run_time,last_run_status,mid_server,polling_interval
  limit: 50

REST APIを使用する場合：

GET /api/now/table/em_connector_instance?sysparm_query=active=true^ORDERBYname&sysparm_fields=sys_id,name,connector_type,status,last_run_time,last_run_status,mid_server,polling_interval&sysparm_display_value=true&sysparm_limit=50

ステップ2：利用可能なコネクタータイプを確認する

対象の可観測性プラットフォームでサポートされているコネクタータイプを特定します。

MCPを使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: em_connector_type
  query: active=true^nameLIKEdatadog^ORnameLIKEdynatrace^ORnameLIKEnew relic^ORnameLIKEgeneric
  fields: sys_id,name,description,connector_class,direction,protocol
  limit: 20

REST APIを使用する場合：

GET /api/now/table/em_connector_type?sysparm_query=active=true^nameLIKEdatadog^ORnameLIKEdynatrace^ORnameLIKEnew relic^ORnameLIKEgeneric&sysparm_fields=sys_id,name,description,connector_class,direction,protocol&sysparm_display_value=true&sysparm_limit=20

一般的なコネクタータイプ：

プラットフォーム	コネクタータイプ	方向	プロトコル
Datadog	Datadog Connector	プル	REST API
Datadog	Generic Webhook	プッシュ	Webhook
Dynatrace	Dynatrace Connector	プル	REST API
New Relic	New Relic Connector	プル	REST API
Generic	Generic REST Connector	プル／プッシュ	REST API

ステップ3：新しいコネクターインスタンスを設定する

対象の可観測性プラットフォーム用にコネクターインスタンスを作成します。

MCPを使用する場合（Datadogの例）：

Tool: SN-Create-Record
Parameters:
  table_name: em_connector_instance
  data:
    name: Datadog Production Alerts
    connector_type: [connector_type_sys_id]
    active: true
    polling_interval: 60
    mid_server: [mid_server_name]
    url: https://api.datadoghq.com/api/v1/monitor
    api_key: [datadog_api_key]
    application_key: [datadog_app_key]

REST APIを使用する場合：

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

{
  "name": "Datadog Production Alerts",
  "connector_type": "[connector_type_sys_id]",
  "active": "true",
  "polling_interval": "60",
  "mid_server": "[mid_server_name]",
  "url": "https://api.datadoghq.com/api/v1/monitor"
}

ステップ4：アラート正規化ルールを設定する

外部の重要度レベルをServiceNowのアラート重要度にマッピングします。

MCPを使用する場合：

Tool: SN-Execute-Background-Script
Parameters:
  description: Review and report on existing alert normalization mappings
  script: |
    gs.info('=== ALERT NORMALIZATION MAPPING ===');

    // Review existing match rules
    var mr = new GlideRecord('em_match_rule');
    mr.addQuery('active', true);
    mr.orderBy('order');
    mr.query();

    gs.info('\n--- Active Match Rules ---');
    while (mr.next()) {
      gs.info('Rule: ' + mr.name + ' | Order: ' + mr.order + ' | Source: ' + mr.source + ' | Severity Map: ' + mr.severity);
    }

    // Severity mapping reference
    gs.info('\n--- ServiceNow Severity Reference ---');
    gs.info('1 = Critical');
    gs.info('2 = Major');
    gs.info('3 = Minor');
    gs.info('4 = Warning');
    gs.info('5 = Info');
    gs.info('0 = Clear');

    // External platform mapping suggestions
    gs.info('\n--- Suggested Datadog Mappings ---');
    gs.info('Datadog "Alert" -> SN Severity 1 (Critical)');
    gs.info('Datadog "Warn"  -> SN Severity 3 (Minor)');
    gs.info('Datadog "No Data" -> SN Severity 4 (Warning)');
    gs.info('Datadog "OK"    -> SN Severity 0 (Clear)');

    gs.info('\n--- Suggested Dynatrace Mappings ---');
    gs.info('Dynatrace "AVAILABILITY" -> SN Severity 1 (Critical)');
    gs.info('Dynatrace "ERROR"        -> SN Severity 2 (Major)');
    gs.info('Dynatrace "SLOWDOWN"     -> SN Severity 3 (Minor)');
    gs.info('Dynatrace "RESOURCE"     -> SN Severity 4 (Warning)');
    gs.info('Dynatrace "CUSTOM"       -> SN Severity 5 (Info)');

    gs.info('\n--- Suggested New Relic Mappings ---');
    gs.info('New Relic "CRITICAL" -> SN Severity 1 (Critical)');
    gs.info('New Relic "WARNING"  -> SN Severity 3 (Minor)');
    gs.info('New Relic "NOT_CONFIGURED" -> SN Severity 5 (Info)');

ステップ5：受信イベントを検証する

外部プラットフォームからServiceNowにイベントが送信されていることを確認します。

MCPを使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: em_event
  query: source=Datadog^ORsource=Dynatrace^ORsource=New Relic^ORDERBYDESCtime_of_event
  fields: sys_id,source,node,type,resource,metric_name,severity,description,time_of_event,state
  limit: 25

REST APIを使用する場合：

GET /api/now/table/em_event?sysparm_query=source=Datadog^ORsource=Dynatrace^ORsource=New Relic^ORDERBYDESCtime_of_event&sysparm_fields=sys_id,source,node,type,resource,metric_name,severity,description,time_of_event,state&sysparm_display_value=true&sysparm_limit=25

ステップ6：生成されたアラートを確認する

取り込まれたイベントから作成されたアラートを確認し、CIとの関連付けを検証します。

MCPを使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: source=Datadog^ORsource=Dynatrace^ORsource=New Relic^state!=Closed^ORDERBYDESCsys_created_on
  fields: sys_id,number,source,node,ci,severity,state,description,group_source,acknowledged,sys_created_on
  limit: 25

REST APIを使用する場合：

GET /api/now/table/em_alert?sysparm_query=source=Datadog^ORsource=Dynatrace^ORsource=New Relic^state!=Closed^ORDERBYDESCsys_created_on&sysparm_fields=sys_id,number,source,node,ci,severity,state,description,group_source,acknowledged,sys_created_on&sysparm_display_value=true&sysparm_limit=25

ステップ7：CIとの関連付けの精度を分析する

アラートがCMDB CIに正しく関連付けられていることを確認します。

MCPを使用する場合：

Tool: SN-Execute-Background-Script
Parameters:
  description: Analyze CI binding rates for external observability alerts
  script: |
    gs.info('=== CI BINDING ANALYSIS ===');

    var sources = ['Datadog', 'Dynatrace', 'New Relic'];

    for (var i = 0; i < sources.length; i++) {
      var src = sources[i];

      var total = new GlideAggregate('em_alert');
      total.addQuery('source', src);
      total.addAggregate('COUNT');
      total.query();
      total.next();
      var totalCount = parseInt(total.getAggregate('COUNT'));

      if (totalCount === 0) continue;

      var bound = new GlideAggregate('em_alert');
      bound.addQuery('source', src);
      bound.addQuery('ci', '!=', '');
      bound.addAggregate('COUNT');
      bound.query();
      bound.next();
      var boundCount = parseInt(bound.getAggregate('COUNT'));

      var unbound = totalCount - boundCount;
      var rate = Math.round((boundCount / totalCount) * 100);

      gs.info(src + ': Total=' + totalCount + ' | Bound=' + boundCount + ' | Unbound=' + unbound + ' | Rate=' + rate + '%');

      // Show unbound alert nodes for troubleshooting
      if (unbound > 0) {
        var ub = new GlideRecord('em_alert');
        ub.addQuery('source', src);
        ub.addQuery('ci', '');
        ub.setLimit(5);
        ub.query();
        while (ub.next()) {
          gs.info('  Unbound: node=' + ub.node + ' | resource=' + ub.resource + ' | type=' + ub.type);
        }
      }
    }

ステップ8：メトリクスの取り込みを設定する

Health Log Analytics用に、外部メトリクスをServiceNowのメトリクス定義にマッピングします。

MCPを使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: sa_metric_definition
  query: active=true^ORDERBYname
  fields: sys_id,name,description,ci_type,metric_type,unit,source
  limit: 30

REST APIを使用する場合：

GET /api/now/table/sa_metric_definition?sysparm_query=active=true^ORDERBYname&sysparm_fields=sys_id,name,description,ci_type,metric_type,unit,source&sysparm_display_value=true&sysparm_limit=30

ツールの使用方法

MCPツールのリファレンス

ツール	使用する場面
SN-Query-Table	コネクター、イベント、アラート、照合ルールのクエリ
SN-Get-Record	特定のコネクターまたはアラートの詳細の取得
SN-Create-Record	新しいコネクターインスタンスまたは照合ルールの作成
SN-Update-Record	コネクター設定またはアラート状態の変更
SN-Execute-Background-Script	CI関連付けの分析、一括検証、正規化の確認
SN-Natural-Language-Search	「Datadogからの未関連付けアラート」などの自然言語によるクエリ

REST API リファレンス

エンドポイント	メソッド	目的
/api/now/table/em_connector_instance	GET/POST	コネクターインスタンスを管理します
/api/now/table/em_connector_type	GET	利用可能なコネクタータイプを一覧表示します
/api/now/table/em_event	GET	取り込まれた生イベントを表示します
/api/now/table/em_alert	GET	処理済みのアラートを表示します
/api/now/table/em_match_rule	GET/POST	アラート正規化ルールを管理します
/api/now/table/sa_metric_definition	GET	メトリック定義を表示します

ベストプラクティス

• 早期に正規化する： 本番環境でコネクターを有効にする前に、重大度と優先度のマッピングを設定し、アラートの大量発生を防ぎます
• CI にバインドする： 外部ホスト名が CMDB の CI 名に対応していることを確認します。命名規則を同期するには、ディスカバリーまたはインポートセットを使用します
• ソースの重複を排除する： 重複排除ルールなしで、同じリソースを複数のプラットフォームから監視しないようにします
• 本番前環境でテストする： 昇格する前に、本番前環境のインスタンスでコネクターの設定とアラート量を検証します
• ポーリング間隔を適切に設定する： データの鮮度と API レート制限のバランスを取ります。本番環境では通常 60～120 秒です
• コネクターの健全性を監視する： last_run_status を定期的に確認するスケジュールを設定し、気づかれにくい障害を検出します

トラブルシューティング

コネクターのステータスが「Error」と表示される

原因： 認証の失敗、API エンドポイントへの接続不可、または MID Server の接続性の問題です 解決策： API キーとエンドポイント URL を確認します。ネットワークエラーがないか MID Server のログを確認します。MID Server ホストから外部 API に直接接続してテストします。

イベントは取り込まれるが、アラートが作成されない

原因： イベント処理ルールまたはマッチルールが、受信したイベントのペイロードに一致していません 解決策： em_event レコードで生のペイロードを確認します。node、type、resource フィールドがマッチルールで想定される形式と一致していることを確認します。

アラートが CI にバインドされない

原因： 外部プラットフォームの node 値が、CMDB 内のいずれの CI の name、fqdn、ip_address とも一致していません 解決策： 外部ホスト名と CMDB の命名を調整するため、CI ルックアップルールまたは変換マップを作成します。カスタムバインドロジックには em_binding_rule テーブルを使用します。

アラート量が多い／アラートが大量発生する

原因： コネクターレベルのフィルタリングが不十分であるか、監視範囲が広すぎます 解決策： コネクター設定にフィルターを適用して、取り込むモニター／アラートを制限します。アラート管理ルールを使用して、価値の低いアラートを抑制します。

例

例 1：Datadog 統合のヘルスチェック

# 1. Check connector status
Tool: SN-Query-Table
Parameters:
  table_name: em_connector_instance
  query: nameLIKEDatadog
  fields: sys_id,name,status,last_run_time,last_run_status,polling_interval
  limit: 5

# 2. View recent Datadog events
Tool: SN-Query-Table
Parameters:
  table_name: em_event
  query: source=Datadog^ORDERBYDESCtime_of_event
  fields: source,node,type,severity,description,time_of_event
  limit: 10

# 3. View resulting alerts
Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: source=Datadog^state!=Closed^ORDERBYDESCsys_created_on
  fields: number,node,ci,severity,state,description
  limit: 10

例 2：重大度マッピングの監査

Tool: SN-Execute-Background-Script
Parameters:
  description: Audit severity distribution by source
  script: |
    var sources = ['Datadog', 'Dynatrace', 'New Relic'];
    for (var i = 0; i < sources.length; i++) {
      var ga = new GlideAggregate('em_alert');
      ga.addQuery('source', sources[i]);
      ga.addQuery('state', '!=', 'Closed');
      ga.addAggregate('COUNT');
      ga.groupBy('severity');
      ga.query();

      gs.info('=== ' + sources[i] + ' Alert Severity Distribution ===');
      while (ga.next()) {
        gs.info('Severity ' + ga.severity.getDisplayValue() + ': ' + ga.getAggregate('COUNT'));
      }
    }

例 3：プラットフォーム間のアラート比較

Tool: SN-Execute-Background-Script
Parameters:
  description: Compare alert volumes and CI binding across observability platforms
  script: |
    gs.info('=== CROSS-PLATFORM COMPARISON ===');
    var sources = ['Datadog', 'Dynatrace', 'New Relic'];
    for (var i = 0; i < sources.length; i++) {
      var ga = new GlideAggregate('em_alert');
      ga.addQuery('source', sources[i]);
      ga.addQuery('sys_created_on', '>=', gs.daysAgo(7));
      ga.addAggregate('COUNT');
      ga.query();
      ga.next();
      var count = ga.getAggregate('COUNT');
      gs.info(sources[i] + ' alerts (last 7 days): ' + count);
    }

関連スキル

• itom/alert-analysis - 任意のソースからのアラートを分析および管理します
• itom/service-mapping - 可観測性データをビジネスサービスにマッピングします
• itom/health-log-analytics - 取り込んだメトリックを異常検出に使用します
• cmdb/relationship-mapping - アラートのバインドに備えて CI が適切に表現されていることを確認します

参考資料

• ServiceNow Event Management
• コネクターの設定
• アラートの正規化