> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 抑制

> 有更严重或更上游的事件时，压住次要事件的通知，只通知该看的那一个。

数据库挂了，依赖它的十个服务都在报错。这时值班的人只需要知道数据库的事，其余的告警只会把他的手机打爆。抑制规则说的就是这件事：**符合「源」条件的事件在时，符合「目标」条件、指定标签取值相同的事件，通知压着。**

被压住的事件照常开启和记录，页面上看得见，只是通知不发、升级不往下走。源事件恢复后，目标事件还开着的就照常通知。

打开 **告警 → 抑制**。查看需要 `alerts.inhibitions.read`，新建、修改和删除需要 `alerts.inhibitions.manage`。

## 抑制和静默的区别

| | 静默 | 抑制 |
| - | - | - |
| 什么时候生效 | 到了设定的时间窗 | 有符合条件的事件正在进行 |
| 适合 | 计划内的维护、已知的噪声 | 一个故障带出的一连串告警 |
| 谁决定压什么 | 人提前写好时间 | 系统按此刻进行中的事件判断 |

两者都只压通知和升级，都不影响事件本身、[状态页](https://docs.molesignal.com/zh-Hans/status-pages)和[工单](https://docs.molesignal.com/zh-Hans/alerting/tickets.md)。

## 新建规则

点击 **新建抑制规则**：

| 设置 | 说明 |
| - | - |
| **名称**、**启用** | 关闭的规则不压任何事件。 |
| 源事件的 **严重度不低于**、标签条件 | 哪些事件能压别的。空着不限，但这时必须写 **这些标签要相同**。 |
| 目标事件的 **严重度不高于**、标签条件 | 哪些事件会被压。空着是所有事件。 |
| **这些标签要相同** | 逗号分隔。两边都要有这个标签、取值相同才压，缺了算不同。空着不看标签，这时必须写清源事件的条件：否则任何事件都能压住所有别的事件。 |
| **源事件要比目标事件严重** | 默认打开：源事件必须严格比目标事件严重，所以一条规则就能写出「同一个服务上，严重的压住次要的」。上下游依赖（数据库压业务）可以关掉。 |
| **目标事件先等（秒）** | 默认 60 秒，最短 15 秒，最长 600 秒。见[时间上的两个缓冲](#时间上的两个缓冲)。 |
| **源事件恢复后再压（秒）** | 默认 120 秒，最长 3600 秒。 |

标签条件的写法和[静默策略](https://docs.molesignal.com/zh-Hans/alerting/silences.md)一样，所有条件都要命中，`=~` 与 `!~` 是整串匹配的正则表达式。除了事件的标签，还认这三个：

* `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`，记进时间线和审计日志。
* **时间线**：开始被压、抑制结束（源事件恢复、规则改了或删了、有人放开）各记一条。
* **规则列表**：一条规则的事件都被压着时，状态是 **触发中（已抑制）**。
* **抑制页**：每条规则写明此刻压着几个事件。删除这样的规则时，确认框写明它们会马上通知。

立即升级、转派、增派也算人要叫人，这个事件顺带放开。

## 多个集群

抑制规则随[跨集群联邦](https://docs.molesignal.com/zh-Hans/settings/data-plane.md#跨集群联邦)同步，各集群按自己的事件判定：一个集群的事件不会压住另一个集群的事件。

## 抑制 API

| 操作 | 端点 |
| - | - |
| 管理抑制规则 | [`/api/v1/alerts/inhibit-rules`](https://docs.molesignal.com/zh-Hans/api/alerting/inhibit-rules) |
| 预览一条规则 | [`POST /api/v1/alerts/inhibit-rules/preview`](https://docs.molesignal.com/zh-Hans/api/alerting/inhibit-rules#预览) |
| 放开一个事件 | [`POST /api/v1/alerts/incidents/{id}/inhibition/lift`](https://docs.molesignal.com/zh-Hans/api/alerting/inhibit-rules#放开一个事件) |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.