监控VPS的CPU和内存，核心就一句话：先学会用top和free两条命令应急，再部署一套netdata或Prometheus + Grafana做长期趋势记录，最后配上告警通知，日常就不用盯着看了。
这个思路覆盖了从“临时排查”到“长期运维”的完整链路，下面我按实际使用场景,把每一步拆开讲。
临时排查：VPS卡了，先看这两条命令
网站打不开、SSH敲命令明显延迟，这时候别慌，登进服务器先看两个数据：CPU有没有被打满，内存是不是不够用了，操作系统自带的标准工具，90%的情况能直接定位问题。
CPU占用高怎么看
登录服务器后，输入top回车，屏幕上半部分就是CPU和内存的实时总览，重点关注%Cpu(s)这一行里的us（用户态）和sy（系统态）数值，如果这两项加起来长期超过80%，说明CPU确实在忙，忙的原因是什么？看下面进程列表里的%CPU列，按P键可以按CPU占用率排序，哪个进程在最上面,就是它在吃CPU。
如果CPU占用率不高，但系统很卡，要留意wa（I/O等待）数值，如果wa长期超过30%，多半是磁盘读写卡住了，这时候CPU在等硬盘，换CPU没用,得看磁盘IO和swap使用量。
内存和交换分区检查
看内存不用退出top，直接看KiB Mem和KiB Swap两行。free -h命令的输出更直观，推荐两个一起用，看内存别只看used列，重点看available（可用内存）,这才是程序真正能用的量。
Linux的内存策略是“有多少用多少”，空闲内存被文件缓存占用是正常的，如果available接近0，同时Swap的used数值持续增长，说明物理内存真不够了，系统开始用磁盘假装内存,这时候性能会断崖式下跌。
行业共识认为，swap使用率持续超过20%,就该考虑升级内存配置或者排查是否有内存泄漏了。
长期监控：别等卡了再看，让工具替你盯着
临时命令只能看当下瞬间，无法回答“昨晚是不是有人跑了个定时任务吃满了CPU”这类问题，长期监控本质是解决三件事：记录历史数据、设置告警、预测容量。
轻量级方案：netdata，适合单台VPS
如果你只有一两台VPS，不想折腾，直接用netdata，安装很简单，官方给了一键脚本，装在Ubuntu或Debian系统上两分钟能跑起来，装完后浏览器访问
http://你的服务器IP:19999，就能看到实时滚动的CPU、内存、网络、磁盘图表。
netdata的特点是可以看到秒级的数据变化，排查偶发性能问题很好用，它内置了告警规则，比如CPU温度过高或内存不足时会发出通知，支持邮件、Telegram、钉钉等多种渠道，唯一缺点是它在服务器上本身会占用约100MB左右内存，配置特别低（如512MB内存）的VPS不建议装。
重量级方案：Prometheus + Grafana，适合集群和多台机器
机器多了或者想要自定义告警规则，就得用Prometheus采集数据、Grafana做可视化、Alertmanager发告警，这套组合是当前开源监控的事实标准，踩坑案例多,网上资料也全。
这套方案有三块拼图：
node_exporter：装在被监控的VPS上,暴露一个HTTP接口提供系统指标。Prometheus服务端：定期去抓取node_exporter的数据,存在自带的时间序列数据库里。Grafana：从Prometheus读取数据画图，支持拖拽式仪表盘，模板很多,导入ID就能用。
配置时需要写一个配置文件，指定要采集哪些目标，首次配置比较复杂，但如果管理超过3台VPS,这套方案比挨个登录netdata看效率高得多。
告警规则：监控的最终目的是触发通知
数据图表存了一大堆，没人看等于白搭，设置告警的准则是：别报太多，报一条就要精准解决问题。
CPU和内存告警阈值怎么设
行业常规做法是按优先级区分：
- 警告级（Warning）：CPU使用率持续10分钟超过80%，或内存可用量低于20%。
- 严重级（Critical）：CPU使用率持续5分钟超过95%，或内存可用量低于5%，或swap使用率超过50%。
熟练运维会把“持续时间”加上，避免短暂的峰值频繁骚扰，比如某活动瞬时CPU到了90%，但两秒就降下来了，这种情况不该收到告警，借助工具内置的for语法，可以设置当CPU > 80%，持续2分钟才触发。
告警渠道优先级
推荐首选Telegram Bot或钉钉/企业微信机器人，它们免费且推送速度快，邮件适合做日报存档，不适合告警，因为大多数人不会秒回邮件，如果VPS在国内，考虑Server酱或飞书机器人，配置都挺简单,本质上是往一个Webhook地址发一段JSON请求。
场景实战：网站变慢时的排查顺序
这里整理一个常见场景的排查步骤，希望你能记住，云服务器厂商的工单系统遇到逼疯客服的问题,也多半绕不开这几步。
假设业务是WordPress站点，用户反馈后台打开很慢,按以下顺序操作：
- SSH登录VPS，先跑
free -h，看内存是否耗尽、swap是否被大量使用，如果swap的used数值在跳,说明内存是瓶颈。 - 再跑
top，按P看CPU占用最高的进程，如果PHP-FPM占了多个进程且CPU都高,可能是数据库查询慢或有人刷接口。 - 如果CPU和内存都正常，用
vmstat 1 5看r（运行队列）值。r值持续大于CPU核心数，代表任务在排队,体验会明显卡顿。 - 都排查不出问题时，检查
dmesg | tail，看有没有OOM（内存溢出）杀进程的记录，这通常意味着某些程序内存不够用,被内核强制终止了。
常用命令速查表
这里汇总我平时用得最多的几条命令,建议截图收藏：
| 场景 | 命令 | 关键关注点 |
|---|---|---|
| 实时总览 | top |
us/sy/wa 三类CPU占比，进程CPU排行 |
| 内存明细 | free -h |
available列，swap的used值 |
| CPU核心数 | nproc |
判断是否有4个及以上核心 |
| 磁盘IO瓶颈 | iostat -x 1 |
%util是否接近100% |
| 历史负载趋势 | uptime |
1分钟/5分钟/15分钟负载均值对比 |
| 查OOM日志 | dmesg | grep -i kill |
看是否有进程被强制终止 |
常见误区：盯错指标比不看还坑
新手监控VPS最常犯的错，是把空闲内存当成可用内存，Linux的内存管理机制把空闲内存用作文件缓存（buff/cache），这部分内存在程序需要时会被内核自动释放，所以看到used占比90%不用紧张，只要available还够,就不用加内存。
第二个误区是盲目追求CPU使用率低，如果一台VPS部署着数据库，CPU长期100%但查询响应很快，这种情况下不一定是坏事，可能在预处理聚合报表，关键看在服务的响应时间,不是看资源利用率数字本身。
第三个误区，忽略了1分钟负载和15分钟负载的差值
，负载是一个平均数，如果1分钟负载比15分钟高出一大截，说明系统正在经历瞬时峰值，可能是定时任务所致，反过来，1分钟低而15分钟高，说明系统已经持续高负载了一段时间,更值得警惕。
监控工具选型：结合成本和人效
对于多数个人站长，付费的云监控服务通常比自建更省心，简米云、酷番云都自带免费的“基础监控”，包含CPU、内存、带宽的图表数据，能在控制台里直接看，还能设置报警规则，好处是零部署、无额外资源消耗，缺点是历史数据默认只保留几天,想查更早的数据需要开通付费的云监控服务。
第三方探针服务（如UptimeRobot、StatusCake）则是从外部视角探测网站可用性，能够发现服务器活着但网站打不开的情况，这类服务通常有免费额度，监控频率是1分钟或5分钟,对个人项目来说够用了。
如果是低配VPS，比如512MB内存以下（经常出现在廉价VPS和特价VPS中），建议别装太多监控组件，用系统的cron写一个脚本，每隔5分钟把CPU和内存使用率追加到日志文件，再用logrotate做日志轮转,足够了。
Q&A：关于VPS性能监控的高频疑问
VPS的CPU使用率在哪里看是最准的？
以Linux系统为例，以top命令输出为准，云厂商控制台的监控面板数据采样频率通常是10到60秒一次，曲线会被平滑掉，瞬时尖峰显示不出来。top看到的是当前实时数据，如果希望更合理判断整体压力，参照uptime里的15分钟负载比单看CPU百分比更能反映系统稳定性。
用宝塔面板的监控够用吗？
宝塔面板自带的监控图表能满足基础需求，它本质上是读取系统的/proc虚拟文件系统数据并绘制图形，优点是一眼浏览所有资源，适合新手，但这些数据不够细，缺少进程级历史回溯，新装的软件如果短时间内存飙升，面板上只能看到整体内存曲线有波动，很难定位到具体进程，用htop补足进程级实时观察,会适用大多数排查需求。
免费监控工具能撑住多大规模的业务？
个人博客、小型电商站点用netdata或云厂商自带监控完全够用，底层依赖的/proc接口数据采集本身消耗极小，对VPS性能影响通常小于1%，当规模上升到几十台机器、需要做容量规划或统一告警时，免费方案的维护复杂度会显著增加,此时需要评估投入时间成本是选择商业SaaS监控服务还是自建Prometheus体系更划算。