🟢 biz 业务后端：核心盘精简镜像

💡 一句话理解

biz 是「另一家连锁分店」：独立于 backend 的 gunicorn 多 worker 业务后端（APP_WORKERS 默认 4）。这张盘不发明任何新指标——就是把核心盘已经教过的体检项目（HTTP 四件套、连接池两对卡、RSS/GC）在 biz 身上原样再量一遍，项目相同、读法相同，只有「读数」因服务而异。

所以学这课只需要记一张映射表：b1↔c16、b2↔c17、b3↔c18、b4↔c19、b5/b6↔m115/m116、b7/b8↔m117/m118、b9↔m101、b10↔m126；再加 biz 特有的三件事：handler 不含 /api/v2 前缀、Redis 与 Agent 服务共享（对方挤占）、池面板按机器 repeat 成对出现。

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

连锁体检的故事。你已经在前面的课程里学会了整套体检流程：量血压（HTTP 四件套：QPS、5xx、并发、延迟）、量血液粘度（连接池：借出 ÷ 藏书）、量体温（RSS 形态）、看白细胞（GC 速率）。现在公司新开了一家分店——biz 服务，设备与流程和总店（backend）完全一样，只是换了店名。体检报告自然也长一个样：项目一样、正常范围的判读方法一样，你不需要重新学，只需要对号入座。

这家分店的门牌号。biz 用 gunicorn 开了 4 家门店（APP_WORKERS 默认 4，每家是独立进程、独立内存、独立连接池）。Prometheus 每 30 秒来抄一次表，每家门店单独一本账：指标身份证上的 instance 写着「机器-biz-序号」，比如 253-biz-0 就是 253 这台机器上 biz 的 0 号 worker。菜单上的菜名（handler）是子路由模板，比如 /me——不含 /api/v2 前缀，去日志里搜接口名时别把前缀带上。

一处特别的合租。biz 的 Redis 图书馆不是独享的：它与 Agent 服务共享同一个 Redis（连接上限 max_connections=50）。合租意味着室友用得多，也会挤占你的池子——所以 b7/b8 的使用率莫名走高时，除了查 biz 自己，还要想想室友干了什么。另外这张盘的池面板按机器 repeat 成对出现（每台机器一对图），下钻时用仪表盘顶部的 HOST 变量按机器前缀切换。

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

gunicorn 多 worker

biz 用 gunicorn 起了 4 个 worker（APP_WORKERS 默认 4），每个是独立进程：独立内存、独立连接池、独立 GC。所以每张图都是 per-worker 视角，一条线异常就能定位到具体分店。

# instance 命名：<机器>-biz-<序号>
siliang_biz_http_requests_total{instance="253-biz-0"}
# → 单独看 0 号 worker 的请求计数

job=siliang-biz

biz 面板的指标全挂在 job="siliang-biz" 下。biz 是 per-worker 精确抓取、无漏计（口径卡 b0）；自己写查询时带上 job 过滤，避免混入其他服务的系列。

# 手工查询的标准姿势：
sum(rate(siliang_biz_http_requests_total{job="siliang-biz"}[5m]))

handler 不含 /api/v2

图例里的接口名是子路由模板（如 /me），不含 /api/v2 前缀。按 handler 去日志里搜的时候，别把前缀带上，否则一行都搜不到。

# 图例显示 /me ↔ 完整路径是 /api/v2/me
sum(rate(siliang_biz_http_requests_total[5m])) by (handler)

DB 池 10+20=30

biz 的 DB 图书馆：平时最多借 10 条，高峰可临时加座（overflow）到 30——这是每个 worker 各一份，单机 4 worker 合计至多 120 条。使用率 80% 黄 / 95% 红。

# 使用率 = 借出 ÷ 藏书（b5 的口径）
max_over_time(siliang_biz_db_pool_connections{state="checked_out"}[1m])
  / max_over_time(siliang_biz_db_pool_capacity[1m])

Redis 与 Agent 共享

biz 的 Redis 池上限 max_connections=50，且这个 Redis 与 Agent 服务共享——对方用得多也会挤占你的额度。b7 使用率走高，先想室友再想自己。

# Redis 借出数（b8 绝对值口径，上限 50 参考线）
siliang_biz_redis_pool_connections{state="in_use"}

池面板成对出现

