网站 downtime 监控

Downtime 监控与 uptime 监控

它们使用同一种机制：从你的基础设施外部按计划检查。但 downtime 监控强调发现速度和告警质量。如果工具检查得很少、对噪音告警，或把告警发到没人看的地方，它技术上可以“监控 uptime”，却很差地完成 downtime 监控。

实际问题不是“它有没有检查我的网站”，多数工具都会检查；而是“从网站宕机到有人知道中间多久”，以及“告警是否到达能处理的人”。

downtime 实际来自什么

多数故障来自少数原因：DNS 问题、TLS 证书过期、域名过期、主机或服务器本身失败，或一次坏部署破坏了某些东西但没有抛出清晰错误。每种原因都需要稍有不同的检查才能可靠捕捉；普通 uptime ping 可以发现死服务器，却发现不了三周后即将过期的证书。

因此，正确的 downtime 监控是一小组检查，而不是一个检查：uptime、TLS 过期、域名过期和 DNS 解析加在一起，覆盖真实世界故障的大多数原因。

多快才算够快

诚实答案是“快过用户注意到并投诉”。5 分钟检查间隔意味着真实故障开始到被检查发现之间，最坏情况有 5 分钟空档；这对多数网站合理，也是 Holter Free 计划的间隔。任何面向客户且收入关键的服务，都更适合更快间隔和更短告警宽限。

发现速度只有在告警到达某个人时才有意义。一个 monitor 把告警发到没人看的频道，或进入被过滤到文件夹的收件箱，本身就增加了发现延迟，有时比故障持续时间还长。

延迟发现的错误

只从一个位置检查。单一视角无法区分“网站宕机”和“这一条网络路径宕机”；从几个探测节点检查，可以在告警前排除这种情况。

第一次失败就告警。这会制造太多误报，让人开始忽略告警，从而违背监控本身目的。

没有告警负责人。告警落到无人监看的地方，功能上等同于没有告警；故障仍会先被客户发现。

只检查首页。如果结账、登录或 API 路径独立失败，首页检查看不到。

不会碰到首页的 downtime

不是所有 downtime 都像一个死掉的网站。cron job 停止运行、队列 worker 静默死亡，或夜间备份中途失败，都可能持续数天，而任何外部检查都不会失败，因为首页没有变化。这些需要另一种监控：heartbeat，由任务本身在成功时 check in（或明确报告失败），一旦预期 check-in 没按计划到达就触发告警。

只看前门的 downtime 监控会完全错过这一类问题。网站对每个访客看起来都健康，底下备份却可能静默停止；真正紧急时才发现没有近期备份可恢复，就是第一条明显信号。

告警之后：衡量实际花了多久

快速发现 downtime 只是工作的一半；另一半是在事后知道事故实际持续多久、多久被发现。monitor 的事故历史可以回答两者：第一次失败检查何时发生、告警何时触发、何时恢复。真实事故后复盘这些数据，才能逐步调优连续失败阈值或检查间隔，而不是设置一次后永远不看。

Holter 如何处理

Holter 从多个探测节点运行外部检查：uptime、TLS、DNS、域名过期，并配合 inbound heartbeat monitor，用于需要主动 check in、而不是响应请求的 cron、队列和备份。当检查超过你的连续失败阈值，或预期 heartbeat 缺失时，事故会打开并通知你配置的渠道。

Free 计划包含 5 个 monitor、5 分钟检查、无需信用卡，足够今天就在网站核心 URL 和后台任务上设置真实 downtime 发现：外部检查加 heartbeat。