2026 年网站正常运行时间监控的工作原理

实现 99.99% 正常运行时间的服务每年离线时间不到 53 分钟。下降到 99.9%,您将损失超过八小时。正常运行时间监控就是那一小段基础设施,能在故障发生的瞬间捕捉到这些分钟。本指南解释了它的工作原理、应监控哪些内容、检查频率,以及那些让有用工具变成背景噪音的错误。

正常运行时间监控实际做什么

正常运行时间监控运行一个小循环。从公共互联网上的某个服务器,它向您指定的目标发送请求。它记录响应、状态码以及往返所花费的时间。然后等待您选择的间隔时间再次尝试。

探测器有意位于您的基础设施之外。如果从自己的网络内部进行监控,您将无法捕捉到那些从内部看正常但对真实用户来说已经故障的中断。这就是合成监控(外部探测器)与真实用户监控(来自真实访客的遥测数据)之间的区别。大多数团队两者都会使用。正常运行时间监控属于合成监控这一类。

您实际可以监控什么

现代正常运行时间工具涵盖的不仅仅是 HTTP。市场上常见的九种探测类型都回答着略有不同的问题。

• HTTP 检查返回任何 URL 的状态码和响应时间。
• Ping (ICMP) 检查主机是否在网络层做出响应。
• SSL 检查您的证书还剩多少天。
• DNS 验证 A、AAAA、MX、TXT 或 NS 记录是否仍然解析为预期值。
• TCP 端口 检查服务是否在指定端口上监听,或者本应关闭的端口是否突然开放。
• WHOIS 监视您域名的注册到期时间。
• Blacklist 检查您的发送 IP 是否被列入 Spamhaus、SORBS 或类似名单。
• Heartbeat 颠倒了这种关系:由您的任务向监控器发送 ping,当它停止时您会收到告警。

检查频率

检查频率是准确性与噪音之间的权衡。更快的频率能捕捉到较短的故障，但也会因瞬时网络波动产生更多误报。较慢的频率可以过滤噪音，却会错过那些仍会消耗错误预算的短时故障。

一个务实的默认值：对重要服务的 HTTP 和 ping 使用 60 秒，对低优先级页面使用 5 分钟，对 SSL 使用 15 分钟，对 WHOIS 每小时一次。只有当宕机每分钟都会带来可量化的金钱损失时，才将间隔降至 30 秒。低于 30 秒很少能改善结果，反而经常引发告警疲劳。

无噪音的告警路由

无人查看的告警比没有告警更糟。三条规则适用于大多数团队。

• 默认将 DOWN 发送到单一渠道，最好是团队已经在查看的渠道（Slack、Discord、Telegram 或电子邮件）。
• 使用至少连续 3 次失败的阈值规则后再触发寻呼。一次漏检是噪音，连续三次才是信号。
• 通过签名的 webhook 将关键服务路由到寻呼工具（PagerDuty、Opsgenie）。将其他所有内容路由到聊天工具。一旦有人接手，请确认事件以停止寻呼。

扼杀正常运行时间计划的错误

第一个错误是只监控首页。可正常工作的首页几乎不能告诉你结账流程或移动应用所调用的 API 的任何信息。请为对收入或客服负载最重要的 URL 添加专门的 HTTP 监控。

第二个错误是无声的广播分发。每个监控都触发所有渠道，然后每个团队成员都将吵闹的渠道静音，于是真正的事件出现在被静音的渠道中。请定义一条默认路由，将例外路由到特定人员，并每季度审查一次规则。

10 分钟入门设置

如果你从零开始，实用步骤很简短。在你的主 URL 上创建一个 60 秒间隔的 HTTP 监控。在同一主机名上创建一个带 30 天预警窗口的 SSL 监控。创建一条将 DOWN 路由到团队聊天的通知规则。如果你有关心正常运行时间的外部用户，请添加一个状态页。为运行账单、报告和备份的 cron 任务添加心跳。现在你已经领先于一般运维人员了。