网站挂了两小时我才知道，后来搞了个监控

上周五晚上，朋友发微信说我博客打不开。我一看，API 服务也挂了，502。查了一下日志，PHP-FPM 进程满了，重启之后恢复。

从挂掉到我知道，差不多两个小时。

其实之前也不是没想过搞监控。写过一个 crontab + curl 的脚本，逻辑很简单：

#!/bin/bash
SITES="https://blog.example.com https://api.example.com"
for url in $SITES; do
  status=$(curl -o /dev/null -s -w "%{http_code}" --max-time 10 "$url")
  if [ "$status" != "200" ]; then
    echo "$url 返回 $status" | mail -s "站点异常" me@example.com
  fi
done

挂到 crontab 每五分钟跑一次，看起来够用了。

跑了大概一个月，出了几件事。

第一个问题是邮件通知。我用的是本机 mail 命令，依赖 postfix 配置。有一次系统更新之后 postfix 挂了，脚本照常跑、也确实检测到了异常，但通知发不出来。等于监控跑着，告警没到。

第二个问题是 crontab 本身。这台机器后来换了系统盘做了次恢复，crontab 配置丢了。脚本文件还在，但没人调它了。我也是过了一个多月才发现。

第三个更细的坑：curl 判断返回码等于 200 就算正常。但有一次 Nginx 配置写错，所有请求返回 301 跳到了一个不存在的地址。curl 拿到 301，脚本判定"不是 200，报警"，没毛病。但如果我当时加了 -L 跟随跳转，就可能拿到 200（跳到默认页），误判成正常。状态码判断不如想象中可靠。

还有一个不算 bug 的问题：这个脚本只能检测 HTTP 状态码，TCP 端口通不通、PING 延迟多少、SSL 证书还有几天过期，全都顾不上。真要都覆盖，脚本会越写越长，测试和维护成本跟着涨。

后来换了个方式

想清楚之后，我需要的就几点：

• 不用自己跑脚本，不依赖某台机器的 crontab
• 通知能到微信或者钉钉，邮件真的不看
• 最好把站点可用性、端口、证书到期都管了，别分几套东西

找了一圈工具，有些要装 agent，有些得自己搭 Prometheus + Alertmanager，搞监控的成本比搞业务还高。

最后用了个在线工具，纯网页操作。加一个监控项就是填个域名或 IP，选监控类型（HTTP、TCP、PING、HTTPS 证书），设定检测间隔，配好通知渠道就行了。

配置过程

我加了这么几个监控项：

监控对象	类型	检测内容
blog.example.com	HTTP	站点可用性，判断返回 200
api.example.com:3000	TCP	端口是否可达
blog.example.com	HTTPS 证书	证书剩余天数
8.8.8.8	PING	网络连通性

通知渠道我选了微信和飞书。微信是给自己看的，飞书群是发给团队的。邮件也留了一个，当兜底。短信和电话通道也支持，不过那两个是收费的，我暂时用不上。

配完跑了一周，中间 API 服务有一次响应超时（超过 10 秒没返回），微信上 30 秒内就收到了告警推送。比我自己写的 crontab 脚本靠谱多了——至少通知渠道不会因为本机 postfix 挂了就静默失败。

自己写脚本 vs 用现成工具

说实话，curl + crontab 那套方案技术上完全可行。如果你就一两个站、服务器稳定、邮件配置没问题，脚本够用了。

但我的经验是，监控脚本本身也需要被监控。crontab 会丢、邮件会发不出去、服务器会重装。花在维护脚本上的时间，比脚本帮你省下的时间还多。

对我这种管着三五个站、没有专职运维的情况，用现成工具把域名填进去就完事了。省下来的时间写代码不好吗。

我用的是 up.spug.cc，站点可用性、TCP 端口、PING、HTTPS 证书到期都能监控，通知渠道支持微信、邮件、钉钉、飞书，基础功能免费。