feat: stabilize multi-region runtime sync and worker orchestration

docs/后台运行观察口径.md

@@ -0,0 +1,229 @@
+# 后台运行观察口径
+
+> 说明：这份文档主要解释页面怎么看。当前线上执行口径与判断顺序，统一以 [当前线上最终Runbook.md](/www/wwwroot/getDomain/docs/当前线上最终Runbook.md) 为准。
+
+更新时间：`2026-04-24 14:24`
+
+## 先说结论
+
+以后不要先盯散乱日志。
+
+日志只是辅助定位。
+
+现在优先看后台 `运行中心` 第一屏。
+
+那里已经会直接告诉你：
+
+- 全库总盘子有多少
+- 当前活跃批次到底有多少
+- 近 15 分钟真实推进了多少
+- 当前到底算不算真跑起来了
+- 还有多少待处理
+- 真正有多少进程和线程在干活
+- 最近 15 分钟处理了多少
+- 失败多不多
+- 黑名单有没有推进
+- 当前最忙的是哪些进程
+- 主要积压卡在哪几个步骤
+
+只有在后台页面临时不可用，或者你想在终端里持续盯时，才再用下面这条命令：
+
+```bash
+cd /www/wwwroot/getDomain
+./.venv/bin/python tools/runtime_observer.py
+```
+
+如果想持续盯着看，就用：
+
+```bash
+cd /www/wwwroot/getDomain
+./.venv/bin/python tools/runtime_observer.py --watch 5
+```
+
+它会把和后台首屏同一套核心数字收成一屏，不用再自己去拼：
+
+- 当前任务是谁
+- 还有多少待处理
+- 真正有多少进程和线程在干活
+- 最近 15 分钟到底处理了多少
+- 失败多不多
+- 黑名单有没有推进
+- 哪几个节点真的在跑
+- 每一步卡在哪
+
+## 先看哪 4 组数
+
+脚本里最重要的是这 4 行：
+
+### 1. 任务积压
+
+看：
+
+- `pending`
+- `claimed`
+- `running`
+
+这组数回答的是：
+
+- 还有多少活没做
+- 有没有任务已经被领走
+- 当前有多少任务处于运行中
+
+### 2. 结果产出
+
+看：
+
+- `completed`
+- `failed`
+- `blacklisted`
+
+这组数回答的是：
+
+- 成功推进了多少
+- 失败了多少
+- 黑名单命中了多少
+
+### 3. 执行面
+
+看：
+
+- `active_processes`
+- `active_threads`
+- `max_threads`
+
+这组数回答的是：
+
+- 现在到底有多少执行实例真的在动
+- 当前用了多少线程
+- 当前理论上限是多少
+
+### 4. 最近吞吐
+
+看：
+
+- `processed_recent`
+- `per_minute`
+- `failed_recent`
+- `blacklisted_recent`
+
+这组数回答的是：
+
+- 最近 15 分钟有没有真实推进
+- 大概每分钟能跑多少
+- 最近失败是不是很多
+- 最近有没有新的黑名单命中
+
+## 怎么判断“真跑起来了”
+
+满足下面这 3 条，才算真跑：
+
+1. `pending` 还有积压
+2. `active_threads` 不是 0
+3. `processed_recent` 持续增长
+
+如果只是页面上显示 `running`，但：
+
+- `active_threads` 接近 0
+- `processed_recent` 也接近 0
+
+那更像是：
+
+- 旧状态残影
+- 口径没收准
+- 或者任务挂着但没真正消化
+
+## 怎么快速判断卡在哪
+
+### 情况 1：`pending` 很高，`active_threads` 很低
+
+说明更像：
+
+- 没真正拉起执行面
+- worker 没开始干活
+- 或者任务没正确分发进去
+
+### 情况 2：`active_threads` 不低，但 `failed_recent` 很高
+
+说明更像：
+
+- 不是没跑
+- 而是外部步骤在大量失败
+- 常见就是代理、RDAP、爱站、时光机这类链路超时
+
+### 情况 3：`completed_recent` 很低，`blacklisted_recent` 也很低
+
+说明更像：
+
+- 线程虽然在跑
+- 但结果大多没形成有效推进
+- 更像在外部失败里空转
+
+### 情况 4：节点列表里只有一台在有动作
+
+说明更像：
+
+- 当前真正承担执行的就一台
+- 其他节点可能只是在线
+- 或者只是历史残影，不是真正参与执行
+
+## 为什么不要先盯日志
+
+因为日志只能回答：
+
+- 某一步报了什么错
+- 某个实例刚才做了什么
+
+但它回答不了：
+
+- 现在到底有多少进程真在跑
+- 一共跑成功了多少
+- 黑名单推进了多少
+- 当前整体吞吐是上升还是下降
+
+所以顺序应该固定成：
+
+1. 先看后台 `运行中心` 第一屏
+2. 再看节点列表和步骤分布
+3. 只有需要深挖时，再看 `runtime_observer.py` 或具体日志
+
+## 一句话记法
+
+先看：
+
+- 有没有积压
+- 有没有执行面
+- 最近有没有吞吐
+
+这 3 个一起动，才算真的在跑。
+
+## 现在先看哪 3 块
+
+后台第一屏已经拆成这 3 个核心口径：
+
+### 1. 总盘子（全库）
+
+回答的是：
+
+- 海外主库现在一共有多少域名
+- 全库还有多少待检测
+- 全库已经通过、失败、黑名单各多少
+
+### 2. 当前活跃批次
+
+回答的是：
+
+- 当前正在跑的是哪一批
+- 这一批的展示口径有多少
+- 这一批的原始口径有多少
+
+这一块非常重要。
+
+它不是全库总量。
+
+### 3. 近窗吞吐
+
+回答的是：
+
+- 最近 15 分钟到底推进了多少
+- 每分钟大概多少
+- 最近完成、失败、黑名单各多少