智能扫描重构遗留问题处理Phase 2

[iwanghc]

原始issue：https://github.com/actiontech/sqle-ee/issues/1576
关联issue：#2523

需求描述（Describe）

3.2409.0-pre1

• 智能扫描报告中LastCollectTime字段与同步任务更新冲突问题 @iwanghc
  问题影响： 扫描任务定时刷新需要同步的任务，由于该问题会导致每次都把全量的扫描任务查出来（包括已删除的），然后再过滤掉不需要执行的，预期是只要查出配置更新过的任务。

• 审核是个同步动作，花费时间过长可能会导致页面展示效果阻塞。需要调整审核的位置 @iwanghc
  问题影响： 当扫描任务采集到的sql数据量较大时，由于批量审核的阻塞，可能出现在sql列表中无法即时展示出来这些sql，需要调整审核逻辑，先能展示采集的sql，再补充审核结果。

• 扫描任务概览中统计的 审核有问题的SQL数 不准确 @iwanghc

3.2409.0-pre3

• 智能扫描补充端点信息 (需要升级方案) #2616
  问题影响： 无法展示端点信息。

后续处理

• TopSQL排序字段，理论上会有四个.预期是可以做下拉选择 @iwanghc
  问题影响： 待确认。

• 库表扫描任务中，存在自增主键建表SQL语句会由于自增值增加导致语句出现变更，由于建表语句变化导致sql_manage_record变化。更新时间每次扫描都会调整为最新，并且该建表语句一直被推送告警 @LordofAvernus
  问题影响： 一条sql一直重复告警。

• 其他代码里的todo项 / todo：移除废弃接口和实现;移除所有无用代吗 @LordofAvernus

• 容错处理
  从queues里读取出的记录处理失败怎么办？
  handler里插入记录和删除queues的事务性，
  审核失败怎么办如何处理；
  容错处理需要优化，考虑新增字段来解决
  问题影响： 扫描任务某些地方未进行错误处理，没有日志输出，可能会导致采集的sql部分丢失，审核结果不符合预期等问题。

• TDSQL慢日志没有链接信息（确认是否复用了mysql的逻辑） @iwanghc
  问题影响： TDQSL慢日志无法从页面复制scannerd启动命令，待确认TDSQL慢日志是否复用的mysql慢日志逻辑。

• 需要改造各类型的智能扫描类型，以兼容旧数据 （问题待确认，来源？）

• 扫描任务导出审核结果，csv文件审核结果列内容未格式化

测试遗留问题

DB2

• 库表元数据：报错 create variable failed, error
• TOP SQL：未采集到数据

OB MySQL

• TOP SQL：报错 extract sql failed, can not do this task, plugin not implement api Query

待测试
OB Oracle
TIDB审计日志
TDSQL库表元数据、慢日志
rds相关任务

[iwanghc]

智能扫描报告中LastCollectTime字段与同步任务更新冲突问题

1. AuditPlanV2表是否仅作为配置表，如果仅作为配置表存在，LastCollectTime属性与表定义存在冲突（这种情况需要拆表解决）
2. 当AuditPlanV2作为扫描任务记录，那么默认update_time字段值的变更，不应该被识别为任务做变更。应该由其他标准来确认配置变更（才能做出任务更新/删除动作）

• 方案1和2选中一个来解决
  评估影响面和兼容

方案一：

影响面：新增一个记录最后采集时间的表
1、任务采集sql：在每次进行采集的时候更新该时间
2、定时同步任务：记录配置更新时间到内存，每次根据更新时间查需要同步的任务
3、概览列表查询时关联该表、删除任务/实例任务时关联删除
兼容性：不兼容旧版本，需要将配置表记录的最后更新时间迁移到新表中，并删除扫描任务配置表的last_collect_time字段，

方案二：

影响面：在配置表新增一个字段记录配置最后更新时间
1、定时同步任务：同步任务时根据配置最后更新时间筛选需要同步的任务
2、在更新扫描任务配置、删除扫描任务时都需要更该字段

兼容性：兼容旧版本

最终方案：方案一

方案一合理性：在配置表中不存储业务信息更为合理，将最后采集时间拆分出来。
优点：后续若有业务需要，任务有新的业务信息需要补充可以在此表新增字段，相较于方案二，不需要在更新删除任务时关注时间字段的更新。
缺点：成本略高

升级方案：

假设sqle服务的业务数据库名为sqle，执行以下sql语句
1、创建audit_plan_task_infos表

CREATE TABLE sqle.audit_plan_task_infos (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `created_at` datetime(3) DEFAULT CURRENT_TIMESTAMP(3),
  `updated_at` datetime(3) DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3),
  `deleted_at` datetime(3) DEFAULT NULL,
  `audit_plan_id` bigint(20) unsigned NOT NULL,
  `last_collection_time` datetime(3) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2、将存量扫描任务id及最后采集时间同步至audit_plan_task_infos 表

INSERT INTO  sqle.audit_plan_task_infos (updated_at, deleted_at, audit_plan_id, last_collection_time) select updated_at, deleted_at,id, last_collection_time  from sqle.audit_plans_v2;

3、删除audit_plans_v2表的last_collection_time

ALTER TABLE sqle.audit_plans_v2 DROP COLUMN last_collection_time;

[iwanghc]

优化扫描任务审核逻辑，避免阻塞页面显示

背景：

当采集的sql数量较大时，由于审核的阻塞，导致在前端展示会有一定时差（队列每次peek1000条-->批量审核(耗时)-->设置高优先级-->数据落地-->移除被peek的队列数据）

解决方案：

1、调整扫描任务审核逻辑（队列每次peek1000条-->开启事务-->数据落地-->移除被peek的队列数据-->提交事务-->开启协程-->批量审核(耗时)-->设置高优先级-->更新数据）
2、扫描任务sql列表的审核结果列补充一个审核中，首次采集到的sql数据落地但未审核完时展示为审核中
3、在sql管控列表的审核结果列补充一个审核中，审核结果为NULL的展示为审核中（需要调整sql管控接口定义，新增audit_status字段）

影响：

1、智能扫描
2、sql管控
（采集后页面第一时间不能展示出审核结果和高优先级内容，影响仅在数据量较大时有感知）

兼容性：

兼容旧版本

[zzyangh]

为了处理‘审核是个同步动作，花费时间过长可能会导致页面展示效果阻塞。’问题，后端在SQL管控列表接口和智能扫描任务详情接口中加入了‘审核中’状态，前端需要处理当sql是‘审核中’状态时，自动刷新列表更新列表数据。刷新机制和工单上线中的自动刷新机制一致，1000ms刷新一次。

• 快速审核、SQL管控、SQL管控配置-任务详情列表 当sql为‘审核中’状态时，自动刷新列表数据