compaction/indexing task auditing history

[xiaobingxia-at]

由于业务需求，我们要建立100k个partition。目前看到，导入和搜索都不是问题。唯一特别担心的是compaction task / indexing task的阻塞和跟不上。目前没有看到一个有效的途径来监控所有compaction task的历史记录。2.5 的 UI只会显示最近的32个task？

能否expose一个API，能够返回过去1小时内全局所有的indexing compaction task，包括建立时间，在queue里的等待时间，分配给了哪个node，执行时间，调度时间等等。也可以把这些audit数据放在一个milvus内表里吗？这样我们查询就可以监控了。

谢谢。

[xiaobingxia-at]

另外，indexing task确实跟不上。把这个参数调成4会有副作用嘛

        indexNode:
            scheduler:
                buildParallel: 4

[xiaofan-luan]

调整这个配置应该帮助不大，目前有多少indexnode？

[xiaocai2333]

调整这个配置帮助不大，可以的话增加 indexnode 数量比较合适。

[xiaobingxia-at]

6个，由于我们是大量很小的partition，所以每个node 5 core。
主要是我经常看到这个log
[2025/01/02 23:04:56.837 +00:00] [WARN] [session/indexnode_manager.go:140] ["get IndexNode slots failed"] [nodeID=14]

但是后来我又仔细分析了一下。应该不是index node不够用。因为我导入触碰的partition数目有限，大概两秒一个。而我有6个index node。这个log会不会有什么恶劣后果？（我比较担心有些segment永远不会被index到）

[xiaobingxia-at]

然后我发现我的indexing task被卡主了

[2025/01/03 05:59:41.950 +00:00] [INFO] [datacoord/task_scheduler.go:258] ["there is no idle indexing node, waiting for retry..."]

index node资源充足。

[xiaobingxia-at]

再后来发现原来是因为segment在compacting，所以index task被取消了。

[jaime0815]

对，现在2.5 webui 只会显示 32，这个后面可以调大一点，但空间不大。因为现在都是内存缓存，一个小时数据对内存占用不可控。 对于你的需求可以使用, http://<proxy_ip>:9091/api/v1/_dc/tasks/compaction 读到最近32 个 任务状态，然后写到业务audit表中

[xiaofan-luan]

32 可能太小了，先保留最近15分钟的1000个task吧，参数改成可以调整的 @jaime0815

[xiaofan-luan]

我们可以能需要另外一个参数，正在排队等index的任务数目 @xiaocai2333 可以帮忙一起看看

[xiaobingxia-at]

另外execution time和starttime是错的。

[xiaobingxia-at]

collection id 也是错的。所有collection的id里都找不到图上的collection id。

[xiaofan-luan]

collecitonid 会因为int64浏览器溢出了，2.5.1应该已经修复了