biz 部署在两台机器上，池面板按机器 repeat 成对出现：每台机器一对图。别把「只看到一张」误判为另一台没数据——用 HOST 变量切换机器即可。

# 按机器前缀下钻（HOST 变量的底层逻辑）
sum by (instance) (siliang_biz_db_pool_connections{state="checked_out"})

RSS 三形态

锯齿（涨跌交替）=健康；冲高后平台期=allocator 不归还（Python 常态，不是泄漏）；线性爬升永不回落=真泄漏。判「真累积」用 deriv 算斜率。

# 每小时涨多少字节（口径卡告警：deriv > 5MB/h）
deriv(siliang_biz_process_resident_memory_bytes[1h])

GC 互证

gen0/1 周转快属正常；gen2 长期停滞 + gen0/1 活跃 = 有大对象赖在老年代不走——与 b9 的 RSS 平台期/爬升互证，才好定罪。

# 垃圾车出车频率（b10 口径，按代拆）
sum by (generation) (rate(siliang_biz_python_gc_collections_total[5m]))

📋 逐面板精讲 11 张图一张不落（顺序 = 主图谱 biz 盘顺序）

# 附 4 条建议告警（口径卡原文）：
# 1. DB 池打满   2. Redis 池打满
# 3. 5xx 速率 > 1   4. deriv(RSS[1h]) > 5MB/h

# 面板口径：每秒请求数按 handler 拆
sum(rate(siliang_biz_http_requests_total[5m])) by (handler)

# 面板口径：只数 5xx（正则 status=~"5.."）
sum(rate(siliang_biz_http_requests_total{status=~"5.."}[5m])) by (handler)

# 面板口径：在途请求数按 method 拆
sum(siliang_biz_http_requests_in_progress) by (method)

# 面板口径：从延迟直方图水桶插值算 P95，topk 只留前 5
topk(5, histogram_quantile(0.95,
  sum(rate(siliang_biz_http_request_duration_seconds_bucket[5m])) by (le, handler)))

# 面板口径：使用率（分子 checked_out，分母 capacity）
max_over_time(siliang_biz_db_pool_connections{state="checked_out"}[1m])
  / max_over_time(siliang_biz_db_pool_capacity[1m])

# 面板口径：借出数 + 上限参考线（max 取容量）
siliang_biz_db_pool_connections{state="checked_out"}
  + max(siliang_biz_db_pool_capacity)

# 面板口径：Redis 使用率（in_use ÷ capacity）
max_over_time(siliang_biz_redis_pool_connections{state="in_use"}[1m])
  / max_over_time(siliang_biz_redis_pool_capacity[1m])

# 面板口径：借出数 + 上限参考线
siliang_biz_redis_pool_connections{state="in_use"}
  + max(siliang_biz_redis_pool_capacity)

# 面板口径：1 分钟窗口最大值，每 worker 一条线
max_over_time(siliang_biz_process_resident_memory_bytes[1m])
# 判「真累积」：deriv(...[1h]) 每小时涨多少字节（> 5MB/h 是口径卡告警线）

# 面板口径：各代回收速率
sum by (generation) (rate(siliang_biz_python_gc_collections_total[5m]))

🏭 生产实战 real world

# 第 1 步：哪个接口在出 500？（b2）
sum(rate(siliang_biz_http_requests_total{job="siliang-biz", status=~"5.."}[5m])) by (handler)
  # > 1 req/s 即进入排查；锁定的 handler 去日志搜（记得去掉 /api/v2 前缀）

# 第 2 步：是不是 DB 池打满连坐？（b5/b6）
max_over_time(siliang_biz_db_pool_connections{state="checked_out"}[1m])
  / max_over_time(siliang_biz_db_pool_capacity[1m])
  # 贴 1.0（100%）= 请求在等连接 → 去找占着连接的慢查询

# 第 3 步：是不是 Redis 挤占？（b7，注意与 Agent 服务共享上限 50）
siliang_biz_redis_pool_connections{state="in_use"}
  # 贴近 50 = 合租池紧张 → 看 b8 的机器分布，确认是 biz 还是室友

# 1) 最慢的 5 个接口（b4；想看最惨的 1% 就把 0.95 改 0.99）
topk(5, histogram_quantile(0.95,
  sum(rate(siliang_biz_http_request_duration_seconds_bucket[5m])) by (le, handler)))

