很多站长把网站部署上线之后，就很少再回头看服务器本身的状态了。直到某天网站突然打不开、CPU 飙到 100%、磁盘被日志写满、流量跑冒烟，才手忙脚乱地 SSH 上去翻日志。其实性能问题从来不是突然出现的，只是没有在它萌芽的时候发现它。这篇文章按真实的排查顺序，从命令行工具讲到可视化面板，把 VPS 性能监控从“事后救火”变成“事前预防”。
一、先看负载：你的 VPS 到底忙不忙
排查性能问题，第一步永远是看系统负载。SSH 登录后先执行 uptime：
uptime
输出示例：
14:32:11 up 68 days, 4:23, 2 users, load average: 0.18, 0.31, 0.35
load average 的三个数字分别代表 1 分钟、5 分钟、15 分钟的平均负载。对 VPS 来说，负载除以 CPU 核数，结果接近 1 就是满负荷，长期大于 1 说明 CPU 不够用。比如 2 核机器负载常驻 2.0 以上，就该考虑优化程序或者升级配置了。
需要注意，负载高不代表一定是 CPU 问题：磁盘 I/O 阻塞、内存不足频繁换页也会把负载拉高。所以下一步要结合 CPU 和内存一起看。
二、CPU 与内存：top 的进阶用法
top 是最常用的性能命令，但很多人只看第一行。真正排查的时候要重点看两样东西：CPU 占用最高的进程、以及内存的“实际剩余”。
top -c
进入 top 之后：按 P 按 CPU 排序，按 M 按内存排序；按 1 查看每个 CPU 核心的使用情况；按 c 切换显示完整命令行，看清到底是哪个程序在跑。
如果某个进程 CPU 持续 100%，先用 ps 确认它的启动参数和归属：
ps aux --sort=-%cpu | head -10
重点怀疑对象：PHP-FPM 进程数爆满、Java 堆内存太小频繁 Full GC、以及来路不明的进程（公网机器被植入挖矿程序是常见事故，遇到不认识的进程配合安全加固文章先处理）。
内存看两处。第一个是 free：
free -h
total used free shared buff/cache available Mem: 1.9Gi 1.2Gi 132Mi 32Mi 578Mi 593Mi
available 才是真正可用的内存，别只看 free 列。如果 available 长期低于 10%，说明内存告急，频繁 swap 会把整台机器拖慢。再配合 vmstat 看 swap 活动：
vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 132M ... 0 0 0 0 12 14 1 1 98 0 0
si/so 如果持续非零，说明系统正在频繁换页，基本可以断定是内存不足。r 列代表等待 CPU 的进程数，长期大于核数就是 CPU 瓶颈。
三、磁盘与 I/O：最容易被忽略的杀手
磁盘写满是 VPS 故障的重灾区。先看空间：
df -h du -sh /var/log/* | sort -hr | head -10
再确认是谁在读写磁盘。如果遇到“系统卡死但 CPU 空闲”的情况，八成是 I/O 阻塞：
iostat -x 1 5
重点看 %util，长期 90% 以上说明磁盘已经是瓶颈。再配合 iotop 实时确认是哪个进程在疯狂读写：
iotop
典型场景：MySQL binlog 没清理、Nginx/PHP 日志无限增长、某个进程在反复写临时文件。配合定时任务文章里的 logrotate，提前把日志轮转配置好，能省掉后面很多麻烦。
四、网络与端口：流量到底去哪了
网站慢有时候是网络问题，而不是服务器性能问题。先看端口监听和连接数：
ss -tunlp ss -s ss -tn state established | wc -l
再装两个实时工具，看流量去向：
apt install -y iftop nethogs yum install -y iftop nethogs
iftop -i eth0 nethogs eth0
如果某个 IP 的并发连接异常高，可能是被 CC 攻击或者爬虫在刷量，在防火墙层面直接封掉，比优化程序更有效。跨地域访问慢的，用 mtr 看链路：
mtr -rwc 20 目标IP
丢包出现在哪个节点一目了然，是本地机房的问题还是上游运营商的问题，先定位再处理。
五、一键上可视化：Netdata 五分钟装好
命令行工具适合排查，但“天天盯命令行”不现实。想低成本获得实时看板，推荐 Netdata：
curl -Ss https://my-netdata.io/kickstart.sh | bash
装完直接访问 http://你的IP:19999，CPU、内存、磁盘、网络、每个进程的实时指标全都有，默认保留最近一小时数据，零配置就能用。对单机 VPS 来说，Netdata 是性价比最高的监控方案，一条命令解决 80% 的监控需求。
六、进阶：Prometheus + Grafana 长期趋势与告警
Netdata 适合实时看。但如果想保留长期趋势、做告警、把多台服务器汇总到一个面板，就需要 Prometheus + Grafana 这套组合。
1. 部署 node_exporter 采集器
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xzf node_exporter-*.tar.gz ./node_exporter &
默认监听 9100 端口，生产环境建议用 systemd 守护。
2. 配置 Prometheus 拉取指标
新建 prometheus.yml：
global:
scrape_interval: 15s
scrape_configs:
- job_name: node
static_configs:
- targets: ['localhost:9100']启动后访问 9090 端口，在 Query 里输入 node_cpu_seconds_total、node_memory_MemAvailable_bytes 就能查原始指标。
3. 接入 Grafana
apt install -y grafana systemctl start grafana-server
默认 3000 端口。登录后添加数据源选择 Prometheus，地址填 http://localhost:9090，再导入现成仪表盘模板（Node Exporter 官方模板 ID 是 1860），几分钟就有一个专业级看板。
4. 配告警，让监控主动找你
Prometheus 里定义告警规则，配合 Alertmanager 发到邮箱或企业微信、钉钉 Webhook：
groups:
- name: host
rules:
- alert: HighCPU
expr: 100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100 > 90
for: 5m
labels:
severity: warning
annotations:
summary: "CPU 使用率超过 90%"告警的意义在于：问题在半夜发生的时候，是系统打电话叫醒你，而不是第二天早上网站挂了你才知道。
七、一个够用的日常监控清单
不想折腾太多工具，直接按这份清单来，已经覆盖 90% 的单机场景：
磁盘：df -h 每周看一次，日志走 logrotate 自动轮转，剩余空间低于 20% 就清理；
证书与备份：SSL 证书到期、备份失败这类“定时”问题交给 Crontab 自动执行，别靠脑子记；
负载：装好 Netdata，每天瞄一眼首页面板，负载曲线突然拔高再上命令排查；
连接数：ss -s 每周看一次，异常增长先查防火墙再查程序；
更新：内核安全补丁及时打，别让一台“裸奔”的机器跑业务。
结语
性能监控的投入产出比极高：装好工具花不了半小时，却能在网站出问题的第一时间定位原因，而不是在用户投诉之后才开始排查。从命令行三件套（top、df、ss）到 Netdata 一键面板，再到 Prometheus + Grafana 的完整方案，按需选择即可——小流量单机用 Netdata 足够，追求长期趋势和多机统一监控再上全套。建议现在登录你的 VPS 跑一遍 uptime 和 df -h，把“不知道服务器状态”变成“心里有数”。