# 查询有结果，为什么告警不触发？

查询有数据却不触发，答案九成在判定记录里：持续时长未满、datasource\_queries 选错、时间段或业务组不符、规则被禁用或被屏蔽。

最后校对于 2026-10-10

在即时查询里把规则的表达式贴进去，数据明明白白超了阈值，规则页面上却一条事件都没有。 这页给的不是「可能是 A 可能是 B」的清单，而是一条从判定记录往回读的路径。

紧急程度：单条规则不触发只影响这条规则覆盖的对象；如果**同一个数据源下的所有规则都不响**， 那多半是引擎没接手这个数据源，属于面上的故障，直接跳到「规则根本没进入评估」。

## 先看判定记录（答案 90% 在这里）[​](#先看判定记录答案-90-在这里 "先看判定记录（答案 90% 在这里）的直接链接")

打开这条规则 → **判定记录**。每个评估周期一条，记着这一轮查了什么、判成了什么、 后面哪一环把它拦下来了。一条记录里最有用的是这几个计数和每条事件的**阶段**：

| 字段               | 含义                                         |
| ------------------ | -------------------------------------------- |
| `anomaly_total`    | 这一轮有多少个序列越过了阈值                 |
| `pending`          | 因为**持续时长**没满足，暂时不产生事件       |
| `inhibited`        | 同一对象同时命中多个级别，被更高级别抑制掉了 |
| `muted`            | 被屏蔽规则拦下（含只屏蔽通知、mute hook）    |
| `drop_by_pipeline` | 被规则上挂的工作流丢弃                       |
| `fired`            | 真的产生/刷新了事件                          |

每条事件还带一个 `stage` 和一段 `detail`，取值就是上面这些环节的名字： `pending`、`inhibited`、`muted`、`muted_notify_only`、`muted_by_hook`、`drop_by_pipeline`、 `fired`、`stalled`、`recovered`、`push_queue_failed`。

**照着 `stage` 往下查，不要猜。** 比如 `pending` 的 detail 长这样：

```
for=180s elapsed=45s
```

意思是持续时长要 180 秒，目前才满足了 45 秒——不是不触发，是还没到时候。

