四两线上监控知识图谱 · 费曼版

🍽️ 人话：此刻有多少人“坐在画布前”。把所有 worker 上的 WebSocket 会话按 user_id 去重后求和。

回答：产品的实时热度如何？发布/故障后用户是不是掉光了？

✅ 随业务节奏起伏；背景色 <50 绿 / 50–200 黄 / >200 红

🚨 归零或骤降 = 接入层/WS 出问题；注意同一用户跨 worker 会被算成两人，这是近似值

sum(siliang_ws_online_users{job="siliang_backend_worker"})

🍽️ 人话：聊天室里有两个数——“几个人”（去重用户，一人开 5 个页签只算 1）和“几条电话线”（在途 SSE 连接数，每个页签一条）。

回答：聊天功能有多少真人在线？连接数和人数比例正常吗？

✅ 连接数 ≈ 人数 × 人均页签数，波动正常；阈值 100/400

🚨 连接数持续上涨不回落 = 监听生成器泄漏（挂了的 SSE 没人挂断）

sum(siliang_chat_resume_active_listener_users) / sum(siliang_chat_resume_active_listeners)

🍽️ 人话：有多少个“画布房间”里还有人。有活跃 WS 会话的 workspace 数。

回答：协作发生的房间数——衡量真实协作广度。阈值 100/300。

sum(siliang_ws_workspaces_active{job="siliang_backend_worker"})

📖 人话：说明书。“在线”有三种，别混：①画布 WS 在线 ②聊天 SSE 在线 ③全能/生图/视频的 SSE 不在这两个数里（要看 HTTP 在途和 LLM 并发）。

还解释了为什么只信 job=siliang_backend_worker：共享端口的 server job 随机命中 worker、会双计数，已全部排除。

🍽️ 人话：把上面所有“在线数”画成 6 条时间曲线：去重用户、聊天用户、在线画布、WS 会话总数、pubsub 订阅任务、聊天 SSE 监听。

回答：一天的业务节奏长什么样？增长还是流失？发布前后对比如何？

✅ 曲线平滑起伏、彼此比例稳定

🚨 某条线脱离大部队独自爬升 = 对应资源在堆积（如 pubsub 任务）

sum(siliang_ws_online_users) / …_workspaces_active / …_sessions_active / …_pubsub_tasks_active

🍽️ 人话：每条聊天“电话线”挂断时的 reason：completed=正常听完；disconnected=用户直接关页面（大多数，正常）；lease_expired=worker 租约失效后收敛退出；error=读流出异常。

回答：SSE 链路健壮吗？

✅ disconnected + completed 占绝对多数

🚨 error 频繁 = 上下行不稳；lease_expired 高 = 实例在异常退出

sum(rate(siliang_chat_resume_listener_outcome_total[5m])) by (outcome)

🍽️ 人话：后厨此刻有多少张“未出餐的订单”。历史教训：这些任务曾经只进不出，把内存吃爆。

回答：泄漏修复后有没有复发？这是本仪表盘最重要的一个数。

✅ 稳态个位数~几十；<20 绿 / 20–50 黄 / >50 红

🚨 持续单调增长 = 任务只进不出 = 泄漏复发，立刻去趋势图确认

sum(siliang_chat_resume_active_generation_tasks{job="siliang_backend_worker"})

🍽️ 人话：同一个数的曲线版。大数字只告诉你“现在多少”，曲线才告诉你“它在往哪走”。

✅ 健康曲线围绕某个值上下波动（锯齿）

🚨 只涨不跌的斜线 = 泄漏，对照内存仪表盘 RSS 形态互证

sum(siliang_chat_resume_active_generation_tasks[曲线])

🍽️ 人话：后厨订单的结局——正常出餐 vs 厨房着火（exception）。

回答：后台任务失败率高不高？

🚨 exception 比例高 = 频繁失败，翻日志；失败重试还会推高内存

sum(rate(siliang_chat_resume_generation_task_outcome_total[5m])) by (outcome)

🍽️ 人话：分布式系统的“心跳+遗嘱”。每个后台任务在 Redis 里立了租约（谁活着谁续约）；这里统计续约失败和清理失败。

回答：多实例协作机制本身有没有坏？

✅ 长期为 0

🚨 redis_error 高 = Redis 不稳；missing_lease 高 = 租约逻辑 bug；lease_expired_failed 高 = 清理逻辑异常

rate(siliang_chat_resume_lease_refresh_failed_total[5m]) by (reason) + rate(siliang_chat_resume_lease_expired_failed_total[5m])

