`t_chaos_scheduler_trigger_log` is too big

[QingShuangWuHen]

数据库中这个t_chaos_scheduler_trigger_log占的硬盘非常大！已经达到了200G！

[xcaspar]

数据库中这个t_chaos_scheduler_trigger_log占的硬盘非常大！已经达到了200G！

这个应该是 chaosblade-box 数据表，用来审计实验执行、停止、工具安装、Agent 探活等行为，我推测可能是AgentPingScheduleJob 任务定时执行导致数据量大，可以先使用以下SQL查询任务占比：

-- 统计各业务类型的任务触发次数和占比
SELECT 
    sj.business_type,
    CASE sj.business_type
        WHEN 0 THEN '演练调度任务'
        WHEN 10 THEN '演练任务守护实例'
        WHEN 11 THEN '演练任务稳定'
        WHEN 20 THEN 'Java Agent安装检查'
        WHEN 21 THEN '活动异步检查'
        WHEN 30 THEN '演练任务自动恢复'
        WHEN 40 THEN '演练状态调度'
        WHEN 51 THEN 'ChaosBlade任务自动恢复'
        WHEN 60 THEN '应用变更禁用为false'
        WHEN 70 THEN '应用变更禁用为true'
        ELSE CONCAT('未知类型(', sj.business_type, ')')
    END AS business_type_name,
    COUNT(*) AS trigger_count,
    ROUND(COUNT(*) * 100.0 / (SELECT COUNT(*) FROM t_chaos_scheduler_trigger_log), 2) AS percentage
FROM t_chaos_scheduler_trigger_log tl
LEFT JOIN t_chaos_scheduler_job sj ON tl.job_id = sj.job_id
GROUP BY sj.business_type
ORDER BY trigger_count DESC;

[oss-sentinel-ai]

Issue Evaluation

Category: type/question | Status: Answered

This issue has been addressed by @xcaspar with detailed guidance on how to diagnose and manage the t_chaos_scheduler_trigger_log table growth.

Summary:

• The table is used for auditing experiment execution, stop, tool installation, and agent ping activities
• The AgentPingScheduleJob periodic task is likely the main contributor to large data volume
• SQL queries provided to analyze task distribution by business type
• Recommendation: set up a scheduled cleanup job or manually archive old records

Recommendation: Consider adding a built-in log retention policy to chaosblade-box that automatically cleans up records older than a configurable threshold (e.g., 30 days). This would prevent unbounded table growth in production deployments.

---

Automated evaluation by oss-taishan-ai - ChaosBlade Community Bot