143 lines
3.9 KiB
Markdown
143 lines
3.9 KiB
Markdown
# HANDOFF 2026-04-19 03:41
|
||
|
||
## 本轮做了什么
|
||
|
||
这轮没有扩功能，只沿着检测执行停滞的最小路径继续推进，完成了：
|
||
|
||
1. 将提交 `c33f4f1` 部署到：
|
||
- `mainland-worker-01`
|
||
- `mainland-controller-01`
|
||
2. 重启两台大陆节点的 `domaincheck-worker`
|
||
3. 验证 worker 控制消息补偿链是否在线上生效
|
||
4. 排查 controller 为什么没有像 worker 一样顺滑接入控制链
|
||
5. 修正 controller 运行环境中的 Redis 密码漂移
|
||
6. 再次下发 `detect/start`，确认 controller 真正收到并执行新启动指令
|
||
7. 再观察中央进度、recent events、sync-summary 是否继续前进
|
||
|
||
## 本轮关键结果
|
||
|
||
### 1. worker 控制消息补偿链已经线上生效
|
||
|
||
`mainland-worker-01` 明确出现：
|
||
|
||
- `发现待执行 Worker 控制指令`
|
||
- `已接受检测启动指令`
|
||
- `开始执行远程检测任务`
|
||
|
||
这说明：
|
||
|
||
- 上一轮代码修复不是只在本地成立
|
||
- pending 控制消息补偿消费链已经在线上闭合
|
||
|
||
### 2. controller 原先确实存在运行环境漂移
|
||
|
||
`mainland-controller-01` 的 `/etc/default/domaincheck-worker` 原始状态：
|
||
|
||
- `REDIS_HOST=127.0.0.1`
|
||
- `REDIS_PORT=6379`
|
||
- `REDIS_PASSWORD=`
|
||
|
||
对应日志：
|
||
|
||
- `Authentication required`
|
||
- `maximum recursion depth exceeded while calling a Python object`
|
||
|
||
这说明：
|
||
|
||
- controller 不是没重启
|
||
- 也不是代码没生效
|
||
- 而是本机 Redis 开了鉴权，但 worker 环境文件没带密码
|
||
|
||
### 3. controller 已完成最小修正并重新接上控制链
|
||
|
||
本轮已把 controller 的 `REDIS_PASSWORD` 补为：
|
||
|
||
- `Qazwe123..`
|
||
|
||
修正后再次重启，日志变为：
|
||
|
||
- `Redis 连接成功: 127.0.0.1:6379`
|
||
- `已接受检测启动指令`
|
||
- `开始执行远程检测任务`
|
||
|
||
之后再次触发 `/api/v1/detect/start`，controller 又出现：
|
||
|
||
- `发现待执行 Worker 控制指令`
|
||
- `收到启动检测指令，但检测任务已在运行，忽略重复启动`
|
||
|
||
这说明：
|
||
|
||
- controller 的控制链也已经恢复
|
||
- 现在不再是 Redis 断链问题
|
||
|
||
### 4. 当前唯一剩余阻塞已经进一步收紧
|
||
|
||
controller 当前最新现场日志反复出现：
|
||
|
||
- `代理已启用，但当前无可用代理`
|
||
|
||
这意味着当前唯一剩余主阻塞已经收紧为：
|
||
|
||
- `mainland-controller-01` 代理池没有可用代理
|
||
|
||
## 中央侧当前表现
|
||
|
||
正向信号：
|
||
|
||
- `remote_access_ready = 3/3`
|
||
- `log_sync_state = full_capture`
|
||
- `runtime/sync-summary` 最新记录继续增长到 `5491`
|
||
- recent events 已刷新到更晚时间
|
||
- `mainland-worker-01` 最新 domain_started 已推进到 `2026-04-19 16:37:00`
|
||
|
||
仍未恢复的信号：
|
||
|
||
- `items_completed = 21`
|
||
- `items_claimed = 34`
|
||
- `items_running = 14`
|
||
- `items_pending = 931`
|
||
- 短观察窗口内没有继续上涨
|
||
|
||
这说明：
|
||
|
||
- 控制链和同步链已经恢复到更健康状态
|
||
- 但执行吞吐还没有恢复成“持续出结果”
|
||
|
||
## 当前结论
|
||
|
||
当前最准确的判断是：
|
||
|
||
- 接管问题：基本已闭合
|
||
- 日志回传问题：已闭合
|
||
- worker 控制消息漏收问题：已闭合
|
||
- controller Redis 环境漂移：已闭合
|
||
- 当前唯一剩余阻塞：`mainland-controller-01` 代理池无可用代理
|
||
|
||
## 下一轮唯一应该做什么
|
||
|
||
下一轮不要发散，只做 controller 代理收口：
|
||
|
||
1. 继续观察 controller `domaincheck-worker` 日志
|
||
2. 重点看是否从：
|
||
- `代理已启用，但当前无可用代理`
|
||
转成：
|
||
- 至少有 `1+` 可用代理
|
||
3. 继续复查：
|
||
- `/api/v1/detect/job/active`
|
||
- `/api/v1/runtime/sync-summary`
|
||
- `/api/v1/ops/nodes`
|
||
4. 只判断一件事：
|
||
- controller 代理恢复后，`items_completed` 是否继续增长
|
||
|
||
## 现在不要做什么
|
||
|
||
- 不扩页面
|
||
- 不做新模块
|
||
- 不做控制面增强
|
||
- 不误判成“接管还没好”
|
||
- 不继续围绕 worker 控制消息链做重复修复
|
||
|
||
## 一句话结论
|
||
|
||
这轮已经把系统从“控制链也有缺口”推进到了“控制链已恢复、只剩 controller 代理池无可用代理”。
|