如何监控网站（5 分钟）

三个步骤，总共大约 5 分钟：为网站的主 URL 创建监控，选择告警应该发送到哪里，并确认告警确实会触发。目标不是第一天就监控每一个 URL，而是覆盖客户最先会注意到的故障，并证明告警会送达真实负责人。

1. 1

   为首页 URL 创建 monitor

   把监控指向真实访客最先访问的 URL：你的首页，或者如果登录页才是真正入口，就用登录页。这是一次由外向内的检查：它按计划从你自己的服务器外部运行，所以即使基础设施内部看起来一切正常，它也能告诉你网站无法访问。使用最终的生产 URL，包含 https，并避免需要登录会话的路径，除非监控本身支持认证。

2. 2

   添加告警渠道

   选择检查失败时告警应该落到哪里：邮件是最简单的默认方式，团队也常用 Slack、Discord，或发到自有系统的 webhook。选择一个真的有人看的渠道，然后决定触发前需要多少确认。对大多数公开网站来说，两次连续失败再告警，通常比一次短暂波动就通知更适合作为第一条规则。

3. 3

   确认它会触发

   不要假设告警能工作，要确认它。把监控临时指向一个你知道会失败的 URL，或者暂时使用一个不可能通过的断言，然后等待下一个检查周期。确认路径的两半都成立：监控状态发生变化，告警也到达正确的人。如果没有，你就在真正故障前发现了坏配置。

   curl -I https://yoursite.com/this-path-does-not-exist
   # expect: HTTP/1.1 404 Not Found
   # then wait for the next scheduled check and confirm the alert arrives

第二和第三个应该监控什么

基础检查和告警确认可用后，下一步添加 TLS 证书过期监控。它会在没有警告的情况下静默失败，直到到期当天才暴露；服务器宕机至少会立刻被访客看见。域名过期属于同一类风险：注册失效可能让网站和邮件同时不可用，往往持续数天，而支付或注册商问题很容易被忽略。

第三，给最重要的客户路径添加一个监控：结账、登录、仪表盘 URL、预约流程，或另一个服务依赖的 API 端点。只监控首页的配置不会发现这些路径单独坏掉，而网站其他部分看起来仍然正常。之后，为 cron 任务、队列、导入和备份添加 heartbeat 监控，这些是由外向内检查看不到的静默工作。

要避免的常见设置错误

第一个失败检查就告警。单次失败可能只是瞬时网络抖动，不是真实故障；要求连续两三次失败后再告警，能把监控从噪音变成可信信号。

只检查首页。如果结账或某个 API 路径独立失败，首页检查不会发现。第一个监控证明网站存在；第二个或第三个监控应该证明客户真正需要的部分仍然可用。

从不测试告警。配置好了但从未确认会触发的监控，会带来虚假的安全感。像第 3 步那样强制失败一次，也检查恢复路径，确保问题修复后监控会回到绿色。