d

2026-04-22 14:13:21 +08:00
parent e0406b5d0e
commit 7cbde2aa78
145 changed files with 23086 additions and 2243 deletions
--- a/docs/ops_center_runtime/IMPLEMENTATION_STATUS.md
+++ b/docs/ops_center_runtime/IMPLEMENTATION_STATUS.md
@@ -1,23 +1,189 @@
 # IMPLEMENTATION_STATUS

-更新时间：2026-04-19 03:41 CST
+更新时间：2026-04-19 21:25 CST

 ## 当前真实状态

 阶段判断：

- 海外单脑接管能力：约 `95%`
- 分布式检测真实执行能力：约 `88%~90%`
- 距离“可稳定上线并放心用后台发起检测”：约 `86%~89%`
+- 海外单脑接管能力：约 `97%`
+- 发布闭环真实可用度：约 `65%~70%`
+- 分布式检测真实执行能力：约 `80%~85%`
+- 距离“可稳定上线并放心用后台发起检测”：约 `78%~82%`
+
+## 21:17 最新校正
+
+刚完成的 `mainland-worker-01` 正式 rollout 已给出最终根因：
+
+- `job 211 / rollout 6 / release 7`
+  - 发布包下载成功
+  - release 解压成功
+  - `current` 软链切换成功
+  - 最终失败在服务重启：
+    - `restart failed: domaincheck-worker`
+    - `Failed to restart domaincheck-worker.service: Interactive authentication required.`
+
+这说明：
+
+- 当前 ReleaseHub 主链路本身已可推进到“切换 current”
+- 真正未闭环的是 mainland node-agent 的 systemd 权限
+- 只要 node-agent 仍以 `www` 运行，后续 `deploy.release / service.restart` 都会在 systemd 这一跳失败
+
+已完成的代码侧修正：
+
+- `domain-api/deploy/systemd/domain-node-agent.service`
+  - 改为 `User=root`
+  - 改为 `Group=root`
+- `domain-api/deploy/multi-region/fix_mainland_release_base.sh`
+  - 改为给 node-agent drop-in 写入 `User=root` / `Group=root`
+
+因此当前真实上线完成度需要再补一句校正：
+
+- 发布闭环真实可用度：
+  - 不是“发布包模型还没修”
+  - 而是“node-agent 权限模型还差最后一次现网切换”
+
+## 21:25 最新进展
+
+worker 侧的现网切换已经完成验证成功：
+
+- `mainland-worker-01`
+  - 已把 `domaincheck-node-agent` 切为 `root`
+  - 随后重新发起：
+    - `rollout_id = 7`
+    - `job_id = 214`
+  - 最终结果：
+    - `job 214 = success`
+    - `rollout 7 = completed`
+
+正式成功证据：
+
+- `agent_completed`
+  - `summary_text = release deployed`
+- `restart_results[domaincheck-worker].returncode = 0`
+- `health_check.ok = true`
+- `systemd ExecStart` 已对齐：
+  - `/opt/domaincheck/current/domainCheck/detect_worker.py`
+
+因此当前关于发布闭环的真实判断应更新为：
+
+- worker 发布闭环：
+  - 已从“卡在 systemd restart 权限”推进到“真实成功”
+- 当前剩余风险不再在 worker
+- 当前剩余预防项在 controller：
+  - `domaincheck-node-agent` 也应同步切为 `root`
+
+## 顶部校正
+
+今天晚上的最新结论，需要覆盖前面一部分偏乐观判断：
+
+- 最新发布包问题已经定位并修复：
+  - 之前发布包漏掉了 `domainCheck/`
+  - 现在最新签收包 `domaincheck_release_20260419_205437` 已经包含 `domainCheck/`
+- 但对 `mainland-worker-01` 的正式发布验证证明：
+  - 线上 mainland 节点目前还不满足现有 ReleaseHub 发布模型
+- 已确认的真实阻塞有两个：
+  - `deploy.release` 在 `mainland-worker-01` 上会因为
+    - `Permission denied: /opt/domaincheck/downloads`
+    - 而直接失败
+  - mainland 两台节点当前 `domaincheck-worker` 的 `ExecStart` 都直接指向：
+    - `/opt/domaincheck/domainCheck/detect_worker.py`
+    - 而不是 `/opt/domaincheck/current/domainCheck/detect_worker.py`
+
+这两个事实组合起来说明：
+
+- 当前发布链虽然在控制面上已经成型
+- 但 mainland 线上节点的安装形态还是旧模式
+- 所以当前不能再把“已能稳定 rollout 新版本”算进上线完成度
+
+## 今晚新增硬证据
+
+- `mainland-worker-01`
+  - `job 204 / rollout 5` 已正式失败回写
+  - 失败原因已收口为：
+    - `install_root not writable: /opt/domaincheck/downloads`
+  - 只读核验得到的实际服务状态仍是旧进程：
+    - `Active since Sun 2026-04-19 18:18:50 CST`
+    - `Main PID = 635924`
+    - `CPU = 18.994s`
+  - 说明 worker 当前并没有切到新包，也没有形成可信的新吞吐样本
+- `mainland-controller-01`
+  - 当前 `domaincheck-worker` 虽然在高负载运行
+  - 但服务启动路径同样是：
+    - `/opt/domaincheck/domainCheck/detect_worker.py`
+  - 说明 controller 也没有对齐 `current` 软链发布模型
+
+## 本轮代码侧新增收口
+
+- 已补齐发布包构建：
+  - `package_domain_release.sh`
+  - `verify_domain_release.sh`
+  - `package_domain_release.ps1`
+  - `verify_domain_release.ps1`
+  - 现在发布包会包含 `domainCheck/`
+- 已补齐发布执行器的失败可观测性：
+  - `domain-api/app/services/ops_release_executor_core.py`
+  - 现在会在发布目录不可写时显式返回失败结果
+  - 同时补充 `ExecStart` 与 `current` 软链的对齐观测
+- 已补齐 node-agent 的兜底失败回写：
+  - `domain-api/app/node_agent.py`
+  - 避免以后再出现任务已经炸掉但控制面一直卡在 `running`

 ## 本轮最新结论

