🚨 泄漏哨兵:防回退警报器(内存盘 3 图)

历史泄漏修复之后加的警报器:沙箱台账应随用随清(非零即违规)· MiniMax H3 登记簿 1024/4096 窗口(贴上限即违规)· 导演组 N6-4(只涨不落即违规)。覆盖内存盘 🚨 泄漏哨兵组 3 张面板(m108 m124 m125)· 仪表盘 siliang-memory。

读数恒 0 = 一切正常 非零 / 贴上限 = 违规 泄漏哨兵 —— 防回退警报器:历史修复的台账,非零即违规 正常路:用 → 清(台账恒 0) 线程/消息/任务用完即销账,台账随用随清 哨兵的日常:一条贴地直线(不是没数据!) 回退路:只进不清(台账爆表) 有人把清理逻辑改没了 → 只登记、不销账 只涨不落 = 修复被回退,警报器该响了 m108 · 沙箱跟踪与清理 跟踪台账 + 待清理队列 设计上随用随清 → 应恒 0 健康读数:贴地直线 告警规则:>0 即报(口径卡核心告警) m124 · MiniMax H3 双登记簿 提交结果窗口 上限 1024 条 已释放任务 ID 上限 4096 条 满了:要么挤掉旧的,要么拒绝新的 上限水位 贴近上限 = 任务终态没收敛 m125 · 导演组跟踪窗口 多智能体协作的消息跟踪台账 处理完应清空(归零型哨兵) 只涨不落 = N6-4 修复被回退 事故现场 · 防回退警报器响了 沙箱跟踪 > 0 —— 对应的泄漏修复被回退了(代码里清理逻辑没了),按告警规则 >0 即报 处置不是调阈值:沙箱/导演组要把清理逻辑找回来;MiniMax 贴上限是另一味药——上调窗口或排查任务终态收敛逻辑 修复验收标准:上线后哨兵回到 0 / 回到窗口低位 —— 不回落等于没修好 哨兵三问:应恒 0 的图有没有非零?贴上限的登记簿有没有降温?只涨不落的台账有没有回落? 口径:max_over_time(…[5m] / [10m])——贴地直线是哨兵的日常健康态,别误判成「面板坏了」

💡 一句话理解

传染病治好了为什么还要复查?因为修过的病最容易复发——代码也一样:修好的泄漏,最怕半年后某人重构时把清理逻辑顺手删掉,老病悄悄回来。这三张面板就是出院病人手上的复查单:m108 沙箱台账(应恒 0,非零即违规)、m124 MiniMax H3 双登记簿(上限 1024/4096,贴上限即违规)、m125 导演组台账(N6-4 修复,只涨不落即违规)。

它们和普通面板读法相反:普通面板"有波动"才正常,哨兵面板"贴地直线"才正常。看到哨兵恒 0 别以为坏了——那正是它在站岗。

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

先懂哨兵思想。历史上 backend 发生过真实泄漏事故:某些资源"只登记、不销账",把内存吃爆。工程师修好了,但他们知道一个残酷规律——代码会被后人改,半年后一次看似无关的重构,就可能把清理逻辑删回去(这叫"回退")。于是他们在每处修复点上装了警报器:给这块逻辑立一本台账,正常情况下台账必须随用随清、读数恒 0;哪天读数不是 0 了,不是"业务变忙了",而是老病复发了。

三只警报器长得不一样。m108 沙箱哨兵是"恒 0 型":沙箱线程的跟踪台账和待清理队列,设计上随用随清,任何 worker 非零都算违规,告警规则就是简单粗暴的 >0 即报。m124 MiniMax H3 哨兵是"水位型":视频任务有两本登记簿——提交结果窗口上限 1024 条、已释放任务 ID 窗口上限 4096 条,登记簿满了要么挤掉旧的要么拒绝新的;贴上限不是"生意好",是任务终态没收敛(该完成的单子一直占着坑)。m125 导演组哨兵也是归零型:多智能体协作流程的消息台账处理完应清空,只涨不回落就是 N6-4 那次修复被回退了。

