网站 uptime 监控：如何工作

检查实际做什么

基础 uptime 检查会向你选择的 URL 发送 HTTP 请求，通常是首页，有时是登录页或 health endpoint，并记录是否得到响应、返回什么状态码以及耗时多久。健康结果通常是在可接受时间窗口内返回 2xx 状态码，比如几秒内。

这一个检查已经能发现最常见失败：服务器完全不响应、超时，或返回错误页（5xx）而不是网站。它不会发现一切；如果页面返回 200 但内容坏了，就需要同时检查响应正文，而不只是状态码。

选择检查间隔

间隔是在多快知道问题和实际需要多少检查之间做取舍。5 分钟间隔意味着真实故障开始到被检查发现之间最坏是 5 分钟；这适合多数网站，包括 Holter Free 计划中的任何内容，该计划每 5 分钟检查且无需信用卡。

停机成本越高，越需要更快间隔。结账流程或付费 API 每停一分钟都损失收入时，比营销页更值得高频检查。把间隔匹配到几分钟未发现停机会造成的实际成本，而不是匹配到听起来 impressive 的数字。

避免误报

单次检查失败不是故障证明；它可能只是探测节点和服务器之间的瞬时网络抖动。第一次失败就告警会训练人忽略告警，这比没有告警更糟。

修复方式是连续失败规则：只有连续两三次检查失败后才告警，最好还来自不止一个探测节点，这样单条路径的路由问题不会被误认为网站宕机。这会把 uptime 监控从误报来源变成人们真正信任并会处理的信号。

“在线”真正应该是什么意思

只看状态码是很弱的“在线”定义。一个 11 秒返回 200 的网站技术上在线，但对已经放弃等待的人来说实际上坏了。把响应时间阈值作为独立于通过/失败状态的检查，可以捕捉二元检查完全错过的“很慢但没死”情况。

内容也重要：带数据库错误文本的 200 响应，或本该有内容却空白的页面，会通过天真的状态检查，却让每个真实用户失败。检查响应中的预期内容，而不只是响应码，可以补上这个缺口。

为什么不止一个探测节点重要

只从单一视角检查，不仅会产生一种误报风险，也就是该探测节点到你服务器之间的路由抖动，还会错过真实但局部的故障：某个地区的 CDN 边缘节点失败，或只有部分访客使用的 DNS 解析器返回过期答案。只问“从这个地方看网站在线吗”的检查，无法区分全局故障和局部故障。

从几个不同探测节点检查可以同时解决两类问题：告警前排除“只是这条路径”的情况，并且能发现对相当一部分访客真实存在、但不一定全球性的故障。单个健康检查只说明网站从你碰巧查看的位置在线。

设置第一个检查

从真实访客最先访问的 URL 开始，设置与你能容忍的未发现停机时间相匹配的间隔，添加响应时间阈值，并要求至少连续两次失败后再触发告警。然后确认告警真的有效：把检查指向一个你知道会失败的 URL，并确认它到达某个有人会看到的位置，再真正信任它。

单靠 uptime 监控抓不到什么

通过的 uptime 检查表示你监控的 URL 正确响应；它不说明未检查的页面、静默停止的后台任务，或下周即将过期的证书。Uptime 监控是基础，不是全部：应搭配 TLS 和域名过期检查，以及 heartbeat 式监控，用于那些按计划运行而不是响应请求的东西，例如备份或 cron job。

Holter 如何处理

Holter 的外部检查会从多个探测节点按你设置的计划运行，并在通过/失败检查之外支持响应时间阈值，所以慢网站也会被标记，而不只是完全死亡的网站。告警可以要求连续失败后再触发，因此单次瞬时抖动不会通知任何人。

Free 计划包含 5 个 monitor、5 分钟检查、无需信用卡，足够今天就在网站核心 URL 上放置真实 uptime 检查，再加上 TLS 和域名过期检查，然后再决定是否需要更快或更复杂的配置。