聚合与向量匹配 · by/without 与那些一对多

sum by (job) (x) 干的事，本质是：按 job 分组，丢掉其他所有标签，组内求和。

输入(6 条 series):
  {job="api", instance="1", status="200"}  10
  {job="api", instance="2", status="200"}  20
  {job="api", instance="1", status="500"}   1
  {job="db",  instance="3", status="200"}  30
  {job="db",  instance="4", status="200"}  40
  {job="db",  instance="3", status="500"}   2

sum by (job) (x)  →  {job="api"}  31     ← instance 和 status 都没了!
                     {job="db"}   72

关键理解：聚合结果的标签集 = by 里列的那些，仅此而已。 所有没被 by 提到的标签全部消失。

without 是反过来的：列出要丢掉的标签，其余全保留。

sum without (instance) (x)  →  {job="api", status="200"}  30
                               {job="api", status="500"}   1
                               {job="db",  status="200"}  70
                               {job="db",  status="500"}   2

实战建议：优先用 without。 为什么？因为 by 是白名单——将来加了新标签（比如 region），by (job) 会默默把它丢掉，你可能根本没意识到结果被跨 region 混在一起了。而 without (instance) 是黑名单，新标签会自动保留，更符合“我只想合并掉实例维度”的意图。

这条经验很多人不知道，但它能避免真实的误导。

第 2 部分讲基数时说过 series 数是乘法**。聚合是那个乘法的逆运算——它把维度消掉。**

原始:  5(method) × 50(route) × 8(status) × 12(le) × 20(instance) = 480,000
sum by (le):                                                      = 12  ← 消掉了 4 个维度!

这就是 recording rules 的价值：把常用的聚合结果预先算好存下来，查询时直接读那 12 条，而不是每次都从 48 万条里现算。第 5 部分会展开。

一个实用心法：聚合时问自己“我丢掉的这个维度，真的不需要吗？” 丢 instance 通常没问题（你要看服务整体）；但如果你正在排查“是不是某个坏实例”，丢掉 instance 就等于丢掉了答案。聚合是有损的，损失的正是你埋点时费心保留的提问自由度。

默认规则（一对一）：标签集完全相同的两条 series 配对**。**

a:  {job="api", instance="1"}  100
    {job="api", instance="2"}  200
b:  {job="api", instance="1"}   10
    {job="api", instance="2"}   20

a / b  →  {job="api", instance="1"}  10    ← 标签全同 → 配对
          {job="api", instance="2"}  10

注意：结果会丢掉指标名（__name__），因为“a 除以 b”是个新东西，不再是 a 也不是 b。

问题来了：如果标签不完全相同呢？ 比如 a 有个额外的 status 标签，b 没有——默认规则下，一条都配不上，结果是空。

这就是“我的查询返回空但每一半都有数据”这个经典困惑的根源。 解法是 on / ignoring：

# 只按 job 配对,忽略其他标签
a / on (job) b

# 忽略 instance,按剩下的配对
a / ignoring (instance) b

on 是白名单（只看这些标签），ignoring 是黑名单（忽略这些标签）——和 by/without 的关系一样。

最让人头疼的场景：一边多、一边少。

经典例子：你想给指标打上元数据标签（比如从 kube_pod_info 拿 node 名）：

# container_cpu 有很多条(每个 pod 一条)
# kube_pod_labels 也是每个 pod 一条,但带着额外的标签

container_cpu_usage_seconds_total * on (pod) group_left(node) kube_pod_labels

group_left 的意思是：“左边是多的那一侧”——即左边的多条 series 可以匹配右边的同一条。group_left(node) 里的 node 是“从右边额外拿过来的标签”。

记忆口诀：group_left = 左边多、从右边捞标签；group_right 反之。

两个常见的坑：

• “multiple matches for labels”错误 —— 说明你方向搞反了，或者匹配的标签不够唯一（右边有多条 series 匹配同一个左边的）。检查：on() 里的标签组合在“一”的那侧是否真的唯一。
• 忘了 group_left 的括号参数 —— group_left 不带参数只是“允许多对一”，不会把右边的标签带过来。要带标签必须写 group_left(node)。

这个 xxx * on(...) group_left(...) yyy 的模式是生产环境的高频套路（给指标补元数据、做 join），值得专门记住。

模式 ③ 里的 on ()（空括号）值得注意：它表示“不按任何标签配对”，即所有左边的 series 都匹配右边那唯一一条**（sum() 的结果没有标签）。这是“算占比”的标准写法。**

模式 ④ 的 unless 是集合运算：PromQL 有 and（交）、or（并）、unless（差）。它们也遵循向量匹配规则，同样可以配 on/ignoring。unless 特别适合“找出缺失的东西”——比如“哪些实例 up 了但没上报某个指标”。