-这轮结论需要更新为四段：
+新增结论：

- 接管与同步能力已经明显趋于完成
- worker 控制消息补偿链已经完成线上验证
- controller 运行环境漂移已经被现场修正
- 当前唯一剩余主阻塞已经收紧到 controller 代理池无可用代理
+- 检测页观察面已完成一轮线上收口：
+  - `任务日志控制台` 已移到事件表上方
+  - `检测事件流` 已改成独立滚动区
+  - 已在真实线上静态目录重建生产包并通过本机 `3201` 端口验证
+  - 当前如果用户仍看到旧布局，优先判断为浏览器缓存而不是部署未生效
+- 代理链已完成策略切换：
+  - worker 启动后会主动刷新代理池
+  - 配置更新后也会主动刷新代理池
+  - 后台已能区分：
+    - `等待首刷`
+    - `proxy_validation_zero`
+    - `直入池`
+  - 当前本机最新真实结果是：
+    - 原始代理 `270`
+    - 预验证 `0`
+    - 直入池 `270`
+  - 说明当前问题已经从“代理校验过严导致池为空”切换为“真实任务内动态淘汰失效代理”
+
+- `mainland-controller-01`
+  - 已确认解除“代理不足即同步刷新、反向压死并发”的旧限制
+  - 海外后台当前已能看到：
+    - `active_threads = 99~100`
+    - `max_threads = 100`
+  - 说明 controller 的 `100` 并发已经真实生效
+- `mainland-worker-01`
+  - 已重新部署最新版 `detect_worker.py`
+  - 已重新接收新的 `sync-pull` 批次并重进检测：
+    - `开始执行域名检测任务`
+    - `开始检测，刷新代理池`
+    - `代理池刷新完成，共 23 个可用代理`
+    - `开始创建线程，当前批次域名数: 400，最大线程数: 50`
+  - 当前 worker 进程本机线程量已到：
+    - `152` 个 OS 线程
+  - 说明它并不是没启动，而是已经进入新批次执行
+- 当前剩余偏差：
+  - overseas 后台对 `mainland-worker-01.active_threads/current_load` 的显示仍偏低
+  - 这已经从“真实执行问题”收敛为“运行态上报 / 显示口径问题”
+
+这一轮不是只修了显示问题，而是把“大陆节点真实执行 + worker 日志回传”一起补齐了。
+
+当前最新结论：
+
+- controller 的 `pull_tasks -> 本地队列` 断点已经修通
+- 两台大陆 worker 都已经进入真实镜像队列执行
+- `mainland-worker-01` 的 `worker_log` 已开始直接回灌 overseas `detect_debug_events`
+- `runtime_projection` 权限问题已经修复，后台运行态同步恢复
+- `/api/v1/ops/nodes` 已能证明 controller 的高并发真实生效
+- 当前剩余问题已经收敛为：
+  - `mainland-worker-01` 运行态显示口径仍需继续对齐
+  - 检测页主计数口径是否完全跟上
+  - 结果统计回推是否持续稳定

 ## 当前证据拆分

