🔴 后台生成任务：内存泄漏核心哨兵（核心盘 5 图）

💡 一句话理解

把后台生成任务想成后厨订单：用户点单（任务创建）→ 灶上炒菜（处理中）→ 出餐（completed）或着火（exception）。c7 的大数字就是"后厨此刻有多少张未出餐的订单"——它是 Gauge，健康时围绕一个低位波动（进多少出多少），只进不出就是泄漏。这些任务曾经真的只进不出、把内存吃爆，所以 c7 被称为内存泄漏核心哨兵：修复之后，它就是防复发的警报器。

多台机器抢着干活，怎么知道"这单归谁、那人死没死"？答案是租约（Redis 里的心跳+遗嘱）和收尸（实例崩了别人替它收尾）。c10 盯租约机制本身坏没坏，c11 盯有没有实例在异常退出——它们长期为 0 才是健康。

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

先看后厨本厨。每一单从下锅到出餐都要占一个灶位、占一套锅碗——这就是"任务攥着上下文内存"。生意好的时候，后厨里同时有十几张单子在炒，单子数上下波动，但进多少、出多少，收盘时灶位清空。有一天出了个 bug：出的菜没被记账，订单永远显示"处理中"——单子越积越多，灶位全满，最后整个后厨（worker 内存）被撑爆。这就是历史事故："这些任务曾经只进不出，把内存吃爆"。修好之后，c7 这张"未出餐订单数"就成了哨兵：数字再爬起来，就是复发。

再看着火的单子。厨房着火（exception）的单子不能端给客人，要倒掉重做——而重做会再占一遍灶位。所以 c9 里 exception 比例高，不只是"失败率高"，还会连累内存：失败重试会反复占内存，和 RSS 曲线对时间戳能看出联动。

最后是多店协作。连锁后厨（4 个 worker 多实例）怎么分单？每张单在 Redis 里立一张租约——像共享单车扫码开锁："这单归你 30 秒，到点前必须续约报平安；你不续，系统默认你死了，把车（任务）收回来给别人"。续约失败的原因（reason 标签）直接指向病灶：Redis 挂了（redis_error）、租约逻辑写错了（missing_lease）、清理逻辑异常（lease_expired_failed）。而如果一家分店半夜塌了（实例崩了、租约过期），它手里的烂尾单不能永远悬着——由别的分店替它收尾，这就是"收尸"（c11）。偶尔收一次是常态，经常收 = 公司在批量倒闭（实例在异常退出）。

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

活跃任务数是 Gauge

未出餐订单数可进可出，是温度计不是里程表——直接读数，别配 rate。

# 对：Gauge 直接读（c7 口径）
sum(siliang_chat_resume_active_generation_tasks{job="siliang_backend_worker"})

大数字 vs 曲线

c7 只给"现在多少"，c8 才给"往哪走"。判泄漏必须看曲线形态：锯齿=健康，斜线=泄漏。

# 同一个数的曲线版（c8 口径），看 6h 形态
sum(siliang_chat_resume_active_generation_tasks{job="siliang_backend_worker"})

泄漏=只进不出

每个任务攥着一份上下文内存；只进不出 = 灶位全满 = 内存吃爆。这是历史真实事故，不是假设。

# 复发判据：曲线只涨不跌 + 内存盘 RSS 线性爬升互证
deriv(siliang_process_resident_memory_bytes[1h])  # >5MB/h = 真累积

outcome 结局分布

订单结局是 Counter（_total），配 rate 按 outcome 拆：completed=出餐，exception=着火。

# Counter 配 rate（c9 口径）
sum(rate(siliang_chat_resume_generation_task_outcome_total[5m])) by (outcome)

租约（心跳+遗嘱）

多实例分单靠 Redis 租约：到点前必须续约报平安，没续上视为死亡、任务转移。

# 续约失败 + 过期清理失败，按 reason 拆（c10 口径）
rate(siliang_chat_resume_lease_refresh_failed_total[5m]) by (reason)
  + rate(siliang_chat_resume_lease_expired_failed_total[5m])

reason 三分类

续约失败的 reason 直接指向病灶：redis_error=Redis 不稳；missing_lease=租约逻辑 bug；lease_expired_failed=清理逻辑异常。

# reason 读法：先分清"环境坏了"还是"代码坏了"
rate(...lease_refresh_failed_total[5m]) by (reason)  # 健康时长期为 0

收尸（stale finalized）

实例崩了/租约过期后，别的实例替它收尾——收尸计数偶发为 0 正常，持续走高 = 有实例异常退出。

# 收尸计数器（c11 口径）
sum(rate(siliang_chat_resume_stale_finalized_total[5m])) by (reason, status)

job 过滤

只信 job=siliang_backend_worker：共享端口的 server job 会双计数，所有面板已排除。

# 不带过滤 = 混入双计的 server job
{job="siliang_backend_worker"}   # 唯一可信口径

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

# 面板 PromQL（照抄主图谱口径）
sum(siliang_chat_resume_active_generation_tasks{job="siliang_backend_worker"})

