[OPTIMIZATION] 支持日志状态表的删除

[ZhuoZhuoCrayon]

你想要什么功能
支持日志状态表的删除，删除后不影响页面/API查看任务状态

为什么需要
避免该表的过度膨胀

建议如何实现

日志状态表：SubscriptionInstanceStatusDetail

配置：是否定期清理日志，仅保留xx天的日志，保留什么级别的日志，由于存量日志过多，每次最多删除xx条
指引：危机时刻删表、按时间戳删除历史日志（保留xx天）

[ZhuoZhuoCrayon]

实现思路

目标

• 删除 SubscriptionInstanceStatusDetail，SubscriptionInstanceRecord 的 status 不会被重置
• 任务历史，子步骤状态可以处于 PENDING
• 订阅（采集） & 页面相关的依赖接口不能有报错

可能需要调整的地方

apps/backend/subscription/task_tools.py

1. 保留失败日志的情况下，确保可以通过仅存的失败节点，还原之前的节点状态

2. SubscriptionInstanceRecord 有明确状态的情况下，如果 collect_status 处于 PENDING，填充 SubscriptionInstanceRecord 自身的状态及时间

[CohleRustW]

方案实现事项

• 周期任务清理订阅日志表
  • 尽量根据索引和时间段进行删除，避免非索引字段条件进行DELETE

注意事项

1. 清理SubscriptionInstanceStatusDetail时避免全表扫描
2. 保持status 和 status_display 统一
3. 对保留指定日志级别的任务注意还原前节点状态

紧急清理表方案

1. 指引Truncate表方案
2. 指引周期任务配置方案

[ZhuoZhuoCrayon]

交付目标

文档

数据删除的操作指引

自测截图

Pipeline 相关的表默认删除，删除的表参考：apps/backend/management/commands/clean_old_instance_record.py
删表操作执行后，需要删表时间点之后的 SubscriptionInstanceRecord 数据强制失败，避免后续巡检报执行中的错误
以下每个功能自测点附上截图，作为后续给出方案及效果的一部分

SubscriptionInstanceStatusDetail 全表删除

• SaaS - 执行历史允许「步骤」级别的状态不准确，但「主机执行状态」（SubscriptionInstanceRecord）要准确
• 订阅 - 巡检/重试不受影响
• 订阅 - instance_status / statistic / task_result_detail / task_result 不报错，主机执行状态准确

保留 SubscriptionInstanceStatusDetail ERROR 日志

• SaaS - 执行历史允许「步骤」级别的状态不准确（失败节点日志可查），但「主机执行状态」（SubscriptionInstanceRecord）要准确
• 订阅 - 巡检/重试不受影响
• 订阅 - instance_status / statistic / task_result_detail / task_result 不报错，主机执行状态准确，失败节点日志可查

保留 SubscriptionInstanceStatusDetail 某个时间后的数据

• 日志保留时间之外：同 SubscriptionInstanceStatusDetail 全表删除
• 日志保留时间之内：各项功能需正常

[CohleRustW]

自测截图

清理数据前

清理所有日志

保留失败日志

[CohleRustW]

订阅巡检

1. 启用订阅巡检

2. 查询订阅 task

3. 执行巡检任务

4. 查询巡检订阅 TASK

5. 相关接口执行结果验证

[CohleRustW]

删除指定时间之前的日志

[ZhuoZhuoCrayon]

本意是想压缩存储节点，但漏了 {"SUCCESS", "PENDING"} 这种状态组合，在这种情况下，会偶发任务提前成功的现象

模拟该情况：

保留失败日志：