health-log-analytics

ヘルスログ分析

概要

このスキルでは、ServiceNow ITOM におけるヘルスログ分析（HLA）の管理方法を体系的に説明します。以下の内容を扱います。

• メトリクスの収集とログの取り込みに使用するログソースの設定
• 予防的なアラート通知に向けたメトリクスしきい値の定義と調整
• 機械学習に基づくベースラインを使用した、CI のパフォーマンスパターンの異常検出
• 過去のメトリクストレンドに基づくキャパシティプランニング分析の実施
• インフラストラクチャとサービスのパフォーマンストレンドレポートの作成
• しきい値ポリシーとアラート抑制ルールの管理

使用する場面： 運用チームがインフラストラクチャの健全性を予防的に監視する場合、サービスに影響が及ぶ前にパフォーマンスの低下を検出する場合、キャパシティのニーズを計画する場合、または不要なアラートを減らすためにアラートのしきい値を調整する場合に使用します。

必要なプラグイン： com.snc.sa.health-log-analytics

前提条件

• ロール： sa_admin、evt_mgmt_admin、または itil
• アクセス権： sa_metric_definition、sa_threshold、sa_anomaly、sa_log_source、em_alert に対する読み取り／書き込み権限
• 知識： ITOM のメトリクスタイプ、時系列データの概念、CI のパフォーマンスベースラインに関する知識
• プラグイン： com.snc.sa.health-log-analytics と com.snc.em が有効化されていること
• データ： 監視対象の CI からメトリクスを収集する MID Server、またはメトリクスデータを取り込むオブザーバビリティプラットフォームコネクタ

手順

ステップ 1：設定済みのログソースを確認する

有効なログソースを一覧にして、現在のデータ収集範囲を把握します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sa_log_source
  query: active=true^ORDERBYname
  fields: sys_id,name,type,source_type,ci,status,last_collection_time,collection_interval,mid_server
  limit: 50

REST API を使用：

GET /api/now/table/sa_log_source?sysparm_query=active=true^ORDERBYname&sysparm_fields=sys_id,name,type,source_type,ci,status,last_collection_time,collection_interval,mid_server&sysparm_display_value=true&sysparm_limit=50

ログソースのタイプ：

タイプ	説明
Agent	ホストからデータを収集する ServiceNow エージェント
SNMP	ネットワークデバイスからの SNMP ポーリング
WMI	Windows Management Instrumentation
SSH	SSH 経由のスクリプトベースの収集
REST	外部 API からの取得
Syslog	プッシュ型の syslog レシーバー

ステップ 2：メトリクス定義を確認する

追跡対象のメトリクスとその設定を確認します。

MCP を使用：

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

REST API を使用：

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

一般的なメトリクスタイプ：

メトリクス	CI タイプ	単位	一般的なしきい値
CPU 使用率	cmdb_ci_server	パーセント	警告：80%、重大：95%
メモリ使用量	cmdb_ci_server	パーセント	警告：85%、重大：95%
ディスク使用量	cmdb_ci_server	パーセント	警告：80%、重大：90%
ネットワーク遅延	cmdb_ci_netgear	ms	警告：100ms、重大：500ms
応答時間	cmdb_ci_service	ms	警告：2000ms、重大：5000ms

ステップ 3：しきい値を管理する

予防的なアラート通知に向けて、メトリクスのしきい値を確認して設定します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sa_threshold
  query: active=true^ORDERBYmetric_definition.name
  fields: sys_id,name,metric_definition,ci,ci_type,warning_value,critical_value,operator,duration,active
  limit: 50

REST API を使用：

GET /api/now/table/sa_threshold?sysparm_query=active=true^ORDERBYmetric_definition.name&sysparm_fields=sys_id,name,metric_definition,ci,ci_type,warning_value,critical_value,operator,duration,active&sysparm_display_value=true&sysparm_limit=50

新しいしきい値を作成する：

Tool: SN-Create-Record
Parameters:
  table_name: sa_threshold
  data:
    name: High CPU Alert - Production Servers
    metric_definition: [metric_def_sys_id]
    ci_type: cmdb_ci_server
    warning_value: 80
    critical_value: 95
    operator: ">="
    duration: 300
    active: true

ステップ 4：異常を検出する

検出された異常を照会して、予期しないパフォーマンスパターンを特定します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sa_anomaly
  query: state=active^ORDERBYDESCdetection_time
  fields: sys_id,ci,metric_definition,severity,state,detection_time,expected_value,actual_value,deviation,description
  limit: 30

REST API を使用：

GET /api/now/table/sa_anomaly?sysparm_query=state=active^ORDERBYDESCdetection_time&sysparm_fields=sys_id,ci,metric_definition,severity,state,detection_time,expected_value,actual_value,deviation,description&sysparm_display_value=true&sysparm_limit=30

ステップ 5：キャパシティプランニング分析

過去のメトリクストレンドを分析して、キャパシティのニーズを予測します。

MCP を使用：

