不想折腾复杂探针？Cloudflare 自带监控才是中小型网站的稳如磐石之选

在日常的服务器运维和网站管理中，我们总会面临一个核心问题：如何知道我的服务是不是“挂了”？

为了解决这个问题，很多朋友（包括以前的自己）都会去折腾各种第三方探针服务，什么 UptimeRobot、StatusCake、以及各种自建的监控面板。虽然功能强大，但配置繁琐、界面臃肿，甚至有些免费版还有各种限制。

最近在折腾服务监控时，我突然悟了：在这个领域，很多时候并不是工具越多越好，而是越“原生”越稳。 尤其是对于已经把域名接入 Cloudflare 的用户来说，自家的 Cloudflare Monitor 往往才是那个被低估的王者。

今天就来聊聊为什么我最终放弃了花里胡哨的第三方探针，转投了 CF Monitor 的怀抱，以及它到底好在哪里。

为什么我会“叛变”到 Cloudflare？

在 Cloudflare 控制台的 Traffic 菜单下找到 Monitoring 功能。

老实说，用过的监控工具不少。有的邮件报警延迟严重，有的对国内网络支持不佳，还有的自建探针本身就是个“资源消耗大户”甚至成为了被监控的单点故障。

Cloudflare Monitor 的核心优势其实很简单：原生、顺滑、免费。

1. 网络节点优势明显：Cloudflare 拥有遍布全球的边缘节点。当你的监控请求从 CF 的节点发出时，它本身就是你站点架构的一部分。相比于第三方从单一或多点发起探测，CF 的视角更接近实际用户的访问情况，尤其是如果你本来就把业务跑在 CF 的 CDN 上，那这就更是“天作之合”。

2. 配置极简：不需要注册新账号，不需要验证邮件，不需要粘贴复杂的 API 密钥。只要登录 Cloudflare 面板，点几下鼠标就能搞定。

3. 报警即时且灵活：支持 Email 和 Webhook 钩子。这意味着你不仅能在第一时间收到邮件通知，还能通过 Webhook 接入 Telegram、钉钉或者企业微信，实现故障秒级触达。

Cloudflare Monitor 实战配置指南

虽然它的界面很简单，但还是有一些细节值得说道说道，尤其是针对我们要“薅羊毛”（追求极致性价比和稳定性）的需求。

第一步：找到入口

登录 Cloudflare 控制台，选择你的域名（或者直接在左侧菜单栏找到 Traffic（流量） 下的 Monitoring（监控））。如果你没有看到，可能需要确认一下你的账户计划，通常免费版账户就可以使用基础的监控功能，部分高级功能可能需要 Pro 或更高级别套餐，但对于基本的 HTTP/HTTPS 检查完全够用。

配置邮件或 Webhook 通知方式，确保故障第一时间触达。

第二步：创建监控脚本

点击 Create monitor。

这里有几个关键参数需要注意：

• Type（类型）：通常选择 HTTP 或 HTTPS。如果你启用了强制 HTTPS，请务必选 HTTPS，否则会因为跳转问题误报。
• URL（路径）：输入你要监控的完整 URL。建议监控具体的业务页面（例如 /api/health 或者首页），而不仅仅是根目录，这样能更准确地反映后端服务的真实状态。
• Frequency（频率）：这是监控的“心跳”间隔。免费版通常提供 1 分钟、5 分钟等选项。如果是核心业务，建议设置为 1 分钟，虽然成本稍微高一点点（CF 计量可能涉及请求次数），但为了稳定性值得。
• Regions（区域）：你可以选择从哪里发起探测。建议选择 全球 或者与你目标用户群体最近的区域。如果你的服务主要面向国内，且 CF 的节点在国内延迟尚可，可以指定亚太区域。
• Expectations（预期设定）：这是最关键的一步。
  • Status code（状态码）：通常是 200。但是要注意，如果你的网站做了维护，返回 503，CF 是会报警的。所以要做好白名单或者在维护时暂停监控。
  • Text body check（正文检查）：这是防止“假死”的神器。比如你的首页正常返回 200，但其实数据库挂了，页面只显示了“Error Connecting DB”。在这个框里输入一段正常情况下一定会出现的文字（比如页脚的版权信息），只有当状态码正确 且 页面包含这段文字时，才算监控通过。

第三步：配置通知渠道

监控到了问题谁来处理？

在 Notifications 里设置。填写你的接收邮箱。如果你想更极客一点，直接使用 Webhooks。

对于喜欢用 Telegram 的朋友，可以直接配置 Telegram Bot 的 API，这样服务器一挂，你的手机立马就能收到消息推送，比邮件查收效率高多了。

与传统探针方案的对比思考

有人可能会问：“那我自建的探针面板多好看啊，还能展示给客户看。”

没错，自建或者第三方面板有展示页面的优势，适合做服务状态公示页。但如果你是个人站长或者小团队运维，追求的是自己第一时间收到警报，而不是给别人看花哨的图表，那 CF Monitor 的优势就非常明显了：

• 维护成本低：你不需要维护“监控探针”本身的稳定性。很多自建探针最后是“探针服务器先挂了，导致以为业务正常”，这就很尴尬。
• 资源占用零：完全运行在 Cloudflare 端，不消耗你自家 VPS 的一点点 CPU 或内存。
• 误报率相对较低：因为是从 CDN 边缘发起，如果 CDN 都打不通你的源站，那基本上就是真挂了。

进阶玩法：结合 Cloudflare Worker 做深度监控

如果你觉得简单的 URL 探测还不够硬核，可以结合 Cloudflare Workers。

比如写一个简单的 Worker 脚本，访问你的数据库接口，返回 JSON 数据 {"status":"ok"}，然后让 Cloudflare Monitor 去探测这个 Worker 的地址。这样，你监控的就不单单是 Web 页面，而是整个后端逻辑的健康状况了。

总结

在“羊毛党”和技术原教旨主义之间，我越来越倾向于利用好手头已有的强大生态。

Cloudflare Monitor 就是这样一种工具：它不喧宾夺主，没有复杂的配置界面，也没有花哨的数据可视化，但它足够稳、足够快、足够靠谱。对于绝大多数不想在监控这件事上花太多钱、也不想花太多精力维护的博主和运维来说，它绝对是目前性价比最高的“隐形守护者”。

下次如果你在为服务器莫名其妙宕机而烦恼，不妨试着关掉那些臃肿的第三方插件，回到 Cloudflare 的怀抱，简单才是硬道理。