alerts.inhibitions.read，新建、修改和删除需要 alerts.inhibitions.manage。
抑制和静默的区别
两者都只压通知和升级，都不影响事件本身、状态页和工单。
新建规则
点击 新建抑制规则：
标签条件的写法和静默策略一样，所有条件都要命中，
=~ 与 !~ 是整串匹配的正则表达式。除了事件的标签，还认这三个：
service、host：事件没带这个标签时，取它受影响的服务、主机；alert.rule_id：开事件的规则或告警来源的 ID，可以写「规则 A 压住规则 B」。
常见的写法
同一个服务上，严重的压住次要的。 这是新建规则的默认样子：- 这些标签要相同：
service - 源事件要比目标事件严重：打开
- 源事件的标签条件：
service=database - 目标事件的标签条件：
tier=api - 这些标签要相同：
region（只压同一个地域的） - 源事件要比目标事件严重：关闭
怎么判断
抑制由升级派发每一轮（默认 10 秒）判定，结果写在事件上。为了保证被压住的事件，上游总有一个真的会通知人的事件，判定时：- 被静默的事件不当源。 它自己没人收到，再压别的就谁都收不到了。
- 已确认的事件照样当源。 有人在处理了。
- 并入别的事件的事件两边都不算。
- 有人手动开的事件不会被压，但可以压别的。
- 压可以串起来。 A 压 B、B 压 C 时，B 和 C 都不通知，由 A 通知。
- 互相压的事件留下一个。 两条规则写成了 A 压 B、B 压 A 时，严重的（一样严重时先开的）照常通知。
时间上的两个缓冲
目标事件先等。 症状常常比根因先报出来：业务的错误率先过线，数据库那条规则下一轮才评估。可能被压的事件开启时，它的通知先等 目标事件先等 这么久，这期间源事件来了就压住，没来就照常通知。设成 0 也会等 15 秒：抑制由下一轮派发判定，第一条通知不能抢在它前面。 只有可能被压的事件才等：more_severe_only 打开时最严重的事件不等，缺 这些标签要相同 里的标签的事件不等。
源事件恢复后再压。 根因恢复时症状也快好了，不必再叫一遍人。源事件恢复后，目标事件还压这么久；期间又有源事件来了就接着压。到点还开着的事件，压着的通知才发出。
通知怎么处理
在页面上看
- 事件列表：被压的事件在摘要行写 已抑制；列表多一个 已抑制 视图，只在有被压的事件时出现。
- 事件详情：写明因为哪个事件、哪条规则压着，源事件的名字可以点开。还在等的事件写明等到什么时候。旁边的 照常通知 放开这个事件：压着的通知马上发出，之后不再被抑制。放开要
alerts.incidents.update，记进时间线和审计日志。 - 时间线：开始被压、抑制结束（源事件恢复、规则改了或删了、有人放开）各记一条。
- 规则列表：一条规则的事件都被压着时，状态是 触发中（已抑制）。
- 抑制页：每条规则写明此刻压着几个事件。删除这样的规则时，确认框写明它们会马上通知。