最后记住验收规矩:修完泄漏,上线后必须盯着哨兵回到 0、回到窗口低位——不回落等于没修好。哨兵存在的意义就是把"我觉得修好了"变成"仪表盘证明修好了"。

类比里的东西系统里对应的东西
出院病人的复查指标泄漏哨兵面板:不测"现在健不健康",专测"修过的老病有没有复发"
病房台账随用随销m108 沙箱跟踪台账 + 待清理队列:设计上随用随清,应恒 0,>0 即报
停车场剩余车位m124 MiniMax H3:提交结果窗口 ≤1024、已释放任务 ID ≤4096;满了挤旧或拒新
散会即清的会议纪要m125 导演组消息跟踪台账:处理完应清空,只涨不落 = 回退
被拆掉的烟雾报警器修复回退:清理逻辑被改没了,台账开始只进不清——哨兵读数立刻异常
复查单上的"参考值:0"告警规则 >0 即报;修复验收 = 上线后哨兵归 0 / 回窗口低位

🛠 动手验证(4 步,在 Grafana 里亲手做一遍)

  1. m108 拉 7 天——健康是一条贴地直线(恒 0)。任何一根刺、任何非零读数都值得追。
  2. m124 看两条线离上限多远——submission_results 距 1024、released_task_ids 距 4096;贴着走就是终态没收敛。
  3. m125 看走势——应随处理清空来回抖;一条只涨不落的斜线 = N6-4 修复被回退。
  4. 对照发布记录——哨兵异常起点若与某次发布/合码时间重合,回退范围基本就锁定了。

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

哨兵思想
历史泄漏修复后的防回退警报器:修过的 bug 最容易在后续重构中被改回去,哨兵负责第一时间尖叫。
# 哨兵与普通面板的读法相反:
# 普通面板:有波动才正常;哨兵:贴地直线才正常
非零即违规
m108 沙箱台账的设计语义就是"随用随清",所以它的告警规则简单粗暴:>0 即报(内存盘口径卡核心告警第三条)。
# m108 口径:台账 + 待清理队列,双线
max_over_time(siliang_sandbox_tracked_threads[5m])
max_over_time(siliang_sandbox_cleanup_tasks_pending[5m])
水位型哨兵
m124 的两本登记簿有硬上限:满了要么挤掉旧的要么拒绝新的——贴上限本身就是病灶信号。
# m124 口径:两种 kind 各一条线,10 分钟窗口
max_over_time(siliang_minimax_h3_tracked_entries{kind="submission_results"}[10m])
# 另一条:kind="released_task_ids"
归零型哨兵
m125 导演组消息台账处理完应清空——关注"只涨不落"的形态,而不是绝对数值大小。
# m125 口径:按 kind 拆线
max_over_time(siliang_director_tracked_messages[5m]) by (kind)
两种违规两种药
沙箱/导演组非零 = 清理逻辑没了,药是把逻辑找回来;MiniMax 贴上限 = 终态没收敛,药是上调窗口或修终态收敛——别开错药。
# 分诊:
# 非零(恒 0 型)   → 查清理逻辑是否被回退
# 贴上限(水位型) → 查任务终态收敛 / 评估窗口
修复验收单
泄漏修完的验收不是"我觉得好了",是哨兵回 0 / 回窗口低位——仪表盘证明才算数。
# 上线后盯 30 分钟:
max_over_time(siliang_sandbox_tracked_threads[5m])  # 应回落并归 0
贴地直线不是坏图
哨兵面板 7 天一条直线是最高荣誉;"这图是不是没数据"是新手最常闹的误会。
# 判断"没数据" vs "恒 0":看查询本身有没有返回序列
siliang_sandbox_tracked_threads  # 有序列、值为 0 = 在站岗

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

🚨 m108 · 泄露哨兵:沙箱跟踪与清理(应恒 0)

