核心是模拟真实用户访问行为，从外部视角持续探测并结合内部指标交叉验证，需覆盖多地域多运营商节点、按需选择协议、设置合理超时与内容校验，支持多步骤业务链路拨测，并通过服务器日志、stub_status或prometheus采集真实响应时间，配置可用性、延迟及状态码告警，辅以cdn直连、curl细分耗时、traceroute和dns解析等手段交叉验证。
服务器监控网站可用性与响应延迟，核心是模拟真实用户访问行为，从外部视角持续探测，并结合内部指标交叉验证。不能只看服务器是否开机，而要看页面能否打开、内容是否正确、加载是否够快。
用外部拨测模拟真实用户
这是最贴近用户体验的方式，尤其适合判断“用户打不开”这类问题。
- 选择多地域、多运营商的探测节点（如700+节点覆盖全国及海外），避免单点误判
- 协议按需选：HTTP/HTTPS测页面状态码和内容；PING测基础连通性；DNS测域名解析；TCP测端口可达性
- 每步设置合理超时（如HTTP请求设10秒），并校验关键内容（如页面含“登录成功”字样）
- 支持多步骤流程（如登录→下单→支付），覆盖业务链路而非单个URL
抓取服务端真实响应时间
外部拨测反映的是“用户看到的延迟”，而Nginx、Apache等Web服务器日志里的$request_time或$upstream_response_time，记录的是后端实际处理耗时，两者结合才能定位瓶颈在哪儿。
- 开启Nginx的access_log，记录$request_time和$upstream_response_time字段
- 用awk或ELK分析日志，统计各URL的P95延迟、慢请求分布、错误率
- 配合stub_status模块，查看当前活跃连接、请求数等实时状态
- 若用Prometheus，可通过nginx-lua-prometheus暴露指标，接入Grafana做趋势分析
配置自动告警与阈值判断
光有数据没用，得让系统在异常发生时及时提醒人。
- 可用性告警：连续3次探测失败，或可用率低于99.5%持续5分钟
- 延迟告警：HTTP响应时间超过3秒（P95）、TTFB（首字节时间）超过800ms
- 状态码告警：非2xx/3xx响应占比突增，或出现大量502/504
- 告警渠道要打通：邮件、钉钉、短信，关键故障建议电话通知
补充验证手段防漏判
单一监控可能被缓存、CDN或中间代理干扰，需要交叉印证。
- 关闭CDN直连源站测试，确认是CDN问题还是源站问题
- 用curl -w “@format.txt” -o /dev/null -s URL，手动测TTFB、connect_time等细分阶段耗时
- Traceroute或MTR查路由路径，确认高延迟是否出现在某段网络节点
- 检查DNS解析时间，避免因DNS慢导致整体访问卡顿