🍽️ 人话：“收尸计数器”——某个实例崩了/租约过期后，由别的实例替它把烂尾任务收尾的次数。

回答：有没有实例在异常退出？

✅ 偶发为 0；active 稳定而 stale 高 = 有实例异常退出（对照发布记录）

sum(rate(siliang_chat_resume_stale_finalized_total[5m])) by (reason, status)

🍽️ 人话：每家大模型（gpt-5 / xAI / MiniMax…）每秒被我们 call 几次——钱花在哪家的实时账。

回答：调用量分布与突增（也被刷/活动时最先动的一条线）。

sum(rate(siliang_llm_calls_total[5m])) by (provider)

🍽️ 人话：每家供应商的“失约率”= 失败次数 ÷ 总次数。

✅ <5% 绿 / 5–10% 黄

🚨 >10% 红：多半是 provider 限流（429）或 key 失效——切流量或换 key，不是我们的 bug

rate(siliang_llm_calls_total{outcome="error"}[5m]) / clamp_min(rate(siliang_llm_calls_total[5m]), 1)

🍽️ 人话：此刻每家供应商有几通“电话正在通话中”（在途调用）。

回答：LLM 是不是成了瓶颈？持续高位 = 大家在排队等模型回话。

🚨 持续高位且用户等得久 → 扩并发额度 / 换更快的模型 / 上队列

sum(siliang_llm_active_calls{job="siliang_backend_worker"}) by (provider)

🍽️ 人话：用户等模型回话要多久——典型体验看 P50，最惨的 5%/1% 看 P95/P99。

✅ gpt-5 长输出跑到 60s+ 属正常，别当成故障（单位：秒）

🚨 P50 突然整体抬升 = provider 变慢/限流；对照错误率面板互证

histogram_quantile(0.50/0.95/0.99, sum(rate(siliang_llm_call_duration_seconds_bucket[5m])) by (le, model))

🍽️ 人话：backend 每个接口每秒被调几次（handler=路由模板，不含 /api/v2 前缀）。

回答：谁是最忙接口？流量结构有没有突变？

🚨 无发布无活动却突增 = 被刷/爬虫；某接口流量归零 = 上游调用方挂了

sum(rate(siliang_http_requests_total[5m])) by (handler)

🍽️ 人话：每秒有多少次“服务员自己把菜搞砸了”（服务端错误，按 handler 拆开）。

回答：现在有没有事故？哪个接口在出事故？

🚨 >1 req/s 就该排查（DB / Redis / 依赖故障），按 handler 直奔日志

sum(rate(siliang_http_requests_total{status=~"5.."}[5m])) by (handler)

🍽️ 人话：此刻店里有多少客人没走（在途请求）。多一条“ops 排空口径”参考线，专盯发布。

回答：请求在不在排队？发布时旧 worker 有没有干净退场？

✅ 滚动发布时每个 worker 的在途数应逐个归零

🚨 持续高位 = 排队（DB 慢查询或依赖抖动）；发布后不归零 = 排空卡住

sum(siliang_http_requests_in_progress) by (method) + sum(siliang_ops_http_in_flight)

🍽️ 人话：全站最慢的 10 个接口排行榜（P99=最惨的 1% 请求的等待时间）。这就是你的“性能优化待办清单”。

回答：该优化哪个接口？优化后变快了吗？

topk(10, histogram_quantile(0.99, sum(rate(siliang_http_request_duration_seconds_bucket[5m])) by (le, handler)))

🍽️ 人话：画布协作此刻有多少条“对讲机”在线。

✅ 与在线用户数成比例（约每人 1–2 条）；<100 绿 / 100–500 黄

🚨 持续上涨不回落 = 连接泄漏（断了没回收）

sum(siliang_ws_connections_active{job="siliang_backend_worker"})

🍽️ 人话：敲门之后的结果：accepted=请进；其他 = 鉴权失败 / 超限 / Origin 不对，被拒之门外。

✅ accepted 一枝独秀

🚨 哪种拒绝高就是哪类问题：鉴权失败=token 问题；超限=连接数上限；Origin=跨域配置

sum(rate(siliang_ws_connections_total[5m])) by (outcome)

🍽️ 人话：协作神经系统的病变类型。teardown_step 高 = Redis 故障留下“幽灵 session”（人走了系统以为还在）；redis_pubsub > 0 = 跨实例广播失明——你在 A 机器画，B 机器上的同伴看不到。