它是什么:沙箱线程的"跟踪台账"和"待清理队列"两条线。设计上台账应该随用随清——沙箱线程用完即销账、清理任务排上就消费掉,所以这两条线的健康值就是 0。

回答什么问题:沙箱相关的泄漏修复还在不在?有没有被后续改动回退?

✅ 恒 0:7 天拉出来一条贴地直线——这就是哨兵在正常站岗

🚨 任一 worker 非零 = 对应的泄漏修复被回退了(代码里清理逻辑没了),按告警规则 >0 即报。动作:对照发布/合码记录找回退点,把清理逻辑恢复——不是调阈值

# 面板 PromQL(照抄主图谱口径:双线)
max_over_time(siliang_sandbox_tracked_threads[5m])
max_over_time(siliang_sandbox_cleanup_tasks_pending[5m])

联动:主图谱 m108 ↗ · 相关课程:后台生成任务(同款哨兵思想) · 内存全局水位(告警口径卡)

🚨 m124 · 泄露哨兵:MiniMax H3 窗口

它是什么:MiniMax 视频任务的两个"登记簿"——提交结果窗口(上限 1024 条)和已释放任务 ID 窗口(上限 4096 条),按 kind 各一条线。登记簿满了要么挤掉旧的、要么拒绝新的,所以"贴近上限"本身就是异常状态。

回答什么问题:视频任务的终态收敛逻辑还正常吗?登记簿是不是被"赖着不走的任务"占满了?

✅ 两条线在窗口低位平稳波动,距 1024 / 4096 上限有充足余量

🚨 贴近上限 = 任务终态没收敛(该完成的一直占着坑)。动作:排查终态收敛逻辑;确认逻辑没问题后,才考虑上调窗口——顺序不能反

# 面板 PromQL(照抄主图谱口径,两种 kind)
max_over_time(siliang_minimax_h3_tracked_entries{kind="submission_results"}[10m])
max_over_time(siliang_minimax_h3_tracked_entries{kind="released_task_ids"}[10m])

联动:主图谱 m124 ↗ · 相关课程:视频后台流水线(任务终态从哪来) · 内存全局水位

🚨 m125 · 泄露哨兵:导演组跟踪窗口

它是什么:导演组(多智能体协作流程)的消息跟踪台账,按 kind 拆线。设计语义是"处理完应清空"——消息被跟踪、被处理、然后销账,循环往复。

回答什么问题:N6-4 那次泄漏修复还在吗?消息台账是不是又开始只进不出了?

✅ 随处理节奏上下抖动、整体低位;没有只涨不落的斜线

🚨 只涨不回落 = N6-4 修复被回退。动作:按 instance 定位 + 对照发布记录,恢复清空逻辑;修复验收以"回落"为准

# 面板 PromQL(照抄主图谱口径)
max_over_time(siliang_director_tracked_messages[5m]) by (kind)

联动:主图谱 m125 ↗ · 相关课程:大对象在途(上一课) · 泄漏判定心法

🏭 生产实战 real world

场景 1 · 三只哨兵的告警规则(YAML 可直接抄)

恒 0 型用 >0 即报,归零型加一个持续爬升判据,水位型盯占比。

# 告警规则:防回退哨兵(口径来自内存盘口径卡:沙箱跟踪 >0 即报)
groups:
- name: siliang-leak-sentinels
  rules:
  - alert: SandboxSentinelViolated
    expr: max_over_time(siliang_sandbox_tracked_threads{job="siliang_backend_worker"}[5m]) > 0
    for: 5m           # 抓取毛刺容忍 5 分钟,持续非零才是回退
    labels:
      severity: critical
  - alert: DirectorSentinelRising
    expr: deriv(siliang_director_tracked_messages[1h]) > 0
    for: 30m          # 台账持续 30 分钟净增长 = 只进不清
    labels:
      severity: warning

判读收尾:告警触发后第一步是看形态(刺 vs 斜线),第二步对照发布记录,而不是重启。

