你是不是也遇过，半夜被告警钉钉群炸醒，点进去一看，同一条「节点CPU过高」的告警，阿里云发了一条，自己搭的Prometheus也发了一条，然后下面还有「Pod内存超了」的20条，数都数不过来？这就是双监控同时上报指标导致的告警风暴，噪音大到根本没法处理。本文就聊怎么用静默规则和聚合分组把这些噪音收住，不管你是刚接触监控的新手还是老运维，都能照着做。

一、问题起源：双监控上报的告警噪音爆发

1.1 噪音的典型场景

很多公司会这么玩：把业务放在阿里云的K8s集群上，阿里云会自带agent抓节点、Pod、容器的基础指标；同时自己团队又搭了一套Prometheus，加了业务自定义的指标（比如订单处理时长、支付成功率），两边都给告警设了阈值。结果就是：同一个节点的CPU使用率超过90%，阿里云云监控发一条，Prometheus的Node Exporter也发一条；当集群里20个Pod的内存都超了阈值，阿里云的agent会每条Pod发一条告警，Prometheus也跟着发20条，一天下来几百上千条，真正需要处理的问题反而被淹没。

1.2 噪音的核心原因

一是「重复上报」：同一指标被两套监控同时采集，阈值又差不多，异常时就会重复告警；二是「批量告警无聚合」：同类型的批量指标没有合并，比如多个Pod挂了，不分组就会出N条重复类告警。

二、核心解决方案：静默规则+聚合分组

要收这种告警噪音，核心就是两个动作：精准删掉重复的特定告警，把批量的同类告警合并成一条，不会乱炸。这里我们用Prometheus Alertmanager做统一处理（所有示例基于这个技术栈，避免混用），它正好能同时管理Prometheus自身的告警，也能同步阿里云云监控的告警。

2.1 静默规则：精准屏蔽重复的特定告警

静默规则就像「定向拉黑」，只屏蔽你指定来源/类型的告警，不会误杀其他重要告警。比如我们要屏蔽阿里云节点监控发的重复CPU告警，保留自建Prometheus的同类型告警，操作步骤很简单： 技术栈：Prometheus Alertmanager v0.25+

# 用官方工具amtool创建静默规则，有效期24小时
amtool silence add \
  --comment "屏蔽阿里云节点监控重复上报的CPU过高告警，保留自建Prometheus同指标告警" \
  --duration 24h \
  --match "alertname=HighNodeCPU,job=node-exporter,instance=~aliyun-.*"

注释：

  • alertname=HighNodeCPU：指定要屏蔽的告警名（两边重复的都是这个名）
  • instance=~aliyun-.*：匹配阿里云监控的实例标识（所有阿里云的实例名都是aliyun开头的）
  • 这样设置后，只有阿里云来源的这个CPU告警会被静默，自建的就不会受影响。

2.2 聚合分组：把批量同类告警合并成一条

聚合分组就像「把相同问题打包发」，比如同一个节点上的10个Pod都内存超了，会合并成一条：「节点XX上有10个Pod内存过高」，不会发10条。配置是在Alertmanager的路由里加分组维度： 技术栈：Prometheus Alertmanager v0.25+

# Alertmanager的路由配置片段，用于聚合批量告警
route:
  group_by: ['cluster', 'node', 'alertname'] # 按集群、节点、告警名分组，同一维度的合并
  group_wait: 30s # 新告警出来后，等30秒再合并，避免刚出现就发
  group_interval: 5m # 同一组内的告警，两次通知间隔5分钟，不会频繁炸
  repeat_interval: 1h # 问题没解决的话，每1小时发一次提醒，不会一直弹
  receiver: '企业微信告警群' # 通知渠道
  routes:
    # 过滤节点相关告警，直接用上面的分组
    - match: {alertname: ".*Node.*"}
      continue: false
    # 过滤Pod相关告警，用同样的分组规则
    - match: {alertname: ".*Pod.*"}
      continue: false

注释：group_by选的维度是关键，选「集群」「节点」「告警名」就能把同一个节点的同一类告警合并，要是选没用的标签（比如告警创建时间），就合并不了。

三、实际落地的完整示例：解决双监控的告警问题

现在我们把两个方案结合，从找重复告警到配置，一步一步来：

  1. 先找重复告警的标签：先查活跃告警，看哪些是重复的，用Prometheus的API：
# 查询所有活跃告警，提取关键标签，技术栈：Prometheus v2.47+
curl -s http://prometheus:9090/api/v1/alerts | jq '.data.alerts[] | {告警名:.labels.alertname,来源:.labels.job,实例:.labels.instance}'

注释：执行后会看到类似两条「HighNodeCPU」的记录，一条job是aliyun-node-exporter（阿里云的），一条是self-node-exporter（自建的），这就是重复的。 2. 屏蔽阿里云的重复告警：用之前的amtool命令，把阿里云的这条告警静默24小时； 3. 配置聚合分组：把Alertmanager的路由按cluster、node、alertname分组，这样自建Prometheus的Pod批量告警会合并。 4. 测试效果：故意让两个Pod内存超阈值，会收到一条合并后的告警，不是两条；阿里云的同类告警也不会再发。

四、技术优缺点分析

4.1 静默规则的优缺点

优点：精准，只屏蔽特定来源/类型的告警，不会影响其他告警；可以设有效期，比如双监控同步的临时期过了就删掉，不用长期维护。 缺点：如果匹配条件写得太粗（比如只凭alertname），可能误杀其他正常告警；如果要屏蔽多个来源的重复告警，要写多条静默，维护量会上升。

4.2 聚合分组的优缺点

优点：大幅减少告警数量，把几百条炸成几条，运维能快速看核心问题；可以控制通知频率，避免晚上被反复弹消息。 缺点：合并后看不到具体的单个实例，比如合并成「节点X有3个Pod挂了」，要查具体Pod得点进告警详情；如果分组维度不对，会把不相关的告警合并，反而更乱。

五、注意事项

  1. 静默规则的匹配条件一定要精准，用唯一标签（比如job和instance），不要只靠告警名，不然会误杀其他实例的同类型告警；
  2. 聚合分组的维度要选有用的，优先选集群、节点、服务名，不要选临时的标签（比如告警的创建时间）；
  3. 定期清理过期的静默规则，比如阿里云同步告警的测试结束后，就删掉对应的静默，避免长期屏蔽；
  4. 双监控同步告警时，要统一标签映射，比如阿里云的来源标签和Prometheus的job标签对应上，方便匹配静默和分组；
  5. 不要过度合并，比如把业务错误和系统错误合并成一条，会掩盖真正的业务问题。

六、总结

双监控同时上报指标确实容易炸出告警风暴，但只要用「静默规则精准删重复」+「聚合分组合批量」，就能把噪音降到可控范围。核心是先理清告警的重复源和批量类型，再对应设置，不能瞎配。毕竟运维要的是精准的重要告警，不是满屏的垃圾消息。