@@ -25,210 +191,273 @@

 已经完成：

- `detect_result_projection` 支持 `recent_domain_events`
- 中央 ingest 会把逐条事件写入 `detect_run_events`
- `sync_agent` 会自动产出 `detect_result_projection`
- worker 控制消息新增 `request_id`
- worker 运行态心跳会补偿消费 pending 控制消息
- worker 收到并处理控制消息后会按 `request_id` 清理 pending 指令
+- `sync_push_service.ingest_detect_task_projection`
+  - 不再只导入 `domains`
+  - 已改为同时创建本地 `detect_jobs`
+  - 已改为同时创建本地 `detect_job_items`
+  - 已把 `target_job_id / target_job_code / queued_count / worker_start_ok` 回写到同步结果
+- `sync_agent`
+  - controller 现在会在每轮 `pull_tasks` 后自动唤起本地 worker
+- `detect_worker._set_active_cycle_context`
+  - 已兼容 `sync-pull` 控制消息
+  - 不再只读取 `job_id / job_code`
+  - 现在会回退读取 `target_job_id / target_job_code`
+- 运行态同步链
+  - controller `runtime/detect_runs.json` 权限已修正为 `www:www`
+  - `runtime_projection` 已恢复成功推送

 本地代码验证已通过：

- `unittest domain-api/tests/test_worker_control_service.py`
- `python -m py_compile domainCheck/detect_worker.py domain-api/app/services/worker_control_service.py`
+- `python -m py_compile domain-api/app/services/sync_push_service.py`
+- `python -m py_compile domain-api/app/services/runtime_control_service.py`
+- `python -m py_compile domain-api/app/sync_agent.py`
+- `python -m py_compile domainCheck/detect_worker.py`

-线上运行验证也已经出现正向证据：
+### 2. 接管 / 外部条件闭环

- `mainland-worker-01`
-  - 启动后发现待执行控制指令
-  - 接受 `start_detection`
-  - 开始执行远程检测任务
- `mainland-controller-01`
-  - 修正 Redis 环境后
-  - 重新接受 `start_detection`
-  - 开始执行远程检测任务
-
-### 2. 接管/同步闭环
-
-当前已完成：
+已经完成：

 - `remote_access_ready = 3/3`
- `log_sync_state = full_capture`
- `mainland-controller-01` 的 `domaincheck-sync-agent` 已重启到新进程
- 首轮 `detect_result_projection` 推送成功过一次
- 中央已收到 mainland 首批 `domain_*` 事件
+- `ssh_ready = 2`
+- 大陆 controller / worker 都可远程运维
+- controller `domaincheck-sync-agent` 在线
+- mainland 两台 `domaincheck-node-agent` 在线

-这说明：
+当前仍依赖你额外输入的部分：

