跳到主要内容

查询有结果但告警不触发

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

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

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

先看判定记录（答案 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，说明查询这一步就没有越阈的序列——不是判定的问题， 回到查询本身：数据源连上了但查不到数据。

规则根本没进入评估​

判定记录一条都没有（不是「有记录但没事件」），那这条规则压根没被任何引擎接手。 这种情况服务端不会打任何日志——命中不了哈希环时是一个静默的 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_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> 开头的行（这个前缀能把这条规则的所有日志一网打尽）。

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

下一步​

本页目录