场景 2 · 哨兵响了:回退排查 SOP

哨兵的价值是"指路":它直接告诉你哪次修复出问题了。

# 第 1 步:确认是哪只哨兵、哪条线(m108 双线口径)
max_over_time(siliang_sandbox_tracked_threads[5m]) by (instance)
max_over_time(siliang_sandbox_cleanup_tasks_pending[5m]) by (instance)
# 第 2 步:找异常起点时刻,对照发布/合码时间轴
#        异常起点 ≈ 某次发布时间 → 该次改动范围内的清理逻辑逐个核对
# 第 3 步:恢复清理逻辑后,盯哨兵回落归 0(验收)
max_over_time(siliang_sandbox_tracked_threads[5m])
# 判读:回落并贴地 = 修复完成;仍非零 = 没修干净,继续查

场景 3 · H3 水位比:离上限还有几条

登记簿类哨兵要看"占座率",而不是绝对值。

# 提交结果窗口占座率(上限 1024)
max_over_time(siliang_minimax_h3_tracked_entries{kind="submission_results"}[10m])
  / 1024
# 已释放任务 ID 窗口占座率(上限 4096)
max_over_time(siliang_minimax_h3_tracked_entries{kind="released_task_ids"}[10m])
  / 4096
# 判读:长期 <30% 健康;持续 >80% = 终态没收敛,先查终态逻辑再谈扩窗口

场景 4 · 修复验收单:上线后 30 分钟盯哨兵

泄漏修复的完成标志不是代码合入,是哨兵归位。

# 验收查询:三条哨兵一起盯(上线后观察 30m)
max_over_time(siliang_sandbox_tracked_threads[5m])          # → 应回 0
max_over_time(siliang_sandbox_cleanup_tasks_pending[5m])    # → 应回 0
max_over_time(siliang_director_tracked_messages[5m]) by (kind)  # → 应恢复回落形态
# H3 水位型验收:占座率应从高位回落
max_over_time(siliang_minimax_h3_tracked_entries{kind="submission_results"}[10m]) / 1024
# 验收标准:恒 0 型归零;归零型恢复清空节奏;水位型回落到低位

场景 5 · 每日巡检加入哨兵三问(2 分钟版)

主图谱"每日例行巡检"路径的最后一站就是哨兵——三问走一遍。

# 巡检三问对应的查询
# 问 1:应恒 0 的图有没有非零?
max_over_time(siliang_sandbox_tracked_threads[5m])
# 问 2:贴上限的登记簿有没有降温?
max_over_time(siliang_minimax_h3_tracked_entries{kind="submission_results"}[10m]) / 1024
# 问 3:只涨不落的台账有没有回落?
max_over_time(siliang_director_tracked_messages[5m]) by (kind)
# 全部过关(0 / 低位 / 会回落)→ 今日哨兵巡检完成

⚠️ 常见坑 pitfalls

