230 lines
4.6 KiB
Markdown
230 lines
4.6 KiB
Markdown
# 后台运行观察口径
|
||
|
||
> 说明：这份文档主要解释页面怎么看。当前线上执行口径与判断顺序，统一以 [当前线上最终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 分钟到底推进了多少
|
||
- 每分钟大概多少
|
||
- 最近完成、失败、黑名单各多少
|