🟢 HTTP 健康：门面四件套（核心盘 4 图）

💡 一句话理解

把 backend 想成一家奶茶店：c16 是进店速度（每个柜台每秒接几单），c17 是服务员自己把菜搞砸的次数（5xx，按柜台拆开），c18 是此刻店里有多少客人没走（在途请求，发布时看旧员工有没有把手上单子做完再走），c19 是全店最慢的十个柜台排行榜（你的性能优化待办清单）。

四张图不是孤立的：铁三角（并发 ≈ QPS × 延迟）把它们串成一条因果链——某依赖变慢 → 请求排队 → 并发抬升 → 池打满 → 5xx 雪崩。所以看门面生意永远四件套连看，单看一张最容易误判。

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

先分清两组数。"每分钟进来多少个客人"是 QPS（进店速度），"店里此刻有多少人在等咖啡"是并发（在途请求）——这是两个完全不同的东西：店里人满为患，可能是客人来得太猛（QPS 涨），也可能是做咖啡变慢了（延迟涨），分不清这两种就没法下结论。利特尔法则把它们连起来：店里人数 = 进店速度 × 每人待的时间。

再看"搞砸"的归责。4xx 是客人的点单方式不对——参数写错、没登录就下单，服务员把单子退回去就行，不用半夜爬起来；5xx 是后厨自己炸了——代码抛异常、DB 锁冲突、Redis 或 LLM 依赖挂了。所以错误率面板只盯 5xx，而且按 handler（柜台号）拆开：哪个柜台在搞砸，直奔哪个柜台的日志。口径卡给的行动线很具体：>1 req/s 就该排查了。

最后是排行榜和发布。c19 用 topk(10, …) 把全站最慢的十个接口挑出来——这就是你的性能优化待办清单，优化完再来看同一条查询，榜单名次的变化就是成效。c18 还多一条"ops 排空口径"参考线，专盯发布：滚动发布时，旧 worker 手上的在途请求应该逐个归零（旧员工把手上的单做完再下班）；发布完还挂着不归零，就是排空卡住。而雪崩链在暗中随时待命：延迟翻倍 → 并发翻倍 → 连接池打满 → 排队更狠 → 5xx 铺开——这就是为什么"慢"从来不是小事。

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

handler（柜台号）

请求按路由模板记账：handler 就是接口的"柜台号"，四两的 handler 不含 /api/v2 前缀——按它拆开才知道"谁"最忙、"谁"在出错。

# 按 handler 拆 = 每个柜台一条线（c16 口径）
sum(rate(siliang_http_requests_total[5m])) by (handler)

QPS = rate(请求数)

请求总数是 Counter（_total 只增不减），配 rate 才是"每秒几次"。窗口 [5m] 越大越平滑，排查细节临时改 [1m]。

# Counter 必配 rate（c16 口径）
sum(rate(siliang_http_requests_total[5m])) by (handler)

5xx vs 4xx

4xx=客人的点单方式不对（参数错/没登录），5xx=后厨炸了（异常/依赖挂）。错误率面板只盯 5xx，>1 req/s 就该看日志。

# 只筛 5xx：正则 5.. 匹配 500/502/503/504…（c17 口径）
sum(rate(siliang_http_requests_total{status=~"5.."}[5m])) by (handler)

status=~"5.." 正则

"5.." 匹配所有 5 开头的两位数状态码；写成 ="500" 会漏掉 502/503/504——雪崩时恰恰是它们。

# 错：只盯 500 一种；对：正则覆盖全部 5xx
{status=~"5.."}   # 500 · 502 · 503 · 504 全算

并发是 Gauge

在途请求（已到达未返回）是温度计，直接读数；它高只有两种可能：来得太多（QPS 涨）或走得太慢（延迟涨）。

# Gauge 直接读（c18 口径，含 ops 排空线）
sum(siliang_http_requests_in_progress) by (method)
  + sum(siliang_ops_http_in_flight)

ops 排空口径

滚动发布专用的参考线：旧 worker 手上的在途请求应逐个归零（单做完再下班）；发布后不归零=排空卡住。

# 发布验证：by (instance) 变体逐 worker 看（c18 扩写）
sum(siliang_http_requests_in_progress) by (instance)

P99 从水桶里插值

延迟存在 _bucket 累积水桶里，histogram_quantile(0.99, …) 插值算出"最惨的 1%"；by 里必须带 le。

# le 必进 by（c19 口径）
histogram_quantile(0.99, sum(rate(siliang_http_request_duration_seconds_bucket[5m])) by (le, handler))

topk 只看前 N 名

几十条 handler 的延迟线会糊成毛线团，topk(10, …) 只画最慢的前 10 条——现成的优化待办清单。

