跳到主要内容

降噪模式

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

这页按症状组织：先认出你遇到的是哪一种噪声，再按对应的做法处理。 各机制的先后顺序在降噪与路由模型，这里只讲怎么用。

抖动：一会儿报一会儿恢复​

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

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

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

排查步骤见告警反复触发和恢复。

发布期间的告警风暴​

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

建一条屏蔽规则，关键是两个选择：

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

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

最省事的建法：故障发生时在活跃事件里打开一条， 点详情底部的屏蔽，标签已经预填好了。

一个故障，多条规则同时响​

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

  1. 先确认真的是一个故障。 在活跃告警上方选一条按机器聚合的规则 （{{.TagsMap.ident}}），如果几十条事件折成一张卡片，那就是同一台机器的派生告警， 见事件聚合与去重；

  2. 压制派生的那几条，留下根因那条。 用屏蔽规则按派生规则的标签屏掉， 或者在事件 Pipeline 里用事件丢弃处理器按规则名丢掉：

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

  3. 长期解法是分级。 根因规则给 S1、派生规则给 S3，然后在通知规则里让 S3 只进群、 不打电话，见条件路由。这样派生告警仍然留着供排查，但不叫醒人。

重复数据源导致的双份告警​

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

规则默认作用于「所有数据源」，迁移期间要显式锁定到一个数据源， 见按业务组与数据源划定范围。

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

什么根本不该叫醒人​

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

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

一条自查清单​

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

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

下一步​

本页目录