要查看服务器的历史内存和CPU使用情况,核心上文归纳是：必须依赖系统自带的日志记录工具或部署第三方监控系统，因为Linux或Windows系统自带的实时命令（如top、htop或任务管理器）只能展示当前瞬间的快照，无法回溯过去的数据，要实现历史数据的回溯，通常需要开启系统内置的性能计数器日志，或者安装专业的监控代理（如Prometheus、Zabbix）来持续采集并存储时序数据。
Linux服务器查看历史资源使用情况
在Linux服务器环境下,查看历史数据最直接且无需安装额外大型软件的方式是利用sysstat工具包中的sar命令。sar（System Activity Reporter）是系统性能监控的黄金标准，它能够通过后台服务定期收集系统状态并保存为二进制日志文件。
安装与配置sysstat
大多数Linux发行版默认并未开启自动记录功能，首先需要确保sysstat包已安装。
- 安装命令：
yum install sysstat(CentOS/RHEL) 或apt-get install sysstat(Ubuntu/Debian)。 - 开启记录：安装后，需要修改配置文件
/etc/default/sysstat（Debian系）或/etc/sysconfig/sysstat（RedHat系），将ENABLED设置为true，并调整收集频率，例如每10分钟收集一次。 - 历史日志位置：默认情况下，日志文件保存在
/var/log/sa/目录下，文件名通常为saXX（XX代表日期）。
使用sar命令查看历史数据
配置完成后，管理员可以通过sar命令调取指定日期的历史文件进行分析。
- 查看历史CPU使用率：使用命令
sar -u -f /var/log/sa/sa10（假设查看10号的日志），输出结果中，%user代表用户空间进程占用，%system代表内核空间占用，%idle代表空闲率，如果%idle长期低于10%，说明CPU负载过高。 - 查看历史内存使用情况：使用命令
sar -r -f /var/log/sa/sa10，重点关注%memused（内存使用百分比）和%commit（提交空间的使用率），如果kbmemfree（剩余内存）持续维持在极低水平，且伴随kbswpfree（交换空间剩余）减少，说明系统发生了内存交换，会导致性能急剧下降。
进程级历史追踪
sar只能看到整体资源使用情况，无法定位具体是哪个进程导致的，若需查看历史进程资源消耗，可以使用psacct或acct服务。
- 启用进程记账：启动
accton服务，系统会记录所有进程的执行历史。 - 查询命令：使用
lastcomm命令可以查看历史上执行过的命令及其消耗的CPU时间和内存时间，这对于排查“是谁在凌晨3点把服务器跑挂了”这类问题非常有效。
Windows服务器查看历史资源使用情况
Windows Server提供了强大的内置工具“性能监视器”，无需下载第三方软件即可实现专业的历史数据记录。
配置数据收集器集
- 打开“性能监视器”，在左侧导航栏展开“数据收集器集”。
- 右键点击“用户定义”，选择“新建” -> “数据收集器集”。
- 选择“创建手动数据收集器集”，命名为“Server_Monitor”。
- 选择“性能计数器”，在此处添加关键指标：Processor下的
% Processor Time（CPU使用率）、Memory下的Available MBytes（可用内存）和Pages/sec（换页率）。 - 设置保存目录和日志格式（通常选择二进制循环数据库，以避免占用过多磁盘空间）。
查看历史数据
配置完成后，系统会按照设定的时间间隔（如1分钟）自动记录数据，管理员只需在“数据收集器集”中右键点击刚才创建的集合并选择“最新报告”，即可看到可视化的历史曲线图，通过图表可以直观地发现CPU波峰出现的具体时间点，以及内存是否存在缓慢泄漏的趋势。
企业级监控解决方案（专业架构）
对于生产环境,单纯依赖系统自带的日志往往不够直观且难以管理，构建基于Prometheus + Grafana的监控体系是目前业界最专业、最权威的解决方案。
部署Node Exporter
在每一台需要监控的服务器上部署Node Exporter，它是一个轻量级的采集代理，能够实时读取服务器的/proc文件系统（Linux）或性能计数器（Windows），并将CPU、内存、磁盘I/O等指标以HTTP接口的形式暴露出来。
数据采集与存储
部署Prometheus服务器，配置抓取任务，定期拉取所有Node Exporter的数据，Prometheus内置了强大的时序数据库，能够高效存储多年的历史数据，并支持PromQL查询语言进行复杂的数据分析。
可视化与告警
部署Grafana并连接Prometheus作为数据源，在Grafana中可以导入专业的Dashboard模板（如“Node Exporter Full”），一键生成包含历史趋势、峰值、平均值等丰富图表的大屏。
- 独立见解：相比于查看命令行，Grafana支持“数据下钻”，当你发现某天凌晨CPU异常时，可以直接在图表上框选该时间段，放大查看细节，甚至通过关联日志面板直接查看当时的报错信息，这种“所见即所得”的体验是命令行工具无法比拟的。
历史数据分析与故障排查思路
拥有数据只是第一步,如何解读数据才是体现运维专业度的关键。
识别CPU瓶颈
如果在历史数据中发现CPU的%iowait（等待I/O时间）较高，说明CPU并非瓶颈，瓶颈在于磁盘读写速度；如果是%system较高，说明内核进行了大量上下文切换，可能是因为进程数量过多或短连接请求过于频繁。
诊断内存泄漏
正常的内存使用曲线应该是“锯齿状”的（业务请求增加内存升高，业务结束内存释放），如果历史曲线呈现“阶梯状”持续上升，且从未回落，这通常是应用程序存在内存泄漏，结合top命令查看具体进程的RES（常驻物理内存）变化，可以定位到具体的PID。
关联Swap活动
观察内存历史时，必须同时关注Swap in/out的指标，如果历史数据显示在内存未满的情况下就发生了Swap活动，可能是swappiness参数设置过低，导致系统过于积极地交换内存，这需要调整内核参数进行优化。
相关问答
Q1：为什么我输入 top 命令看不到昨天的CPU和内存数据？
A： top 命令是一个动态实时监视工具，它直接从 /proc 目录读取当前瞬时的系统状态快照，它不具备后台存储功能，不会将数据写入硬盘文件，一旦退出或刷新，之前的数据就会丢失，要查看历史数据，必须使用具备日志记录功能的工具，如 sar 或 vmstat 配合脚本记录。
Q2：服务器重启后，之前的监控历史数据会丢失吗？
A： 这取决于使用的监控方案，如果使用 Linux 自带的 sysstat（sar），其日志文件保存在 /var/log/sa/ 目录下，重启不会丢失这些文件，如果使用 Prometheus + Grafana 等第三方监控系统，数据存储在独立的数据库或持久化存储卷中，服务器重启也不会影响历史数据的保留，但如果是仅依赖内存缓存的临时监控方案，重启后数据会清空。
能帮助您全面掌握服务器历史资源的监控方法,如果您在配置 sysstat 或搭建 Prometheus 环境时遇到具体的报错问题，欢迎在评论区留言，我们将为您提供具体的故障排查建议。
