大多数团队都有网站监控。真正能在客户、销售和支持发现问题之前捕捉到问题的监控则少之又少。差距很少是工具本身，更多是围绕它的实践：检查什么、从哪里检查、多频繁检查、哪些触发通知、以及谁来决定检查失败是检测失败还是网站故障。
本操作手册收集了八条网站监控最佳实践，区分了SRE和DevOps团队信赖的设置和那些悄无声息变成噪音的设置。每条都很具体：阈值、间隔、反模式以及一旦有效后应继续做的事情。无论你是在营销网站上运行正常运行时间监控，还是在SaaS结帐流程中运行完整的合成事务监控，这些实践都是适用的。
“良好”是什么样的（以及大多数设置为何未达标）
一个工作定义：如果你的团队能从监控中了解每一个面向客户的问题，且在客户之前收到告警，并且你收到的告警几乎总是可操作的，那么你的监控就是良好的。这就是全部标准。
三个数字衡量它。平均检测时间（MTTD）告诉你监控是否足够快。平均修复时间（MTTR）告诉你监控呈现的数据是否足以修复问题。告警精度——即真实且需要即时处理的告警所占比例——告诉你团队在六个月后是否仍会信任那些告警。大多数SRE团队会衡量MTTD和MTTR。大多数团队却不测量精度。这就是为什么许多值班轮转最终沦为无声的确认和学会无助的原因。
本操作手册剩余部分都是关于如何同时推动这两个数字向正确方向发展。
覆盖完整请求路径的多层检查
单一的HTTPS检查就像一个只有一个传感器的烟雾警报器。它告诉你有问题，但不告诉你问题在哪里。当用户输入URL并等待页面渲染时，请求至少通过六层：DNS解析、TCP握手、TLS协商、HTTP响应、资源加载和客户端最终渲染。每一层的失败方式不同，根本原因也各异。
实际设置如下：
- DNS：检查A、AAAA、CNAME及MX记录从多个解析器解析至预期值。DNS问题最容易被忽视，且事后调试最痛苦。最佳DNS监控工具会监控未经授权的记录变更、传播延迟及特定解析器失败。
- TCP和ICMP：确认端口开放且网络路径健康。防火墙若阻断443端口，在相同网络段的HTTP检查中无法体现。
- TLS：验证证书链、过期时间、主机名匹配及密码支持。大多数证书故障可预防——证书只是周日过期。需在60、30、14和3天时收到明确的过期告警。具体配置见如何监控SSL证书过期。
- HTTP：状态码、响应时间和内容断言。状态200但响应体空白视为检查失败，而非成功。
- 渲染及事务：用真实浏览器驱动用户流程，对最终状态的已知元素进行断言，并测量交互时间。合成监控使用真实浏览器捕捉协议检查无法发现的问题——破损的JavaScript、挂起的第三方脚本、使购物车按钮不可见的丢失CSS文件。
- API：将API视为一级端点。网站加载正常但支付API超时导致结帐失败，网站仍算故障。API监控需独立制定检查计划，与依赖它的页面分开。
当出现故障时，首个触发告警的层是根因查找的起点。只监控HTTP的团队只能得到“故障”这一个信息；监控全部六层的团队则拥有故障树。
合成监控与真实用户监控（RUM）并行运行，而非互斥
这两种方法回答不同的问题，互不替代。下表总结了多数团队运行一个季度后达成的共识。
| 能力 | 合成监控 | 真实用户监控（RUM） |
|---|---|---|
| 数据来源 | 从受控地点的脚本化检查 | 真实访客的浏览器 |
| 能在零流量下工作 | 是 | 否 |
| 基线一致 | 是——相同脚本，相同地点 | 否——随流量结构变化 |
| 能在用户之前捕捉回归 | 是 | 否 |
| 反映真实设备和网络多样性 | 有限 | 是 |
| 最佳用途 | SLA报告、主动告警、正常运行时间监控 | 真实体验分析、优先级修复 |
| 常见失败模式 | 遗漏脚本未涵盖的边缘案例 | 通过Twitter得知故障 |
合成监控以固定时间表从固定地点运行脚本检查。数据时间上始终一致，不会受流量波动影响，也能在深夜运行（无用户时也能发现如登录页坏了的部署）。因此，合成监控适合SLA报告、回归检测和主动告警。
RUM捕获来自真实浏览器的性能和错误数据，反映用户设备、网络、地理的真实分布。它是唯一能告诉你比如2%特定运营商安卓用户首次字节时间为9秒的来源。RUM适合理解真实体验和优化工程优先级。
用合成监控确保网站运行正常；用RUM了解这种行为对应的真实付费用户。只选其一的团队要么被边缘案例打脸（仅合成），要么只能通过Twitter获悉故障（仅RUM）。
从创造收入的地区进行监控
仅从相邻数据中心的检查点只能告诉你该数据中心是否在线，却无法告诉你圣保罗的用户体验如何。
规则很简单：在每个对收入有实质贡献的地区放置检查点，外加一两个作为对照地区。如果你的35%销售来自EMEA区，你至少需要两个EMEA检查点——一个在主要市场如法兰克福或伦敦，另一个在次要市场如马德里或斯德哥尔摩。单一检查点覆盖EMEA容易掩盖区域ISP故障和CDN边缘故障。
三种值得设立的模式：
- 多地域确认后的告警。要求至少两个不同地区的故障在60秒内重复出现才触发告警。某一区域单独故障通常是区域运营商或某个检查点的问题，不是站点故障。
- 区域基线。东京和爱荷华的加载速度不同，不应共用阈值。跟踪各区域的95百分位延迟，按区域波动告警，而非全球平均。
- 企业网络内的私有代理。如果你为客户企业提供服务，且他们从自有防火墙后访问应用，应在该环境内运行检查点。私有代理可捕获客户网络导致的问题，这在客户看来仍是你的问题。
Dotcom-Monitor检查点网络覆盖30多个国家；具体启用列表应依据收入来源，而非数据中心所在。
基于基线设定阈值，而非圆整数
最常见的监控误区是“响应时间>3秒即告警”。三秒是个圆整数。网站不关心圆整数。如果真实95百分位是4.2秒且稳定，你每天会收到24次正常行为的告警；如果95百分位是0.8秒且降至2.5秒，你却完全没告警，因为2.5秒还在3秒阈值内。
修正方案是采用基线相对阈值：
当10分钟窗口内持续的95百分位超过 (基线95百分位×1.5) 或 (基线95百分位+2σ) 中较大者，且该条件持续两个连续评估窗口时触发告警。
这个公式同时保证三件事。1.5倍的乘数随页面性能缩放，使快页和慢页能用同一规则。2σ项抑制正常波动。“两个连续窗口”防止大多数告警噪声来自的短暂峰值。
大多数团队跳过基线计算。应每周根据前14天数据重新计算基线，排除部署窗口和已知事件期。自动基线检测的异常检测产品是捷径，但务必核实其排除了哪些数据。受上周事件污染的基线不如没有基线。
对于正常运行时间检查，等价规则是：要求两个连续失败且来自两个不同地理位置才告警。单点失败几乎总是检查点问题。两点失败才是真正故障。
设计告警，而非仅设计检查
检查告诉你发生了什么。告警告诉人该做什么。二者差别很大，大多数团队只设计第一者。
告警设计的目标是把正确的信息以能让人在60秒内响应的格式传达给正确的人。瓶颈通常是：
- 告警过多。如果值班工程师平均每班收到超过三次告警，下一个告警会被轻视。这不是道德问题，而是人类注意力规律。
- 告警缺乏上下文。“结帐慢”不可操作；“结帐95百分位4.8秒（基线1.1秒）来自欧盟地区，始于14:32 UTC，关联部署abc123于14:30”则可操作。
- 渠道错误。Slack不是告警通道，邮件也不是。短信、推送、电话才是告警。混用会稀释信号。
有效模式：
- 三级严重性，三级渠道。严重（站点宕机、支付故障）→短信或电话。警告（持续降级）→推送或带值班提示的聊天。信息（单次失败检查、基线漂移）→仪表盘或日报。信息不告警。
- 依赖抑制。DNS故障时不同时告警依赖DNS的14个HTTP检查。告警分组与依赖抑制是基础；不支持的产品要为此付出睡眠代价。
- 升级网格，不是升级链。主要值班5分钟内无响应，立即通知次要值班且通知团队频道。串联升级每跳耗时5分钟，期间站点持续故障。
- 非关键告警的静默时段。周日凌晨2点的性能回退通常不需叫醒值班，但关键故障需要。配置规则时要明确区分。
并且度量精度。每月统计触发的告警，标记为真正事件、误报、不需操作。如精度低于80%，先修复最噪的告警再新增。
覆盖你不控制的环节
你的站点不仅是你的代码。现代结帐页加载支付处理器、标签管理、分析提供商、聊天组件、A/B测试工具、CDN，有时还包括反欺诈服务的脚本。任意环节故障都能让页面瘫痪。
第三方依赖须设独立监控：
- 各区域CDN边缘响应时间。CDN会失效，尤其在区域事件期间。
- 支付网关往返时间作为针对网关状态端点或沙箱的合成API检查。
- 标签管理与分析脚本加载时间作为合成事务一部分测量。阻塞性分析标签会为每页增加2秒加载时间，你需要知道这一点。
- 外部身份认证提供商（OAuth，SSO）。如果“用Google登录”按钮失效，你需要比支持团队更早知道。
- DNS提供商。从多个解析器运行DNS监控，以捕获传播延迟和部分故障。
记录每个第三方阻断的用户流程。当第三方失败时，运行手册应说明正确操作是“降级”、“等待”还是“通知供应商值班”。没有这张地图，每个第三方故障都变成即兴演出。
每个监控都绑定运行手册
任何事件最昂贵的五分钟是值班工程师试图弄明白告警含义的时间。
一次性解决：每个监控链接到一个运行手册条目。运行手册不必很详细，三个部分足够：
- 本检查项覆盖内容一句话描述。（“验证从法兰克福和阿姆斯特丹的欧盟结帐流程完成时间不超过5秒。”）
- 触发时首要检查项。状态页链接、仪表盘、最近部署、相关告警、供应商状态页。
- 已知误报模式，如有。（“法兰克福检查点偶尔在供应商维护窗口2023年6月10日02:00-02:30 UTC超时，抑制告警。”）
你第一次写运行手册需15分钟，后续每次事件节省15分钟。道理很简单，但多数团队仍不执行。
每季度验证监控并审计覆盖范围
未经测试的监控只是愿望，不是保障。两种做法帮你发现漏洞。
混沌操练告警。每季度有意破坏某项检查——关闭测试端点、在测试环境让证书过期、将响应时间阈值设为0——确认告警触发、升级并到达指定人员。约三分之一告警首次操练失败。常见原因：过期的值班轮换、不再有效的集成令牌、无人关注的Slack频道。
审计覆盖地图。维护包含所有用户流程、所有外部依赖及每个URL类别的单一文档。每行列出覆盖的监控。空行即漏洞。最近季度新增功能一般分布在空行。
审计还揭示另一个问题：覆盖不再存在URL的监控。删掉它们。对410接口的监控永远产生噪声，且毫无价值。
监控平台选型要点
大多数平台都能Ping个URL。差异在于应对更复杂情形。当评估工具时，越过仪表板演示，问问：
- 能否脚本化真实浏览器事务并支持条件逻辑？静态录制版一旦页面变动即失效。可脚本事务监控（Selenium风格或专有）能承受正常产品演进。
- 支持多少原生协议？HTTP、HTTPS、DNS、FTP、SMTP、IMAP、POP3、TCP、UDP、ICMP。将每个协议交给不同工具意味着多供应商关系和多登录。
- 全球检查点布局实际如何？一家有200“检查点”但都集中在三个云区的供应商不算全球。要索要具体城市列表。
- 能否在内部网络运行？私有代理是监控预发布环境、内部应用和客户专属部署的必备。
- 如何处理告警依赖与分组？一DNS故障触发14条告警的产品，是让你付出压力代价。
- 数据导出如何？若不能提取原始检查结果至自身分析堆栈，无法调查复杂事件。
- 与事件管理工具集成情况。PagerDuty、Opsgenie、Slack、Microsoft Teams、ServiceNow、Jira。原生集成优于Webhook拼接。
想要详尽买家清单和评分标准，参见如何选择最佳网站监控工具和Datadog竞争对手与替代方案，了解各玩家定位。
常见故障模式
以下模式几乎出现在每次监控评审中。无需新工具即可修复。
- 多区域站点使用单一全局阈值。快速区域延迟升高，慢区性能下降，全球平均良好，告警却未触发。
- 状态200检查无内容断言。CDN错误页返回空白200通过检查，上线后故障。
- 依赖真实客户账户的合成事务。密码过期、多因素认证、账户锁定。使用权限明确的服务账户。
- 只在7天过期时告警的证书检查。7天是最后期限，不是预警。提前60、30、14及3天告警。SSL证书监控应分阶段设置。
- 无部署关联日志。无“此告警在部署abc123后三分钟启动”信息，每起事件都从手动git日志开始。
- 告警阈值长时间无调整。设置“>5秒”两年前，如果站点性能翻倍，阈值功能形同废弃。
- 监控主页而忽略核心业务流程。主页可用率是虚荣指标。结帐、注册、登录可用性才是关键。
有关应用层细节——特别是API、脚本化旅程和微服务拓扑，请结合Web应用监控最佳实践。有关延迟预算为何重要的SEO角度，请参见网站速度如何影响SEO。
将手册付诸实践
从此列表选三项当前设置未覆盖的实践，在本次冲刺中实现。完成后针对新监控运行混沌操练。30天后审核告警精度。
若平台是瓶颈，Dotcom-Monitor一站式覆盖全栈：真实浏览器合成监控、多协议检查、带私有代理的全球检查点网络，以及为上述模式设计的告警工程功能。参见Web应用监控、API监控、DNS监控和SSL证书监控，或直接跳转企业级监控概览，适合大型环境。
