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	严重	需要立即采取行动
2	重大	出现明显性能下降
3	轻微	影响有限，需密切监控
4	警告	可能正在出现问题
5	信息	仅供参考，无需采取行动
0	已清除	先前触发的警报现已清除

步骤 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
• 警报关联
• 事件管理最佳实践