Contents
1 前言
关于群站应用的健康检查和即时通知，之前我曾经写过一套方案：自建 Uptime 搭配 Bark，用来自行监控服务状态，并将异常推送到我的苹果设备(iPhone、iPad、macOS)上(具体的搭建步骤参看文章：docker系列 搭建基于uptime和bark的应用实时健康监测及报警系统)。除了只能支持苹果生态这一点之外，这套方案在功能性上其实相当完整。
不过，用了一段时间后我还是放弃了，不是因为技术层面出问题，而是从实际使用体验来看，性价比确实不高，原因大致有以下几点：
- 图形界面浪费资源：Uptime 的图表页面对我来说几乎没用，我也不会没事去盯着看，但后台渲染这些内容却占用不少轻量服务器的资源——而腾讯云的轻量服务器本来也不算性能强悍。
- WAF 规则妥协安全性：为了让 Uptime 的探测请求能成功回源，我还得把腾讯云服务器的 IP 加入 Cloudflare 的 WAF 白名单。老实说，我并不喜欢这样做，总觉得埋下了安全隐患。
- 误报频繁心烦意乱：探测包从国内出发，经由复杂路径抵达 Cloudflare 数据中心（大多在美西），本身就容易受网络波动影响，于是经常莫名其妙就收到 Bark 通知，有时一分钟收到好几次，哪怕后来我已经降低了探测频率，但是仍旧无法根治——关键是服务压根没出问题，被吵得烦心，我又不是拿钱上班的真运维～～～。
- 服务其实挺稳定：更现实的是，我这套服务长期来看其实挺稳，几乎没发生过重大中断。既然真出问题的概率本就很低，那花费有限的轻量服务器资源维持一个持续运行的监控系统意义也不那么大。
也正是出于以上这些考虑，我后来彻底放弃了自建这套监控 + 通知组合。不过，这段时间翻查Cloudflare 提供的各种功能想看看 Cloudflare 还有什么能薅的羊毛时，结果发现原来别人早就提供了原生的运行状况检查和通知机制。
虽然对我来说这不是刚需，但既然别人白送功能，我肯定乐意接住，于是，就有了这篇文章，用来记录一下 Cloudflare 的”运行状况检查”与”通知”功能是怎么帮我”低成本”重建了一套更适合站长运维场景的轻量监控方案。
2 运行状况检查(Pro及以上)
2.1 概述
Cloudflare 的”运行状况检查”功能允许用户定期检查网站或服务器的可用性，确保网站在正常运行并及时发现问题：通过指定 URL 路径(如首页、API 接口或者特定的检查页面等)，Cloudflare 会定期发起 HTTP 请求，验证目标是否返回预期的状态码(如 200 OK）。用户可以自定义检查的频率、超时设置和期望的 HTTP 状态码。一旦检查失败，Cloudflare 会通过电子邮件或 Webhook 发送通知，帮助用户快速响应。此功能适用于单站点或多源站配置，Pro 用户可以免费使用最多 10 个健康检查，确保站点始终在线并提升站点的可用性。
2.2 设置步骤
2.2.1 添加运行状况检查
以我的博客添加运行状况检查为例，图文教程如下：
成功添加后：
相比传统的第三方可用性监控工具(如前面提到的Uptime），Cloudflare 的运行状况检查提供了更贴近真实回源路径的探测方式：Uptime 发出的探测请求通常是从它设定的检测节点(比如我就是从国内腾讯云轻量服务器)访问 Cloudflare 的边缘节点，再由 Cloudflare 向源站发起回源请求。而运行状况检查则是直接从 Cloudflare 的边缘网络向我的源站发起 HTTP 检测，它的探测链路更短，回源路径几乎与 Cloudflare 实际服务访客时的回源路径完全一致，因此能更准确反映 Cloudflare 是否真正”打得通”源站。
但真正让人感到强大的是，将运行状况检查与 Cloudflare 的通知系统结合之后所带来的”事件联动判断”能力。比如，我可以在通知系统中为 Tunnel 设置”隧道运行状况警报”，为博客设置”运行状况检查”，如果这两项在同一时间段内同时触发异常，基本可以判断是 Tunnel 断连导致了 Cloudflare 无法回源。这点只使用第三方监测工具中是无法做到的——Uptime 只知道源站无法访问，但无法判断是源站本身挂了、Tunnel 掉了，还是 Cloudflare 出了问题。相比之下，Cloudflare 原生监控系统可以从多个维度收集内部信号，进行交叉分析后推送告警(比如通过 Email、Webhook），这对我这样部署在内网并依赖 Tunnel 的用户来说极具价值。
2.2.2 配置运行状况检查的”警报”
所谓警报，默认其实就是邮件通知，可以直接在运行状况检查界面开始配置：
以后当博客不可访问时，设置的邮箱会收到类似的邮件通知：
如果博客恢复到可访问的状态，设置的邮箱会收到类似的邮件通知：
3 Cloudflare通知
Cloudflare 的通知功能可以说是站长运维中不可忽视的一环，无论你的网站是静态博客还是动态服务，设置好通知后，在网站出现问题的第一时间你就能知道。它支持通过邮件、Webhook等多种方式推送消息，覆盖的事件类型也很丰富，比如常见的 DDoS 攻击、回源异常、SSL/TLS 证书即将过期、运行状况检查失败、WAF 触发、隧道运行状况警报、Page Shield 报警等。
不过需要注意的一点是，不同订阅等级的用户能使用的警报类型是不一样的。Free 用户能订阅的警报类型比较基础，而 Pro、Business 以及 Enterprise 用户能解锁更多高级通知，比如品牌保护、新域名监测、BGP 劫持检测、独立运行状况检查等。
文章前面提到的”运行状况检查”的警报，其实就是”通知”功能中的”运行状况检查”，所以在通知里创建”运行状况检查”警报其实是一样的。
另外，其实就算是对 Free 订阅的用户而言，也有不少有用的警报可以启用，比如：
- HTTP DDoS 攻击警报(默认开启)：Cloudflare 会检测并缓解针对您域的 HTTP DDoS 攻击，一旦发生，系统会及时发送通知。
- SSL/TLS 证书过期警报：当 SSL/TLS 证书接近过期时，Cloudflare 会提醒您，避免证书过期导致的访问问题。
- Page Shield 新代码更改检测警报：如果页面加载的 JavaScript 文件发生更改，您会收到相关警报，帮助及时发现可能影响站点安全的代码变化。
- Page Shield 新恶意域警报：当您的用户加载的资源来自已知的恶意域时，Cloudflare 会发送通知，提醒您资源的安全性。
- Page Shield 新恶意脚本警报：如果用户加载的 JavaScript 被标记为恶意脚本，系统也会发出警报。
- 品牌保护警报：如果检测到与您的域查询或徽标匹配的新域，您将收到实时通知，有助于及时发现潜在的品牌滥用行为。
而对于Pro用户，除了Free用户能使用的通知类型以外，还多了包括前面提到的”运行状况检查”、”被动源服务器监控”、”Tunnel隧道运行状况警报”、”Web Analytics 指标更新”、”Cloudforce One 端口扫描警报”等更加使用的警报类型，比如我创建的所有通知如下：
注1：比较无语的一点是，在通知中并未标明不同等级订阅用户可用的警报类型，这在使用的时候很不方便，所以设置时可能会碰到部分选项变灰或无法添加的情况，基本可以理解为不是当前等级支持的。
注2：Free 计划的用户在 Cloudflare 提供的通知功能方面确实受限，很多高级警报类型并不包含在内，尤其是针对 流量管理、健康检查、端口扫描 等较为实用的功能。相比之下，Pro 及以上计划提供的通知功能会更全面，能够帮助用户更好地应对潜在的流量激增、DDoS 攻击、维护影响等问题。所以如果需要更精细的控制，升级到 Pro 计划可能是一个不错的选择，尤其是当网站的流量和安全性需求较高时。
4 增强实时通知
4.1 邮件通知的局限
其实，邮件通知也算是准实时通知了，只是可能大部分人都不太把邮件通知当回事，特别还是在经常收到垃圾邮件的情况下，我不可能每次听到新邮件的提醒声响就去看是不是站点出了问题吧(除非是单独为了接收通知创建的邮箱或者将Cloudflare发来的通知邮件设置为特殊的提示音)，所以需要一个可以接受的，常规的实时通知方式。
4.2 低端妥协版：139短信通知
这种方式有门槛：就是有一个移动手机号，其利用的是139邮箱提供的新邮件免费短信通知：
这种方式不多说，很简单，主要是来自：
[email protected]邮箱的通知邮件，大家自信研究一下即可，Tunnel出现问题时短信效果如下：
遇到HTTP DDoS攻击时的短信效果如下：
有些警报类型的主题也看不完整，不过好歹知道是Cloudflare发来的，且是”tencentcloud”这个Tunnel出现了问题，实时通知这一点基本还是能实现的，不过就是有时候会不那么实时，我最晚的一次是10多分钟后才收到通知短信～。另外，关注微信公众号之后，还支持微信公众号的提醒，总的来说，实用性还是很不错的，关键是不用折腾。
4.3 webhook通知方式
4.3.1 什么是webhook
Webhook 是一种通过 HTTP 协议让应用程序之间进行实时通信的方式。当某个事件在一个系统中发生时，它会自动向你事先配置的 URL（即接收端的地址）发送一段数据，通常是以 HTTP POST 请求的形式。这些数据可以是 JSON、XML 等格式，包含了与事件相关的信息。
举个实际例子：假设你在 GitHub 上有一个仓库，并且你希望当有人对这个仓库提交 Pull Request 时，自动触发一个 CI/CD 工具进行构建和测试。你可以设置一个 webhook，让 GitHub 在 Pull Request 事件发生时，自动向 CI/CD 系统提供一个 HTTP POST 请求，包含事件的详细信息（如提交者、修改内容等），CI/CD 系统接收到请求后就会开始执行构建和测试流程。
与轮询(不断查询服务器是否有新数据)相比，webhook 更加高效，因为它是事件驱动的，一旦事件发生，系统就会主动推送数据给你，而不是你去频繁请求数据。简而言之，webhook 是一种通过定义触发条件，将相关信息实时发送到指定 URL 的机制，常用于系统之间的自动化交互。
说了这么多，只是因为Cloudflare的通知功能除了邮件通知以外，还支持webhook方式(Free订阅用户也可以使用)：
4.3.2 基于Bark创建通知的webhook接收端
对于使用苹果生态设备的个人用户来说，Bark 是一个非常便捷的个人 Webhook地址搭建工具(具体的搭建步骤参看文章：docker系列 搭建基于bark server的消息推送服务器)，其本质是一个自身不负责存储、不负责身份校验，就是一个”判断 URI → 转发消息”的中转服务：每个Bark终端(iPhone、IPad、Mac设备)在特定的Bark服务器注册之后会获得一个唯一的 device key(token)，然后只要以这个device key为URI前缀发送约定格式的URI路径请求到Bark服务器，Bark服务器就会从请求中提取出通知内容然后发送这个device key对应的设备上(平时这些终端都和Bark服务器保持着通信)。
下面以我的Bark服务器(地址为：https://barkapi.tangwudi.com)和device key为”123456789″的虚拟设备为例，演示基于Bark创建HTTP DDoS警报类型 webhook通知的步骤：
然后设置Bark服务端的地址：
如果测试成功，对应的终端设备上的Bark客户端会收到通知：
通知在终端展现方式，在Bark里有很多方式可以选择，大家自行决定：
最后，只需要在具体的事件通知(本例中是HTTP DDos攻击警报)中，选择之前创建的webhook通知方式，然后保存即可：
我最终创建的所有webhook通知如下：
注：上图中我为什么要创建创建这么多webhook通知？因为如果要在Bark通知中区分开各种警报类型，那么每一个终端设备至少应该为每一种需要的警报类型创建一条对应的Bark通知(总不能所有的警报类型都共用一条相同通告内容的通知吧，相当于只能知道有事发生，具体是啥事就一头雾水)，我为了更加容易区分，则是为部分警报类型(比如隧道状况、博客监控)分别创建了2条(up和down)，再加上每一个终端都需要创建2条，而我这里又包含了2个终端(iPhone、macmini，甚至HTTP DDoS攻击的通知还加上了iPad)，自然而然就变成这么多了～。
5 总结
Cloudflare 的”运行状况检查”和”通知”两大功能结合使用，为站长日常运维提供了极大的便利。虽然市面上也有像 Uptime 这类第三方可用性监测工具，但无论在监测精度、问题定位能力，还是告警机制的灵活性方面，与 Cloudflare 的原生方案相比，都存在不少短板。
其一，第三方工具的探测节点通常分布在公共云或海外数据中心，虽然它们能够检测站点是否可访问，但由于探测路径与用户实际访问路径不同，特别是网络波动、地理位置差异等因素的影响，监测的精度可能无法完美模拟全球范围内的访问体验。相比之下，Cloudflare 的运行状况检查是从多个边缘节点分布式发起的，尤其在使用 Tunnel 回源时，这种多节点探测几乎能完整反映来自不同地区的实际访问路径，因此能够更准确地反映 Cloudflare 是否能成功回源并服务访客。
其二，Uptime 虽能报告”访问失败”，但对于使用 Tunnel 或隐藏在内网的部署来说，无法进一步判断问题到底出在 Tunnel、Cloudflare 回源过程，还是源站本身。而 Cloudflare 的方案则可以通过”事件警报”机制，将运行状况检查、Tunnel 连接状态、WAF 行为等多个事件源结合起来分析，轻松定位问题根因：例如，当运行状况检查失败同时 Tunnel 断连，就能初步判断是 Tunnel 出现故障而非源站本身不可用——这是大多数第三方方案难以做到的。
岐山，在通知方式上，第三方工具虽然支持 Email 或 Webhook，但告警逻辑通常较为死板，只能对单一状态变化进行通知。相比之下，Cloudflare 提供了一体化、可组合的告警系统，所有配置集中在一个平台内，操作简洁，逻辑清晰。无论是邮件通知，还是对接 Bark、139 邮箱短信等外部推送工具，都能轻松完成，几乎无门槛接入。
对于那些将服务部署在内网、不开放公网访问，仅通过 Cloudflare Tunnel 回源的用户来说，这种”贴近源头”的原生探测机制与灵活告警系统显得尤为珍贵：它不仅节省了搭建独立监控体系的精力，更让站长真正实现了”有事秒知，无事不扰”的轻量化、高可靠运维目标。
不过，这套方案也并非无懈可击，唯一的小遗憾大概就是：Free用户白嫖不了。
