🪪 job / instance / label：指标的身份证

💡 一句话理解

Prometheus 里的每个指标样本都随身带一张身份证：job 写着"我属于哪个服务"（siliang_backend_worker / siliang-biz / siliang-rag），instance 写着"我是哪个 worker"（<机器>-<服务>-<序号>，如 253-biz-0 = 253 号机器上 biz 的 0 号窗口），其余 label 写着"从哪个角度看"（handler、provider、outcome、generation…）。

为什么这课重要：图上每条线就是一个身份证。会读身份证，你能把任何一条异常线定位到"某台机器的某个进程"；不会读，89 张图对你来说就是一团毛线。另外有一个必须知道的口径：共享端口的 server job 会随机命中 worker 造成双计——所有面板已把它排除，你自己写查询时也要记得过滤。

🧩 费曼拆解 讲给完全没接触过的小白

把监控数据想象成快递网络。每一个包裹（指标样本）上都贴着一张运单：发件仓（job）写"北京仓/上海仓"——对应"哪个服务"；详细地址（instance）写"253 号楼 biz 单元 0 室"——对应"哪台机器的哪个 worker"；包裹属性（label）写"品类=生鲜、品牌=xx、签收状态=已签收"——对应"从哪个角度看这份数据"。

四两的 instance 是语义化身份证：253-biz-0 一眼读出三段信息——253 号机器（两台 4C 宿主机之一）、biz 服务、0 号 worker（gunicorn 开了 4 个窗口，这是其中第 0 个）。为什么要起这么长的名字？因为这套环境是单 IP NAT，光靠 IP 分不清谁是谁；有了语义化命名，图例里每条线都有名有姓，一条线异常就能直接定位到具体机器上的具体进程。

还有一个著名的陷阱：backend 有个共享端口的 server job——它抓谁全凭随机（请求打到哪个 worker 就算谁的），于是同一个请求会被记两次、分布却是随机的，曲线看起来像抽风。这就像一个快递员同时挂两个仓的工牌，每单被两个仓各记一次账。处理方式很干脆：所有面板统一排除 server job（只信 job="siliang_backend_worker" 这种 per-worker 精确抓取）。你看每张盘的"先读我"卡都会重申这条口径。

🧠 必知必会 看懂本课全部面板的地基

job = 哪个服务

一套服务一个 job 名。四两核心/内存盘用 siliang_backend_worker，biz 盘用 siliang-biz，rag/review 用 siliang-rag / siliang-review。名字里下划线、连字符是逐字区分的，抄错就查不到数据。

# 核心盘/内存盘口径：只信 per-worker 抓取
siliang_http_requests_total{job="siliang_backend_worker"}

instance = 哪个 worker

命名规则 <机器>-<服务>-<序号>：253-biz-0 = 253 机器上 biz 的 0 号 worker；253-backend-3 = 253 机器 backend 的 3 号 worker。图例里每条线就是一个 instance。

# 按 worker 拆开看：一人一条线
max by (instance) (max_over_time(siliang_process_resident_memory_bytes[1m]))

label = 切维度

同一份数据的多个观察角度：handler（哪个接口）、provider（哪家 LLM）、outcome（成功/exception）、generation（GC 第几代）。用 by (label) 决定图上按什么拆线。

# 钱花在哪家的实时账：按 provider 切（c12 口径）
sum(rate(siliang_llm_calls_total[5m])) by (provider)

by () 决定图的颗粒度

聚合时保留哪个 label，图上就有几条线。sum(...) 全抹掉只剩一条总线；sum by (handler)(...) 一个接口一条线。

# 总线 vs 分线
sum(rate(siliang_http_requests_total[5m]))                 # → 1 条总线
sum by (handler) (rate(siliang_http_requests_total[5m]))   # → 每接口一条

server job 双计（已排除）

backend 有个共享端口的 server job，随机命中任意 worker——同一请求记两次、分布随机。所有面板已统一排除；自己写查询也必须带 job 过滤，否则数字虚高。

# 错误示范 → 正确口径（带 job 过滤）
siliang_process_resident_memory_bytes                          # → 可能混入 server job
siliang_process_resident_memory_bytes{job="siliang_backend_worker"}  # → 面板口径

per-worker 精确抓取

Prometheus 到每个 worker 的独立端口抄 /metrics，核心仪表盘 15s、其余 30s。所以 per-worker 数字无漏计无重计，可以放心做除法（错误率、池使用率）。

# 点名：现在有几个 worker 活着（每个 instance 一组）
count by (instance) (siliang_process_resident_memory_bytes{job="siliang_backend_worker"})

gunicorn 4 worker 与 per-worker 容量

backend/biz 各开 4 个 worker，每家是独立进程：独立内存、独立连接池、独立 GC。所以连接池容量是每 worker 各一份（biz DB 池 30，整机 4 个 worker 理论最多 120 条连接）。