- mainland 到中央的基础同步链是活的
- 结果投影链至少成功打通过一次
+- 暂无新的 SSH / 接管前置输入缺口
+- 如果页面仍显示旧状态，最多只需要你浏览器强刷确认，不需要再补 SSH 信息
+
+### 2.1 前端部署闭环
+
+已经完成：
+
+- 在线静态根目录确认：
+  - `/www/wwwroot/getDomain/domain-web/dist`
+- 在线 Nginx 配置确认：
+  - `/www/server/panel/vhost/nginx/domaincheck_3201.conf`
+  - `/www/server/panel/vhost/nginx/domaincheck_152.53.37.118.conf`
+- 生产包重建确认：
+  - `vite build` 成功
+- 线上资源确认：
+  - `DetectView-B9S1WMRT.js`
+  - `DetectView-BFxMNRNR.css`
+
+说明：
+
+- 检测页布局调整不是只停留在源码
+- 已经进入线上可访问静态产物
+
+### 2.2 代理运行态闭环
+
+已经完成：
+
+- worker 启动即触发代理池首刷
+- 配置变更后自动补刷
+- API 状态页已能准确显示：
+  - `proxy_not_refreshed_yet`
+  - `proxy_validation_zero`
+  - `宽松入池`
+
+当前最新证据：
+
+- `proxy_last_refresh_status = 直入池 270 个（跳过预验证）`
+- `proxy_last_refresh_total_items = 270`
+- `proxy_last_validated_count = 0`
+- `proxy_last_available_count = 270`
+
+说明：
+
+- 代理配置本身已成功下发
+- 代理源接口本身也能返回大量原始代理
+- 当前不再把“预验证是否通过”作为入池门槛
+- 现在改为让真实检测来完成失效代理淘汰

 ### 3. 检测执行闭环

-当前未完成：
+这一块现在已经从“怀疑恢复”进入“确认恢复”：

- 短观察窗口内：
-  - `progress_percent` 仍是 `2.1`
-  - `items_completed` 仍是 `21`
-  - `items_claimed` 仍是 `34`
-  - `items_pending` 仍是 `931`
- 中央 recent events 已刷新到更晚时间
- `runtime/sync-summary` 最新记录已继续增长
- 但 completed 尚未继续上涨
+- `mainland-controller-01`
+  - 已出现：
+    - `从任务队列获取到 800 个需要检测的域名`
+    - `最大线程数: 100`
+    - `当前实际线程数量: 1/100 ... 6/100`
+- `mainland-worker-01`
+  - 已出现：
+    - `从任务队列获取到 400 个需要检测的域名`
+    - `开始创建线程，当前批次域名数: 400，最大线程数: 50`
+    - `当前实际线程数量: 1/50 ... 3/50`
+    - `开始检测域名: 0-demagogo.com`
+    - `开始检测域名: 00123321.com`
+    - `开始检测域名: 001dm.com`

 这说明：

- 当前不是单纯“页面没刷新”
- 而是执行现场这段时间没有继续出结果
+- `100/50` 已不是“配置已写入但没生效”
+- 它已经进入真实任务消费
+- worker 的远端日志也已经跟着真实执行一起回传
+
+### 4. 海外后台可视证据
+
+`/api/v1/ops/nodes` 当前已显示：
+
+- `summary.remote_access_ready = 3`
+- `summary.participating = 3`
+- `summary.dispatch_active = 1`
+
+并且大陆两台都已经被判定为真实参与者：
+
+- `mainland-controller-01`
+  - `agent_state = online_busy`
+  - `participation_state = recent_throughput`
+  - `processed_recent = 115`
+  - `processed_per_minute = 7.67`
+  - `detect_runtime.max_threads = 100`
+- `mainland-worker-01`
+  - `agent_state = online_busy`
+  - `participation_state = recent_throughput`
+  - `processed_recent = 632`
+  - `processed_per_minute = 42.13`
+  - `detect_runtime.max_threads = 50`
+
+这说明：
+
+- 海外后台已经不只是看到“在线”
+- 现在已经能看到大陆节点的实际吞吐

 ## 本轮新增硬证据

-通过中央观测面、节点现场日志和远端 `domaincheck-worker` 日志，已确认：
+### 证据 1：controller 的镜像队列已经真正落库

- `mainland-controller-01` 现场日志显示：
-  - `当前可用代理数: 0`
-  - `最近结果: 刷新成功，可用 0 个`
- controller 新增远端日志显示：
-  - 代理源拉取成功
-  - 抽样校验后 `共 0 个可用代理`
-  - 失败集中在：
-    - `ProxyError@https://m.baidu.com`
-    - `Unable to connect to proxy`
-    - `ConnectTimeoutError`
- worker 新增远端日志显示：
-  - `发现待执行 Worker 控制指令`
-  - `已接受检测启动指令`
-  - `开始执行远程检测任务`
-  - 说明线上补偿消费链已真正工作
- controller 新增远端日志显示：
-  - 初次重启后：
-    - `Authentication required`
-    - `maximum recursion depth exceeded`
-  - 进一步排查确认：
-    - `/etc/default/domaincheck-worker` 的 `REDIS_PASSWORD` 为空
-  - 修正后再次重启：
-    - `Redis 连接成功: 127.0.0.1:6379`
-    - `已接受检测启动指令`
-    - `开始执行远程检测任务`
-  - 后续日志继续收紧到：
-    - `代理已启用，但当前无可用代理`
- 两台大陆节点 full capture 已开启，但源日志时间没有继续前进
+`sync-agent` 现场日志已出现：