✅ 长期贴地

sum(rate(siliang_ws_errors_total[5m])) by (error_type)

🍽️ 人话：一条“对讲机”平均开多久。连接总要结束（关页/超时），时长分布能暴露“该死的没死”。

🚨 P99 异常长 = 僵尸连接（teardown 清理没触发），与活跃连接数互证

histogram_quantile(0.50/0.95/0.99, sum(rate(siliang_ws_connection_duration_seconds_bucket[5m])) by (le))

🍽️ 人话：↑ 用户在画布上做的每个动作（拖拽/编辑…）传到服务器的速度，按 event type 拆开。

回答：协作活跃度；哪种操作最频繁（决定优化优先级）。

sum(rate(siliang_ws_messages_received_total[5m])) by (type)

🍽️ 人话：↓ 服务器把变更广播给房间里其他人的速度。接收是“进话”，发送是“出话”。

回答：广播压力多大？接收正常而发送归零 = 广播链路（pubsub）出问题。

sum(rate(siliang_ws_messages_sent_total[5m])) by (type)

🍽️ 人话：客户端每隔几秒报一次“我还活着”（presence:ping）和“我的光标在这”（cursor/select）。

回答：有多少“活人”在动。心跳归零但连接还在 = 全是僵尸连接。

sum(rate(siliang_ws_heartbeat_messages_total[5m])) by (type)

🍽️ 人话：算账服务的两条线——查询成不成功（ok/failed），以及 unattributed=“找不到主人的消费”（结算时无法通过会话确认这笔账算哪个画布的）。

回答：用户的钱算得准不准？

🚨 unattributed 持续增长 = 计费归因缺口（少收/错账），这是收入完整性问题

rate(siliang_workspace_consumption_query_total[5m]) by (endpoint, result) + rate(siliang_workspace_consumption_unattributed_total[5m])

🍽️ 人话：查账单要等多久（按端点拆）。聚合统计类 SQL 会随数据量变慢。

🚨 持续升高 = 聚合查询需要优化（索引/预聚合）

histogram_quantile(0.95, sum(rate(siliang_workspace_consumption_query_duration_seconds_bucket[5m])) by (le, endpoint))

🍽️ 人话：点“生成”之后正式开工前的“前奏”三段耗时 P95：Planner 规划 → Case 检索 → 首个可见进度事件。用户感知的“卡不卡”很大程度在这。

回答：生成体验的第一印象快不快？慢在哪一段？

histogram_quantile(0.95, …) on siliang_inspiration_plan / _search / _first_visible_duration_ms_bucket（单位 ms）

🍽️ 人话：灵感链路的三种“不如意”：empty=检索啥也没搜到；degraded=某阶段坏了走备用路（按错误码）；skipped=语义上主动跳过。

✅ 偶发正常

🚨 degraded 持续增长 = 向量库/案例库不稳，用户拿到的是降级体验

rate(siliang_inspiration_empty_total) / …_degraded_total by (error_code) / …_skipped_total by (reason)

🍽️ 人话：检索“ Fishing ”收获如何——召回命中数 P95、其中投影完整有效多少、损坏无效多少。相当于渔网捞上多少鱼、多少是烂的。

🚨 invalid_document 持续偏高 = 向量库文档损坏或投影字段缺失（搜到了但用不了）

histogram_quantile(0.95, …) on siliang_inspiration_vector_hit / _valid_document / _invalid_document_count_bucket

🍽️ 人话：检索量按 backend（现在只有 vector，留了混合召回扩展位）+ 向量库失败按原因（timeout/error）。

🚨 失败速率持续 > 0 = 向量库不稳 → 拖慢首屏 + 触发降级（与上两张卡互证）

rate(siliang_inspiration_retrieval_total[5m]) by (backend) + rate(siliang_inspiration_vector_failure_total[5m]) by (reason)

🍽️ 人话：招聘视角——candidate=进入面试的人（合并排序后的候选数），selected=最终录取数。

回答：检索效果的质量趋势。

🚨 candidate 持续走低 = 召回变窄（网眼变大）；candidate 高而 selected 低 = 排序/过滤过严（卡太狠）

histogram_quantile(0.95, …) on siliang_inspiration_candidate_count_bucket / _selected_count_bucket

🍽️ 人话：过去 1 小时数据库“抢座位吵架”了几次。这是锁专项修复（L-21）留下的哨兵：删除节点/换源的重试兜底每触发一次计一次。

