正常运行时间监控会按计划从您的网络外部发起检测，只要响应出现异常即刻提醒您。
大多数团队都是通过客户邮件、社交帖子或销售仪表盘的异常才发现网站宕机。在人工察觉到之前，故障已经持续了投诉发出的时间，而损失则早在故障开始时就已经发生。
正常运行时间监控通过一个简单机制弥补了这段时间差：按计划自动从您的网络外部发起检测，一旦响应异常或无响应立即报警。设置仅需几分钟。但要让监控报告真是的状态，需要做一些多数教程忽略的决策，因为默认配置的监控可能会漏报真实故障，也可能误报虚假故障。
本指南将通过七个步骤来指导这些决策：定义“正常”含义，选择检测类型，设置检测频率，多地验证，报警配置，过滤误报，及根据SLA报告正常运行时间。
贯穿七个步骤的核心理念是：将监控视为一个真实状态栈，而非单一检测。DNS验证域名解析，TCP验证服务可达，TLS验证浏览器信任，HTTP验证应用响应，内容验证确保页面正确渲染，用户路径监控确保访客能完成任务。外向内构建此栈，每个告警指明故障层级，而非简单地说“网站宕机”。
步骤1：定义您的网站“正常”的含义
最懒的定义是“服务器有响应”。这也是多数人栽进坑的原因。主机回应ping但网站服务进程已死；网站服务器返回HTTP 200，但正在展示维护页、半成品模板，或DNS劫持后的他人内容。上述情况对访问者来说都不是正常。
给“宕机”划分三种状态有助于理解。硬宕机：主机完全无响应。软宕机：服务器返回200状态，但展示数据库错误页、空白模板或DNS劫持后的其他内容。虚假宕机：服务器正常，但CDN边缘节点异常或区域路由失败导致部分访客无法访问。只能检测硬宕机的监控忽略了更常见的两种状态。
所以，配置前请先写下网站真正可用时必须满足的条件：
- 域名快速解析到正确地址。
- 关键页面返回成功状态码。关键页包括首页及导致损失的页面，如结账、登录、注册、关键API端点。
- 响应包含正确内容。某关键词或页面元素只有正确渲染时出现，避免200状态的错误模板通过检测。
- 证书有效且响应时间在用户可接受范围内。
此列表非官僚主义，而是对应请求实际失败的层级，DNS、TCP、TLS、HTTP 各层都有特定故障表现。只测试单层的检测对其它层故障盲目。也明确了监控哪些URL：非全站页面，而是您定义的关键页面。
以电商网站为例，首页监控规则可能是：3秒内返回200，包含“免运费”词汇，证书有效期不少于14天，解析到期望的CDN CNAME。结账页更严格：返回200，含“订单摘要”，若支付提供商脚本缺失即失败。两个URL都算正常，但其定义不同。
步骤2：选择您的正常运行时间检测类型
定义清楚后，选合适的检测覆盖每个层面。五种检测类型涵盖几乎所有场景，但如果仅凭单一检测断定全部体验，极易误判：
| 检测类型 | 验证内容 | 捕获问题 | 可能误导处 |
|---|---|---|---|
| HTTP(S) | URL的状态码及响应内容 | 服务器错误，200状态下的错误页面，错误或被劫持的内容 | 200状态可能加载错误模板或缓存的错误页面 |
| Ping (ICMP) | 主机响应回声请求 | 网络及主机级故障，丢包，路由问题 | 主机响应ping但Web服务或TLS已坏 |
| TCP端口 | 指定端口接收连接 | 主机响应ping，但服务进程崩溃导致端口拒绝连接 | 开放端口证明有监听服务，但不能保证应用健康 |
| DNS | 域名解析到期望记录 | 过期域名，错误记录修改，DNS供应商宕机 | 某解析器返回正确结果，但其他地区仍缓存旧记录 |
| SSL证书 | 证书有效性及剩余天数 | 过期或配置错误导致浏览器阻断 | 证书有效不代表服务内容正确 |
HTTP和HTTPS检测
基础检测。请求URL，验证状态码，若配置得当，还断言响应体包含关键词。范围外状态码，诸如常见4xx和5xx，判为失败。内容断言区分“服务器响应”与“页面正确加载”：200状态承载错误模板会通过单纯状态检测，但会失败关键词检测。
Ping (ICMP)检测
ICMP ping监控验证主机可达性，测量延迟和丢包率。快速廉价，适合网络级故障排查。但仅靠此检测弱点明显：服务器响应ping但Web服务崩溃，或某些网络直接阻断ICMP包。
TCP端口检测
通过TCP端口检测验证特定端口能否接受连接，如443端口作Web流量，25端口用于邮件，或自定义应用端口。捕获主机响应ping成功，但服务进程已崩溃端口拒绝连接的这类中间故障。
DNS检测
DNS监控确保域名解析到期望记录，跟踪解析时间。DNS故障（如注册过期，记录错误，服务商宕机）导致网站对所有人不可访问，尽管服务器正常。此为团队最常忽视的故障模式。
SSL证书检测
SSL证书监控跟踪证书过期和验证链问题。证书过期功能等同宕机：浏览器全屏警告，大部分访客不愿绕过。随着证书生命周期变短，单纯日曆提醒不够，监控可在30、14、7天时预警。
合理组合建议：对每个关键页面用带内容断言的HTTP(S)检测，域名使用DNS和证书检测，辅助网络与应用问题区分处可加Ping与TCP检测。
步骤3：设置合适的检测频率
检测间隔决定发现故障的最快时间。故障发生于检测间隔末端时，故障多达整个监测间隔才被捕获，且还有验证和报警延迟。
这对可用性目标影响巨大。99.9%月度目标允许约43分钟宕机。五分钟一次检测可能会在意识到问题前消耗超过10%的宕机预算，即所谓的宕机成本。把检测间隔看作“检测预算”：决定允许多少宕机时间被人类发现前消耗。以99.9%预算的10%为例，约4分钟，五分钟检测间隔显然太长。以收入计算，时赚5000美元的网站，五分钟盲点将损失超400美元。经验规则：
- 每分钟一次适用于收入关键资源：结账、登录、支付API及正式SLA覆盖服务。
- 每3至5分钟一次适合标准营销站点和内容页。
- 每15至60分钟一次适合内部工具、预生产环境和低风险服务。
轻量HTTP检测便宜，可高频执行。重量级浏览器检测因资源消耗大常放慢频率，叠加在快速基础检测之上。欲了解检测频率与地理分布关系，请见监控频率与地点指南。
步骤4：从多个地点监控
单点监控只能从一个视角观察，产生两种失效：漏检只影响部分地区的故障，如CDN边缘故障、Geo-DNS错误配置或ISP与主机间路由问题；加上这个地点网络问题产生误报。
选择符合用户分布的地点。面向北美和欧洲的站点应至少从两岸美洲和欧洲某城市监测，非单一数据中心。支持全球网络的监控平台（包括Dotcom-Monitor）允许跨洲选择检测点，模拟真实用户体验。
多地点复核：一个监测点发现故障，先由其他地点确认后再报警。
多地点还支持交叉验证（第6步依赖）：单点报告故障时，平台从其他检测点复核确认后再宣告宕机。故障真实时，地域分布首次提示故障诊断方向。全面失败指源站、全局DNS、证书或发布错误；单一地域故障指CDN边缘、区域路由或本地提供商；HTTP全通过但内容断言失败指模板错误或缓存错页。不同模式指向不同供应商，地理划分细读很有必要。
步骤5：配置报警与升级
检测有意义须有人响应。首次事故前明确：谁通过何渠道、按何顺序接收哪些故障信息：
- 根据严重度匹配渠道。如30天后证书到期，用邮件通知即可；确认的硬宕机故障应通知电话、短信或值班工具。报警支持邮件、短信、电话及Slack、Teams、PagerDuty等集成。
- 无人响应自动升级。首次报警发给值班工程师，若几分钟内无确认自动上报下一层，否则无人响应等于无人告警。
- 警告性能下降，不仅是宕机。响应时间翻三倍往往是宕机前兆，性能预警留出处理时间，二元状态报警则没有。
- 计划维护保持静默。避免频繁部署打断报警有效性，保护报警信誉。
报警文本应像合同：指出哪部分失败，何处发现，持续多久，较上次成功有什么变化。如“法兰克福和伦敦连续两次结账内容检测失败；DNS及TLS通过；未检出预期‘订单摘要’；上次成功09:41 UTC”。代入假设，便于响应。仅报告“网站宕机”毫无价值。
完整阈值、路由和升级规则见网站监控报警实践。
步骤6：消除误报
误报是监控项目的杀手。凌晨几次虚惊，值班工程师就会忽视真正故障。大多数误报来源四类：测站与站点间的短暂网络故障，因设定超紧的超时，监测点自身故障，及未经通知的发布。
对应对策：
- 报警前先二地点确认。单点失败应先触发其他监测点复核，而非立即报警。Dotcom-Monitor平台如一地与多数检测结果不符即调用所有已选择地点检测，避免单点误报打扰团队。
- 设置超时需基于历史数据。根据网站实际响应时间设阈值并留裕量，避免慢响应误报宕机，只生成性能警告。
- 内容验证胜于单纯连通性。关键词断言双向保障：捕获状态码漏检的软故障，也避免慢第三方脚本导致误报，因为检测面向必须内容，不是所有元素。
- 合理设置部署维护窗口。计划中的维护是最廉价有效的误报消减方法。
剩余误报可在周度复盘分三类：视角问题、阈值设置问题、正常定义问题。视角问题靠跨地点确认，阈值问题按真实响应调整，定义问题强化内容断言。三类之外的警报持久噪声，延长检测间隔只会延后真实事件发现。
步骤7：依据SLA衡量正常运行时间
每个检测结果都会记录持续可用性，转变监控从烟雾探测器到证据。正常运行目标看似抽象，换算成分钟即明晰：
| 正常运行目标 | 30天内允许宕机 | 每年允许宕机 |
|---|---|---|
| 99% | 7.2小时 | 约3.7天 |
| 99.9%（“三九”） | 43.2分钟 | 约8.8小时 |
| 99.95% | 21.6分钟 | 约4.4小时 |
| 99.99%（“四九”） | 4.3分钟 | 约53分钟 |
此数学解释了先前关于检测频率的建议：四九目标下，五分钟检测间隔可能错过的宕机时长超出整月预算。使用可用性计算器自行验证您的SLA真实承诺的分钟数。
保持记录独立性。若主机或CDN承诺SLA，您的补偿请求须基于自己外部测量数据，而非供应商状态页。保持证据简洁可导出：时间戳、检测点位置、解析IP、TLS验证、HTTP状态、响应时长及失败断言。状态页截图只是论据；带位置标记检测记录才是证据，不论申诉补偿还是公开状态页均需如此。定时正常运行与SLA报告可自动发至相关人士，按检测项目和地区详细拆分。拆分极关键：健康的全球平均可能掩盖某地区整周宕机。
超越正常运行时间：监控完整用户旅程
以上内容回答了一个问题：网站是否可访问且响应正确？它无法判断访客能否搜索目录、加入购物车、支付或登录，因为这些流程跨多页、多脚本和第三方服务，单URL检测无法覆盖。
营销团队应关注的旅程是推广承诺的操作路径。比如付费搜索推广访客至“开始免费试用”，脚本应加载着陆页，点击CTA，填写测试数据，确认感谢页面。推广期间如果此路径故障，首页正常运行时间就成了虚荣指标。
这正是合成监控的工作：脚本化真实浏览器会话分步执行关键旅程，精确定位失败步骤。使用录制工具，如EveryStep，结账或登录流程无需编码即可成为重复监控脚本。完成此处七步后，交易级监控是自然进阶层。
总结
优秀的网站正常运行时间监控是构建真实状态栈，不是简单打勾。以业务语言定义“正常”，明确抵御哪种“宕机”。用HTTP、ping、TCP、DNS和证书检测覆盖每个请求层，并了解各检测可能误导处。设定符合SLA的检测预算，从用户分布地执行检测。编写包含假设的报警，静默升级，报警前确认，保持独立、可导出的可用性记录，按区域和检测类型拆分。
如此配置，正常运行时间监控不再是打勾的复选框，而是第一个发现问题的系统，领先客户几分钟时间。此领先即所有价值所在。
几分钟内开始您的正常运行时间监控
利用Dotcom-Monitor正常运行时间监控，从全球监控网络设置HTTP、ping、TCP、DNS和SSL检测，配置您值班团队真正信任的报警。开始免费试用。
