监控网站可用性，网站最直接的可用控连接方式就是HTTP请求。你写个脚本，性监定时向目标URL发个GET请求，连接看返回状态码是网站不是200。这办法粗糙，可用控但管用。性监我见过不少初创公司就这么干，连接用个cron job每五分钟跑一次，网站挂了就发邮件告警。可用控

但HTTP请求有个盲区——它只能告诉你服务器“有没有回应”，性监告诉不了你用户“体验怎么样”。连接有一次我监控一个电商网站，网站状态码一直200，可用控可用户投诉说页面打不开。性监查了半天才发现，服务器返回的是个错误页，但状态码设置错了，还是200。从那以后我就明白了，光看状态码不够，得解析响应内容，检查关键元素在不在。比如页面里必须出现“购物车”这个词，或者某个特定的meta标签，否则就算请求成功也当故障处理。

再往上走一层，就是真实浏览器模拟。用Puppeteer或Selenium这类工具，驱动一个无头浏览器去访问页面。这能捕捉到JavaScript渲染错误、资源加载失败、甚至是布局错位这类肉眼可见的问题。代价是慢，一个页面可能要几秒才能加载完，而且吃内存。我一般只在核心页面用这种方式，比如首页、登录页、支付流程，其他页面用轻量级检查就够了。

连接方式里还有个容易被忽略的选项——TCP端口探测。有时候你关心的不是HTTP层，而是某个服务是不是活着。比如数据库端口3306，Redis的6379。直接telnet一下，通就代表进程在跑。但这里有个坑：端口通不代表服务健康。MySQL端口开着，可能连接池已经满了，新连接进不来。所以端口探测只能当辅助，不能当主力。

还有个更底层的思路，ICMP Ping。它检查的是网络连通性，不关心任何应用层协议。好处是轻快，坏处是很多云服务商会屏蔽ICMP，你ping不通不代表服务挂了。我有次就被这个坑过，机房网络策略改了，所有ping都超时，告警响了一晚上，结果服务一直好好跑着。

DNS解析检查也值得做。用户访问你的网站，第一步是解析域名。如果DNS挂了，后面全白搭。监控工具可以定期查询你的域名解析记录，看返回的IP对不对，TTL有没有异常变化。这招特别能发现域名劫持或者配置错误。

说到分布式监控，连接方式就得考虑地域因素。同一个网站，从北京访问和从纽约访问，结果可能完全不同。CDN节点挂了、运营商线路拥堵，这些都会影响可用性。所以别只从一个点监控，用多个地域的探针去测，才能看到真实的全貌。

最后提一嘴被动监控。前面说的都是主动发请求，还有一种方式是在用户访问时埋点，收集真实用户的加载时间和错误信息。这种数据最真实，但问题在于——等用户报告错误的时候，故障已经发生了。所以被动监控适合用来发现那些主动监控测不出来的问题，比如某个特定浏览器版本的白屏，或者某个地区用户的慢加载。

实际做的时候，我习惯把几种方式混着用。核心页面用浏览器模拟，次要页面用HTTP内容检查，基础设施用端口探测，再配上DNS检查和被动埋点。监控这事没有银弹，每种连接方式都有盲区，组合起来才能织成一张还算密实的网。成本也得控制，开一堆无头浏览器实例跑监控，一个月下来云账单能吓你一跳。