-这说明：
+- `target_job_code = sync-overseas-7380`
+- `queued_count = 200`
+- `worker_start_ok = True`

- worker 控制消息链不再是主阻塞
- controller Redis 环境漂移也不再是主阻塞
- 当前第一主阻塞已经进一步收紧到 controller 代理池不可用
- worker 的时光机异常是客观存在的次级问题
- 不是控制面未接管
- 不是同步链未打通
+并持续产生：

-## 本轮新增代码修复
+- `sync-overseas-7383`
+- `sync-overseas-7386`
+- `sync-overseas-7392`
+- `sync-overseas-7417`

-本轮不是只停留在诊断，还补了一处运行态最小修复：
+说明：

-### 修复点 1：控制消息唯一标识
+- 大陆 controller 现在不是只拉数据
+- 而是在持续形成可执行批次

- 文件：
-  - `domain-api/app/services/worker_control_service.py`
- 变更：
-  - 每次 `send_worker_command(...)` 都附带 `request_id`
-  - Redis `publish` 与 pending fallback 使用同一份消息体
+### 证据 2：两台大陆 worker 都已转入真实队列

-### 修复点 2：worker 运行态补偿消费 pending 指令
+现场日志已明确出现：

- 文件：
-  - `domainCheck/detect_worker.py`
- 变更：
-  - 心跳线程每轮会补偿尝试消费 pending 控制消息
-  - 解决“worker 在线但 pubsub 消息漏收，导致 pending 指令长期不被消费”的风险
+- controller：
+  - `从任务队列获取到 800 个需要检测的域名`
+- worker：
+  - `从任务队列获取到 400 个需要检测的域名`

-### 修复点 3：worker 收到指令后确认清理 pending
+说明：

- 文件：
-  - `domainCheck/detect_worker.py`
- 变更：
-  - worker 实际收到控制消息后，会按 `request_id` 清理对应 pending 指令
-  - 避免修复后又产生重复回放
+- 当前不是兼容旧链路假运行
+- 是镜像队列真运行

-### 当前判断
+### 证据 3：runtime_projection 已恢复成功

-这组修复解决的是：
+修复前：

- “检测启动已经发布，但 worker 可能静默漏收”的代码风险
+- `refresh runtime_projection failed: [Errno 13] Permission denied`

-所以当前最准确的状态是：
+修复后：

- 代码级控制链缺口已补上
- 线上部署验证已通过
- 但 `controller` 代理池校验后 `0 available` 的现场阻塞仍然存在
+- 最新 `sync-agent` 日志已出现：
+  - `sync_state = success`
+  - `runtime_projection -> 投影推送成功`
+
+说明：
+
+- 后台运行态刷新和日志窗口不再被 controller 本地权限卡死
+
+### 证据 4：`mainland-worker-01` 的 `worker_log` 已进入 overseas
+
+`/api/v1/runtime/debug-events` 当前已能看到：
+
+- `mainland-worker-01 -> 开始执行检测任务，来源: redis-control`
+- `mainland-worker-01 -> 开始执行域名检测任务，正在加载配置`
+- `mainland-worker-01 -> 开始检测，正在刷新代理池`
+- `mainland-worker-01 -> 代理池刷新完成，共 7 个可用代理，来源链接 6 个，原始 265 个，验证 150 个`
+- `mainland-worker-01 -> 从任务队列获取到 400 个需要检测的域名`
+- `mainland-worker-01 -> 开始创建线程，当前批次域名数: 400，最大线程数: 50`
+- `mainland-worker-01 -> 当前实际线程数量: 1/50`
+- `mainland-worker-01 -> 当前实际线程数量: 2/50`
+- `mainland-worker-01 -> 当前实际线程数量: 3/50`
+
+说明：
+
+- worker 的真实执行链已经进入 overseas 的日志视图
+- “后台看不到大陆 worker 在干活”这一层已经闭合
+
+## 当前口径说明
+
+这里有一个非常关键的判断口径已经变化：
+
+- 大陆节点当前执行的是“海外任务在大陆本地落镜像队列，再把运行态和结果同步回海外”
+- 因此不能再只盯中央原生 `detect_job_items.claimed/running`
+- 现在应该同时看：
+  - `/api/v1/ops/nodes`
+  - `processed_recent`
+  - `processed_per_minute`
+  - `detect_runtime.active_threads/max_threads`
+  - 大陆 controller 本地 `sync-overseas-*` 队列
+
+如果只看中央原生队列，会误判“大陆没有参与”。

 ## 当前已闭合的问题

 已闭合：

