uptime 是什么?网站 uptime 监控如何告警并自动恢复

uptime 指网站或服务在指定时间段内可正常访问的时间，通常用百分比表示；与之相对的 downtime 是不可访问时间。网站 uptime 监控的核心做法是：从多个地点按设定间隔扫描目标，确认故障后发出告警，并在配置允许时执行恢复动作。Pingmeter 的资料显示，其监控覆盖多地点扫描、误报防护、延迟告警、短信/电话/邮件通知、DNS 故障转移和服务器恢复等环节。适用前提是：你拥有可被外部访问的网站或服务器，并能提供相应的恢复凭据或 DNS 服务商 API 权限。

uptime 与 downtime 怎么衡量

uptime 关注的是“服务是否可用”，而不是“服务是否快”。常见衡量方式是把统计周期内的可用时间除以总时间，得到可用率。例如一个月内累计不可用 43 分钟，按 30 天计算，可用率约为 99.9%。这个数字的意义取决于监控频率：扫描间隔越粗，越可能漏掉短时故障。

Pingmeter 的资料强调“每一分钟都重要”，支持从多个地点同时扫描，并允许自定义扫描间隔。对读者来说，选择监控服务时应先确认两件事：扫描间隔是否满足你的故障容忍度，以及是否支持多地点，避免单一网络线路的偶发问题被误判为宕机。

多地点扫描与误报防护如何判断宕机

监控系统判断宕机不能只看一次请求失败。Pingmeter 的描述是：从多个地点双重检查错误，确认 downtime 不是瞬时网络抖动造成的；同时支持延迟告警，在延迟期间持续观察服务器是否自行恢复，只有未恢复才通知你。

这套机制解决的是两类误报：

• 单点网络波动：某个扫描节点到目标服务器的线路抖动，其他地点仍可访问，不应判定为全站宕机。
• 短暂重启或瞬时错误：服务器在几十秒内恢复，延迟告警可以避免半夜被无效电话叫醒。

配置时的关键输入是“确认故障所需的地点数量”和“延迟告警时长”。预期结果是：只有多地点持续失败且超过延迟窗口，才触发通知。常见卡点是延迟设得过长，真实故障的通知被推迟；设得过短，又容易收到误报。建议按业务对停机时间的容忍度来定。

宕机确认后如何告警

Pingmeter 资料列出的通知渠道包括短信、语音电话和邮件。触发条件是：多地点确认 downtime 持续指定时间，且恢复动作未能让服务重新上线。资料还提到“在线检测器”：宕机发生时检测网站上的在线访客数量，并在通知中告知访客数，帮助判断影响范围。

此外，维护模式允许你预设计划维护时间，在此期间不触发恢复动作和电话通知。这对有固定发布窗口的团队很实用：把已知的维护时段录入，避免把计划内停机当成故障处理。

自动恢复动作适用于哪些场景

Pingmeter 提供两类恢复动作：

选择时看两点：如果故障多为进程挂死或服务未启动，服务器恢复动作更直接；如果是整台主机或机房不可用，DNS 故障转移更合适。两者都需要提前配置，不能等宕机后再补。

公开状态页与记录回看的作用

Pingmeter 支持在自有子域名下生成公开状态页，展示网站或服务的 uptime 与 downtime，并可设置密码保护。状态页适合对外沟通：用户能看到已知故障，减少重复询问。记录回看方面，资料称会保留扫描日志，可查看历史 downtime、ping 时间和失败地点，并从启用服务之日起获得逐分钟报告。

使用建议：状态页对外发布前，确认展示范围不泄露内部服务细节；日志回看则用于事后复盘，例如对比故障时段的失败地点分布，判断是局部线路问题还是全局故障。

上手检查清单

要落地一套 uptime 监控，按以下顺序确认：

1. 明确目标：监控首页、关键 API 还是数据库端口，不同目标对应不同扫描方式。
2. 设定扫描间隔与地点：按故障容忍度选择，间隔越短越能发现短时故障，但扫描量也越大。
3. 配置误报防护：设置多地点确认和延迟告警时长，先观察一段时间再收紧。
4. 填写通知渠道：短信、电话、邮件至少保留一种可靠渠道，并确认接收人。
5. 准备恢复动作：需要自动恢复时，提前配置密钥登录或 DNS 服务商 API，并测试备用服务器可用性。
6. 设置维护模式：把计划维护窗口录入，避免误告警。
7. 验证：人为制造一次可控的短时不可用，确认告警是否按预期触发、恢复动作是否执行。

常见卡点集中在恢复动作的凭据配置和 DNS 切换后的回切流程；这两项建议在正式依赖前单独演练一次。