监控数据不准通常源于插件服务异常、数据库损坏或采集配置不同步，而非系统重装；应优先检查bt-monitor服务状态、修复SQLite数据库完整性，并同步调整后端采集间隔与前端轮询频率。
监控数据不准，绝大多数情况跟系统重装无关，而是插件服务、数据库或采集配置出了问题。重装系统是过度操作，既不能解决根本问题，还可能引入新故障。
监控图表空白或显示 0：先查 bt-monitor 服务状态
宝塔首页的 CPU、内存、磁盘等图表由 bt-monitor 进程驱动，它依赖 SQLite 数据库存储采集点。服务挂了，图表就彻底失联。
- 执行
systemctl status bt-monitor，确认状态是否为active (running) - 若显示
inactive (dead)或报Failed to start bt-monitor.service，直接重启：systemctl restart bt-monitor - 重启后等 60 秒，再刷新面板。很多“不准”只是服务卡住，没真正崩溃
- 如果重启失败，检查日志：
journalctl -u bt-monitor -n 50 --no-pager，重点看是否有database is locked或no such table: cpu
bt_monitor.db 损坏或表结构缺失：别删库，先尝试 SQL 恢复
直接 rm -f bt_monitor.db 会清空所有历史数据，且新库初始化失败时图表仍不显示。SQLite 支持在线恢复，优先用 .recover 命令抢救。
- 进数据库目录：
cd /www/server/panel/plugin/monitor/ - 检查完整性：
sqlite3 bt_monitor.db "PRAGMA integrity_check;"，返回不是ok就要修 - 执行恢复：
sqlite3 bt_monitor.db ".recover" | sqlite3 bt_monitor.db.recovered && mv bt_monitor.db.recovered bt_monitor.db - 验证表是否存在：
sqlite3 bt_monitor.db ".tables"，必须看到cpu memory disk network等表名 - 若仍缺表，按宝塔 v8.0+ 实际 schema 手动建，例如：
sqlite3 bt_monitor.db "CREATE TABLE IF NOT EXISTS cpu (id INTEGER PRIMARY KEY AUTOINCREMENT, time INTEGER, used REAL, system REAL, user REAL, iowait REAL);"
采集周期和前端轮询不同步：改了后端不调前端等于白改
很多人把 status.conf 的 interval=300 改成 60，但前端 JS 还在每 30 秒请求一次 API，结果图表更新延迟翻倍。
- 后端改采集间隔：
vi /www/server/panel/data/status.conf→ 修改interval=60→systemctl restart bt_status - 前端改轮询：
vi /www/server/panel/BTPanel/static/js/index.js→ 搜索setInterval(function(){→ 找到类似url: '/api/panel/get_system_info'的请求段 → 把30000改成10000 - 浏览器必须强制刷新（
Ctrl+Shift+R），否则缓存的旧 JS 仍在运行 - 注意：低于 30 秒轮询可能让低配机器（1 核 1G）的
bt_statusCPU 占用从 0.5% 涨到 5%，慎压
真正难排查的是「数据有但明显偏低/偏高」，比如流量比 iftop 少一半——这往往是因为宝塔默认统计所有网卡，而你只关注 eth0。切换首页右上角网卡下拉框，逐个对比，才能定位是否是聚合统计导致的偏差。