回答：锁问题修干净了吗？有没有新的锁窗口冒出来？

✅ 根因修净后恒为 0（<1 绿）

🚨 ≥1 黄 / ≥10 红；持续 > 0 = 仍有锁窗口未收敛，去下面速率图定位

sum(increase(siliang_db_lock_errors_total{job="siliang_backend_worker"}[1h]))

🍽️ 人话：吵架细节——operation（删画布输出 / 节点换源）× code。1205=锁等待超时（等太久放弃），1213=死锁（俩事务互相等，数据库强制一个滚）。

回答：哪类操作在跟谁抢锁？修复上线后应归零并保持。

sum(rate(siliang_db_lock_errors_total[5m])) by (operation, code)

📖 人话：本盘使用说明书——instance 命名规则、server job 双计已排除、池面板“两张卡”用法（使用率卡看趋势告警 + 绝对值卡看上限）、5 条核心告警规则。

最重要的判定心法：线性爬升=真累积（查泄漏）；平台期=allocator 不归还（常态）。

🍽️ 人话：每个 worker 的体温计。RSS=物理内存真实占用（主看这条）；VMS=虚拟地址空间（虚高，仅参考）。

✅ 锯齿形（涨跌交替）健康；冲高后平台期 = allocator 不归还，常态

🚨 线性爬升永不回落 = 真泄漏，马上下钻下面几组找凶手

max_over_time(siliang_process_resident_memory_bytes[1m]) / …_virtual_memory_bytes（按机器 repeat）

🍽️ 人话：垃圾回收站里三个区各堆了多少“待处理垃圾”。gen0/1 周转快属正常波动。

🚨 gen2（老物件区）待回收持续爬升 = 泄漏早期信号：大对象赖在老年代不走。比 RSS 涨得更早，是预警器

max_over_time(siliang_python_gc_pending_objects{generation="0/1/2"}[1m])

🍽️ 人话：事件循环里的“待办便签”数量。协程也会泄漏——创建后忘了 await/cancel，便签越贴越多。

🚨 只涨不落 = 协程泄漏（对照后台任务数判断来源）

max_over_time(siliang_asyncio_tasks_active[1m])（每 worker 一条线）

🍽️ 人话：进程的“手指头”（线程）和“拿着的文件句柄”（FD）。子进程、网络连接、临时文件都要占 FD。

🚨 持续上涨不回落 = 子进程/连接/临时文件泄漏的旁证（FD 耗尽会直接报错 Too many open files）

max_over_time(siliang_process_threads[1m]) / …_open_file_descriptors[1m]

🍽️ 人话：重活“外包车间”（compute/batch 子进程池）当前在干几个活。CPU 密集型工作不阻塞主事件循环的关键。

回答：外包车间忙不忙？活是不是堆在车间里没人收？

max_over_time(siliang_process_pool_active[1m]) by (pool)

🍽️ 人话：垃圾车每秒出车几次（按代拆）。gen0/1 应该频繁出车。

🚨 gen2 长期不出车 + gen2 待回收爬升（上一组）= 大对象驻留实锤，两张图互证

sum by (generation) (rate(siliang_python_gc_collections_total[5m]))

🍽️ 人话：三条线 = ZIP 打包 / 快照合成 / skill 整包，各有多少个“正在手里的活”。这些活每个都攥着大块内存。

✅ 忙完就归零（所以叫稳态应归零）

🚨 有活一直挂着不归零 = 大对象滞留内存，RSS 抬升的直接嫌疑人

max_over_time(siliang_file_batch_archive_active / …_snapshot_compose_active / …_openapi_skill_package_active[1m])

🍽️ 人话：图片分割 / 画布裁剪正在处理几个。图片解码后体积暴涨（一张几 MB 的 PNG 解码后占几十 MB 内存），是典型的大对象来源。

🚨 挂着不归零 = 图片对象没释放

max_over_time(siliang_image_segmentation_active / …_workspace_crop_active[1m])

🍽️ 人话：沙箱线程的“跟踪台账”和“待清理队列”。设计上台账应该随用随清。

🚨 任一 worker 非零 = 对应的泄漏修复被回退了（代码里清理逻辑没了），按告警规则 >0 即报

max_over_time(siliang_sandbox_tracked_threads[5m]) / …_sandbox_cleanup_tasks_pending[5m]

🍽️ 人话：MiniMax 视频任务的两个“登记簿”——提交结果窗口（上限 1024 条）和已释放任务 ID 窗口（上限 4096 条）。登记簿满了要么挤掉旧的要么拒绝新的。

