为什么个人站长最需要监控

个人站长的服务器通常只有一台，既没有专业的运维团队，也没有值班制度，网站出了任何问题都只能等自己发现。问题恰恰就在这里：等你发现网站打不开的时候，往往已经过去了几个小时甚至一整天。搜索引擎的爬虫在这段时间里抓到的全是错误页面，用户体验受损，网站的信任度也会被搜索引擎降低。与其事后补救，不如提前建立一套简单的监控告警机制，让服务器在出问题的第一时间就主动通知你。好消息是，这套机制用不到那些重型商业产品，几个 Shell 脚本加一个 crontab 就能覆盖个人站长百分之九十的监控需求，成本几乎为零。

本文会从监控指标讲起，逐步给出磁盘空间、进程状态、网站可用性三类核心监控脚本的完整代码，然后介绍几种实用的告警通知渠道，最后简单聊聊进阶方案 Prometheus 加 Grafana。所有脚本都是纯 Shell 加系统自带命令，不需要安装额外依赖，复制到服务器上改几个参数就能用。

个人站长应该监控什么

监控不是越多越好，指标太多反而会淹没真正重要的告警。对个人站长来说，优先级最高的是下面四类：第一，磁盘空间，这是最常见也最致命的问题，日志文件、备份文件、数据库文件任何一个把磁盘写满，网站就会立刻报错，甚至数据库直接崩溃；第二，内存和 Swap，内存耗尽会触发 OOM Killer 随机杀进程，网站进程被干掉也是常有的事；第三，关键进程和端口，比如 Nginx、MySQL、PHP-FPM 是否在运行，端口是否在监听；第四，网站可用性，也就是从外部视角看网站能不能正常访问，HTTP 状态码是否为 200。CPU 负载反而不用太紧张，短时间的高负载是正常的，只要不是持续飙升到核数的好几倍，一般不用告警。

磁盘空间监控脚本

磁盘监控的核心是定期检查挂载点的使用率，超过阈值就告警。下面的脚本检查根分区和 /home 分区，使用率超过 85% 就触发告警，同时把占用最大的几个目录列出来，方便你快速定位是谁在吃磁盘：

