📉 max_over_time 与 deriv：抹抖动与算斜率

💡 一句话理解

护士每 15 秒给你量一次体温，单次读数总有毛刺（刚喝过热水、刚打了个冷颤）——max_over_time(x[1m]) 就是「取这一分钟里的最高体温」，把抓取瞬间的抖动抹平，曲线立刻干净好读。而医生真正关心的往往不是「现在几度」，而是「还在往上烧吗、烧得多快」——deriv(rss[1h]) 就是「过去 1 小时体温的上升速度」。

一个负责看得清（抹抖动定形态），一个负责判得准（算斜率定量）。四两内存盘的核心告警 deriv(RSS[1h]) > 5MB/h 就是靠后者抓「真累积」：每小时涨超 5MB 且持续，说明内存在被真吃掉，而不是正常的锯齿波动。

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

想象住院量体温。护士每 15 秒来读一次体温计（Prometheus 每 15/30 秒抓一个点），把读数记在本子上。你把本子上的数画成曲线——毛毛躁躁上下抖，因为你刚喝了口热水读数就高一点，手凉了一下读数就低一点。这不代表病情在抖，只是测量本身有噪声。怎么办？看「一分钟里的最高读数」：max_over_time(x[1m]) 在每个时刻往回看 1 分钟的窗口，取窗口里的最大值——毛刺被抹平，趋势一眼可见。内存盘的 RSS 面板（m101）、GC 待回收面板（m102）、连接池使用率面板（m115）都是这么干的。

第二步是定量。医生查房时不问「现在几度」，他问「和两小时前比，烧退了还是更高了？」——也就是斜率。deriv(x[1h]) 对过去 1 小时窗口内的所有点做一次「直线拟合」，算出这条直线的坡度：正数在涨、负数在降、绝对值越大涨得越猛。对内存来说，斜率就是「每小时涨多少字节」——这是唯一能把「真泄漏」和「正常波动」区分开的数字。

两条路一对比就懂：健康路是锯齿形——处理请求时内存涨上去，干完活 GC 收回来，一小时的净涨幅约等于零，deriv ≈ 0，不告警；危险路是线性爬升——每小时稳定涨超 5MB，一天就是 120MB，迟早顶到容器限额被 OOM 枪毙。所以告警不看「现在内存多少」（高位平台期可能完全健康），只看「是不是在持续爬」。

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

max_over_time 只喂 Gauge

它取「窗口内最大值」，只对可上可下的温度计（Gauge）有意义。内存、GC 待回收、池借出数、协程数全是 Gauge——所以四两内存盘几乎每张曲线都这么写。

# m101 进程内存面板的口径：1 分钟窗口取最大
max_over_time(siliang_process_resident_memory_bytes[1m])

窗口大小的取舍

[1m] 刚好抹掉抓取抖动又不迟钝，是曲线显示的默认口径；哨兵类面板用 [5m]/[10m] 更稳（如 m108 沙箱哨兵用 5m、m124 MiniMax 登记簿用 10m）。窗口越大越平滑，但也越「钝」。

# 哨兵面板口径：5m 窗口，非零即违规
max_over_time(siliang_sandbox_tracked_threads[5m])

deriv 是斜率不是当前值

deriv 对窗口内的点做线性拟合，输出的是「变化快慢」（拟合坡度）；内存告警按「每小时涨超 5MB」判读。它回答的是「往哪走、走多快」，不是「现在多少」。

# 斜率 = 累积速度；告警口径：持续 > 5MB/h（以 m100 口径卡为准）
deriv(siliang_process_resident_memory_bytes[1h])

deriv 喂 Gauge，rate 喂 Counter

rate 专门处理「只增不减 + 重启归零」的里程表，会自动补齐 Counter 重置的断崖；deriv 处理的是温度计，直接拟合。两者喂错了对象，曲线都无意义。

# 错配演示：Gauge 求 rate 毫无意义
rate(siliang_process_resident_memory_bytes[5m])  # ✗
deriv(siliang_process_resident_memory_bytes[1h]) # ✓ 斜率

为什么告警窗口用 1h

短窗口的 deriv 会被一次大对象冲高骗到（比如处理一个 200MB 视频让 RSS 冲一下又回落）；1h 窗口拟合出来的是「这一小时整体在不在爬」，专抓持续性，不抓单次冲高。

# m109 字节分布面板解释了冲高：处理 200MB 视频内存必先涨 200MB+
# 1h 窗口的 deriv 冲高后回落 = 正常；持续为正 = 真累积

负斜率也是信息

deriv < 0 = 内存在回落：可能是大活干完了、GC 收割了，或刚发布重启。发布后确认 deriv 转负，是「新版本没有泄漏」的快速旁证。

# 发布后看一眼：斜率转负 = 新版本把内存还回来了
deriv(siliang_process_resident_memory_bytes[1h]) # 负数 = 回落

同族函数一起记

max_over_time / min_over_time / avg_over_time 是一家人。四两面板选 max，因为抓取瞬间可能恰好取到一个偏低的点，取最大值更接近真实水位。