🚨 贴近上限 = 任务终态没收敛（该完成的一直占着坑），需上调窗口或排查终态逻辑

max_over_time(siliang_minimax_h3_tracked_entries{kind="submission_results"/"released_task_ids"}[10m])

🍽️ 人话：导演组（多智能体协作流程）的消息跟踪台账，处理完应清空。

🚨 只涨不回落 = N6-4 修复被回退

max_over_time(siliang_director_tracked_messages[5m]) by (kind)

🍽️ 人话：ZIP 产物 / 视频转存 / TTS 音频的“典型体重”（P95）。趋势参考——它解释了 RSS 为什么冲高：处理 200MB 的视频，内存必然先涨 200MB+。

用法：RSS 冲高时来这里对时间戳——谁在什么时候搬了大文件，一对照便知。

histogram_quantile(0.95, …) on siliang_file_batch_archive / _video_transfer / _tts_audio_bytes_bucket

🍽️ 人话：五类图像资产的典型体重：快照源图 / 分割图层 / skill 整包 / provider 生图返回 / Seedance 参考图。

用法：同上，定位“内存冲高时刻是谁的大图在处理”；provider 生图若突然变大，先怀疑上游换了默认分辨率。

histogram_quantile(0.95, …) on siliang_snapshot_compose_source / _image_segmentation_layer / _openapi_skill_package / _provider_image_response / _seedance_reference_bytes_bucket

🍽️ 人话：xAI 返回生图的体积分布（p50/p95 对照）。b64_json 格式会把图片塞进 JSON 文本，天然比 URL 形态大 33%+。

用法：判断响应是否异常膨胀（格式切换/分辨率变大），膨胀会直接放大内存峰值。

histogram_quantile(0.95/0.50, sum(rate(siliang_xai_image_response_bytes_bucket[5m])))

🍽️ 人话：ZIP / 视频转存 / TTS 三类活的结局（成功/exception）。

🚨 exception 高 = 频繁失败；失败任务的重试会反复占内存，和 RSS、在途面板三角互证

sum by (outcome) (rate(siliang_file_batch_archive_outcome_total / …_video_transfer_outcome_total / …_tts_outcome_total[5m]))

🍽️ 人话：快照合成 / skill 整包两类活的结局，同上。

sum by (outcome) (rate(siliang_snapshot_compose_outcome_total / …_openapi_skill_package_outcome_total[5m]))

🍽️ 人话：画布裁剪活的结局速率（正在处理几个看前面“图像处理在途”卡，这里看干得成不成功）。

sum by (outcome) (rate(siliang_workspace_crop_outcome_total[5m]))

🍽️ 人话：借出书 ÷ 藏书量，按 worker × 池（sync/async/checkpointer）拆。80% 黄 / 95% 红。

🚨 贴 100% = 池打满，请求开始排队（通常伴随某个慢查询）

max_over_time(siliang_db_pool_connections{state="checked_out"}[1m]) / on(instance,pool) max_over_time(siliang_db_pool_capacity[1m])

🍽️ 人话：上一张的绝对值版——实线=各 worker 借了几条，水平参考线=该池藏书量（sync 30 / async 80 / checkpointer 30）。看“离天花板还有几条”更直观。

siliang_db_pool_connections{state="checked_out"} + max by (pool) (siliang_db_pool_capacity)

🍽️ 人话：Redis 图书馆两张借书证——shared（业务共用池）和 broadcaster_pubsub（画布广播专用池）。广播池打满 = 协作消息发不出去。

max_over_time(siliang_redis_pool_connections{state="in_use"}[1m]) / on(instance,pool) …_capacity[1m]

🍽️ 人话：Redis 池的绝对值版——各 worker 借出几条 + 上限参考线。

siliang_redis_pool_connections{state="in_use"} + max by (pool) (siliang_redis_pool_capacity)

🍽️ 人话：出站电话总机（httpx 共享 client）上每 worker 正在占用的线路数。

用法：按 worker 展开——不均衡说明某个 worker 上的任务在狂打外部请求。

siliang_http_client_connections{state="active"} by (instance, client)

🍽️ 人话：到各家 provider 的“电话总机”本身还在不在（1=在，0=没了）。连接复用是省内存省延迟的关键设计。

🚨 有聊天流量时某 provider 掉 0 = 连接复用被回退（退回每次新建连接 → FD 和内存抖动）

