跳到主要内容

降噪与路由模型

屏蔽规则、订阅、事件 Pipeline、通知规则不是并列的备选，而是按固定先后作用于事件；搞错顺序就会出现配了屏蔽仍收到告警。

夜莺有四种「对事件动手」的机制，它们不是并列的，作用的时机不同。 搞错顺序，就会出现「明明配了屏蔽还是收到告警」「Pipeline 改了标签但路由没跟着变」这类问题。

真实顺序​

规则判定出一个事件
        │
        ├─① 规则上挂的事件 Pipeline
        │     处理器按顺序执行，可以改标签、补充上下文，也可以直接丢弃事件
        │
        ├─② 屏蔽规则
        │     · 屏蔽事件与通知（默认）→ 事件根本不产生
        │     · 只屏蔽通知           → 事件照常产生和记录，只是不发
        │
        ├─③ 事件落库，订阅规则在这里把事件复制给别的团队
        │
        └─④ 逐条通知规则处理：
              ├─ 通知规则上挂的事件 Pipeline（又一次，和 ① 不是同一个）
              ├─ 按级别、标签、时段匹配
              └─ 选中媒介和消息模板，发送

两个容易踩的点：

  • Pipeline 在屏蔽之前跑。 所以 Pipeline 改写出来的标签，屏蔽规则是能匹配到的。
  • Pipeline 有两处入口：告警规则上挂一份，通知规则上还能挂一份。 前者影响所有下游，后者只影响这一条通知规则的这一次发送。

该用哪一个​

你想要的效果用什么
变更窗口内不要吵屏蔽规则，选「屏蔽事件与通知」
事件要留档，但这段时间别发屏蔽规则，选「只屏蔽通知」
某类事件根本不该存在规则上的 Pipeline，用丢弃处理器
给事件补上负责人、机房这类信息Pipeline 的标签富化处理器
另一个团队也想知道这类告警订阅规则
S1 打电话、S3 只进群通知规则里按级别配不同媒介
同一个故障别发一百条屏蔽规则，配合足够长的持续时长过滤毛刺

屏蔽的两种方式差别很大​

  • 屏蔽事件与通知（默认）：命中后事件根本不产生。好处是干净， 代价是这段时间的历史里查不到——事后复盘会缺一块。
  • 只屏蔽通知：事件照常产生、照常记录，只是不发出去，并且会打上标记。 想事后知道「屏蔽期间到底发生了什么」，用这个。

订阅不是转发​

订阅规则的语义是「我也想收到符合这些条件的事件」，由订阅方自己配、 自己决定走哪个媒介和级别过滤。规则的所有者不需要知道有谁订阅了它。

这和「在通知规则里多加一个接收人」是两回事：后者要改别人的规则，前者不用。

相关​

本页目录