Tool: SN-Execute-Background-Script
Parameters:
  description: Analyze capacity trends for servers approaching resource limits
  script: |
    gs.info('=== CAPACITY PLANNING ANALYSIS ===');

    // Find CIs with recent high-utilization alerts
    var ga = new GlideAggregate('em_alert');
    ga.addQuery('source', 'Health Log Analytics');
    ga.addQuery('severity', '<=', '2'); // Critical or Major
    ga.addQuery('sys_created_on', '>=', gs.daysAgo(30));
    ga.addAggregate('COUNT');
    ga.groupBy('ci');
    ga.orderByAggregate('COUNT', 'DESC');
    ga.setLimit(20);
    ga.query();

    gs.info('\n--- CIs with Most HLA Alerts (Last 30 Days) ---');
    while (ga.next()) {
      var ciId = ga.ci.toString();
      var count = ga.getAggregate('COUNT');
      var ci = new GlideRecord('cmdb_ci');
      if (ci.get(ciId)) {
        gs.info('CI: ' + ci.name + ' (' + ci.sys_class_name + ') | Alerts: ' + count + ' | Status: ' + ci.operational_status.getDisplayValue());
      }
    }

    // Identify anomalies with upward trends (capacity risk)
    gs.info('\n--- Active Anomalies Indicating Growth ---');
    var anomaly = new GlideRecord('sa_anomaly');
    anomaly.addQuery('state', 'active');
    anomaly.addQuery('actual_value', '>', 'expected_value');
    anomaly.orderByDesc('deviation');
    anomaly.setLimit(15);
    anomaly.query();

    while (anomaly.next()) {
      gs.info('CI: ' + anomaly.ci.getDisplayValue() + ' | Metric: ' + anomaly.metric_definition.getDisplayValue() + ' | Expected: ' + anomaly.expected_value + ' | Actual: ' + anomaly.actual_value + ' | Deviation: ' + anomaly.deviation + '%');
    }

ステップ 6：パフォーマンストレンドレポート

重要なインフラストラクチャのパフォーマンス概要を生成します。

MCP を使用：

Tool: SN-Execute-Background-Script
Parameters:
  description: Generate performance trending summary for critical services
  script: |
    gs.info('=== PERFORMANCE TRENDING REPORT ===');

    // Alerts by severity over time
    gs.info('\n--- Alert Trend (Last 7 Days) ---');
    for (var d = 6; d >= 0; d--) {
      var dayStart = gs.daysAgo(d + 1);
      var dayEnd = gs.daysAgo(d);

      var ga = new GlideAggregate('em_alert');
      ga.addQuery('source', 'Health Log Analytics');
      ga.addQuery('sys_created_on', '>=', dayStart);
      ga.addQuery('sys_created_on', '<', dayEnd);
      ga.addAggregate('COUNT');
      ga.query();
      ga.next();
      var count = ga.getAggregate('COUNT');

      var dt = new GlideDateTime(dayStart);
      gs.info(dt.getDate().getByFormat('yyyy-MM-dd') + ': ' + count + ' alerts');
    }

    // Top alerting CIs
    gs.info('\n--- Top 10 Alerting CIs (Last 7 Days) ---');
    var topCI = new GlideAggregate('em_alert');
    topCI.addQuery('source', 'Health Log Analytics');
    topCI.addQuery('sys_created_on', '>=', gs.daysAgo(7));
    topCI.addAggregate('COUNT');
    topCI.groupBy('ci');
    topCI.orderByAggregate('COUNT', 'DESC');
    topCI.setLimit(10);
    topCI.query();

    while (topCI.next()) {
      gs.info('CI: ' + topCI.ci.getDisplayValue() + ' | Alerts: ' + topCI.getAggregate('COUNT'));
    }

    // Threshold breach distribution
    gs.info('\n--- Threshold Breaches by Metric ---');
    var thr = new GlideAggregate('em_alert');
    thr.addQuery('source', 'Health Log Analytics');
    thr.addQuery('sys_created_on', '>=', gs.daysAgo(7));
    thr.addAggregate('COUNT');
    thr.groupBy('metric_name');
    thr.orderByAggregate('COUNT', 'DESC');
    thr.setLimit(10);
    thr.query();

    while (thr.next()) {
      gs.info('Metric: ' + thr.metric_name + ' | Breaches: ' + thr.getAggregate('COUNT'));
    }

ステップ 7：しきい値ポリシーを調整する

トレンドデータに基づいてしきい値を調整し、誤検知を減らします。

MCP を使用：

Tool: SN-Update-Record
Parameters:
  table_name: sa_threshold
  sys_id: [threshold_sys_id]
  data:
    warning_value: 85
    critical_value: 97
    duration: 600

REST API を使用：

PATCH /api/now/table/sa_threshold/[threshold_sys_id]
Content-Type: application/json

{
  "warning_value": "85",
  "critical_value": "97",
  "duration": "600"
}

ツールの使用

MCP ツールリファレンス