#!/bin/bash
THRESHOLD=85
df -h | grep -E '^/dev/' | while read line; do
  usage=$(echo $line | awk '{print $5}' | tr -d '%')
  mount=$(echo $line | awk '{print $6}')
  if [ "$usage" -ge "$THRESHOLD" ]; then
    echo "磁盘告警：$mount 使用率已达 ${usage}%" | send_alert
    echo "占用最大的目录：" >> /tmp/disk_alert.log
    du -sh /home/* 2>/dev/null | sort -rh | head -5 >> /tmp/disk_alert.log
  fi
done

脚本里的 send_alert 是一个占位函数，后面我们会把它替换成真正的通知命令。这里有一个细节值得注意：管道里的 while 循环是在子 shell 里执行的，如果你想在循环外面统计告警次数，记得用临时文件或者进程替换，否则变量值传不出来，这是 Shell 编程里很经典的坑。

进程与端口监控脚本

进程挂掉是服务器最常见的事故之一，特别是 PHP-FPM，内存压力一大就可能退出。监控进程的思路是检查进程数量，为 0 就说明挂了，尝试自动重启并告警：

#!/bin/bash
if [ $(pgrep -c php-fpm) -eq 0 ]; then
  /etc/init.d/php-fpm start
  echo "PHP-FPM 进程不存在，已尝试自动重启" | send_alert
fi
if [ $(pgrep -c nginx) -eq 0 ]; then
  /etc/init.d/nginx start
  echo "Nginx 进程不存在，已尝试自动重启" | send_alert
fi

端口监控用 ss 命令更准确，进程活着不代表端口在监听：

#!/bin/bash
if ! ss -tln | grep -q ':3306 '; then
  echo "MySQL 3306 端口无监听，尝试重启" | send_alert
  /etc/init.d/mysqld start
fi

自动重启要小心一种情况：如果进程是因为配置错误反复崩溃，自动重启脚本会陷入重启、崩溃、再重启的死循环，把服务器资源耗尽。稳妥的做法是在脚本里记录重启次数，比如连续三次重启失败就停止尝试，只发告警等你人工介入，同时把每次重启的时间写进日志，方便事后分析。

网站可用性监控脚本

进程和端口都正常，不代表网站真的能访问。反代配置写错、证书过期、数据库连接数打满，都可能让网站返回 502 或者 500。所以最可靠的方式是从外部模拟用户请求，检查 HTTP 状态码和响应时间。下面这个脚本用 curl 检测网站首页，返回 200 视为正常，其他状态码一律告警：

#!/bin/bash
URL="https://www.example.com"
code=$(curl -s -o /dev/null -w '%{http_code}' --connect-timeout 10 \
  --max-time 20 -A "Mozilla/5.0" "$URL")
if [ "$code" != "200" ]; then
  echo "网站异常：HTTP $code，请立即检查" | send_alert
else
  echo "检测通过，HTTP $code"
fi

这里有两个参数值得注意：--connect-timeout 是连接超时，--max-time 是总超时，两者都要设置，否则 curl 会一直傻等，脚本就被卡住了。另外，curl 的结果要加引号再比较，否则 HTTP 状态码为空时 if 判断会报错。如果网站套了 CDN，建议直接检测源站 IP 或者用 CDN 提供的健康检查接口，否则告警只能说明 CDN 边缘节点有问题，定位不到源站。

告警通知渠道怎么选

监控脚本的输出必须送到你真正能看到的地方，不然监控就失去了意义。对国内个人站长来说，最省事的方案是 Server酱，它通过微信服务号推送消息，调用一个 HTTPS 接口就行，免费版每天有推送条数限制，个人监控完全够用：

curl -s "https://sctapi.ftqq.com/你的SendKey.send" \
  -d "title=服务器告警" -d "desp=磁盘使用率超过 85%，请及时处理"

如果你在用 Telegram，可以申请一个 Bot，把消息发到自己的频道，配合简单脚本同样能实现推送，而且没有条数限制，海外服务器用起来很方便。国内用户还可以用钉钉或者企业微信的群机器人，往群里发告警，方便多人同时收到。无论用哪个渠道，都要注意一点：告警内容要包含服务器名称、故障时间、具体指标值，这样收到消息后不用登录服务器就能判断问题的严重程度。另外强烈建议给告警脚本加上频率限制，比如同一故障一小时只推送一次，防止半夜被重复告警轰炸到麻木。

用 crontab 把监控跑起来

脚本写好后，用 crontab 定时执行。磁盘和进程监控建议每五分钟跑一次，网站可用性检测可以更频繁，每两分钟一次，不过要注意别太频繁，避免监控请求本身占用网站资源。编辑 crontab：

crontab -e
*/5 * * * * /root/monitor/disk_check.sh >> /root/monitor/monitor.log 2>&1
*/5 * * * * /root/monitor/process_check.sh >> /root/monitor/monitor.log 2>&1
*/2 * * * * /root/monitor/site_check.sh >> /root/monitor/site_check.log 2>&1

日志一定要落盘，不然脚本静默失败你根本不知道。建议每周检查一次监控日志的大小，配合 logrotate 做轮转，防止日志文件自己把磁盘吃满，那就成监控引发事故了。新加的脚本先用 crontab -l 确认条目写进去了，再手动执行一遍验证逻辑无误，最后观察一两天，确认没有误报也没有漏报，再放心交给定时任务。

进阶方案：Prometheus 加 Grafana

当你的服务器不止一台，或者想看 CPU、内存、网络流量的历史趋势图时，Shell 脚本就有点力不从心了。这时候可以考虑 Prometheus 加 Grafana 这套开源监控组合。Prometheus 负责采集和存储指标，node_exporter 暴露服务器的系统指标，Grafana 负责把数据画成漂亮的仪表盘。部署方式不复杂：node_exporter 和 Prometheus 都是单个二进制文件，下载解压就能跑，Grafana 装好后配好数据源和导入现成的 Node Exporter Full 仪表盘模板，五分钟就能看到完整的服务器监控大屏，比脚本方案直观得多。

不过要提醒一句：Prometheus 和 Grafana 本身也是要占内存的服务，对小内存服务器来说反而是负担。建议 1G 内存以下的机器继续用脚本方案，2G 以上再上这套组合，或者直接把监控部署在另一台便宜的机器上，用黑盒探测的方式监控主服务器，这样主服务器出任何问题监控都不会跟着挂。

监控是省心不是折腾

搭建监控系统的投入产出比非常高：一次性花一两个小时把脚本写好，之后每天都能自动值守，网站出问题十分钟内你就能收到通知，而不是等用户来骂你。而且监控日志本身就是一份宝贵的事故记录，半年后回头看，你能清楚知道服务器哪些环节最脆弱，优化起来有的放矢。从最简单的磁盘告警开始，逐步补上进程、端口、网站可用性，再到可视化大屏，一步步来，你的服务器就从裸奔变成了有哨兵值守的堡垒。希望这篇实战指南能帮你把监控这件事真正落地。