如何通过日志追踪系统资源消耗

聊一个系统运维中绕不开的话题——资源监控。通过日志追踪系统资源消耗，是排查性能瓶颈、定位异常、优化稳定性的基本功。下面把整个过程拆开来细说，从选工具到搭警报，一步不落。

1. 确定需要监控的资源

别急着开干，先想清楚：你到底要盯哪些指标？常见的几类资源，一个都不能少：

• CPU 使用率——看看是不是有进程在“吃”满核心；
• 内存使用情况——有没有泄漏、Swap 是不是频繁；
• 磁盘 I/O——读写是否陷入瓶颈；
• 网络流量——带宽有没有被占满；
• 进程和线程活动——哪个程序在搞事情。

把清单列出来，后续配置才有方向。经验之谈：一开始别贪多，先抓最关键的几个。

2. 选择合适的日志工具

不同操作系统，各有看家本领。选工具时，先看自己手上的牌——

• Linux 阵营：sysstat 包里的 sar 是经典，配合 top/htop、vmstat、iostat、netstat、dstat，基本覆盖全场景；
• Windows 阵营：任务管理器看个大概，Resource Monitor 能深扒，Performance Monitor（perfmon）适合长期记录，Process Explorer 则擅长抓进程细节。

选哪个？我的建议是：日常排查用 top/任务管理器，长期记录上 sar/perfmon。

3. 配置日志工具

工具选好，接下来就是“怎么记”。以 sar 为例，设置采样间隔和记录时间简直是分分钟的事：

# 记录 CPU 使用情况
sar -u 1 10 > cpu_usage.log
# 记录内存使用情况
sar -r 1 10 > memory_usage.log
# 记录磁盘 I/O 情况
sar -d 1 10 > disk_io_usage.log
# 记录网络流量
sar -n DEV 1 10 > network_usage.log

这里 1 10 的意思是每隔1秒采样一次，共10次。实际生产环境中，采样间隔和总时长要根据业务负载来调——比如高峰时段加密，低谷时段拉长。

4. 分析日志文件

日志落地只是第一步，真正花时间的是分析。数据到手之后，有几种玩法：

• 直接用文本编辑器打开 vim、nano 快速扫一眼峰值点；
• 用命令行三剑客 grep、awk、sed 做过滤和统计，比如找出 CPU 使用率超过 90% 的时间段；
• 数据量大了，上可视化工具 gnuplot、matplotlib、Plotly 画个折线图，一眼看出趋势。

别小看这些“笨办法”，很多隐性瓶颈就是靠 awk 一行行揪出来的。

5. 设置警报

被动等人报修？不，最好让日志替你值班。比如用 cron 定时跑个脚本，一旦 CPU 超标就发邮件：

# 每小时检查一次 CPU 使用率，如果超过 90% 则发送邮件
0 * * * * /path/to/check_cpu_usage.sh

当然，邮件容易淹没，可以换成钉钉/企业微信/信息，根据自己的运维设施来。关键是阈值设置——别太敏感，也别太迟钝，先根据历史数据定个基线。

6. 自动化监控

如果手下的机器超过三五台，靠手动跑 sar 和写脚本就不太现实了。这时候就该请出专业选手：Prometheus + Grafana、Zabbix 等。它们能实时采集、持久存储、可视化展示，还有灵活的告警规则。简单说：把日志变成可交互的仪表盘，资源消耗一目了然，异常自动推送。

示例脚本

最后贴一个顺手就能用的 Bash 脚本，把几个资源的日志一次性收起来：

#!/bin/bash
# 记录 CPU 使用情况
sar -u 1 1 > cpu_usage.log &
# 记录内存使用情况
sar -r 1 1 > memory_usage.log &
# 记录磁盘 I/O 使用情况
sar -d 1 1 > disk_io_usage.log &
# 记录网络流量
sar -n DEV 1 1 > network_usage.log &

实际使用时可把 1 1 改成你需要的采样次数和间隔，也可以加个 while 循环让它持续记录。总之，日志追踪这事，入门不难，深挖可无穷——关键是形成习惯，把数据变成决策依据。