ツール	使用する場面
SN-Query-Table	ログソース、メトリクス、しきい値、異常、アラートをクエリする
SN-Get-Record	特定のメトリクス定義またはしきい値の詳細を取得する
SN-Create-Record	新しいしきい値、ログソース、またはメトリクス定義を作成する
SN-Update-Record	しきい値を調整する、またはログソースの設定を更新する
SN-Execute-Background-Script	キャパシティ分析、傾向レポート、一括検証を行う
SN-Natural-Language-Search	「CPU に異常があるサーバー」のような自然言語クエリを実行する

REST API リファレンス

エンドポイント	メソッド	目的
/api/now/table/sa_log_source	GET/POST	ログソースを管理する
/api/now/table/sa_metric_definition	GET	メトリクス定義を表示する
/api/now/table/sa_threshold	GET/POST/PATCH	しきい値を管理する
/api/now/table/sa_anomaly	GET	検出された異常を表示する
/api/now/table/em_alert	GET	HLA が生成したアラートを表示する

ベストプラクティス

• アラート設定前にベースラインを確立する： 厳しいしきい値を設定する前に、HLA がベースラインデータを2～4週間分蓄積できるようにします
• 継続時間を設定する： 一時的な急増でアラートが発生しないよう、しきい値の継続時間を5～10分に設定します
• しきい値を段階的に設定する： 重大な影響が発生する前に早期警告を提供できるよう、警告用と重大用のしきい値を作成します
• 異常を毎週確認する： 異常検出を毎週確認する予定を設定し、新たなキャパシティ傾向を特定します
• 変更と関連付ける： 異常検出を最近の変更リクエストと照合し、想定内の動作と想定外の動作を区別します
• 反復的に調整する： 保守的なしきい値から始め、運用経験に基づいて厳しくしていきます

トラブルシューティング

メトリクスが収集されない

原因： ログソースが有効でない、MID Server がオフライン、または認証情報が無効です 解決策： sa_log_source.status を確認してエラーがないか調べます。MID Server の接続を確認します。MID Server ホストから認証情報をテストします。

誤検知された異常

原因： ベースラインデータが不十分、または定期メンテナンスが除外されていません 解決策： ベースラインの学習期間を延長します。既知の定期アクティビティを異常検出から除外するよう、メンテナンス時間帯を設定します。

しきい値アラートが発生しない

原因： しきい値が正しいメトリクス定義または CI タイプに関連付けられていない、あるいは継続時間が長すぎます 解決策： しきい値の metric_definition 参照を確認します。ci_type が監視対象の CI と一致していることを確認します。急増が短時間の場合は、継続時間を短くします。

HLA ダッシュボードに古いデータが表示される

原因： 収集間隔が長すぎる、またはログソースのポーリングが停止しています 解決策： sa_log_source.last_collection_time を確認します。収集スケジュールが有効であることを確認します。MID Server のログを調べて収集エラーがないか確認します。

例

例 1：サーバーのキャパシティ確認

# 1. Find servers with high-severity anomalies
Tool: SN-Query-Table
Parameters:
  table_name: sa_anomaly
  query: state=active^ci.sys_class_name=cmdb_ci_server^severity<=2
  fields: ci,metric_definition,severity,actual_value,expected_value,deviation,detection_time
  limit: 20

# 2. Check threshold configuration for those servers
Tool: SN-Query-Table
Parameters:
  table_name: sa_threshold
  query: ci_type=cmdb_ci_server^active=true
  fields: name,metric_definition,warning_value,critical_value,duration
  limit: 20

例 2：ログソースの健全性チェック

Tool: SN-Execute-Background-Script
Parameters:
  description: Check log source collection health
  script: |
    var ga = new GlideAggregate('sa_log_source');
    ga.addQuery('active', true);
    ga.addAggregate('COUNT');
    ga.groupBy('status');
    ga.query();

    gs.info('=== LOG SOURCE STATUS SUMMARY ===');
    while (ga.next()) {
      gs.info('Status: ' + ga.status.getDisplayValue() + ' | Count: ' + ga.getAggregate('COUNT'));
    }

    // Find stale log sources (no collection in 24 hours)
    gs.info('\n--- Stale Log Sources ---');
    var stale = new GlideRecord('sa_log_source');
    stale.addQuery('active', true);
    stale.addQuery('last_collection_time', '<', gs.daysAgo(1));
    stale.query();
    while (stale.next()) {
      gs.info('Source: ' + stale.name + ' | Last Collected: ' + stale.last_collection_time + ' | CI: ' + stale.ci.getDisplayValue());
    }

例 3：週次パフォーマンス概要

Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: severity=1^source=Health Log Analytics^sys_created_on>=javascript:gs.daysAgoStart(7)
  fields: number,ci,severity,metric_name,description,sys_created_on
  limit: 25

関連スキル

• itom/observability-integration - 外部メトリクスを HLA に取り込む
• itom/alert-analysis - HLA が生成したアラートを分析する
• itom/service-mapping - HLA データをサービスのトポロジーと関連付ける
• reporting/trend-analysis - HLA のメトリクスデータからレポートを作成する

参考資料

• ServiceNow Health Log Analytics
• メトリクス定義
• 異常検出