UptimeRobot 教程：用免费服务搭一套可靠的网站可用性监控
做网站运维的人最怕的不是 bug，而是”网站挂了没人发现”。等用户来反馈，往往已经过去几十分钟甚至几个小时。UptimeRobot 是国外一款老牌的可监控网站/API 稳定性的在线服务，免费额度对于个人站长和中小团队已经够用，操作门槛也低，注册几分钟就能跑起来。下面从功能、额度、场景、配置几个角度系统讲一下它怎么用，以及在什么情况下应该考虑替代品。
UptimeRobot 是什么
UptimeRobot 是一个 SaaS 形态的可用性监控平台。它的工作原理很直接：你在平台上添加一个或多个”监控器”（Monitor），每个监控器对应一个 URL、一个端口或者一个关键词。UptimeRobot 在全球部署了多个探测节点，按照设定的时间间隔（免费版默认 5 分钟）反复访问你的目标，根据返回的状态码、响应时间、内容判断目标是否正常。一旦探测失败次数达到阈值，它就会通过你配置的渠道发出告警。
它不是基础设施层面的监控工具，不采集 CPU、内存、磁盘这种指标，也不替代 Prometheus 那一套。UptimeRobot 解决的核心问题只有一个：“我的网站/服务现在用户能不能正常访问？”
核心监控类型
UptimeRobot 支持的监控类型覆盖了大部分常见场景：
- HTTP(s) 监控：最常用的类型，定期请求一个 URL，根据状态码判断是否正常。可以设置匹配的状态码（比如只把 200 算正常，其他都算异常）。
- 关键字监控：在 HTTP 监控基础上更进一步，页面返回内容必须包含某个关键词才算正常。比如监控一个静态博客页面里是否包含特定的版权字符串。
- Ping 监控：用 ICMP 探测主机是否在线，适合监控服务器本身。
- 端口监控：探测某个 TCP 端口是否在监听，比如监控 Redis 的 6379、数据库的 3306 这种内网端口。
- DNS、SSL 证书过期提醒：检查域名解析记录和 SSL 证书的有效期，提前提醒证书快过期。
这些类型基本够用。如果你的需求是采集应用内部的 metrics、追踪慢 SQL、画漂亮的 dashboard，那 UptimeRobot 不适合，那是 Prometheus + Grafana 的活。
免费额度与付费方案
UptimeRobot 的免费层对于个人项目非常友好，主要限制如下：
- 监控器数量：免费版可建 50 个监控器，对于一个博客加上几个 API 端点绰绰有余。
- 检查间隔：免费版默认 5 分钟一次。对于大多数场景，5 分钟是可接受的——故障从发生到你收到告警，最多 5–10 分钟。
- 通知渠道：邮件、Twitter DM、Webhook、Slack、Discord 等基础渠道在免费层就开放，Telegram 通知需要付费。
- 公开状态页：免费版支持创建 1 个公开状态页，可以嵌入到你自己的网站里。
付费方案（Pro/Enterprise）主要提升在以下几个方面：
- 检查间隔缩短到 1 分钟甚至更短，适合对实时性敏感的电商、SaaS 服务。
- 监控器数量大幅提升（几百到几千个）。
- 解锁 SMS 短信告警和更多的通知渠道。
- 多用户协作、更长的日志保留时间。
要不要付费取决于业务对可用性的敏感度。个人博客基本没必要付费；如果是面向客户承诺 SLA 的 SaaS，5 分钟探测间隔太长，建议升级。
典型适用场景
个人博客或小项目：监控主站、备份站、GitHub Pages 镜像。免费额度完全够用。
API 服务：给自己的 API 加几个端点监控（/health、关键 GET 接口），出问题第一时间知道，不用等用户反馈。
小型 SaaS 产品：配合公开状态页，把”我们的服务目前正常”这种信心直接传递给客户。状态页本身也是一种透明度的体现。
内网服务的可达性：端口监控可以帮你盯一些内网服务，比如家里的 NAS、树莓派上的服务（注意要从外网探测，得做端口映射或用其他穿透方案）。
不适合的场景：需要细粒度性能分析、复杂告警策略（按时间段静音、复杂的升级规则）、采集主机硬件指标、需要完全私有化部署——这些场景 UptimeRobot 都覆盖不到。
进阶配置：通知渠道与状态页
通知渠道决定了故障发生后你多久能收到信息。UptimeRobot 支持的渠道比较全，包括邮件、Webhook、Telegram、Slack、Discord、Microsoft Teams、PagerDuty 等。配置上没有什么复杂的，主要注意几点：
- 至少配置两个渠道：邮件 + Telegram/微信（通过 Webhook 转发到微信企业机器人）是常见组合，避免单渠道失效。
- Webhook 是万能方案：任何支持自定义 Webhook 的服务都能对接。UptimeRobot 的 Webhook 在告警触发时会 POST 一个 JSON 负载，包含监控器名称、状态、详细信息，你可以自己写脚本处理。
- 联系人静默规则：UptimeRobot 支持”维护窗口”，在指定时间段内不发送告警，避免凌晨部署时手机被轰炸。
公开状态页是另一个有用功能。你可以为不同的监控器分组（比如”主站””API””第三方依赖”），生成一个独立的状态页 URL。这个页面默认是公开可访问的，订阅者可以填邮箱接收更新。对于面向客户的服务来说，这是一个低成本但能显著提升信任感的工具。
与同类服务的对比
把 UptimeRobot 放进更大的生态里看，能更清楚地知道什么时候选它、什么时候选别的：
| 工具 | 形态 | 主要特点 | 适合场景 |
|---|---|---|---|
| UptimeRobot | SaaS | 免费额度大、上手快、监控类型全 | 个人站长、小型项目、SaaS 状态页 |
| Statuspage | SaaS（Atlassian） | 强大的状态页和事件管理，偏企业内部协作 | 中大型团队，需要复杂的事件流转 |
| Better Stack | SaaS | Uptime 监控 + 状态页 + 日志，Svelte 团队用的就是它 | 既要监控又要日志聚合的团队 |
| Prometheus + Blackbox exporter | 自建 | 完全可控、自定义告警规则、可深度集成 Grafana | 有运维能力、需要私有化、监控指标复杂的场景 |
| Checkmate（开源） | 自托管 | 类似 UptimeRobot 的功能但开源可自建，提供 Docker Compose 一键部署 | 想用开源替代 UptimeRobot、又想要现成 UI 的团队 |
简单选型思路：
- 想要省事、成本低：UptimeRobot 起步。
- 想要完全自托管、避免数据出内网：考虑 Checkmate 这类开源方案，或者 Prometheus + Blackbox exporter。
- 需要事件管理、ITIL 流程：Statuspage / Better Stack 更合适。
- 已经重度依赖Grafana 生态：Prometheus 一条路走到底。
上手步骤简述
虽然 UptimeRobot 已经相当直观，还是按顺序走一遍常见流程：
- 注册账号（邮箱即可，免费层不需要信用卡）。
- 在主面板点击 Add New Monitor，选择类型（HTTP 多数情况）、填入 URL、设置监控器名称和检查间隔。
- 在 My Settings → Alert Contacts 里添加通知渠道，至少加一个邮件，再加一个 Webhook/Telegram 作为冗余。
- 把通知渠道绑定到刚创建的监控器上。
- （可选）在 Public Status Pages 里创建一个状态页，把相关监控器分组加入。
- 把状态页 URL 放到你网站的 footer 或帮助文档里。
整个过程不需要任何代码，最多 10 分钟就能跑起来。
几点实践建议
- 监控器命名要规范：建议带环境（prod/staging）和服务名（如
prod-api-health），状态页展示和后续维护都更清晰。 - 不要只监控首页：首页可能因为 CDN 缓存返回 200，但 API 已经挂了。关键业务接口也要单独加监控。
- 把告警接收人控制在能立刻行动的人：太多人订阅反而没人负责。
- 定期 review 监控列表：服务下线后及时删掉失效监控器，避免误报淹没真实告警。
免费层作为起步完全够用，当业务规模、监控对象数量、对实时性的要求都上来时，再评估付费或迁移到自建方案也不迟。
评论(0)