# 榜单套在分位数外面（c19 口径）
topk(10, histogram_quantile(0.99, …))

📋 逐面板精讲 4 张图一张不落

# 面板 PromQL（照抄主图谱口径）
sum(rate(siliang_http_requests_total[5m])) by (handler)

# 面板 PromQL（照抄主图谱口径）
sum(rate(siliang_http_requests_total{status=~"5.."}[5m])) by (handler)

# 面板 PromQL（照抄主图谱口径）
sum(siliang_http_requests_in_progress) by (method)
  + sum(siliang_ops_http_in_flight)

# 面板 PromQL（照抄主图谱口径）
topk(10, histogram_quantile(0.99,
  sum(rate(siliang_http_request_duration_seconds_bucket[5m])) by (le, handler)))

🏭 生产实战 real world

# 告警规则：5xx 速率（阈值来自核心盘 c17 口径卡）
groups:
- name: siliang-http
  rules:
  - alert: Backend5xxRateHigh
    expr: sum(rate(siliang_http_requests_total{status=~"5.."}[5m])) by (handler) > 1
    for: 5m           # 持续 5 分钟才报，避开偶发成刺
    labels:
      severity: critical
    annotations:
      summary: "handler {{ $labels.handler }} 5xx 超 1 req/s —— 直奔该 handler 日志"

# 1) 哪个 handler 在出事（c17 口径）
sum(rate(siliang_http_requests_total{status=~"5.."}[5m])) by (handler)
# 2) 是不是 DB 锁连坐（c35 口径：operation × code，1205/1213）
sum(rate(siliang_db_lock_errors_total[5m])) by (operation, code)
# 3) 是不是 LLM 依赖连坐（c13 口径）
rate(siliang_llm_calls_total{outcome="error"}[5m]) by (provider)
# 判读：三张图对时间戳——谁先冒头谁是源头，别急着回滚

# 1) 谁最慢（c19 口径）
topk(10, histogram_quantile(0.99, sum(rate(siliang_http_request_duration_seconds_bucket[5m])) by (le, handler)))
# 2) 在不在排队（c18 口径）
sum(siliang_http_requests_in_progress) by (method) + sum(siliang_ops_http_in_flight)
# 3) DB 池打满没有（m115 口径：借出 ÷ 藏书，95% 红）
max_over_time(siliang_db_pool_connections{state="checked_out"}[1m])
  / on(instance,pool) max_over_time(siliang_db_pool_capacity[1m])
# 4) 还要排除：LLM 在拖（c15）与容器 CPU 挤占（k3）

# 发布窗口内盯：按 instance 逐 worker 看（c18 口径的 by 变体）
sum(siliang_http_requests_in_progress) by (instance)
  + sum(siliang_ops_http_in_flight) by (instance)
# 健康形态：每个旧 worker 的在途数在发布后几分钟内依次归零
# 危险形态：某 worker 的线挂住不归零 = 排空卡住（查慢请求/长连接）
# 配套确认：跨进程收尸（c11）——旧实例退场有没有留下烂尾任务

# 优化前：锁定目标（c19 口径）
topk(10, histogram_quantile(0.99, sum(rate(siliang_http_request_duration_seconds_bucket[5m])) by (le, handler)))
# 优化后：跑同一条查询，看该 handler 的 P99 是否整体下移
# 判读：名次下降/绝对值下降 = 有效
#       被别的 handler 顶上榜首 = 达标，翻下一页待办

⚠️ 常见坑 pitfalls

# 错: 把 4xx 计入告警错误率
# 对: sum(rate(siliang_http_requests_total{status=~"5.."}[5m])) by (handler)

# 错: {status="500"}                          # → 漏 502/503/504
# 对: {status=~"5.."}                         # → 全部 5xx

# 错: avg(rate(...)) / avg 折线看延迟
# 对: topk(10, histogram_quantile(0.99, … by (le, handler)))

# 错: sum(rate(..._duration_seconds_bucket[5m]))
# 对: sum(rate(..._duration_seconds_bucket[5m])) by (le, handler)

# 错: c18 高 → 直接扩容
# 对: c16 没涨 + c18 高 = 走得慢 → 去 c19/m115 找慢因

# 错: 发布后在途不归零 → 判连接泄漏
# 对: sum(siliang_http_requests_in_progress) by (instance) → 找挂住的 worker 查慢请求

# 错: QPS 翻倍 → 直接封 IP
# 对: 对照发布/活动日历 → 无事件才按被刷/爬虫处置

# 错: handler 线归零 → 忽略
# 对: 主力 handler 归零 → 上游调用方挂了，立即按故障排查

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

🔗 相关课程