网站上线后的监控告警：三层兜底和一个死亡开关

网站上线那天，可能是它被「监控」得最认真的一天：开发者盯着页面反复刷新，确认一切正常才敢合上电脑。从第二天起就没人盯了——宕机不知道，定时备份失败不知道，往往直到有用户来问「你们网站怎么打不开」，问题才浮出水面。日志解决的是事后查得到，监控解决的是当时就知道，这两层缺一不可。这篇文章把上线后的监控告警拆成三层兜底，按「发现什么问题」逐层给方法。

监控不是装个工具就完事，按要发现的问题分三层：

三层视角不同：拨测从外部看整体，健康检查从内部验证依赖，死亡开关盯的是不跑才出事的后台任务。小项目三层全用免费服务就能搭齐。

外部拨测的原理最朴素：第三方服务隔几分钟请求一次你的 URL，连续失败就告警。免费额度普遍够用，以 UptimeRobot 为例，免费档提供 50 个监控点、5 分钟间隔，覆盖 HTTP、关键词、端口、心跳等检查类型（官方帮助中心明确说明，免费档可用于商业项目）。

两个常见误区：

只监控首页。首页返回 200 不代表详情页、搜索、登录正常——把它们各自建成独立的监控点，哪个路径断了告警里直接写明。

告警发回服务器自己。用服务器本机的邮件服务发告警，服务器一挂告警链路跟着死。告警通道必须完全架在第三方上——邮件、Telegram、Slack、webhook 都行，原则只有一条：告警系统的存活不依赖被监控对象。误报控制交给服务端的多节点复查机制：一个节点失败先复测，多个节点确认才开告警单，避免网络抖动半夜吵人。

拨测只能证明一件事：进程还能应答。但数据库连接池耗尽、磁盘写满、缓存服务挂掉这类故障里，进程本身活得好好的，只是每个页面都在报 500——拨测看到的仍是 200 之外的报错才算失败，如果首页恰好是纯静态页，它甚至可能一直 200。

所以关键服务要补一个健康检查端点，而且检查逻辑必须真的碰关键依赖。一个只有三行的端点就够了：

# healthz：探活必须真的摸到数据库，不能只回静态字符串
def healthz(request):
    with connection.cursor() as cur:
        cur.execute("SELECT 1")
    return JsonResponse({"status": "ok"})

为什么这么写：SELECT 1 走一遍完整的连接获取和查询流程，数据库不可用时这个端点会跟着失败，拨测监控直接指向它，假活就被拨测层捕获了。这是业界通行的判断（容器编排里的 liveness/readiness 探针是同一思路的系统化版本）；注意保持端点便宜——只做最轻的查询，不查全表不写文件，因为它会被高频调用。

最危险的故障不是报错，而是静默。经典场景：每晚的备份脚本悄悄失败了三个月没人发现，直到某天要恢复数据，最新的备份是 90 天前的。

为什么静默？cron 的默认行为是把任务输出以邮件发给本机用户，而现代服务器大多没有配置邮件投递，输出落在没人看的本地邮箱里无声消失；更根本的是，cron 根本感知不到「任务该跑而没跑」—— scheduled 那一刻服务器正好关机、crontab 被误删、表达式写错根本没触发，cron 一声不吭。盯着任务内部的任何检查也一样：任务没被拉起来，里面的代码一行都不会执行。

死亡开关（dead man's switch）把方向反过来：任务成功完成时主动请求一个 URL 报平安，外部服务在约定周期内没等到 ping 就告警。它报警的依据不是「失败了」，而是**「没来报平安」**——任务没跑、跑挂了、跑到一半卡死，全都会触发。

Healthchecks.io 是这类服务的代表：每个任务一个 ping URL，可配置期望周期（Period）与宽限期（Grace），免费档提供 20 个 check，支持邮件、Telegram、Slack、webhook 等通知渠道，也可用其开源版本自托管（官网与多个独立评测一致）。接入只需在脚本末尾加一行：

# 备份脚本最后一步：成功才报平安，失败或没跑到都不会 ping
sqlite3 /data/app.db "VACUUM INTO '/tmp/backup.db'" \
  && curl -fsS --retry 3 https://hc-ping.com/<你的uuid>

为什么挂在成功之后而不是失败分支：命令失败、脚本没执行、机器关机三种情况都不会发出 ping，外部服务统一按「超时未报」处理，一条逻辑覆盖所有失败形态。

告警链路要真测一次。监控配完从不验证通知能否到达，是转发率最高的一步——有人把第一次真实故障当成告警系统的第一次测试。配完任何一个监控点，手动触发一次故障，确认手机真的响了。

成功也通知等于告警疲劳。如果每次任务成功都推一条消息，人很快会开始无脑划掉，等真故障来了那条告警也被一起划掉。死亡开关天然符合这个纪律：成功保持沉默，缺席才出声，让每条告警都值得点开。

备份任务优先挂开关。备份失败的代价要等到恢复那天才结算，是所有定时任务里静默窗口最长、赌注最大的一个——它应该是死亡开关的第一个接入者。

监控这件事的性价比高得反常：注册一个免费账号、写十几行配置，换到的是把发现故障的时间从「用户来问」提前到「几分钟内」。拨测看整体，健康检查戳破假活，死亡开关兜住静默——三层搭完，网站才真正算是有人值守了。

你的线上服务目前停在第几层？如果这篇文章帮你补上了缺口，欢迎转发给同样在独自维护服务的朋友。

#网站运维 #监控告警 #Linux #定时任务 #Django #稳定性