Prometheus 查询
从实际使用场景出发，介绍夜莺 Prometheus 告警规则的查询配置：写 PromQL、简单模式与表达式模式、多查询混合运算，以及逐 series 判定的机制。
概述
Prometheus 是夜莺最常用的告警数据源。告警引擎按执行频率在 Prometheus 上跑一段 PromQL，把返回的时序结果交给「告警条件」做布尔判定——满足就触发告警事件。VictoriaMetrics、Thanos、Mimir 等兼容 Prometheus HTTP API 的系统也走同一套配置。
配置分布在告警规则编辑页的两个区块：
- 第 2 步「数据源」：数据源类型选
Prometheus，再用数据源筛选选中具体实例； - 第 3 步「告警条件」：写 PromQL 查询，配置阈值判定，设执行频率与持续时长。
| 字段 | 必填 | 说明 |
|---|---|---|
| 数据源类型 / 数据源 | 是 | 选 Prometheus 类型，并选中已接入的 Prometheus 数据源 实例 |
| PromQL | 是 | 查询语句，支持全部 PromQL 函数；阈值可直接写进查询（如 cpu_usage_idle < 20），也可添加多条查询（$A、$B…）后用告警表达式混合判定 |
| 告警分级 | 是 | 一级 Critical / 二级 Warning / 三级 Info |
| 执行频率 | 是 | 多久跑一次查询，默认 @every 60s |
| 持续时长 | 是 | 满足条件持续多久才触发，用于抖动抑制 |
下面按实际使用场景介绍。
场景一：单个 PromQL + 阈值
最常见的告警：一条 PromQL 加一个阈值。比如「CPU 空闲率低于 20% 就告警」，把阈值直接写进 PromQL：
cpu_usage_idle{cpu="cpu-total"} < 20
写完点「数据预览」，能看到查询当前返回的时序和值，确认没写错再保存：
几条要点：
- 阈值写进 PromQL 后，任何被过滤出来的 series（上例即空闲率 < 20 的机器）都会触发告警；
- 「告警分级」选 Critical/Warning/Info，会成为告警事件的级别；
- 「执行频率」控制多久跑一次查询，「持续时长」控制满足条件持续多久才触发（用于抑制瞬时抖动）。
场景二：多个查询混合判定
有些告警要同时看多个指标，比如「QPS 高且错误率高才告警」，或者算比率「错误数 / 总数 > 5%」。这时点「＋查询与阈值」添加 $B 查询，用告警表达式做混合运算：
$A > 1000 && $B > 0.05
关键约束——混合运算要求参与运算的 series 标签一致：
- 用
&&/||连接多个 PromQL 做联合判断时，两侧 series 的标签集合必须能对齐，否则无法配对运算； - 用
or在单条 PromQL 里连接多个指标则不要求标签一致； - 标签对不齐时，用 PromQL 的
sum by(维度)/sum without(维度)先把无关标签聚合掉。
表达式模式支持的完整运算符（算术、比较、逻辑、字符串、时间等）见 告警表达式语法。
场景三：一条规则适配多台机器 / 多套阈值（启用变量）
同一条规则想覆盖一批机器，但个别机器要用不同阈值；或者只想监控筛选出来的某些机器——打开告警条件里的「启用变量」开关，在 PromQL 里用 $变量名 占位，执行时自动展开。详见 PromQL 变量查询。
逐 series 判定：一条规则可能产生多条事件
理解这一点能避免"告警怎么产生了几百条"的困惑：PromQL 返回几条 series，告警引擎就逐条独立判定，每条满足阈值的 series 各触发一次告警事件，事件标签就是该 series 的标签。
比如 cpu_usage_idle 返回 100 台机器的数据，就可能产生最多 100 条告警事件（每台机器一条）。如果不希望产出这么多事件，在 PromQL 里用 sum by(维度) 把粒度聚合到你真正关心的维度。
常见问题
Q1：PromQL 返回了几千条 series，会产生几千条告警吗？
A：会——引擎对每条 series 独立判定，每条满足阈值的 series 触发一条事件。用 sum by(维度) 把无关标签聚合掉可以控制事件数量。
Q2：告警事件的标签从哪来？
A：来自 PromQL 返回时序的标签。如 up{instance="…",job="…"} 返回的 series 带 instance、job 标签，事件就带这两个标签。还可以在基础配置的「附加标签」里补业务侧标签。
Q3：明明满足了 PromQL 阈值，为什么没产生事件？
A：按顺序排查：持续时长还没满足（默认要持续 N 秒才触发）；去即时查询用同样的 PromQL 验证能否返回数据；告警引擎是否健康；数据源是否被禁用或数据延迟。
Q4：能查 VictoriaMetrics / Thanos / Mimir 吗？
A：可以，它们都兼容 Prometheus HTTP API。建议用各自的原生数据源类型（如 VictoriaMetrics）以获得更好性能和扩展函数（MetricsQL 等）。
Q5：多查询混合运算不生效？
A：最常见原因是两条查询返回的 series 标签对不齐，无法配对运算。用数据预览看两侧实际标签，再用 sum by/without 对齐维度。详见 告警表达式语法 的「基于标签的对齐」。
