今年有天早上，我习惯性地打开博客看一眼——转圈，打不开。SSH 上去 top 一看，内存被吃光了，系统在疯狂 swap。重启，恢复，前后十分钟。但那十分钟里我一直在想：它挂了多久？我完全不知道。这感觉就像家里烟雾报警器没装电池，着没着火全靠鼻子。

那天之后，我给这台 2核2G 的小机器装上了"烟雾报警器"。下面是从 free、top 看起，到写一个超限告警脚本的完整入门记录。

先学会看：free、top、df 三件套

监控的第一步不是装软件，是学会看机器的脸色。这三个命令够用很久：

free -h

看内存。重点看 available 那一列，那是真正还能用的。我的经验：长期低于 200M 就要警惕了，2核2G 的机器，available 掉到 100M 以内，离出事不远。

top

看 CPU 和进程。按 M 按内存排序，按 P 按 CPU 排序，一眼找出吃资源的大户。那天早上吃光我内存的，就是一个失控的进程，top 里排第一，RES 列数字大得刺眼。top 是动态的，按 q 退出，别在里面迷路。

df -h

看硬盘。日志、备份最容易把硬盘吃满，/ 分区用到 85% 以上就该清理了。硬盘满了比内存满了更麻烦——内存满了重启能好，硬盘满了连日志都写不进去。

硬盘满了比内存满了更麻烦，日志和备份最容易把硬盘吃满，我的备份方案是每天凌晨打包、只留 7 天，脚本记在另一篇。

这三个命令，我现在每周看一次，跟检查汽车胎压一个频率。不用天天看，但要养成习惯。

告警脚本：让机器学会"喊疼"

人不可能天天盯着 top，所以第二步是写个脚本：资源超限就喊一嗓子。脚本放在 /root/monitor.sh：

#!/bin/bash
# 内存使用超过 85% 就告警
MEM_USED=$(free | awk '/Mem:/ {printf "%.0f", $3/$2*100}')
# 根分区使用超过 85% 就告警
DISK_USED=$(df / | awk 'NR==2 {print $5}' | tr -d '%')
# 1 分钟平均负载超过 CPU 核数就告警（2核机器，超过 2 就算高）
LOAD=$(awk '{print $1}' /proc/loadavg)

ALERT=""

if [ "$MEM_USED" -gt 85 ]; then
    ALERT="${ALERT}内存使用 ${MEM_USED}%，超过 85%。\n"
fi

if [ "$DISK_USED" -gt 85 ]; then
    ALERT="${ALERT}硬盘使用 ${DISK_USED}%，超过 85%。\n"
fi

if awk "BEGIN {exit !($LOAD > 2)}"; then
    ALERT="${ALERT}1 分钟负载 ${LOAD}，超过 2（2核机器）。\n"
fi

if [ -n "$ALERT" ]; then
    echo -e "VPS 告警：\n$ALERT" | mail -s "VPS 资源告警" myemail@example.com
fi

解释一下阈值。内存和硬盘设 85%，是留 15% 的缓冲——告警是让你提前处理，不是等火烧眉毛。负载阈值设成 CPU 核数（我这台 2核，就是 2），这是 Unix 世界的老规矩：负载长期超过核数，说明 CPU 真忙不过来了。短期冲高不用慌，看的是持续。

告警通道我用的邮件。mail 命令需要系统能发信，Ubuntu 上装个 postfix 配成只发送模式就行。有人用 Telegram Bot，有人用 ntfy（我另一篇文章里提过，手机推送很及时）。通道不重要，重要的是告警必须能吵醒你——发到一个你从来不看的邮箱，等于没装报警器。

告警通道我提过 ntfy，它是我 2核2G 机器上跑的三个轻量服务之一，二十来 M 内存，清单记在另一篇里。

定时跑：cron 每 5 分钟检查一次

chmod +x /root/monitor.sh
crontab -e

加一行：

*/5 * * * * /root/monitor.sh

每 5 分钟跑一次。频率别太高，1 分钟一次的话，偶发抖动会让你收到一堆狼来了的告警；也别太低，半小时一次的话，真出事了你知道得太晚。5 分钟是中庸之道——中年人的处世哲学，同样适用于 cron。

收到告警之后：先看 top，再决定

告警只是个哨子，吹哨之后还得会处理。我的处理流程很固定：

  1. SSH 上去，top 按 M 排序，看是谁在吃内存。
  2. 如果是已知服务偶发抖动（比如备份时 tar 占 CPU），等它跑完，观察。
  3. 如果是未知进程或持续走高，systemctl restart 重启对应服务，不行就深入查日志。
  4. 误报（比如备份那几分钟内存冲高）就调阈值或加白名单，别让狼来了消磨你的警惕性。

第 4 条很重要。告警太多，人会麻木，最后真出事也当没看见。阈值是活的，跑一两个月，根据机器的脾气微调。

监控是事后喊疼，事前锁门是另一回事，新机到手我先花二十分钟做了六步加固，清单在另一篇。

把告警接进手机：ntfy 一行命令

邮件告警有个毛病：半夜邮箱里躺着几十封促销邮件，告警混在里面，经常早上才看见——报警器响了，但我没听见，等于没装。

我后来把告警接到了 ntfy，手机推送，专线专用。改脚本里最后一段就行：

if [ -n "$ALERT" ]; then
    curl -d "VPS 告警：$ALERT" ntfy.sh/my-vps-alerts-2026x
fi

ntfy.sh 是公共推送服务器，topic 名字就是地址。注意两点：topic 名起复杂点（my-vps-alerts-2026x 这种），别用 test、admin——公共 topic 谁订阅谁都能看，名字就是密码；讲究点的自己搭 ntfy 服务端，我这台 2核2G 上就跑着一个，20M 内存，另一篇文章写过，自建 topic 私密又免费。

手机上装 ntfy App，订阅自己的 topic，推送权限打开。从此告警走推送，邮件只当备份通道。半夜被推送震醒虽然痛苦，但总比早上发现网站挂了一整夜强——这个账，我算过。

我的阈值调参记录

阈值不是圣经，是活的。下面是我这台机器的真实调参记录：

指标初始阈值跑两个月后调整原因
内存85%90%备份时 tar 短暂冲高，85% 太敏感，狼来了
硬盘85%80%日志涨得比预期快，提前量要更大
负载2（=核数）3备份+构建并发时短暂超 2，持续 10 分钟以上才算数

调参原则就一条：误报就放宽，漏报就收紧。目标是"一年响不了几次，响了就是真事"。

还有个经验：阈值调整要记日期和原因。我一开始凭感觉调，调完就忘，下次误报又从头猜。现在调参记录存在笔记里，跟 monitor.sh 放一起——机器的脾气，值得建档。

别急着上重型监控

Prometheus、Grafana、Zabbix 这些，功能强大，但对我这台 2核2G 的小机器来说太重了——监控系统本身吃掉几百 M 内存，本末倒置。个人博客的监控，free+top+一个告警脚本，够用到流量翻十倍。工具是为需求服务的，不是为折腾而折腾。这个道理，我交过学费才懂。

一句话总结

监控入门三步：学会 free、top、df 看机器脸色；写个超限告警脚本（内存/硬盘 85%、负载超核数），cron 每 5 分钟跑一次；收到告警先 top 找元凶。先让机器"会喊疼"，重型监控等真需要了再说。