# 一家三口：取最大 / 取最小 / 取平均
max_over_time(x[1m])  # 面板主流口径
avg_over_time(x[1m])  # 想看均值时用

别忘了 job 过滤

共享端口的 server job 会随机命中 worker 造成双计，四两所有面板查询都带 job="siliang_backend_worker" 排除——你手写查询时也要带上，否则曲线数量翻倍。

# 标准姿势：先按 job 过滤，再按 instance 看 worker
max_over_time(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1m])

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

① 进程内存 RSS / VMS（m101）——内存盘的体温计，曲线就是 max_over_time(...[1m]) 抹过抖动的；判断涨没涨、什么形态全靠它：📊 进程内存 RSS / VMS ↗

② GC 各代待回收对象数（m102）——gen2 待回收持续爬升是比 RSS 更早的泄漏预警器，同样用 max_over_time[1m] 让爬升看得清：🧹 GC 各代待回收对象数 ↗

③ 数据库连接池使用率（m115）——分子分母都套 max_over_time[1m] 再相除，抹掉抓取瞬间的抖动，避免毛刺造成假告警：🔌 数据库连接池使用率 ↗

④ 泄漏哨兵（m108）——「应恒 0」的防回退警报器用 max_over_time[5m]：窗口内出现过非零就揪出来，抖动逃不掉：🚨 沙箱跟踪与清理哨兵 ↗

⑤ 监控口径与告警规则卡（m100）——内存盘 5 条核心告警里最著名的一条就是 deriv(RSS[1h]) > 5MB/h，本课讲的正是它：📖 监控口径与告警规则（先读我）↗

🏭 生产实战 real world

# 第一步：抹毛刺（m101 口径），看形态：锯齿 / 爬升 / 平台期
max_over_time(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1m])

# 第二步：算斜率，定量回答「每小时涨多少字节」
deriv(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1h])

# 判读：deriv 在 0 附近正负交替 = 锯齿健康；
#       持续为正且大 = 真累积，进入排查流程

# 内存真累积告警（Prometheus rule，数值口径以内存盘「先读我」卡为准）
groups:
- name: siliang-memory
  rules:
  - alert: BackendRssClimbing
    expr: |
      deriv(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1h])
        > 5 * 1024 * 1024   # 5MB/h：每小时涨超 5MB 且持续
    for: 30m               # 持续半小时才响，避免单次冲高误报（时长以口径卡为准）
    labels:
      severity: warning
    annotations:
      summary: "worker {{ $labels.instance }} RSS 持续爬升，疑似真累积"

# 平台期：冲高后停住（allocator 留着复用）→ 斜率 ≈ 0
deriv(siliang_process_resident_memory_bytes{instance="253-backend-0"}[1h])
# 预期：在 0 附近抖 → 不是泄漏，别动手

# 真泄漏：爬完没停 → 斜率持续为正
deriv(siliang_process_resident_memory_bytes{instance="253-backend-1"}[1h])
# 预期：稳定 > 5MB/h → 按内存盘排查链下钻（在途 → 哨兵 → GC）

# 发布完成后跑一次：按 instance 看 4 个 worker 各自的斜率
deriv(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1h]) by (instance)

# 预期：旧 worker 内存随流量迁走回落（deriv 负），新 worker 平稳；
# 若新 worker deriv 持续为正且大 → 新版本引入泄漏，考虑回滚

# m115 数据库连接池使用率口径：分子分母都取 1m 最大值再相除
max_over_time(siliang_db_pool_connections{state="checked_out",job="siliang_backend_worker"}[1m])
  / on(instance, pool)
max_over_time(siliang_db_pool_capacity{job="siliang_backend_worker"}[1m])

# 判读：80% 黄 / 95% 红；贴 100% = 池打满，请求开始排队

⚠️ 常见坑 pitfalls

# 错: rate(siliang_process_resident_memory_bytes[5m])   # → Gauge 求 rate，曲线无意义
# 对: deriv(siliang_process_resident_memory_bytes[1h])   # → 每小时涨多少字节

# 错: deriv(siliang_process_resident_memory_bytes[1m])  # → 噪声放大器
# 对: deriv(siliang_process_resident_memory_bytes[1h])  # → 稳定的累积速度

# 错: 看到单点 deriv 大就报警           # → 冲高也响，天天狼来了
# 对: deriv(...[1h]) 持续 > 5MB/h 才响  # → 冲高回落不响，真爬升必响

# 错: max_over_time(siliang_http_requests_total[1m])  # → 永远在涨，无信息
# 对: rate(siliang_http_requests_total[5m])           # → 才是 QPS

# 错: max_over_time(checked_out[1m]) / max_over_time(capacity[1m])        # → 错配
# 对: ... / on(instance, pool) max_over_time(siliang_db_pool_capacity[1m]) # → 按 worker×池 对齐

# 错: deriv(rss[15m]) > 0                         # → 锯齿上行沿天天误报
# 对: deriv(rss[1h]) > 5*1024*1024  for: 30m      # → 只抓真累积

# 错: deriv(siliang_process_resident_memory_bytes[1h])                  # → 双计
# 对: deriv(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1h])

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

🔗 相关课程