🎬 视频后台流水线：结算工厂（内存盘 5 图）

💡 一句话理解

把视频做完想成「客人点的外卖做好了」：生成完成（轮询到 DONE）只是出了制作间，后面还有一整座后台工厂。工厂里两条流水线：结算（算这单用了多少、该收多少钱）和收尾（把成品下载转存到 COS、打上终态标记）。产能怎么读？队列深度=门口排了多少单，丢件率=队伍满到往外丢了多少次（丢了不等于没了——有兜底扫描补投，但延迟会恶化），并发上限=工厂开了几个工位（配置值），最后还有一位收割器：用户关了页面、任务 90s 无动静时，由服务端主动推进它的结局。

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

很多人以为「视频生成完成」就是终点。其实在系统里，轮询到 DONE 只是半成品进厂：钱还没算（用户用了多少秒的 GPU、按哪个价目）、文件还躺在厂商那边（要下载下来转存到我们自己的 COS、打上终态，用户才能稳定拿到）。这两件事各有各的流水线——结算和收尾，各有一条队、各开若干工位、各自记「结局」。

流水线的健康怎么读？三看。一看队：队列深度（Gauge）直接读，持续上涨=消化不足；队伍满了系统会「丢投递」——别慌，任务不丢，有兜底扫描会补投，但延迟会恶化，所以丢件率是比队列深度更严重的信号。二看结局：每个活干完会记 outcome——成功、retrying（再试一次）、exhausted（试到没脾气放弃）。retrying/exhausted 高不是「有点慢」，是「卡住了」：结算卡住=定价或用量数据异常，这单钱算不出来（收入问题）；收尾卡住=转存/转码链路异常，用户的成品可能拿不到。三看工位：并发上限是配置值（Gauge），拿它和队列对照就知道产能瓶颈在哪。

最后是收割器——工厂的「无人认领处理员」。正常情况下前端用户会轮询自己的视频；但用户可能做完就关页面，任务从此没人看着。收割器盯的就是这种：一个任务 90s 无动静，服务端主动去推进它的结局（是推进，不是重做）。它也有自己的结局字典：advanced（推进成功）、forced_timeout（超 24h 强制收敛）、skip_claimed（别的节点刚碰过，互斥跳过——这是互斥机制在正常工作，不是错误）、advance_error（推进失败，要查日志）。待收割的 stale_tasks 持续走高，就是「没人看着的积压」在变多。

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

两条流水线的分工

结算=算钱（DONE 之后计价），收尾=转存 COS+打终态（用户拿成品的保障）。指标前缀 settlement / finalization 别混。

# 两套前缀，两个工厂车间
siliang_video_settlement_outcome_total    # 算钱的结局
siliang_video_finalization_outcome_total  # 转存的结局

outcome 三态

每个活干完记一次结局（Counter → rate by outcome）：成功 / retrying（再试一次）/ exhausted（试到没脾气放弃）。

# 读法
sum by (outcome) (rate(siliang_video_settlement_outcome_total[5m]))
# → retrying 偶发可忍 · exhausted 非零就是事故信号

两种「卡住」两种后果

结算卡住=定价或用量数据异常，这单钱算不出来（收入问题）；收尾卡住=转存/转码链路异常，成品可能拿不到（体验问题）。

# 面板原话浓缩
# 结局卡在结算 → 收入问题（对照计费归因 unattributed）
# 结局卡在收尾 → 用户的成品可能拿不到

队列深度与丢件率

队列深度是 Gauge 直接读；持续上涨=消化不足。队列满开始丢投递时任务不丢（兜底扫描补投），但延迟恶化——丢件率比深度更严重。

# 两条队 + 丢件（主图谱口径）
sum(siliang_video_finalization_queue_depth)
  + sum(siliang_video_settlement_queue_depth)
  + rate(…_dropped_total[5m])   # 丢件率 > 0 = 满到往外丢了

并发上限是配置 Gauge

工位数 = VIDEO_FINALIZER_CONCURRENCY / VIDEO_SETTLEMENT_CONCURRENCY 的当前值。它回答「产能开了多少」，和队列对照决定调参方向。

# 工位配置值（大数字面板）
max(siliang_video_finalization_worker_concurrency)
max(siliang_video_settlement_worker_concurrency)

收割器与 skip_claimed

用户关页面后 90s 无动静，服务端主动推进结局。skip_claimed=别的节点刚碰过、互斥跳过——正常机制，不是错误；advance_error 才是要查的。

# 收割器结局字典
# advanced=推进成功 · forced_timeout=超 24h 强制收敛
# skip_claimed=互斥跳过（正常） · advance_error=推进失败

stale_tasks 积压表

待收割任务数持续走高 = 没人看着的积压在变多。它是 Gauge，取 max 抹抓取抖动。

# 主图谱口径：收割器速率 + 待收割存量
sum by (outcome) (rate(siliang_video_reaper_outcome_total[5m]))
  + max(siliang_video_reaper_stale_tasks)

结算失败与计费的关系

结算 exhausted 的单子=钱算不出来=少收钱。排查速查表把它和计费归因 unattributed 列成同一条「账单对不上」路径。

