565 lines
18 KiB
Markdown
565 lines
18 KiB
Markdown
# TASK_BOARD
|
||
|
||
更新时间：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-检测执行收口批`
|
||
|
||
目标：
|
||
|
||
- 不进入新页面
|
||
- 不扩展控制面
|
||
- 不新增发布动作
|
||
- 只收口三件已经缩小到运行面的事情：
|
||
- 大陆节点必须真正进入统一镜像队列，而不是停留在兼容旧链路
|
||
- 后台必须能看到大陆节点的实时运行态与日志
|
||
- `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 日志回传恢复”的关键跨越。
|
||
|
||
### 本轮前端已上线校验
|
||
|
||
- 检测页 `任务日志控制台` 已调整到事件列表上方
|
||
- `检测事件流` 已改成独立滚动区：
|
||
- 表格 `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`
|
||
|
||
### 本轮代理链已收口
|
||
|
||
- 已修复 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`
|
||
- 已重启 `domaincheck-worker`
|
||
- 已明确进入真实队列：
|
||
- `从任务队列获取到 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`
|
||
|
||
### 当前最关键的新证据
|
||
|
||
- `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`
|
||
- 仍在执行中央原生队列
|
||
- 当前判断：
|
||
- 大陆节点已经不是“纸面在线”
|
||
- 已经是真实参与检测执行
|
||
|
||
## 当前主判断
|
||
|
||
### 本轮新增结论
|
||
|
||
- `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：镜像队列已经落地
|
||
|
||
controller `sync-agent` 最新 `task pull tick` 已出现：
|
||
|
||
- `target_job_id`
|
||
- `target_job_code`
|
||
- `queued_count = 200`
|
||
- `worker_start_ok = True`
|
||
|
||
说明：
|
||
|
||
- controller 现在不是只同步域名
|
||
- 而是在本地持续创建可执行队列
|
||
|
||
### 证据 2：大陆 worker 已进入真实队列
|
||
|
||
现场日志已经明确出现：
|
||
|
||
- `mainland-controller-01 -> 从任务队列获取到 800 个需要检测的域名`
|
||
- `mainland-worker-01 -> 从任务队列获取到 400 个需要检测的域名`
|
||
|
||
说明：
|
||
|
||
- “并发没起来”的主要根因已经修正
|
||
- 它们不是在跑旧兼容链路
|
||
|
||
### 证据 3：运行态同步已恢复
|
||
|
||
controller `sync-agent` 最新日志已经出现：
|
||
|
||
- `sync_state = success`
|
||
- `runtime_projection -> 投影推送成功`
|
||
|
||
说明：
|
||
|
||
- 后台运行态/日志窗口链路已经不再被权限错误卡死
|
||
|
||
### 证据 4：海外 `/ops/nodes` 已把大陆节点判定为真实参与者
|
||
|
||
当前海外控制面已经显示：
|
||
|
||
- `mainland-controller-01`
|
||
- `online_busy`
|
||
- `is_current_participant = true`
|
||
- `processed_recent = 115`
|
||
- `mainland-worker-01`
|
||
- `online_busy`
|
||
- `is_current_participant = true`
|
||
- `processed_recent = 632`
|
||
|
||
说明：
|
||
|
||
- 现在大陆两台都已进入真实参与态
|
||
- 下一步不再是接管问题，而是页面口径与吞吐稳定性问题
|
||
|
||
### 证据 5：Detect 页面远端日志已恢复双节点
|
||
|
||
当前 `/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 不再是“只在节点本地运行、页面看不到”
|
||
- 检测页日志链已经真正接上 mainland worker
|
||
|
||
### 证据 6：full_capture 已开启，但源日志时间没有继续前进
|
||
|
||
节点现场日志最新可见记录仍停在较早时间：
|
||
|
||
- `mainland-controller-01`
|
||
- 最近样本集中在 `01:00:23`
|
||
- `mainland-worker-01`
|
||
- 最近样本集中在 `01:00:35`
|
||
|
||
额外 35 秒观察窗口结果：
|
||
|
||
- `capture_at` 没有继续前进
|
||
- `source_msg` 里的源日志时间也没有继续前进
|
||
|
||
说明：
|
||
|
||
- 不是“全量日志没开”
|
||
- 也不是“日志回传没回来”
|
||
- 而是执行进程这段时间确实没有继续产生日志
|
||
|
||
### 证据 7：worker 控制消息补偿链已在线上验证生效
|
||
|
||
之前运行态存在一个真实风险：
|
||
|
||
- `runtime.start_detection` 成功只代表“控制消息已发布到 Redis”
|
||
- 如果 worker 在线但恰好漏收了 pubsub 消息
|
||
- pending 指令只在启动或重连时消费，就可能造成：
|
||
- 页面显示“已启动”
|
||
- 但 worker 实际没有进入新的执行流
|
||
|
||
当前已完成最小修复：
|
||
|
||
- 每条控制消息带 `request_id`
|
||
- worker 心跳会主动补偿消费 pending 指令
|
||
- worker 真正收到并处理后，会按 `request_id` 清理 pending
|
||
|
||
这一步现在已经不再是“待部署假设”，而是已被线上日志确认生效：
|
||
|
||
- `mainland-worker-01` 已从 pending 指令恢复执行
|
||
- `mainland-controller-01` 在修正 Redis 环境后，也已重新接受并执行 `start_detection`
|
||
|
||
## 当前结论
|
||
|
||
当前结论要收敛成一句话：
|
||
|
||
- 接管链路已基本完成
|
||
- 同步链路已至少成功贯通一次
|
||
- 当前主阻塞仍是检测执行面没有恢复到“持续产出”
|
||
- 但代码级控制链缺口已经闭合
|
||
- 当前唯一剩余现场阻塞可以收紧为：
|
||
- `mainland-controller-01` 代理池可用性为 `0`
|
||
- worker 侧时光机异常仍是次级噪音，不应继续放大
|
||
|
||
## 下一步唯一主批次
|
||
|
||
唯一主批次维持为：`J2-检测执行停滞收口批`
|
||
|
||
本批次唯一目标：
|
||
|
||
- 保持当前不扩功能
|
||
- 只围绕 controller 代理池可用性为 `0` 做收口
|
||
- 继续观察修正后的 controller 是否开始产出 domain 级结果
|
||
- 若仍无结果增长，则只给出代理层最小补救路径
|
||
|
||
## 候选批次
|
||
|
||
### Candidate J3
|
||
|
||
名称：检测执行恢复验证批
|
||
|
||
进入条件：
|
||
|
||
- `J2` 明确根因后
|
||
- 代理或外部站点依赖恢复
|
||
- 再观察 `domain_*` 是否重新增长
|
||
|
||
### Candidate J4
|
||
|
||
名称：上线签收证据批
|
||
|
||
进入条件：
|
||
|
||
- `J3` 确认检测重新持续产出
|
||
- `go-live-summary` 只剩历史 attention
|
||
|
||
## 暂停项
|
||
|
||
继续暂停：
|
||
|
||
- 新页面
|
||
- 新模块
|
||
- 控制面增强
|
||
- 发布动作
|
||
- 与检测执行停滞无关的工作
|
||
|
||
## 下一轮唯一动作
|
||
|
||
下一轮唯一应该继续做的事情：
|
||
|
||
- 只做 controller 代理收口：
|
||
- 继续复查 controller `domaincheck-worker` 日志
|
||
- 观察是否从 `当前无可用代理` 转为有可用代理
|
||
- 继续复查 `/api/v1/detect/job/active`
|
||
- 继续复查 `/api/v1/runtime/sync-summary`
|
||
- 继续复查 recent domain events 是否出现 controller / 新 completed
|
||
- 唯一判断问题是：
|
||
- controller 代理池恢复后，completed 是否开始继续增长
|
||
- 是否仍是 `近窗吞吐 0`
|
||
- 是否仍是 `controller 可用代理数 0`
|
||
- 代理恢复后 `domain_*` 是否重新增长
|