# 面板 PromQL（照抄主图谱口径，看 6h 形态）
sum(siliang_chat_resume_active_generation_tasks{job="siliang_backend_worker"})

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

# 面板 PromQL（照抄主图谱口径）
rate(siliang_chat_resume_lease_refresh_failed_total[5m]) by (reason)
  + rate(siliang_chat_resume_lease_expired_failed_total[5m])

# 面板 PromQL（照抄主图谱口径）
sum(rate(siliang_chat_resume_stale_finalized_total[5m])) by (reason, status)

🏭 生产实战 real world

# 告警规则：后台任务积压（阈值来自核心盘 c7 口径卡）
groups:
- name: siliang-bg-tasks
  rules:
  - alert: BackgroundGenerationTasksWarning
    expr: sum(siliang_chat_resume_active_generation_tasks{job="siliang_backend_worker"}) > 20
    for: 10m          # 黄区持续 10 分钟才报，避开正常高峰的抖动
    labels:
      severity: warning
  - alert: BackgroundGenerationTasksCritical
    expr: sum(siliang_chat_resume_active_generation_tasks{job="siliang_backend_worker"}) > 50
    for: 5m           # 红区：泄漏复发嫌疑，立刻按 SOP 处理
    labels:
      severity: critical

# 第 1 步：确认形态——大数字只给现在，曲线才给方向（c8 口径）
sum(siliang_chat_resume_active_generation_tasks{job="siliang_backend_worker"})
# 第 2 步：对照内存仪表盘 RSS 形态互证（m101 口径，锯齿/爬升/平台期）
max_over_time(siliang_process_resident_memory_bytes[1m])
# 第 3 步：量化爬升速度（内存盘核心告警口径：deriv > 5MB/h = 真累积）
deriv(siliang_process_resident_memory_bytes[1h])
# 第 4 步：任务不是唯一嫌疑人——顺手排除协程泄漏（m103 口径）
max_over_time(siliang_asyncio_tasks_active[1m])
# 判读：任务斜线 + RSS 爬升 = 实锤复发；任务稳而 RSS 爬 = 换嫌疑人再查

# 续约失败 + 过期清理失败，按 reason 拆（c10 口径照抄）
rate(siliang_chat_resume_lease_refresh_failed_total[5m]) by (reason)
  + rate(siliang_chat_resume_lease_expired_failed_total[5m])
# reason 读法：
#   redis_error          → Redis 不稳：先查 Redis 本身（池面板 m117/m118 互证）
#   missing_lease        → 租约逻辑 bug：提代码 bug 单
#   lease_expired_failed → 清理逻辑异常：查收尾代码
# 健康口径：两条线长期为 0；偶发成刺可容忍，持续非零必须处理

# 发布后 10 分钟看收尸计数（主图谱 #triage「发布后确认健康」口径）
sum(rate(siliang_chat_resume_stale_finalized_total[5m])) by (reason, status)
# 判读：active 稳定 + stale 偶发 = 旧实例干净退场
#       stale 持续走高 = 有实例异常退出 → 查容器重启/OOM（k5）与 RSS（m101）
# 配套确认：HTTP 在途发布后逐 worker 归零（c18 ops 排空口径）
sum(siliang_http_requests_in_progress) by (method) + sum(siliang_ops_http_in_flight)

# 结局分布（c9 口径）：着火速率
sum(rate(siliang_chat_resume_generation_task_outcome_total[5m])) by (outcome)
# 连锁检查：失败重试反复占内存——RSS 形态对时间戳
max_over_time(siliang_process_resident_memory_bytes[1m])
# 判读：exception 速率高的时段若 RSS 同步冲高 = 重试在放大内存压力
# 处置：先修失败根因（日志），必要时限流重试，而不是扩内存

⚠️ 常见坑 pitfalls

# 错: 只盯 c7 当前值，低于 50 就安心
# 对: 看 c8 的 6h 形态——只涨不跌的斜线 = 泄漏

# 错: 曲线涨了两格就喊泄漏
# 对: 拉 6h 看整体形态：锯齿 vs 单调爬升，再定罪

# 错: rate(siliang_chat_resume_active_generation_tasks[5m])
# 对: deriv(siliang_chat_resume_active_generation_tasks[1h])  # → 每小时涨多少

# 错: 看到 c10 非零就去重启 Redis
# 对: rate(...failed_total[5m]) by (reason)   # → 先分诊再动手

# 错: stale 高 → 扩容
# 对: changes(container_start_time_seconds[1h])   # → 谁在重启（k5 口径）

# 错: 追求 active 恒等于 0
# 对: 锚点：稳态个位数~几十；<20 绿 / 20–50 黄 / >50 红

# 错: 只看 c9 的失败率百分比
# 对: c9 exception 速率 × max_over_time(rss[1m]) 对时间戳互证

# 错: sum(siliang_chat_resume_active_generation_tasks)
# 对: sum(siliang_chat_resume_active_generation_tasks{job="siliang_backend_worker"})

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

🔗 相关课程