feat: 日志平台采集接入清洗模板改版 --story=135605563 - #11797
Conversation
JunLong-Lin
added
feat
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #11797 +/- ##
==========================================
+ Coverage 54.28% 61.77% +7.48%
==========================================
Files 807 927 +120
Lines 45868 68066 +22198
==========================================
+ Hits 24901 42046 +17145
- Misses 20967 26020 +5053 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
1f2c253 to
97e6796
Compare
yiqiwang-17
left a comment
yiqiwang-17
left a comment
There was a problem hiding this comment.
本轮审查基于最新 head bce8602474。发现 1 个 P0、3 个 P1、3 个 P2，当前不建议合入。主要阻塞项是跨业务清洗模板可见范围被破坏性移除；同步链路还存在 HTTP 长请求、锁过期重入及外部 RT 写入竞态。最新提交已修复 host fast_update 缺少 fields 的回归；本地相关 23 项测试通过，新一轮 CI 仍在运行。
| collectors = collectors.filter(collector_config_id__in=collector_config_ids) | ||
| collectors = list(collectors.order_by("collector_config_id")) | ||
|
|
||
| multi_execute_func = MultiExecuteFunc() |
There was a problem hiding this comment.
🟡 P1：同步在 HTTP 内全量执行，且模板锁可能提前过期
/sync/ 会一次加载全部待同步采集项，并用 MultiExecuteFunc() 默认线程数执行；每项最终同步直调 modify_result_table(..., raise_exception=True)，请求要等待全部完成。关联项多时容易超过网关/worker 超时，而模板锁 TTL 固定 5 分钟且无续期，执行超过 TTL 后第二次同步可以进入并重叠写 RT。
建议改为 Celery 分批异步任务并轮询状态；至少限制单批数量和 worker 数，并增加锁续期或把 TTL 配到高于同步 P99。
There was a problem hiding this comment.
这里评估后暂不改为 Celery 异步任务，本轮采用“有界同步批次”的设计。同步接口单次最多处理 50 个待同步采集项，权限校验也只加载当前批次，并将线程池并发固定为 20，避免在 HTTP 请求内无界全量执行。未进入本批次的采集项不会丢失，仍保持待同步状态；前端已有 pending_sync_collector_count 展示，用户可根据待同步数量再次发起同步。接口继续返回本批各采集项的实际结果，不额外返回 remaining_count，因为多次请求及关联关系变更并非原子操作，该值只能是瞬时快照。
模板锁继续覆盖整个批次，TTL 为 5 分钟；当前部署的 HTTP 请求超时为 60 秒，在单批数量受限后，按现有请求生命周期约束不会出现请求仍在执行但模板锁先过期的情况。完整异步化还需要引入任务状态、丢失恢复、重复执行和状态卡死处理，当前收益不足以覆盖这部分复杂度；如果后续监控发现单批 P99 接近 HTTP 超时，或产品要求一次操作自动完成全部同步，再升级为异步任务。
| results.append(result) | ||
| return results | ||
|
|
||
| def _sync_collector(self, collector: CollectorConfig, template_version: int, clean_config: dict): |
There was a problem hiding this comment.
🟡 P1：乐观更新只保护 DB，未解决外部 RT 写入竞态
这里明确不加采集项级锁，但手动 ETL 的 modify_result_table 是异步任务，模板同步则同步直调 Metadata。clean_template_id + RUNNING 条件只能防止 DB 关系被写回，不能约束两个外部 RT 写入的完成顺序；并发时可能出现 DB 已解绑并记录手动配置，但最后落到 Metadata 的仍是模板配置。
需要对同一采集项的真实 RT 写入做分布式串行，或引入 generation/CAS 丢弃过期任务；锁必须覆盖异步任务内的实际 Metadata 写入。
There was a problem hiding this comment.
这个问题确实无法仅靠 DB 乐观更新完全消除，当前采用“冲突检测 + 阻止错误回写 + 用户恢复”的折中方案。
同步前会校验模板关联，关联已变化则跳过 Metadata 调用；同步完成后仅在 clean_template_id + RUNNING 仍匹配时写回成功状态，避免覆盖并发解绑或改绑后的 DB 状态。如果关联在 Metadata 调用期间变化，则返回失败并提示实际 RT 可能不一致，用户重新保存采集项即可重新下发当前配置。
若要彻底串行外部 RT 写入，需要将采集项级分布式锁延伸到手动 ETL 的 Celery 任务内部，并处理锁续期、任务重试和过期任务，改动风险较大。本次接受该低概率、可检测且可恢复的一致性边界，强一致方案后续单独处理。
Co-authored-by: Cursor <cursoragent@cursor.com>
3 participants
No description provided.