# 2) 并发是否高位不落（b3）——持续高位 = 在排队
sum(siliang_biz_http_requests_in_progress) by (method)

# 3) 按 worker 拆池借出数（b6 变体）——单 worker 打满会被求和掩盖
sum by (instance) (siliang_biz_db_pool_connections{state="checked_out"})
  # 某个 instance 独自顶到 30 = 那家「分店」的池被打满

# 1) 看形态（b9）：每 worker 一条线
max_over_time(siliang_biz_process_resident_memory_bytes[1m])
  # 锯齿/冲高回落 = 健康；冲高后横走 = 平台期（allocator 不归还，常态）
  # 斜着向上永不回落 = 真累积，进入第 2 步

# 2) 量化斜率：每小时涨多少字节
deriv(siliang_biz_process_resident_memory_bytes[1h])
  # 持续 > 5MB/h = 口径卡的「持续爬升」告警线（以 b0 口径卡为准）

# 3) GC 互证（b10）：gen2 停滞而 gen0/1 活跃 = 大对象驻留
sum by (generation) (rate(siliang_biz_python_gc_collections_total[5m]))

# 4) 排除「单纯变忙」：流量同步涨了吗？
sum(siliang_biz_http_requests_in_progress) by (method)

groups:
- name: siliang-biz # 口径卡 b0 的 4 条建议告警
  rules:
  - alert: BizDbPoolNearFull
    expr: max_over_time(siliang_biz_db_pool_connections{state="checked_out"}[1m]) / max_over_time(siliang_biz_db_pool_capacity[1m]) > 0.95
    for: 5m        # 95% 红：池打满的前最后窗口
  - alert: BizRedisPoolNearFull
    expr: max_over_time(siliang_biz_redis_pool_connections{state="in_use"}[1m]) / max_over_time(siliang_biz_redis_pool_capacity[1m]) > 0.95
    for: 5m        # 注意与 Agent 服务共享上限 50
  - alert: BizHttp5xxRate
    expr: sum(rate(siliang_biz_http_requests_total{status=~"5.."}[5m])) > 1
    for: 5m        # > 1 req/s：按 handler 直奔日志
  # 第 4 条：deriv(siliang_biz_process_resident_memory_bytes[1h]) > 5MB/h
  # 阈值口径以 b0 口径卡原文为准

# 1) 突增定位：谁在涨？（b1，临时把窗口改小看细节）
sum(rate(siliang_biz_http_requests_total[1m])) by (handler)

# 2) 近 1h 该 handler 总量对照（increase 看累计）
sum by (handler) (increase(siliang_biz_http_requests_total[1h]))

# 3) 谁消失了：对比各 handler 速率（归零的 = 调用方挂了）
sum(rate(siliang_biz_http_requests_total[5m])) by (handler)
  # 无发布无活动却突增 = 被刷/爬虫：按 handler（短模板名）去限流/封禁

⚠️ 常见坑 pitfalls

# 错: # grep "/api/v2/me" → 图例名 ≠ 完整路径，搜不到
# 对: # grep " /me " → handler 是子路由模板（口径卡 b0）

# 错: sum(siliang_biz_db_pool_connections{state="checked_out"})          # → 4 worker 加总，掩盖单打满
# 对: sum by (instance) (siliang_biz_db_pool_connections{state="checked_out"})

# 错: # b7 高 → 只查 biz 代码（合租水电表，只查一户没用）
# 对: # b7 高 → 先想共享（Agent 服务），再对照时段归因

# 错: rate(siliang_biz_process_resident_memory_bytes[5m])   # → Gauge 求 rate
# 对: deriv(siliang_biz_process_resident_memory_bytes[1h])  # → 每小时涨多少字节

# 错: # 平台期 → 判泄漏 → 回滚（白折腾）
# 对: # deriv(...[1h]) 持续 > 5MB/h 才按泄漏链下钻

# 错: # 只读一张卡就下结论
# 对: # b5（使用率）+ b6（借出 vs 上限 30）成对看

# 错: # 只见一张 → 报「数据丢失」
# 对: # repeat 成对出现；HOST 变量切机器前缀查看

# 错: sum(rate(siliang_http_requests_total[5m]))        # → 这是 backend 的指标
# 对: sum(rate(siliang_biz_http_requests_total[5m]))     # → biz 的指标带 biz_ 前缀

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

🔗 相关课程