admin/getDomain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

d

Browse Source
This commit is contained in:
Your Name
2026-04-22 14:13:21 +08:00
parent e0406b5d0e
commit 7cbde2aa78
145 changed files with 23086 additions and 2243 deletions
Download Patch File Download Diff File Expand all files Collapse all files

509
docs/ops_center_runtime/TASK_BOARD.md
View File

@@ -1,177 +1,456 @@
# TASK_BOARD
更新时间：2026-04-19 03:41 CST
更新时间：2026-04-19 21:25 CST
## 2026-04-20 主线切换说明
从这一刻开始，当前工作重心正式切回：
- 先跑通主任务流程
- 先推进 7 个大任务的测试与验收
- 并发、代理、DB 往返、展示层等细节优化先封存，不再抢主线
细节优化不删除，统一视为 backlog：
- worker pool 持续补位
- claimed 回弹压缩
- 高频 DB 更新继续合并
- 代理失败链和等待窗口继续压缩
- 运营视角页面继续细化
这些后续继续做，但不再打断主任务验收顺序。
当前主口径：
1. 大任务 1 真实验收闭环
2. 大任务 2 controller 编排闭环
3. 大任务 3 统一结果状态机闭环
4. 大任务 4 本地控制状态 + syncer/finalizer 闭环
5. 大任务 5 固定 worker pool 落地
6. 大任务 6 时光机一期接入
7. 大任务 7 运营视角面板闭环
## 21:17 最新补充
刚刚这轮真实 rollout 已经把 mainland worker 的最后一层阻塞拿实：
- `mainland-worker-01`
- `release_id = 7`
- `rollout_id = 6`
- `job_id = 211`
- 发布链路并不是卡在下载或解压：
- 发布包 `domaincheck_release_20260419_205437` 已下载到 `/opt/domaincheck/downloads`
- release 已解压到 `/opt/domaincheck/releases/domaincheck_release_20260419_205437`
- `/opt/domaincheck/current` 已切到新 release
- 最终失败点已经明确：
- `restart failed: domaincheck-worker`
- systemd 原因：
- `Interactive authentication required`
- 这说明当前 mainland 节点的 `domaincheck-node-agent` 虽然能写发布目录，但因为以 `www` 身份运行，无法执行：
- `systemctl restart domaincheck-worker`
当前新的唯一主阻塞已经进一步收敛为：
- node-agent systemd 运行身份不对
- 需要把 `domaincheck-node-agent` 改成 `root` 运行，发布链最后一跳才能闭环
本轮已在仓库内同步修正：
- `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`
## 21:25 worker rollout 收口
`mainland-worker-01` 已完成新一轮正式 rollout 收口成功：
- `release_id = 7`
- `rollout_id = 7`
- `job_id = 214`
结果确认：
- `job 214 = success`
- `rollout 7 = completed`
- `mainland-worker-01` 已恢复为：
- `agent_state = online_busy`
- 最近心跳恢复正常
控制面完成证据：
- `agent_completed`
- `summary_text = release deployed`
- `restart_results`
- `domaincheck-worker.returncode = 0`
- `health_check.ok = true`
- `execstart_alignment.mismatched_services = []`
这说明 worker 当前已经真正完成：
- 新包下载
- release 解压
- `current` 切换
- `domaincheck-worker` 重启
- 健康检查通过
当前关于 mainland rollout 的唯一剩余预防项变成：
- `mainland-controller-01` 也应该同步把 `domaincheck-node-agent` 切到 `root`
- 否则后续 controller 自身执行 `deploy.release / service.restart` 时还会踩到同类 systemd 权限问题
## 顶部校正
今天晚上的最新排查已经把当前主阻塞重新定性，之前“大陆两台已经完全进入统一新镜像执行”的判断需要收紧。
当前新增硬结论：
- 最新正式发布包已经重打并签收通过：
- `domaincheck_release_20260419_205437`
- 发布包现在已经确实包含 `domainCheck/`
- 对 `mainland-worker-01` 发起正式 smart rollout 后，真实失败原因已经拿到：
- `job 204 / rollout 5`
- 本次失败对应的正式 Release 版本仍是：
- `domaincheck_release_20260419_203933`
- 失败原因：
- `Permission denied: /opt/domaincheck/downloads`
- 该失败已通过正式 agent complete 回写，后台不再是假 `running`
- `mainland-worker-01` 当前运行中的 `domaincheck-worker` 仍是旧进程：
- `Main PID = 635924`
- `Active since = 2026-04-19 18:18:50 CST`
- `CPU = 18.994s`
- 说明它不是高吞吐新进程，而是老进程长期挂着
- `mainland-controller-01` 当前运行中的 `domaincheck-worker` 虽然活跃，但服务启动路径同样是：
- `/opt/domaincheck/domainCheck/detect_worker.py`
- 两台 mainland 节点当前 `domaincheck-worker` 的 systemd 启动路径都不是：
- `/opt/domaincheck/current/domainCheck/detect_worker.py`
这意味着：
- 当前 ReleaseHub 的 `current -> release_version` 切换模型，与线上 mainland 节点的实际服务启动路径不一致
- 即使发布包和签收链已经修好，线上节点也还没有具备“按当前发布模型热切版本”的条件
- 当前唯一主阻塞已经从“并发参数是否下发”切换成：
- mainland 节点发布权限/目录模型不匹配
- mainland 节点服务启动路径与发布模型不匹配
## 当前主批次
唯一主批次：`J2-检测执行停滞收口批`
唯一主批次：`J2-检测执行收口批`
目标：
- 不进入新页面
- 不扩展控制面
- 不新增发布动作
- 只收口当前唯一真实阻塞：
- 节点已接管
- 同步已打通
- 但检测执行没有继续产出新结果
- 只收口三件已经缩小到运行面的事情：
- 大陆节点必须真正进入统一镜像队列，而不是停留在兼容旧链路
- 后台必须能看到大陆节点的实时运行态与日志
- `100/50` 并发配置要从“已下发”推进到“真实有参与吞吐”
## 本轮最新状态
本轮已经完成“代码修复 -> 两台大陆节点部署 -> 运行态复查”的完整一轮验证。
### 20:53 最新阻塞结论
### 已完成的最小修复
- `mainland-worker-01` smart rollout 已真实失败，不再继续误判为执行中
- 失败证据：
- node-agent 日志：
- `2026-04-19 20:40:15 [node-agent] loop error: [Errno 13] Permission denied: '/opt/domaincheck/downloads'`
- 发布任务：
- `job 204 = failed`
- 发布批次：
- `rollout 5 = failed`
- 当前不应该继续把精力放在前端展示或并发口径微调上
- 当前必须先收口：
- mainland 节点 `deploy.release` 所需目录权限
- mainland 节点 systemd `ExecStart` 与 `/opt/domaincheck/current` 的一致性
- `worker_control_service.send_worker_command(...)`
- 为每条 worker 控制消息补上 `request_id`
- 保证 Redis 发布与 pending fallback 使用同一份负载
- `detect_worker`
- 在运行态心跳里周期性补偿消费 pending 控制消息
- 在真正收到控制消息后，按 `request_id` 清理 pending 指令
这轮已经完成从“控制链打通”到“真实执行恢复 + worker 日志回传恢复”的关键跨越。
本地验证已通过：
### 本轮前端已上线校验
- `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`
- 检测页 `任务日志控制台` 已调整到事件列表上方
- `检测事件流` 已改成独立滚动区：
- 表格 `max-height = 320`
- 避免事件越积越多把整个页面继续向下撑长
- 已在线上实际静态目录重新构建：
- `/www/wwwroot/getDomain/domain-web/dist`
- 已确认线上 Nginx 指向该目录：
- `domaincheck_3201.conf`
- `domaincheck_152.53.37.118.conf`
- 已通过 `http://127.0.0.1:3201/` 返回 `200` 且加载新资源：
- `DetectView-B9S1WMRT.js`
- `DetectView-BFxMNRNR.css`
### 已完成的线上验证
### 本轮代理链已收口
- `mainland-worker-01`
- 已拉到 `main` 最新提交 `c33f4f1`
- 已重启 `domaincheck-worker`
- 启动后明确出现：
- `发现待执行 Worker 控制指令`
- `已接受检测启动指令`
- `开始执行远程检测任务`
- 已修复 worker 在“代理配置已下发但尚未开始检测”时长期停留 `未刷新` 的问题
- `domaincheck-worker` 现在会在以下时机主动触发代理池刷新：
- worker 启动后
- `proxy_config / thread_count / node_thread_counts / runtime_settings` 更新后
- 当前后台状态已不再误报“未刷新”
- 代理策略已切到：
- 只去掉过期 / 非法代理
- 跳过预验证
- 直接入池执行
- 真实失败后立即淘汰并补刷
- 最新实测结果已经明确：
- 原始代理 `270` 个
- 预验证 `0` 个
- 当前可用代理 `270` 个
- 最近状态：
- `proxy_last_refresh_status = 直入池 270 个（跳过预验证）`
- `available_proxy_count = 270`
### 本轮已完成
- `sync_push_service`
- 已修复 `detect_task_ingest` 只落 `domains`、不落本地 `detect_jobs/detect_job_items` 的缺口
- controller 现在会为拉回来的海外批次持续创建本地镜像任务：
- `sync-overseas-7380`
- `sync-overseas-7383`
- `sync-overseas-7392`
- 持续增长中
- `mainland-controller-01`
- 已拉到 `main` 最新提交 `c33f4f1`
- 已重启 `domaincheck-worker`
- 发现运行环境漂移：
- `/etc/default/domaincheck-worker` 中 `REDIS_PASSWORD` 为空
- 已最小修正该节点运行环境后再次重启
- 修正后明确出现：
- `Redis 连接成功: 127.0.0.1:6379`
- `已接受检测启动指令`
- `开始执行远程检测任务`
- 已明确进入真实队列：
- `从任务队列获取到 800 个需要检测的域名`
- `最大线程数: 100`
- `当前实际线程数量: 1/100 ... 6/100`
- `mainland-worker-01`
- 已修复 `sync-pull` 控制消息上下文绑定缺口：
- `detect_worker._set_active_cycle_context` 现在会读取
- `target_job_id`
- `target_job_code`
- 已重启 `domaincheck-worker`
- 已明确进入真实队列：
- `从任务队列获取到 400 个需要检测的域名`
- `最大线程数: 50`
- `当前实际线程数量: 1/50 ... 3/50`
- 已明确把运行日志回传到 overseas：
- `开始执行检测任务，来源: redis-control`
- `开始执行域名检测任务，正在加载配置`
- `开始检测，正在刷新代理池`
- `开始创建线程，当前批次域名数: 400，最大线程数: 50`
- `当前实际线程数量: 1/50`
- `当前实际线程数量: 2/50`
- `当前实际线程数量: 3/50`
- `runtime_projection`
- 已定位 controller `domain-api/runtime/detect_runs.json` 权限错误
- 已把 `runtime` 目录和 `detect_runs.json` 改回 `www:www`
- `domaincheck-sync-agent` 最新日志已从
- `partial_success`
- 变成：
- `sync_state = success`
- `runtime_projection -> 投影推送成功`
- 海外控制面 `/api/v1/ops/nodes`
- 现已明确看到三台节点都在参与
- `remote_access_ready = 3`
- `participating = 3`
- `mainland-controller-01.is_current_participant = true`
- `mainland-worker-01.is_current_participant = true`
### 本轮仍未完成的事情
### 当前最关键的新证据
- 中央 `items_completed` 仍未在短观察窗口内继续增长
- `mainland-controller-01` 仍然持续报：
- `代理已启用，但当前无可用代理`
- 因此当前剩余阻塞已经进一步收紧到：
- controller 现场代理池没有可用代理
- `mainland-controller-01`
- `processed_recent = 115`
- `processed_per_minute = 7.67`
- `detect_runtime.max_threads = 100`
- `mainland-worker-01`
- `processed_recent = 632`
- `processed_per_minute = 42.13`
- `detect_runtime.max_threads = 50`
- `overseas-control-01`
- 仍在执行中央原生队列
- 当前判断：
- 大陆节点已经不是“纸面在线”
- 已经是真实参与检测执行
## 本轮最新复查结果
## 当前主判断
本轮在完成修复部署后，中央与节点现场出现了新的运行证据：
### 本轮新增结论
- 活跃任务仍是 `detect-20260417170546-96023e`
- `mainland-worker-01` 最新事件时间已经从旧窗口推进到：
- `2026-04-19 16:37:00`
- `runtime/sync-summary` 最新记录已继续增长到：
- `id = 5491`
- `created_at = 2026-04-19 03:40:45`
- 说明中央已经重新收到新的运行侧同步流量
- 但短窗口内主进度仍未松动：
- `completed = 21`
- `running = 14`
- `claimed = 34`
- `pending = 931`
- controller 现场最新日志已收紧为：
- `代理已启用，但当前无可用代理`
- `mainland-controller-01`
- 已修复“代理数量不足反向限制并发”的热路径问题
- 当前海外后台已稳定看到：
- `active_threads ~= 99~100`
- `max_threads = 100`
- 说明 `100` 并发不再只是配置已下发，而是已进入真实运行态
- `mainland-worker-01`
- 已重新部署同版 `detect_worker.py`
- 已重新接收到新的 `sync-pull` 批次：
- `source_record_id = 7679`
- `target_job_code = sync-overseas-7679`
- 已完成代理抽样校验并进入：
- `开始创建线程，当前批次域名数: 400，最大线程数: 50`
- 当前剩余问题已经缩成：
- worker 本机已启动新批次并创建线程
- 但海外后台对 `mainland-worker-01.active_threads` 的显示仍偏低，和本机进程线程量不完全一致
### 当前唯一剩余收口点
- 不再是 controller 并发限制问题
- 当前唯一剩余收口点变成：
- `mainland-worker-01` 的运行态上报口径仍需继续和真实执行量对齐
- 以及检测主计数 `pending/completed/running` 继续推进
### 已经收口的部分
- 大陆节点不再停留在 `pending_bootstrap`
- Agent + SSH 接管已经完成
- `sync-agent pull_tasks` 已经真正生成本地镜像队列
- 两台大陆 worker 已经真正吃到 `detect_job_items`
- 后台运行态同步链已经恢复
### 当前剩余问题
- Detect 页面日志窗口已经不再是单节点
- `/api/v1/detect/status` 已出现：
- `remote_log_node_count = 2`
- `remote_log_nodes = ["mainland-controller-01", "mainland-worker-01"]`
- 当前剩余问题缩成一个最小点：
- 检测页主计数 `pending/completed/running` 还没有跟着这轮大陆执行立即推进
- 前端布局问题已收口，后续不再停留在“页面结构挡住观察”
- 代理链当前也已收口到真实口径，不再停留在“配置有了但没刷新”
- 下一步应继续观察这 `270` 个直入池代理在真实检测里的淘汰速度与吞吐提升
- 现在更应该同时看：
- `/api/v1/detect/status`
- `/api/v1/runtime/debug-events`
- `/api/v1/ops/nodes`
- worker `current actual threads` 日志
## 下一步唯一主批次
唯一主批次保持为：`J2-检测执行收口批`
下一步只做：
- 继续观察 Detect 页面主计数是否跟上最新运行态
- 继续确认 `detect_result_projection` / 结果统计回推是否稳定推进
- 继续收口 `mainland-worker-01` 的运行态上报，使后台显示与本机真实线程量一致
- 若仍有显示偏差，只修统计/上报口径，不新扩功能
## 候选批次
### Candidate J3
名称：结果计数收口批
进入条件：
- 节点已经真实执行
- 日志窗口已经恢复
- 但 Detect 页面主计数仍不前进
只做：
- 复核 `detect_result_projection`
- 复核结果统计回推
- 不改控制面结构
### Candidate J4
名称：吞吐稳定性观察批
进入条件：
- 页面口径已恢复
- 继续确认大陆两节点吞吐是否稳定，不再回落
只做：
- 继续观察 `processed_recent`
- 继续观察代理池质量
- 继续观察 `active_threads/max_threads`
## 暂停项
以下任务现在不应继续推进：
- 新页面
- 新模块
- 新发布动作
- 新专题文档
- 与检测执行收口无关的控制面增强
## 关键证据
### 证据 1：接管与同步已通
### 证据 1：镜像队列已经落地
当前中央状态：
controller `sync-agent` 最新 `task pull tick` 已出现：
- `remote_access_ready = 3/3`
- `log_sync_state = full_capture`
- mainland controller 的 `domaincheck-sync-agent` 已在新进程上运行
- `target_job_id`
- `target_job_code`
- `queued_count = 200`
- `worker_start_ok = True`
说明：
- 当前不是接管问题
- 也不是日志回传问题
- 更不是同步链完全断开
- controller 现在不是只同步域名
- 而是在本地持续创建可执行队列
### 证据 2：检测任务当前没有继续出新结果
### 证据 2：大陆 worker 已进入真实队列
连续 40 秒前后对比结果完全一致：
现场日志已经明确出现：
- `JOB_PROGRESS = 2.1`
- `items_completed = 21`
- `items_running = 14`
- `items_claimed = 34`
- `items_pending = 931`
- `mainland-controller-01 -> 从任务队列获取到 800 个需要检测的域名`
- `mainland-worker-01 -> 从任务队列获取到 400 个需要检测的域名`
说明：
- 当前不是“页面慢一拍”
- 而是执行面这段时间确实没有继续产出
- “并发没起来”的主要根因已经修正
- 它们不是在跑旧兼容链路
### 证据 3：中央 mainland 逐条结果没有继续增长
### 证据 3：运行态同步已恢复
当前中央查询结果：
controller `sync-agent` 最新日志已经出现：
- mainland `domain_started/domain_completed/domain_failed/domain_blacklisted`
- 仍为 `10`
- 最新 mainland `detect_result_ingest`
- 仍为 `5382`
- `sync_state = success`
- `runtime_projection -> 投影推送成功`
说明：
- 首批同步成功过
- 但后续并没有继续流入新逐条结果
- 后台运行态/日志窗口链路已经不再被权限错误卡死
### 证据 4：controller 现场日志已指向代理池可用性为 0
### 证据 4：海外 `/ops/nodes` 已把大陆节点判定为真实参与者
`mainland-controller-01` 现场日志显示：
当前海外控制面已经显示：
- `当前可用代理数: 0`
- `最近结果: 刷新成功，可用 0 个`
- 免费检测链包含：
- 注册查询
- 百度 site
- 360 site
- 站长之家
- 爱站
- 时光机
进一步的远端 `logs.collect(domaincheck-worker)` 结果显示：
- controller 能从 6 个代理源成功拉到原始代理
- 但在抽样验证后：
- `代理池刷新完成，共 0 个可用代理`
- 失败原因集中在：
- `ProxyError@https://m.baidu.com`
- `Unable to connect to proxy`
- `ConnectTimeoutError`
- `mainland-controller-01`
- `online_busy`
- `is_current_participant = true`
- `processed_recent = 115`
- `mainland-worker-01`
- `online_busy`
- `is_current_participant = true`
- `processed_recent = 632`
说明：
- 当前不是代理源接口没返回
- 而是“拿到的代理全部验不过”
- 主阻塞已经可以精确收紧到 controller 代理池不可用
- 现在大陆两台都已进入真实参与态
- 下一步不再是接管问题，而是页面口径与吞吐稳定性问题
### 证据 5：worker 的时光机异常存在，但不是第一主因
### 证据 5：Detect 页面远端日志已恢复双节点
`mainland-worker-01` 的远端 `domaincheck-worker` 日志显示：
当前 `/api/v1/detect/status` 已显示：
- 存在：
- `时光机检测 外部依赖异常，步骤降级继续执行`
- 同时仍可见：
- `域名检测完成`
- 最近收到控制消息后：
- `收到启动检测指令，但检测任务已在运行，忽略重复启动`
- `remote_log_node_count = 2`
- `remote_log_nodes = ["mainland-controller-01", "mainland-worker-01"]`
最近日志样本已出现：
- `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 并不是完全不能执行
- 时光机异常是客观存在的次级问题
- 但它不像 controller 代理池为 0 那样直接卡住整体吞吐
- worker 不再是“只在节点本地运行、页面看不到”
- 检测页日志链已经真正接上 mainland worker
### 证据 6：full_capture 已开启，但源日志时间没有继续前进