# b6 口径：借出数 + 上限参考线（上限 30 是"每个 worker"的）
siliang_biz_db_pool_connections{state="checked_out"} + max(siliang_biz_db_pool_capacity)

HOST 变量 = 机器前缀下钻

仪表盘顶部的 HOST 变量本质是按 instance 前缀过滤：选 253 = 只看这台机器。手写查询等价于 instance=~"253-.*"。

# 等价于选了 HOST=253
siliang_process_resident_memory_bytes{instance=~"253-.*"}

🔗 在四两监控里哪里用到 理论落回你的 89 张图

🟣 核心盘 · 在线用户数（c1）↗——把所有 worker 上的 WS 会话求和：先按 job="siliang_backend_worker" 认准服务，再 sum 到一起。为什么只信这个 job？口径卡（c4）讲的就是 server job 双计排除。

📊 内存盘 · 数据库连接池使用率（m115）↗——图例是 worker × 池 两级维度（instance × pool）：on(instance,pool) 把借出数和容量按同一张身份证配对相除——身份证对不齐，除法就乱套。

🟢 biz 盘 · HTTP QPS（按 handler）（b1）↗——per-worker 精确抓取、无漏计；sum by (handler) 决定图上一条线一个接口。biz 盘口径卡（b0）还写着 instance 名 = 机器-biz-序号（如 253-biz-0）。

🏭 生产实战 real world

# 只看 253 机器上所有 backend worker 的 RSS（m101 口径 + 前缀过滤）
max_over_time(siliang_process_resident_memory_bytes{job="siliang_backend_worker", instance=~"253-.*"}[1m])
# 组合下钻：某台机器 × 某个池（sync 池打满了？）
max_over_time(siliang_db_pool_connections{instance=~"253-.*", state="checked_out", pool="sync"}[1m])
# 判读：一条线冒尖 = 该机器该 worker 的问题；全部冒尖 = 全局问题

# 每个 worker 一条 RSS 线，不聚合（保留 instance 维度）
max_over_time(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1m])
# 再算每条线的斜率：谁是持续为正的那个
deriv(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1h])
# 输出里 instance=253-backend-2 斜率恒为正 → 凶手住在这间房

# 正确口径：4 个 worker → 每个对应 instance 数出 1
count by (instance) (siliang_process_resident_memory_bytes{job="siliang_backend_worker"})
# 去掉 job 过滤重跑：多出来的行就是 server job 的干扰
count by (instance, job) (siliang_process_resident_memory_bytes)
# 结论：写查询永远带 job 过滤，与 89 张面板同口径

groups:
  - name: siliang-per-worker
    rules:
      - alert: BackendRSSClimbPerWorker
        # 不聚合 → 告警自带 instance 标签，通知直指某台机器某个 worker
        expr: |
          deriv(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1h])
            > 5 * 1024 * 1024
        for: 15m   # 持续窗口为通用示例，线上以内存盘口径卡（m100）为准
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} RSS 每小时涨超 5MB：真累积，按下钻链排查"

# b5 口径：借出 ÷ 藏书，on(instance,pool) 按同一身份证配对
max_over_time(siliang_biz_db_pool_connections{state="checked_out"}[1m])
  / on (instance, pool) max_over_time(siliang_biz_db_pool_capacity[1m])
# 拆开看：哪台机器（repeat 出两张图）、哪个 worker 贴 100%
# 全体同时高 = 业务高峰；个别高 = 该 worker 上有慢查询拖住连接

⚠️ 常见坑 pitfalls

# 错: siliang_http_requests_total                        # → 混入 server job 双计
# 对: siliang_http_requests_total{job="siliang_backend_worker"}

# 错: sum(rate(siliang_http_requests_total[5m]))                  # → 一条总线
# 对: sum by (handler)(rate(siliang_http_requests_total[5m]))     # → 每接口一条

# 错: {instance="253-biz-0"}   # → 序号重排后失效
# 对: {instance=~"253-biz-.*"} # → 按机器+服务前缀下钻

# 错: 全量 instance 线一屏全画           # → 毛线团
# 对: topk(5, max_over_time(…[1m]))     # → 只画前 5 名

# 错: 在 RSS 图里找 "/me 接口那条线"       # → 维度认错
# 对: RSS 图按 instance 拆 → 线=worker；QPS 图按 handler 拆 → 线=接口

# 错: {job="siliang-backend-worker"}   # → 空 results，无报错
# 对: {job="siliang_backend_worker"}   # → 逐字照抄口径卡

# 错: 把 server job 数据也算进结论        # → 数字虚高且分布随机
# 对: 面板统一 job 过滤排除 server job    # → 口径一致才可比

# 错: rate(sum(siliang_http_requests_total)[5m])   # → 重启断崖错乱
# 对: sum(rate(siliang_http_requests_total[5m]))   # → 先 rate 再 sum

🎓 费曼自测 合上书，能讲出来才算懂

🔗 相关课程