max by (provider) (max_over_time(siliang_shared_http_client_alive[1m]))

🍽️ 人话：同一个 worker 画两条线——登记簿上的会话数（注册表）vs 实际活的连接数（握手计数）。两线应重合。

🚨 分叉 = 注册表里有“尸体”（连接断了但登记没销）——注册表泄漏的直接证据

siliang_ws_sessions_active vs siliang_ws_connections_active（同一 instance 对照）

🍽️ 人话：每个会话随身携带的“小背包”有多大（非共享状态）。正常 KB 量级；总量=会话数×单包大小。

🚨 总量 > 50MB 触发告警（口径卡规则）——要么会话数爆了，要么有人往背包里塞了大对象

siliang_ws_total_state_bytes + histogram_quantile(0.95, …_ws_session_state_bytes_bucket)

🍽️ 人话：四道安检门拦下了多少“超规行李”：上传预检 / 媒体下载 / XAI 生图 / provider 响应超限。护栏保护内存不被超大文件击穿。

拦截本身=护栏在工作；但高频拦截说明上游给的东西异常大，值得查源头。

rate(siliang_upload_precheck_rejected_total / …_media_download_rejected_total / …_xai_image_response_rejected_total / …_provider_image_response_rejected_total[5m])

🍽️ 人话：读快照先查缓存——命中了就省一次读取（省时省内存）。按 cache × result 看命中形态。

🚨 命中率突然崩了 = 缓存逻辑被改动/失效，读取压力和内存抖动会跟着上来

sum by (cache, result) (rate(siliang_read_snapshot_cache_total[5m]))

🍽️ 人话：rag / review 两个单进程服务的 RSS。

✅ RAG 处理大文件（LibreOffice 解析）时内存冲高属预期——关键看之后回不回落

🚨 冲高后不回落 + 逼近 2G 限额 = 下一个 OOM 受害者（rag 有前科）

max_over_time(siliang_worker_process_resident_memory_bytes{job=~"siliang-rag|siliang-review"}[1m])

🍽️ 人话：小弟们自己的 DB / Redis 借书证使用率。

siliang_worker_db_pool_connections{state="checked_out"} / …_capacity + …_redis_pool_connections / …_redis_…_capacity

🍽️ 人话：小弟池子的绝对值版，含上限参考线（review 是独立小池 5+5，特别容易被慢任务借空）。

siliang_worker_db_pool_connections / …_capacity + siliang_worker_redis_pool_connections / …_capacity

🍽️ 人话：视频轮询到 DONE 之后，后台工厂算钱的结局。retrying=再试一次，exhausted=试到没脾气放弃。

🚨 retrying/exhausted 高 = 定价或用量数据异常——这单钱算不出来（收入问题）

sum by (outcome) (rate(siliang_video_settlement_outcome_total[5m]))

🍽️ 人话：成功视频的“售后”——下载转存到 COS 再打终态标记的结局。

🚨 retrying/exhausted 高 = 转存/转码链路异常（用户的成品可能拿不到）

sum by (outcome) (rate(siliang_video_finalization_outcome_total[5m]))

🍽️ 人话：工厂门口排队待处理的活（收尾/结算两条队）+ 丢件率。队列满开始丢投递时任务不丢（有兜底扫描补投），但延迟恶化。

🚨 深度持续上涨 = 消化不足；丢弃率 > 0 = 已经满到往外丢了

sum(siliang_video_finalization_queue_depth / …_settlement_queue_depth) + rate(…_dropped_total[5m])

🍽️ 人话：工厂开了几个工位（VIDEO_FINALIZER_CONCURRENCY / VIDEO_SETTLEMENT_CONCURRENCY 当前值）。

用法：和左边队列深度对照——队排在涨而工位没开满？调大并发；调大还不行，收尾侧看转存链路、结算侧先看锁冲突面板。

max(siliang_video_finalization_worker_concurrency / …_settlement_worker_concurrency)

🍽️ 人话：“无人认领处理员”——用户关了页面没人轮询的视频任务（90s 无动静），服务端主动去推进结局。advanced=推进成功；forced_timeout=超 24h 强制收敛；skip_claimed=别的节点刚碰过（互斥跳过，正常）；advance_error=推进失败。

🚨 stale 待收割持续走高 = 没人看着的积压任务在变多

sum by (outcome) (rate(siliang_video_reaper_outcome_total[5m])) + max(siliang_video_reaper_stale_tasks)