# 速查表路径（账单/消耗对不上）
# c27 归因失败 unattributed → c28 查询耗时 → m131 结算 retrying/exhausted

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

# 主图谱口径：结算结局速率
sum by (outcome) (rate(siliang_video_settlement_outcome_total[5m]))

# 主图谱口径：收尾结局速率
sum by (outcome) (rate(siliang_video_finalization_outcome_total[5m]))

# 主图谱口径：两条队深度 + 丢件率
sum(siliang_video_finalization_queue_depth / siliang_video_settlement_queue_depth)
  + rate(siliang_video_finalization_queue_dropped_total[5m])  # dropped 指标名以仪表盘口径卡为准

# 主图谱口径：两个工位配置值
max(siliang_video_finalization_worker_concurrency / siliang_video_settlement_worker_concurrency)

# 主图谱口径：收割器结局速率 + 待收割存量
sum by (outcome) (rate(siliang_video_reaper_outcome_total[5m]))
  + max(siliang_video_reaper_stale_tasks)

🏭 生产实战 real world

# 第 1 步：两条队积压吗？丢件了吗？
sum(siliang_video_finalization_queue_depth) + sum(siliang_video_settlement_queue_depth)
rate(…_dropped_total[5m])   # dropped 指标名以仪表盘口径卡为准

# 第 2 步：工位开满了吗？（没开满=调大并发；开满了=链路卡）
max(siliang_video_finalization_worker_concurrency)
max(siliang_video_settlement_worker_concurrency)

# 第 3 步：卡在哪条流水线？
sum by (outcome) (rate(siliang_video_finalization_outcome_total[5m]))
sum by (outcome) (rate(siliang_video_settlement_outcome_total[5m]))

# 第 4 步：兜底推没推进？（stale 高=没人看着的积压在变多）
max(siliang_video_reaper_stale_tasks)

# 结算放弃 = 收入问题，非零即报
- alert: VideoSettlementExhausted
  expr: sum(rate(siliang_video_settlement_outcome_total{outcome="exhausted"}[15m])) > 0
  labels: {severity: critical}
  annotations: {summary: "视频结算 exhausted：有单子钱算不出来（收入问题）"}

# retrying 抬升 = 即将变成 exhausted 的预警（示例阈值，按基线调）
- alert: VideoSettlementRetryingHigh
  expr: sum(rate(siliang_video_settlement_outcome_total{outcome="retrying"}[15m])) > 0.1
  labels: {severity: warning}
  annotations: {summary: "视频结算重试增多：定价或用量数据可能异常"}

# 判据：队列在涨时，工位有没有开满？
# A. 没开满 → 产能闲置 → 调大 VIDEO_*_CONCURRENCY
max(siliang_video_finalization_worker_concurrency)

# B. 已开满 → 链路卡 → 收尾看转存链路（COS），结算先看锁冲突
sum(rate(siliang_db_lock_errors_total[5m])) by (operation, code)
# → 1205/1213 出现：结算工位全耗在等锁上，调工位无效，先修锁

# 结局速率按 outcome 拆开
sum by (outcome) (rate(siliang_video_reaper_outcome_total[5m]))
# → advanced 主流 · skip_claimed 有读数=互斥正常 · advance_error 才要查

# 存量：待收割持续走高 = 无人认领的积压在变多
max_over_time(siliang_video_reaper_stale_tasks[10m])
# 抬升时对照队列深度：进得多（扩容）还是推不动（修推进链路）
sum(siliang_video_finalization_queue_depth)

# 源头 1：计费归因失败（找不到主人的消费）
rate(siliang_workspace_consumption_unattributed_total[5m])

# 源头 2：视频结算卡住（这单钱算不出来）
sum by (outcome) (rate(siliang_video_settlement_outcome_total{outcome=~"retrying|exhausted"}[15m]))
# → 两个数都该长期贴地；非零的时段就是少收钱的窗口

⚠️ 常见坑 pitfalls

# 错: outcome="skip_claimed" 非零即报      # 天天误报
# 对: 盯 stale_tasks 走高 + advance_error 非零

# 错: dropped > 0 → "数据丢了，全量重跑"
# 对: dropped > 0 → 队列满的信号：扩产能/查卡点，任务有兜底

# 错: 队列涨 → CONCURRENCY ×2 → CPU 打满 → 更多任务卡住
# 对: 对照工位配置 → 没满先调；满了查链路（COS / 1205-1213）

# 错: retrying 线一动就 pager
# 对: retrying 持续抬升 → 预警 · exhausted > 0 → critical

# 错: "对不上账" → 查 finalization_outcome_total
# 对: "对不上账" → 查 settlement（retrying/exhausted）+ unattributed

# 错: "reaper 会不会重复生成、重复计费？"   # 不会：它只推进结局
# 对: 90s 无动静 → 推进结局；超 24h 才 forced_timeout 强制收敛

# 错: siliang_video_reaper_stale_tasks 单点报警
# 对: max_over_time(siliang_video_reaper_stale_tasks[10m]) 持续走高才报

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

🔗 相关课程