坑 1 · 恒 0 以为面板坏了 — 症状:"这图 7 天了全是 0,是不是没数据?"原因:贴地直线正是哨兵的健康态,与"无数据"长得像。正解:看查询有没有返回序列——有序列且值为 0 = 在站岗。
# 错: 全 0 → 判定面板故障,摘掉告警
# 对: siliang_sandbox_tracked_threads 有序列且 =0 → 正常站岗
坑 2 · 台账非零先调阈值 — 症状:m108 报警了,第一反应"阈值太敏感,改成 >100"。原因:恒 0 型哨兵没有"容忍区间",非零本身就是语义违规。正解:查清理逻辑是否被回退,阈值一个字都不动。
# 错: alert: sandbox_tracked > 100   # → 放水,哨兵失灵
# 对: alert: sandbox_tracked > 0 + for: 5m,去查回退
坑 3 · 把 H3 贴上限当"生意好" — 症状:submission_results 逼近 1024,结论"视频业务火爆"。原因:登记簿贴上限 = 该完成的任务一直占着坑,是终态没收敛,不是流量问题。正解:先排查终态收敛逻辑,确认无 bug 才评估上调窗口。
# 错: 贴上限 → 调大窗口到 4096
# 对: 先查终态逻辑;扩窗口只是最后的容量手段
坑 4 · 三张哨兵只看一张 — 症状:只巡 m108,漏了 m124/m125。原因:三只哨兵各守一个修复点,一只安静不代表其他两只没被回退。正解:哨兵三问每天走一遍。
# 错: 只盯 sandbox_tracked_threads
# 对: m108 + m124(两种 kind)+ m125 by (kind) 全看
坑 5 · 修复后不看哨兵归零 — 症状:泄漏修复合入即宣布完成。原因:合入 ≠ 修好,清空逻辑可能仍被上游引用拽着不执行。正解:上线后盯 30 分钟,哨兵归 0 / 回窗口低位才算验收通过。
# 错: merge 完就关单
# 对: 上线后 max_over_time(…[5m]) 回落归 0 → 关单
坑 6 · 窗口口径乱改 — 症状:自建图用 [1m],和官方面板对不上数。原因:哨兵口径是 m108/m125 用 [5m]、m124 用 [10m],窗口不同读数平滑度不同。正解:沿用主图谱口径,别自创窗口。
# 错: max_over_time(siliang_minimax_h3_tracked_entries[1m])
# 对: max_over_time(siliang_minimax_h3_tracked_entries{kind=…}[10m])
坑 7 · 把哨兵当容量指标去扩容 — 症状:导演组台账涨了,结论"加机器"。原因:台账涨是"只进不清"的逻辑问题,加机器只会让每台都涨。正解:哨兵异常一律先查逻辑回退,容量手段不在选项里。
# 错: 台账爬升 → 扩容 worker
# 对: 台账爬升 → 对照发布记录,恢复清空逻辑

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

Q1 · 哨兵面板和普通面板的读法有什么本质区别?

参考答案:普通面板测"现在健不健康",有波动才正常(锯齿是好事);哨兵面板测"修过的老病有没有复发",健康态是一条贴地直线或窗口低位。所以哨兵恒 0 不是没数据、不是面板坏了,而是它在正常站岗;哨兵一旦非零、贴上限或只涨不落,含义不是"变忙了"而是"修复被回退了"。

Q2 · 三只哨兵分别是什么型?各自的违规信号是什么?

参考答案:m108 沙箱是"恒 0 型"——跟踪台账和待清理队列随用随清,任何 worker 非零即违规,告警规则 >0 即报。m124 MiniMax H3 是"水位型"——提交结果窗口上限 1024、已释放任务 ID 窗口上限 4096,贴近上限即违规(任务终态没收敛)。m125 导演组是"归零型"——消息台账处理完应清空,只涨不回落 = N6-4 修复被回退。

Q3 · m108 报警了,正确的处置顺序是什么?

参考答案:第一步看形态(毛刺还是持续非零,告警的 for: 5m 已滤掉毛刺);第二步按 instance 定位、对照发布/合码时间轴找异常起点,锁定被回退的清理逻辑;第三步恢复清理逻辑上线;第四步盯哨兵回落归 0 作为验收。全程不要动告警阈值,也不要重启或扩容——那是逻辑问题,不是资源问题。

Q4 · 为什么 MiniMax 贴上限和沙箱非零的"药方"不一样?

参考答案:因为违规机制不同。沙箱/导演组是"应该清空的东西没清空"——清空逻辑被回退了,药是把逻辑找回来,调阈值只会让警报器失灵。MiniMax H3 登记簿是有意设计的固定容量窗口(满了挤旧或拒新),贴上限说明任务终态收敛太慢、坑被占满——药是先排查终态收敛逻辑,确认无 bug 后才考虑上调窗口。一个是没有清空逻辑,一个是清空太慢,病根不同,药不同。

← 上一课:📦 大对象在途:谁攥着大文件 📚 课程目录 下一课:📏 字节分布:大对象的典型体重 →