如果你手头有两台以上 VPS、上面跑着网站、爬虫或定时任务，编写脚本自动巡检 VPS 运行状态非常值得，成本几乎为零，却能把故障发现时间从几小时压缩到几分钟。
先算一笔账：脚本巡检的成本到底有多低
很多人一听到“写脚本”就头大，觉得要学编程、要折腾半天，写一个最基础的 VPS 状态巡检脚本，用到的命令不超过十个，复制粘贴就能跑，真正花时间的是想清楚“我要检查什么”和“出了问题怎么通知我”。
人工巡检 VPS 的典型流程是：登录 SSH，敲 top 看负载，敲 free -h 看内存，敲 df -h 看磁盘，顺手 ping 一下外部地址，这一套动作熟练的话大概五分钟，如果你有 3 台 VPS，每台都要重复一遍，每天一次就是 15 分钟，一个月就是 7 个多小时，而脚本写完一次，以后每次执行只需要几秒钟，还是自动完成。
便宜 VPS 有必要自动巡检吗？价格越低越不能偷懒
不少朋友觉得,一年几十块钱的便宜 VPS 性能差、配置低，挂了就挂了，不值得专门写脚本盯着，这个想法恰恰反了。
便宜 VPS 通常意味着几个风险：
- 宿主机超售更严重,CPU 或磁盘 I/O 容易突然变慢。
- 商家可能限制突发流量,网络抖动或丢包更常见。
- 硬件故障率相对较高,内存或磁盘报错概率更大。
- 工单响应慢,真出问题等你发现，可能已经宕了好几天。
正是因为它便宜,才更需要自动巡检帮你守住底线，一台跑着个人博客或备用代理的廉价 VPS，如果半夜挂了没人知道，第二天访问失败，损失的是你自己的时间和信誉。
下面这张表可以直观看出人工巡检和脚本巡检的差异：
| 对比项 | 人工巡检 | 脚本自动巡检 |
|---|---|---|
| 单次耗时 | 每台 3-5 分钟 | 全自动，数秒完成 |
| 夜间覆盖 | 基本靠运气 | 定时执行，稳定触发 |
| 告警及时性 | 发现时往往已中断较久 | 可做到分钟级通知 |
| 执行一致性 | 容易漏项 | 每次检查完全一样 |
| 额外成本 | 时间与精力 | 几乎为零 |
VPS 自动巡检脚本值得吗？看这 3 个判断条件就清楚
并不是所有 VPS 都需要自己写脚本，如果你的情况不满足下面任何一条，暂时用手动检查也够用，但只要命中一条，脚本巡检的收益就大于投入。
你管理的 VPS 超过 2 台
机器一多,人工登录检查的时间成本会快速上升，2 台还能忍，3 台开始烦躁，5 台以上基本不可能每天手动查，脚本一次可以批量巡检所有机器，统一输出结果，这个优势非常明显。
上面跑着不能长时间中断的服务
比如个人博客、API 接口、定时推送、数据库备份、刷票脚本或者监控面板，这些服务对可用性有要求，尤其是面向公开用户时，自动巡检可以在服务进程挂掉、端口不通、磁盘写满之前发出提醒，而不是等用户来告诉你“网站打不开了”。
你经常忘记上次是什么时候检查的
很多人是这样的：今天想起来就看一眼，想不起来就半个月不管，脚本不会忘，它可以固定在每天早上、每隔 4 小时、或者每分钟执行，把结果通过邮件、Telegram、Server 酱或者钉钉机器人推送给你，养成习惯之后，你对每台 VPS 的状态都会有连续记录。
业内专家指出,自动巡检的核心价值不在脚本本身，而在强制自己建立检查清单，写脚本的过程就是梳理“哪些指标异常需要处理”的过程。
Linux VPS 自动巡检脚本教程：核心命令与配置路径
这部分直接给可落地的步骤,以最常见的 Ubuntu/Debian 和 CentOS 为例，Shell 脚本语法一致，个别命令路径略有差异。
第一步：确定要巡检的指标
一个基础脚本至少应该覆盖以下五项：
- CPU 负载：用
uptime或者读取/proc/loadavg，判断负载是否超过 CPU 核心数的合理倍数。 - 内存使用：用
free -h或读取/proc/meminfo，判断可用内存是否过低。 - 磁盘占用：用
df -h，检查根分区使用率是否接近写满。 - 关键进程：用
systemctl is-active检查 nginx、mysql、docker 等服务是否运行。 - 网络连通性：用
ping或curl测试外部地址，ping -c 3 8.8.8.8。
第二步：编写 Shell 脚本并添加告警逻辑
下面是一个可直接复制修改的极简脚本,保存为 /root/vps_check.sh：
#!/bin/bash
# 设置告警阈值
LOAD_LIMIT=2.0
MEM_LIMIT=90
DISK_LIMIT=85
# 获取当前时间
DATE=$(date "+%Y-%m-%d %H:%M:%S")
# 检查 CPU 负载（取 1 分钟平均值）
LOAD=$(uptime | awk -F'load average:' '{print $2}' | cut -d',' -f1 | tr -d ' ')
if awk "BEGIN {exit !($LOAD > $LOAD_LIMIT)}"; then
echo "$DATE 负载过高：$LOAD"
fi
# 检查内存使用率
MEM_USED=$(free | grep Mem | awk '{printf "%.0f", $3/$2 100}')
if [ "$MEM_USED" -gt "$MEM_LIMIT" ]; then
echo "$DATE 内存使用率：$MEM_USED%"
fi
# 检查磁盘根分区使用率
DISK_USED=$(df -h / | awk 'NR==2 {gsub("%",""); print $5}')
if [ "$DISK_USED" -gt "$DISK_LIMIT" ]; then
echo "$DATE 磁盘使用率：$DISK_USED%"
fi
# 检查关键服务
for SERVICE in nginx mysql docker; do
if ! systemctl is-active --quiet $SERVICE; then
echo "$DATE 服务 $SERVICE 未运行"
fi
done
# 检查网络连通性
if ! ping -c 3 -W 2 8.8.8.8 > /dev/null 2>&1; then
echo "$DATE 网络不通"
fi
这个脚本把异常情况输出到终端,你可以手动执行一次看效果，如果所有指标正常，不会有任何输出。
第三步：接入告警推送并用 cron 定时执行
光在终端输出还不够,深夜宕机时你看不到，推荐用 curl 调用 Server 酱、Telegram Bot 或者钉钉群机器人，把异常信息推送出去，修改脚本最后，把 echo 替换成推送函数即可。
下面用 Telegram Bot 举例，在脚本开头配置好 Token 和 Chat ID：
TOKEN="你的机器人Token"
CHAT_ID="你的Chat_ID"
send_msg() {
curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
-d chat_id="$CHAT_ID" -d text="$1" > /dev/null
}
然后在每个 echo 后面加上 send_msg 调用即可完成告警。
定时任务用 cron 配置，执行 crontab -e，加入一行：
/5 /bin/bash /root/vps_check.sh
这表示每 5 分钟执行一次，如果检查频率不需要那么高，可以改成每小时一次：0 。
VPS 监控脚本和宝塔面板对比：轻量与全能的取舍
很多人会问：自己写脚本和用宝塔面板的监控功能，到底哪个好？这个问题没有绝对答案，取决于你的使用习惯和场景。
功能维度
宝塔面板自带资源监控、异常告警、日志查看，还能直接在网页上操作，对新手非常友好，但代价是宝塔会安装大量依赖和面板服务，占用一部分内存和 CPU，在 1 核 512M 的小鸡上，宝塔面板本身可能就要占掉 200M 以上内存，这对跑应用来说是不小的开销。
自写脚本则极其轻量,只调用系统自带命令，不安装额外服务，不占常驻内存，缺点是没有图形界面，所有信息靠推送和日志，排查问题时不如面板直观。
告警灵活性
宝塔的告警方式相对固定,一般通过邮件或内置通知渠道，脚本告警则完全由你掌控，可以接入任意机器人、可以自定义阈值、可以检查面板不支持的指标，比如某个具体端口连通性、某个进程的 CPU 占用、某个域名的 HTTPS 证书剩余天数。
适用场景
- 用自写脚本：VPS 台数多、配置低、追求极致资源利用、有自定义告警需求。
- 用宝塔面板：只有一台机器、想快速搭网站顺便看状态、不愿碰命令行。
行业内也有一种折中选择：用 UptimeRobot 或 HetrixTools 这类外部监控服务做在线率和端口检查，再配合脚本做机器内部资源检查，但外部监控无法检测磁盘将满、内存泄漏、进程假死等内部问题。
海外 VPS 自动巡检方案：加测延迟和丢包
国内 VPS 巡检通常关注资源占用，海外 VPS 还需要额外叠加网络质量检测，因为跨地域链路更容易出现延迟升高、丢包、TCP 握手超时的问题。
为什么海外机器要单独测网络
海外 VPS 的物理位置离你较远，数据要经过多个运营商交换节点，一台洛杉矶 VPS 可能白天延迟 150ms，晚上高峰涨到 300ms，或者出现间歇性丢包，如果只查 CPU 和内存，看起来一切正常，但实际访问体验已经很差。
具体检测命令
在巡检脚本中追加两条命令：
# 测试到国内延迟 ping -c 5 -W 3 114.114.114.114 | tail -1 # 快速查看丢包率 ping -c 10 -W 2 你的本地运营商IP | grep 'packet loss'
对于需要持续观测的海外节点,可以用 mtr 代替 ping，能看到每一跳的延迟和丢包：
mtr -r -c 10 -w 目标IP
把 mtr 输出追加到日志中，方便事后定位是骨干网拥塞还是机房线路故障。
多地域对比
如果你同时有香港、日本、美国、欧洲的 VPS，建议脚本里分别测试到国内的延迟，并设置不同阈值，比如香港机器到广州平均延迟超过 60ms 可能就不正常，美国机器到上海延迟 180ms 则属于正常波动，阈值写死之前，先手动测几天，摸清每台机器的基线。
行业共识认为,海外 VPS 的网络监控至少应包含延迟抖动和丢包率两个维度，单看在线状态很容易漏掉线路劣化。
花半小时写一个 VPS 自动巡检脚本，换来的是每一台机器都在你眼皮底下运行，它不会让你的 VPS 不宕机，但能让你在问题扩大之前知道该动手了。只要你有两台以上的 VPS 或者关键服务在跑，这件事就值得今天开始做。
VPS 自动巡检脚本的常见疑问
VPS 自动巡检脚本多久执行一次比较合适？
多数业务场景下,每 5 分钟执行一次完全够用，频率过高会增加系统负担和推送噪声，频率过低则失去及时发现的意义，对于只跑静态博客的低流量 VPS，每小时一次即可；对于有 API 服务或交易任务的关键机器，可以保持 1-5 分钟一次，同时把告警阈值调得更严格，避免频繁误报。
没有编程基础能学会写 VPS 自动巡检脚本吗？
能,本文展示的 Shell 脚本只需要会复制、修改几个数字、保存文件、运行一条命令，涉及的 uptime、free、df、systemctl 都是 Linux 日常管理命令，不涉及复杂语法，即便完全不会写，也可以先从网上找到现成的巡检脚本模板，按注释改自己的机器信息就能用，多数情况下，改一个现成脚本的学习成本比手动巡检一周的时间成本还低。
用脚本巡检能替代专业监控工具吗？
脚本巡检擅长资源阈值检查和自定义进程检查,但在分布式架构、历史趋势图、多节点统一大盘、复杂告警路由方面，专业工具如 Zabbix、Prometheus、Grafana 仍然更强，单机 VPS 或者小规模多机场景下，自写脚本足够覆盖核心异常；当机器数量增长到十几台以上、或者需要长期保留监控数据做分析时，再迁移到专业监控系统也不迟，自写脚本作为过渡方案，可以在不增加额外部署成本的前提下先建立检查习惯和告警基线。