AI 数据库告警收敛：减少噪声之前先保护根因信号

AI 数据库告警收敛：减少噪声之前先保护根因信号

一、告警少不等于系统健康

AI 告警收敛常被寄予厚望：把重复告警合并，把低价值告警降级，让值班的人少被打扰。但告警减少本身不是目标。如果收敛规则把根因信号吞掉，事故会更难查。数据库系统尤其如此，一个主从延迟、锁等待、IO 抖动可能同时引发几十条告警。

告警收敛要减少噪声，但不能损失根因线索。

二、先建指标拓扑

flowchart TD
  A[磁盘 IO] --> B[查询延迟]
  B --> C[连接堆积]
  D[锁等待] --> B
  E[主从延迟] --> F[读一致性风险]

指标之间有因果和关联关系。AI 收敛前要知道哪些指标是上游，哪些是下游。否则它可能把关键根因当成重复告警合并掉。

alert_topology:
  upstream:
    - disk_io_wait
    - lock_wait
    - replica_lag
  downstream:
    - query_latency
    - connection_queue

拓扑不是一次性配置，要从事故复盘中持续修订。

三、收敛要保留证据包

合并告警时，应保留原始告警列表、触发时间、指标曲线、实例范围和规则版本。值班同学看到一条聚合告警，也能展开看完整证据。

incident_package:
  grouped_alerts: required
  first_trigger_time: required
  affected_instances: required
  metric_snapshots: required
  rule_version: required

如果聚合只剩一句“数据库异常”，那不是智能，是把信息丢了。

四、避免过度静默

降噪最危险的是静默策略。某类告警在维护窗口可以降级，但不能永久隐藏。低频但高危的告警，例如数据不一致、备份失败、主从延迟超过恢复窗口，宁可吵一点，也不能静默。

silence_policy:
  require_expire_time: true
  forbid_silence:
    - backup_failed
    - data_inconsistency
    - replication_broken

还要评估收敛效果。减少了多少重复告警，是否缩短定位时间，是否漏报高危事件，都要用数据说话。

最后，AI 收敛结果要允许人工纠偏。值班人员标记“根因不是这个”后，系统应回收反馈，而不是下次继续犯同样错误。

收敛策略还要区分实例级、集群级和业务级。单实例磁盘抖动和整个集群写入拥塞，处理方式完全不同。AI 聚合时如果把范围混淆，值班人员会误判影响面。

alert_scope:
  instance: single_node
  cluster: multi_node_same_service
  business: user_visible_impact

告警标题也要保留最关键的判断：影响范围、疑似根因、当前风险和建议动作。标题写成“数据库异常聚合告警”，还不如原始告警有用。

最后，收敛规则上线前要用历史事故回放验证。拿真实事故的告警流测试，才能知道它会不会漏掉早期信号。

还要保留未收敛视图。聚合告警适合值班入口，原始告警适合深入排查。两者不是替代关系，而是不同粒度。事故中后期，工程师经常需要回到原始时间线确认因果顺序。

alert_views:
  grouped_for_oncall: true
  raw_timeline_for_debug: true
  switchable_in_incident: true

五、总结

AI 数据库告警收敛要依赖指标拓扑、证据包、静默边界和人工反馈。

减少噪声之前，先保护根因信号。安静不代表安全。