问题出在监控数据存储层或日志采集链路的持久化环节，需重建system.db数据库：先停面板服务，备份原文件，删除损坏库，再用sqlite3初始化新库。
如果您在宝塔面板中查看监控图表时发现历史数据全部为空，但当前实时数据或新产生的数据能正常显示，则问题大概率出在监控数据存储层或日志采集链路的持久化环节。以下是修复此问题的步骤：
一、重建系统监控数据库文件
宝塔面板将系统级监控数据（CPU、内存、磁盘IO、网络等）持久化保存在 /www/server/panel/data/system.db 文件中。该SQLite数据库可能因升级中断、磁盘写入失败或结构损坏导致历史记录无法读取，但服务仍在运行，因此实时数据仍可生成。
1、通过SSH连接服务器，执行命令停止宝塔面板服务：
bt 2
2、备份原数据库文件以防误操作：
cp /www/server/panel/data/system.db /www/backup/system.db_$(date +%Y%m%d_%H%M%S)
3、删除损坏的数据库文件：
rm -f /www/server/panel/data/system.db
4、重新初始化数据库结构并导入默认表定义：
sqlite3 /www/server/panel/data/system.db
5、重启宝塔面板服务：
bt 1
6、登录面板，在“监控”页面点击“清空记录”，再等待5分钟以上观察历史图表是否恢复加载。
二、重置网站监控日志采集配置
网站监控报表依赖Nginx配置中嵌入的特定syslog转发指令，将access_log与error_log实时推送至 /tmp/bt-monitor.sock。若升级后站点配置未同步更新，旧配置将跳过监控日志发送，导致历史访问数据完全缺失，仅保留新配置生效后的增量数据。
1、进入宝塔面板“网站”列表，点击对应站点右侧的“设置”按钮
2、切换到“配置文件”选项卡，定位到所有 location 块内含 access_log 或 error_log 指令的位置
3、在每个 location 块末尾（但在大括号 } 之前）插入以下两行（注意替换其中的站点ID，如原配置中有 tag=4__access，则保持数字4一致）：
#Monitor-Config-Start
access_log syslog:server=unix:/tmp/bt-monitor.sock,nohostname,tag=4__access monitor;
error_log syslog:server=unix:/tmp/bt-monitor.sock,nohostname,tag=4__error;
4、保存配置文件后，点击右上角“重载配置”按钮使Nginx生效
5、返回“网站监控”页面，关闭“开启监控”，等待30秒后再开启，并点击“清空记录”
6、静待10分钟以上，刷新页面检查历史图表是否开始填充数据
三、强制触发监控数据初始化脚本
宝塔监控模块启动时会尝试自动初始化缺失的时间序列数据表。若初始化失败或未执行，会导致前端查询不到任何历史时间点的数据记录，即使数据库文件存在且结构完整。
1、在SSH终端中执行以下命令，手动运行监控初始化脚本：
btpython /www/server/panel/script/monitor_init.py
2、确认输出中包含 "Init monitor tables success" 或类似成功提示
3、若提示表已存在，追加 --force 参数强制重建：
btpython /www/server/panel/script/monitor_init.py --force
4、执行完成后，重启监控服务：
bt 15
5、刷新面板“监控”页面，检查图表底部X轴时间范围是否扩展至7天或30天，默认应显示最近30天历史区间
四、校验并修复面板主数据库完整性
系统监控图表的元信息（如图表类型、采样周期、显示开关状态）由宝塔主数据库 /www/server/panel/data/default.db 管理。若该库中 monitor_config 表字段异常或缺失，可能导致前端拒绝加载历史数据请求，仅渲染空白图表区域。
1、停止宝塔面板：
bt 2
2、使用内置修复命令校验并修复主数据库：
bt 16
3、若提示“修复完成”，继续执行Python脚本增强修复：
btpython /www/server/panel/script/init_db.py repair
4、启动面板：
bt 1
5、登录后进入“面板设置”→“监控设置”，确认“启用系统监控”和“启用网站监控”均处于开启状态，并检查“数据保留天数”是否设为大于0的数值（如30）
6、在“监控”页面按 Ctrl+F5 强制刷新，排除浏览器缓存干扰