- 大陆 controller 无法 `pull_tasks`
- Detect 页面误判“大陆没跑”
- Detect 主统计口径不一致
- Runtime / Queue / Detect 主摘要不统一
- 中央逐条事件接收缺口
- `sync_agent` 自动产出结果投影缺口
+- controller `pull_tasks` 只导入 domain、不导入本地队列
+- 大陆 worker 长时间卡在旧检测会话导致忽略新启动指令
+- controller `runtime_projection` 因文件属主错误无法推送
+- 大陆两台“在线但不确定是否真实执行”的状态模糊

-## 当前唯一剩余问题
+## 当前剩余问题

-当前唯一主问题仍然是：
+当前剩余问题已经缩成两个最小项：

- 检测执行面没有恢复到持续产出
-
-但现在已经不需要再拆成“代码待验证”和“现场阻塞”两层。
-
-当前唯一剩余现场阻塞就是：
-
- controller 代理池可用性为 0
- 因此没有持续产生新的 domain 级结果
+- Detect 页面主计数 `pending/completed/running` 是否继续推进
+- 结果统计回推是否稳定，而不只是日志链路先恢复

 换句话说：

- 现在不是逻辑未实现
- 不是中央映射失败
- 不是节点未接管
- 而是执行现场没有继续产出，且 controller 侧卡在代理校验失败
-
-## acceptance 当前状态
-
-最新接管验收结果仍然成立：
-
- `pbr-9ce5c85f17`：`onboarding.acceptance` 成功
- `pbr-389abd618c`：`onboarding.acceptance` 成功
-
-旧的 `attention` run 依然是历史残留，但它们已经不是当前最真实的生产阻塞。
+- 现在不是接管问题
+- 不是链路不通问题
+- 不是日志完全回不来问题
+- 而是最后一层“主计数推进 + 结果统计收口”问题

 ## 当前是否可以继续跑检测测试

 当前结论：

- 可以继续做最小运行态排查
- 但不需要再优先验证 worker 控制消息链
- 当前还不能把状态视作“后台检测已经稳定恢复”
+- 可以继续跑检测测试
+- 而且现在已经具备“后台可观测 + 大陆真实参与”的条件

 ## 当前是否建议直接上线

 当前结论：

- 不建议现在按“可稳定上线”判断
+- 已接近可上线状态
+- 但我仍建议把它视为“准上线收口态”，不是最终完全签收态

-原因不是接管面，而是执行面：
+原因：

- 三台节点都已接入
- worker / controller 都已重新接上控制链
- 但当前任务没有持续吞吐
- controller 代理池全部验不过会直接影响检测产出
+- 主执行链已经恢复
+- 但还需要再确认 1 到 2 个同步周期内页面口径与吞吐稳定性

 ## 当前优先级判断

 最高优先级：

- `J2-检测执行停滞收口批`
+- `J2-检测执行收口批`

 当前不应继续推进：

@@ -236,18 +465,19 @@
 - 新模块
 - 新页面
 - 发布动作
- 与检测执行停滞无关的工作
+- 与检测执行收口无关的工作

 ## 完成下一轮后的预期

 如果下一轮确认：

- controller 代理池恢复可用
- `domain_*` 开始继续增长
- `items_completed` 和近窗吞吐重新前进
+- Detect 页面主计数已跟上
+- 日志窗口持续刷新
+- `detect_result_projection` 持续推进
+- `processed_recent / processed_per_minute` 持续增长

-则整体可上线程度预计可回升到：
+则整体可上线程度预计可提升到：

- `92%~94%`
+- `96%~98%`

 在那之前，当前口径应保持保守。