什么是可用性监控（Uptime Monitoring）？
可用性监控是最基础的监控形式：定期请求你的 URL，校验状态码与关键字，宕机时立即告警。工作原理、宕机事件处理流程、关键字监控的优势与最佳实践。
可用性监控（Uptime Monitoring，也叫在线率监控）是监控体系里最古老也最直接的一种：自动化地、高频率地检查你的网站或服务是否可用，宕机时立刻通知正确的人。它回答的是一个最朴素的问题——"我们的服务现在还活着吗？"
工作原理
监控器按预设频率（核心业务 30 秒到 1 分钟，一般服务 5-10 分钟）向目标 URL 发起请求，校验返回结果：
- 状态码检查：期望
200 OK。返回 5xx、连接超时、TLS 握手失败，都视为异常。 - 响应时间：顺带记录每次探测的耗时，退化趋势一目了然。
- 超时窗口：请求多久没响应算失败（2 秒到 1 分钟不等，视服务优先级）。
连续 N 次探测失败（或多地域节点同时失败）后，监控器创建宕机事件（downtime incident），按值班表通知到具体的人。
关键字监控：比状态码多一层保险
只查状态码有个著名盲区：页面返回 200，但内容是错的——数据库连接失败后的空壳页面、发布事故导致的白屏模板，状态码都是 200。
关键字监控在响应 HTML 里断言特定内容存在（或不存在）：
- 检查页面包含"立即注册"按钮的标记，确认核心转化入口渲染正常；
- 检查页面不包含"数据库连接失败"等错误文本；
- 检查关键结构化元素（某个
<div id="pricing">）存在。
建议默认使用"状态码 + 关键字"双重断言，这是可用性监控性价比最高的增强。
宕机事件的生命周期
- 探测失败：连续失败达到阈值，事件创建；
- 告警：按升级策略通知——先 IM（钉钉/企微），无响应升级电话，再无人响应升级第二值班人；
- 确认与处理：值班人认领事件，开始排查；
- 恢复：探测恢复成功，事件自动关闭，计算本次宕机时长。
告警里应包含的关键信息：失败开始时间、错误类型（超时/5xx/关键字缺失）、失败节点分布、相关日志链接——让值班人拿到的第一时间就有排查抓手。
该监控哪些端点
别只盯首页。按业务价值列清单：
- 首页与核心落地页；
- 登录/注册接口；
- 核心 API（下单、支付回调）；
- 健康检查端点（
/healthz，返回应用内部依赖状态）； - 关键静态资源（CDN 上的 JS/CSS）。
可用性数字怎么算
可用率 = （总时间 - 宕机时间）/ 总时间。三个九（99.9%）意味着每月允许约 43 分钟宕机；四个九（99.99%）只有 4 分多钟。可用性监控的历史数据就是这份账的依据，也是对外 SLA 的凭证。
观测云对照
观测云可用性监测（拨测）支持 HTTP/TCP/ICMP/SSL/DNS 多协议探测，覆盖多地域节点，支持状态码与关键字双重断言；宕机事件与告警策略、值班通知（钉钉/企微/飞书/电话/Webhook）深度集成；探测数据与 APM、日志天然打通——拨测红了，一键跳到同时段的后端 Trace 和日志，把"发现宕机"到"定位原因"的链路缩到最短。可用率报表自动生成，SLA 对账有据可依。
常见问题（FAQ）
Q：探测频率越高越好吗？
A：频率决定"多快发现"：1 分钟探测意味着最坏 1 分钟盲窗。但频率也带来成本与对服务的额外请求量。核心业务 30s-1min，一般服务 5min，后台系统 10-30min 是合理梯度。
Q：为什么需要多地域节点确认？
A：单一节点失败可能只是节点自身的网络问题（跨境链路抖动很常见）。要求 2-3 个不同地域节点同时失败才告警，是业界标准的防误报手段。
Q：内网服务怎么做可用性监控？
A：观测云支持自建拨测节点部署在内网，对内网系统做同样机制的探测，数据统一汇总到工作空间。
