UptimeFlare：免费开源的多区域网站状态监控 轻松部署到 Workers
前言
很久之前介绍过一款同样开源的站点监控工具 Uptime Kuma，功能非常的丰富，可以满足绝大多数网站状态监控的需求，但也存在一个较为致命的问题——需要部署在自己的 VPS 上。
当然，与其说这是 Uptime Kuma 的缺点，不如说是自身条件的限制。毕竟谁也不能保证部署了 Uptime Kuma 的主控服务器始终稳定，一旦主控服务器或网络出现波动，就可能导致被监控的站点被误判为无法访问。
对于这个问题，像是商业化的监控软件，例如 UptimeRobot 等都支持从多个地区来监控目标站点是否能够访问，但这些商业化软件对于使用免费计划的用户来说，基础功能限制过多，可能无法满足需求，并且订阅的价格通常也不便宜。
而 UptimeFlare 借助 Cloudflare 的强大功能，无需付费就可以实现从全球各地监控进行监控。与此同时，你也不需要单独购买服务器来部署 UptimeFlare，相比之下，将它直接部署到 Cloudflare Workers 上更加的稳定可靠。
功能
铺垫了这么久，简单介绍一下 UptimeFlare 的特性：
-
最多支持 50 个 1 分钟间隔的监控以及 90 天历史记录
-
支持指定区域的监控节点
-
支持 HTTP / HTTPS / TCP 端口监控，自定义 HTTP(s) 请求方法、头和主体，状态码和关键字检查
-
支持 Webhook 通知
-
支持绑定自己的域名
准备工作
标题已经提到了 UptimeFlare 需要部署到 Workers，因此你只需要准备：
-
一个 GitHub 账号用于存放仓库以及运行 Actions 构建到 Workers
-
一个 Cloudflare 账号用于部署 UptimeFlare
搭建
创建仓库
来到 UptimeFlare 的官方仓库，点击右上角的 “Use this template”，将官方仓库作为模板创建一个新的仓库
接着给仓库命名，可以直接叫 UptimeFlare，如果你不希望站点的监控配置对外暴露，那么可以将这个仓库设置为 Private 私有。
但需要注意的是，私有仓库运行 Actions 每个月只有 2000 分钟的额度，如果你私有库非常多的话需要注意一下用量。
创建 Token
通过 Cloudflare 的 API Token 可以让 Actions 构建后自动上传到 Cloudflare Workers 和 Pages，免去繁琐的手动上传操作。
来到 Cloudflare 设置页面，选择 “API Token”，点击右侧的 “Create Token”
下方的模板选择 “Edit Cloudflare Workers”
接着将账号和区域设置为所有，方便后续操作（如果你比较注重安全，也可以按照实际需求选择）
创建完成后会显示 API Token，需要立刻保存下来，离开这个页面后将无法再次查询。
添加 Token
完成 Token 的创建后，还需要将其填写到 GitHub 中
切记千万不要直接填写到 Actions 的配置文件 deploy.yml 中，这样会导致直接明文显示 API Token，是一个非常危险的操作。
正确操作应该是来到 “Settings” 中找到 Actions，在里面设置一个 secret
Name 为 CLOUDFLARE_API_TOKEN，Secret 就是刚才复制的 API Token
这样操作之后， deploy.yml 文件中只会显示 secrets.CLOUDFLARE_API_TOKEN，在运行时会自动进行替换并隐藏。
配置
在仓库的根目录下，有个 uptime.config.ts 文件，所有的配置都在这个文件中定义
详细配置可以参照示例文件的注释修改，下面简单介绍一下各个部分的作用：
-
pageConfig: 修改站点的标题以及导航栏
-
workerConfig: 配置监控项以及通知
-
maintenances: 展示维护信息
pageConfig
-
title 为站点的标题
-
links 为导航栏的链接，数组中的每一个对象对应一个链接
const pageConfig: PageConfig = {
title: "lyc8503's Status Page",
links: [
{ link: 'https://github.com/lyc8503', label: 'GitHub' },
{ link: 'https://blog.lyc8503.net/', label: 'Blog' },
{ link: 'mailto:me@lyc8503.net', label: 'Email Me', highlight: true },
],
}workerConfig
在 monitors 中配置监控项
-
id 需要唯一
-
name 为展示的名字
-
method 与 target 则是监控的方式与目标
-
checkProxy 可以设置为
wnamenamsamweureeurapacocafrme中的任意一个来实现指定区域监控
monitors: [
{
id: 'foo_monitor',
name: 'My API Monitor',
method: 'GET',
target: 'https://www.google.com',
checkProxy: 'worker://apac'
},
{
id: 'test_tcp_monitor',
name: 'Example TCP Monitor',
method: 'TCP_PING',
target: '1.2.3.4:22'
}
],在 notification 中配置通知，推荐直接使用 Webhook 来进行通知，比较便捷，无需另外部署 Apprise。
当然了，通知的配置不是必须的，如果你不需要通知的话可以直接将其删除。
notification: {
webhook: {
url: 'https://api.telegram.org/bot123456:ABCDEF/sendMessage',
payloadType: 'param',
payload: {
chat_id: 5678,
text: '$MSG'
}
}
}maintenances
维护信息一般情况下是用不到的，但不能将它直接删除，否则部署的时候会失败，将它设置为空数组即可
const maintenances: MaintenanceConfig[] = [];部署
如果你对 Git 操作不了解的话，可以直接在网页上编辑 uptime.config.ts，编辑完成后点击右上角的 “Commit” 提交。
提交后会自动触发 GitHub Actions 开始部署，等待几分钟后，应该就能看在 Cloudflare 看到 uptimeflare 与 uptimeflare_worker 了。
此时访问自带的 <name>.pages.dev 域名就能进入 UptimeFlare 了。
如果你需要自定义域名也非常简单，将它添加上方的 uptimeflare 这个 Pages 中即可（注意不要添加到 Workers 去了）
