可用性监控与告警:掉线/宕机第一时间知道

服务器最怕的不是慢,而是「悄无声息地挂了」——等到用户投诉你才发现,往往已经过去几个小时。可用性监控要解决的核心问题只有一个:掉线的那一刻,你就收到通知。

监控的基本思路:从外部探测

判断一台机器是否「活着」,靠的是周期性探测,常见三层:

• Ping(ICMP):确认主机在网络上可达,最轻量,但不代表服务正常。
• TCP 端口探测:连一下 22、443、3306 等端口,确认服务在监听。
• HTTP/HTTPS 探测:请求一个健康检查地址(如 https://your-site/healthz),校验状态码是否 200、响应体是否包含预期关键字、以及证书还有多少天过期。

一条铁律:监控必须放在被监控机之外。如果监控程序和业务跑在同一台 VPS 上,机器一宕机,监控也跟着死了,自然发不出告警。正确做法是用另一台便宜 VPS、或不同机房的节点去探测你的服务器。

方案一:Uptime Kuma(Docker 一键,推荐个人/小团队)

Uptime Kuma 是自建监控里最省心的,一条命令起来:

docker run -d --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma louislam/uptime-kuma:1

浏览器打开 http://监控机IP:3001,建管理员账号后,「Add New Monitor」里选 HTTP(s)/TCP/Ping,填地址与检测间隔(如 60 秒),再到 Notifications 里挂上通知渠道即可。它自带邮件(SMTP)、Telegram、Webhook 等 90+ 种渠道,还能生成对外的状态页。

方案二:Prometheus + Blackbox + Alertmanager(规模化)

已经在用 Prometheus 的团队,用 blackboxexporter 做探测、Alertmanager 做告警分发更合适。一条示例规则:

groups:
  - name: uptime
    rules:
      - alert: InstanceDown
        expr: probe_success == 0
        for: 2m          # 连续 2 分钟失败才告警,过滤瞬时抖动
        labels: { severity: critical }
        annotations:
          summary: "{{ $labels.instance }} 已掉线"

告警渠道与「告警疲劳」

邮件适合留痕,Telegram / Webhook 适合即时触达手机。但真正决定监控好不好用的,是阈值与静默:

• 设 for/重试次数:别一次探测失败就报警,连续失败 2–3 次再触发,过滤网络抖动。
• 静默(silence)与维护窗口:计划内重启、升级前先静默,避免刷屏。
• 分级:证书 30 天到期是「提醒」,服务掉线才是「紧急」,不同级别走不同渠道。

告警太多等于没有告警——一旦你开始习惯性忽略通知,监控就失效了。

小结

可用性监控的要点:从机器外部做 HTTP/TCP/Ping 探测;个人用 Docker 起 Uptime Kuma,规模化用 Prometheus + Alertmanager;告警走邮件留档、Telegram/Webhook 即时触达;用连续失败阈值和静默窗口克制告警疲劳。花十分钟搭好,换来的是「宕机第一时间知道」的安心。