# 降噪模式

经得起生产考验的套路：抖动、发布期间的风暴、重复数据源，以及什么根本不该叫醒人。

最后校对于 2026-10-10

这页按症状组织：先认出你遇到的是哪一种噪声，再按对应的做法处理。 各机制的先后顺序在[降噪与路由模型](https://n9e.github.io/zh/docs/concepts/noise-routing.md)，这里只讲怎么用。

## 抖动：一会儿报一会儿恢复[​](#抖动一会儿报一会儿恢复 "抖动：一会儿报一会儿恢复的直接链接")

指标在阈值上下来回穿，一晚上几十条「触发—恢复—触发」。

**不要**上来就调阈值或建屏蔽——那是把症状盖住。按顺序做：

1. **加持续时长。** 让条件连续成立一段时间才算触发，这条挡掉绝大部分毛刺；
2. **把恢复条件写严。** 默认「查不到数据就恢复」在数据偶尔断点时会误判恢复， 改成「必须查到数据且不满足告警条件才恢复」，见[判定周期与恢复](https://n9e.github.io/zh/docs/alerting/evaluation.md)；
3. **在查询里平滑。** PromQL 用 `avg_over_time` 之类把瞬时抖动抹平，比在告警侧补救干净；
4. **调重复通知间隔。** 事件确实该报，只是不用每几分钟提醒一次。

排查步骤见[告警反复触发和恢复](https://n9e.github.io/zh/docs/troubleshooting/alert-flapping.md)。

## 发布期间的告警风暴[​](#发布期间的告警风暴 "发布期间的告警风暴的直接链接")

发版、重启、演练时，受影响的那批服务同时报警。

建一条[屏蔽规则](https://n9e.github.io/zh/docs/events/mute-rules.md)，关键是两个选择：

* **屏蔽方式选「只屏蔽通知」。** 事件照常产生和记录，只是不发。 这样发布结束后你还能翻出这段时间到底有没有异常——选「屏蔽事件与通知」的话， 这段历史是一个洞；
* **时间类型按性质选。** 一次性的发布窗口用固定时间，选个快捷时长就行； 每周固定的维护窗口用周期时间，一次配好长期有效。

范围尽量用**标签**收窄（`env=prod`、`service=order`），别只填业务组—— 屏蔽规则的界面会专门提示你「没配数据源和事件标签会屏蔽整个业务组」。

最省事的建法：故障发生时在[活跃事件](https://n9e.github.io/zh/docs/events/active-historical.md)里打开一条， 点详情底部的**屏蔽**，标签已经预填好了。

## 一个故障，多条规则同时响[​](#一个故障多条规则同时响 "一个故障，多条规则�同时响的直接链接")

一台机器宕机，主机失联、进程不在、端口不通、上游超时四条规则一起响。

1. **先确认真的是一个故障。** 在活跃告警上方选一条按机器聚合的规则 （`{{.TagsMap.ident}}`），如果几十条事件折成一张卡片，那就是同一台机器的派生告警， 见[事件聚合与去重](https://n9e.github.io/zh/docs/events/aggregation.md)；

2. **压制派生的那几条，留下根因那条。** 用屏蔽规则按派生规则的标签屏掉， 或者在[事件 Pipeline](https://n9e.github.io/zh/docs/events/pipelines.md) 里用事件丢弃处理器按规则名丢掉：

   ```
   {{ if eq $event.RuleName "Port unreachable" }}true{{ end }}
   ```

3. **长期解法是分级。** 根因规则给 S1、派生规则给 S3，然后在通知规则里让 S3 只进群、 不打电话，见[条件路由](https://n9e.github.io/zh/docs/events/routing.md)。这样派生告警仍然留着供排查，但不叫醒人。

## 重复数据源导致的双份告警[​](#重复数据源导致的双份告警 "重复数据源导致的双份告警的直接链接")

同一份数据同时写进了两套时序库（比如迁移期间新旧并存），一条规则没锁数据源， 两边都查一遍，于是同一个问题出两条事件——标签一样、数据源不同。

规则默认作用于「所有数据源」，迁移期间要**显式锁定到一个数据源**， 见[按业务组与数据源划定范围](https://n9e.github.io/zh/docs/alerting/scope.md)。

判断方法：在活跃告警左侧按**数据源**筛一遍，如果两个数据源下各有一条一模一样的事件， 就是这个问题。

## 什么根本不该叫醒人[​](#什么根本不该叫醒人 "什么根本不该叫醒人的直接链接")

一条经验：**能等到明早的，就不该有电话渠道。**

* **S3 / Info 级别**：只进群或只发邮件。在通知规则里给电话那条通知配置的「适用级别」 只勾 S1，见[条件路由](https://n9e.github.io/zh/docs/events/routing.md)；
* **恢复通知**：给电话那条配置的「适用属性」排掉恢复事件，或者干脆在规则上关掉「通知恢复」；
* **非生产环境**：`env=dev` 的事件在工作流里直接丢掉，或者建一条长期的周期屏蔽；
* **没有处置动作的告警**：如果收到之后你什么都不做，这条规则该删或者该降级—— 规则该怎么选见[规则设计实践](https://n9e.github.io/zh/docs/alerting/best-practices.md)。

## 一条自查清单[​](#一条自查清单 "一条自查清单的直接链接")

值班群一天超过 20 条告警时，按这个顺序过一遍：

1. 打开活跃告警，按 `{{.RuleName}}` 聚合，找出刷屏最多的那两三条规则；
2. 对每条问：**收到它之后我做了什么？** 什么都没做的，降级或删掉；
3. 有动作但动作是固定的：写成[自愈脚本](https://n9e.github.io/zh/docs/events/self-healing.md)，让它自己跑；
4. 有动作但只在工作时间做：给它加时段限制，夜里不发；
5. 剩下真正需要人的，确认它是 S1，并且电话渠道只有这一类；
6. 一周后再看一次，确认没被新规则冲掉。

## 下一步[​](#下一步 "下一步的直接链接")

* 各机制作用的先后：[降噪与路由模型](https://n9e.github.io/zh/docs/concepts/noise-routing.md)
* 具体配屏蔽：[屏蔽规则](https://n9e.github.io/zh/docs/events/mute-rules.md)
* 具体配丢弃和富化：[事件 Pipeline](https://n9e.github.io/zh/docs/events/pipelines.md)
* 通知发到了不该发的人：[通知发到了错误的人](https://n9e.github.io/zh/docs/troubleshooting/wrong-routing.md)