监控一个网站，网站最直接的监控接方办法是让一台机器定期去访问它。这台机器可以是网站你的笔记本，也可以是监控接方云上的服务器。访问方式决定了你能拿到什么数据，网站也决定了监控的监控接方准确性和成本。

我最早做网站监控时，网站用的监控接方是最笨的办法：在本地电脑上写个脚本，每五分钟curl一次目标地址。网站结果有次家里断网，监控接方监控直接瞎了两个小时。网站后来才明白，监控接方监控点必须放在离目标网站足够近、网站且网络稳定的监控接方地方。这就是网站为什么绝大多数生产级监控都跑在云服务器上，而不是你的办公桌底下。

HTTP请求：最常用，也最容易踩坑

用HTTP或HTTPS去请求一个URL，看返回的状态码和响应时间，这是九成监控场景的起点。200算正常，301/302要跟进跳转，404说明页面没了，500以上是服务端炸了。听起来简单，但坑不少。

比如有些网站会对频繁请求做限流，你设了每分钟探测一次，结果对方防火墙直接把你IP封了。这时候需要控制频率，或者用多个出口IP轮换。再比如，有些页面返回200但内容其实是“系统维护中”，光看状态码根本发现不了。我一般会加一个关键词检查——在返回的HTML里找一段预期存在的文本，找不到就报警。

还有个细节：超时时间设多少。设3秒，网络稍微抖一下就是误报；设30秒，真挂了也要等半分钟才知道。我的经验是，先跑一周收集响应时间分布，取P99值再加50%作为超时阈值。这个数字不是拍脑袋定的。

TCP连接与Ping：更底层，但信息量有限

有时候你不需要看HTTP层，只想知道服务器端口通不通。TCP监控就是尝试与目标主机的某个端口（比如80、443、3306）建立三次握手。能连上说明网络层和传输层没问题，连不上就是彻底挂了。这种方式比HTTP轻量，适合作为辅助手段。

Ping监控更简单，发ICMP包看丢包率和延迟。但很多云服务商默认禁ICMP，Ping不通不代表网站挂了。我一般把Ping当作参考指标，不作为唯一报警依据。

浏览器模拟：最接近真实用户，也最重

前面两种方式拿到的都是“机器视角”的数据。但真实用户是用浏览器打开的，页面里的JavaScript要执行，CSS要渲染，图片要加载。有些网站HTTP请求返回200，但JS报错导致白屏。这时候需要用到无头浏览器，比如Puppeteer或Playwright，模拟完整加载过程。

我去年监控一个电商活动页时就遇到这种情况：curl返回200，但Puppeteer跑完发现页面主内容区是空的，因为一个第三方SDK加载失败阻塞了渲染。这种问题只有浏览器模拟能抓到。代价是资源消耗大，一个无头浏览器实例吃几百MB内存，不适合高频探测。通常放在关键路径上，每10到15分钟跑一次。

探针部署：位置决定视角

同一个网站在不同网络环境下的可用性可能完全不同。你在北京访问正常，广州用户可能因为运营商路由问题打不开。所以监控探针要分散部署——至少覆盖电信、联通、移动三条线，有条件的话再加上海外节点。

我自己的做法是：核心业务用三家云厂商的轻量服务器各跑一个探针，加上一个海外VPS。每个探针独立上报数据，任何一个节点连续三次失败才触发报警。这样既能发现区域性故障，又能过滤掉单个探针的网络抖动。

监控连接方式没有万能方案。HTTP状态码监控覆盖80%的场景，TCP和Ping做补充，浏览器模拟兜底关键页面。探针位置比探测频率更重要。把这些组合起来，才能让报警真正可信——而不是每天被误报吵醒。