`anomaly_total` 是 0，说明**查询这一步就没有越阈的序列**——不是判定的问题， 回到查询本身：[数据源连上了，为什么查不到数据？](https://n9e.github.io/zh/docs/troubleshooting/no-data.md)。

## 规则根本没进入评估[​](#规则根本没进入评估 "规则根本没进入评估的直接链接")

判定记录一条都没有（不是「有记录但没事件」），那这条规则压根没被任何引擎接手。 这种情况**服务端不会打任何日志**——命中不了哈希环时是一个静默的 `continue`， 连引擎环为空这种最常见的情况都被显式排除在错误日志之外。

判定记录接口返回的 `instances` 和 `disabled_instances` 是唯一的线索： 前者列出正在负责这个数据源的引擎实例，**如果它是空的，就没有引擎在跑这条规则**。

一条一条对：

1. **规则被禁用了吗。** 禁用的规则会从引擎缓存里直接消失，同样没有任何评估期日志， 只在停止时打一行 `alert_eval_<规则id> datasource_<数据源id> stopped`。
2. **数据源还在、还是启用状态吗。** 数据源被禁用后规则会被静默跳过， 只有把日志级别开到 DEBUG 才看得到 `alert_eval_%d datasource %d status is %s` （注意这几行里 `datasource` 后面是空格，不是下划线，grep 的时候容易漏）。
3. **有告警引擎在跑吗。** 去 **系统配置 → 告警引擎** 看一眼。心跳超过 30 秒的实例 就不再参与分片；实例记录要等 10 分钟以上才会被清掉，所以列表里看到的不一定还活着， 要看 `clock` 那一列。

## 数据源选错了：`datasource_queries` 才是生效字段[​](#数据源选错了datasource_queries-才是生效字段 "数据源选错了datasource_queries-才是生效字段的直接链接")

规则模型里有两个看起来都像数据源的字段。**`datasource_ids` 和 `cluster` 都已经废弃、被忽略， 真正生效的是 `datasource_queries`。**

它是一组匹配条件，`match_type` 决定语义：`0` 是显式 ID 列表，`2` 是「全部数据源」。 导入来的规则、或者从旧版本升上来的规则，很容易带着 `{"match_type":2,"values":[0]}` 这种「所有数据源」的配置——**规则可能正跑在一个你完全没预期的数据源上**， 在那个库里查不到数据，自然不触发。

在规则详情里确认「数据源」这一项到底选中了什么，别信内存里的印象。

## 生效时间段和业务组[​](#生效时间段和业务组 "生效时间段和业务组的直接链接")

这两个限制都不会让规则「不评估」，而是让**产生的事件被当成屏蔽处理**—— 所以判定记录里看到的是 `muted`，detail 会直接把原因写出来：

| detail                                                | 含义                                             |
| ----------------------------------------------------- | ------------------------------------------------ |
| `rule is not effective for period of time, was muted` | 当前时间不在规则的生效时间段内                   |
| `ident not exists, was muted`                         | 事件带的机器在设备列表里已经不存在               |
| `ident not match busigroup, was muted`                | 规则勾了「仅本业务组」，但这台机器不属于该业务组 |
| `match mute rule`                                     | 命中了一条屏蔽规则，detail 里带 `mute_id`        |

生效时间段是三个字段合起来的：开始时间、结束时间、星期。**注意规则在非生效时间段里 照样每个周期去查数据源**——它只是不出事件，负载是省不掉的。

顺带一个容易搞错的点：**事件的业务组取自规则所属的业务组，不是对象所属的业务组。** 按业务组筛事件却筛不到，多半是这个原因。

## 屏蔽把事件整个吃掉了[​](#屏蔽把事件整个吃掉了 "屏蔽把事件整个吃掉了的直接链接")

屏蔽规则有两种方式，行为差别很大：

* **默认那种（屏蔽事件与通知）**：命中后**事件根本不产生**， 告警事件页和历史里都查不到。「我明明看着指标超了，历史里一条都没有」几乎都是这一种。
* **只屏蔽通知**：事件照常产生、照常落库，只是不发通知， 并在通知记录里留一条状态为「屏蔽」的记录。

判定记录里 `muted` 和 `muted_notify_only` 就是这两种的区分。要恢复历史可见性， 把屏蔽规则改成「只屏蔽通知」。

## 收集这些再去提问[​](#收集这些再去提问 "收集这些再去提问的直接链接")

1. 规则 ID、业务组、以及规则详情里「数据源」和「生效时间段」的截图或原文；
2. 判定记录里最近几条的 `anomaly_total` / `pending` / `muted` / `fired`， 以及某条事件的 `stage` + `detail`；
3. `curl -s http://127.0.0.1:17000/metrics | grep -E 'n9e_alert_rule_eval_(total|error_total)|n9e_alert_eval_query_series_count'`；
4. 日志里 `alert_eval_<规则id> `开头的行（这个前缀能把这条规则的所有日志一网打尽）。

**脱敏**：查询表达式里的业务标签、主机名、数据源地址都要替换掉。

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

* 判定记录本身是空的：[判定记录为什么缺失或被丢弃？](https://n9e.github.io/zh/docs/troubleshooting/evaluation-missing.md)
* 事件有了但没通知：[有告警事件，为什么收不到通知？](https://n9e.github.io/zh/docs/troubleshooting/no-notification.md)
* 反复触发/不恢复：[告警为什么反复触发或从不恢复？](https://n9e.github.io/zh/docs/troubleshooting/alert-flapping.md)
* 判定与恢复的完整模型：[判定、恢复与状态变化](https://n9e.github.io/zh/docs/concepts/evaluation.md)
* 判定记录页面怎么读：[判定执行记录](https://n9e.github.io/zh/docs/alerting/execution-records.md)