1. 什么需要拨测服务
今年 GPT 大火,我也部署、开发了几个应用、小程序进行学习。当然,秉承帮助厂商测试功能的原则,目前只有 GPT 3.5 的 API 每天有少许费用,服务器、数据库、带宽都是免费的。
为了节省成本,我没有测试环境,每次提交代码,只要能编译成功就会直接发布到正式环境。Golang 的应用还好点,编译成功就问题不大;Python 的应用就坑爹了,没有单元测试就很容易出错,提交之后就是 500 。因此,迫切需要监控服务是否异常,保障其可用性。
拨测就是利用分布于全网的监测点,周期性的监控指定服务的可用性、响应延时等。这正是我所需的功能。
2. 为什么是 Upptime
国内厂商提供的免费额度都太小。免费额度最多的阿里云拨测也只够一个监测点每隔 5 分钟监控一个服务地址。
看到有些独立网站使用的 uptime-kuma 项目,是一个 GitHub 开源项目 https://github.com/louislam/uptime-kuma 。最终的监控效果挺好,展示非常清晰、还支持各种告警通知渠道。但,部署 uptime-kuma 时,需要挂载本地盘或者使用 MySQL 存储数据。对于,没有购买服务器的同学来说,成本就略高了。
此时 Upptime 这个项目进入候选名单。Upptime 也是一个 GitHub 开源项目 https://github.com/upptime/upptime 。Upptime 的实现方式是使用 GitHub Actions 定时执行脚本,将监测结果存储在 GitHub 的仓库中,将告警通过 Issues 的方式提交和管理。这就不需要额外的服务器或者数据存储了,与我之前开发的 https://github.com/shaowenchen/debugger-action 项目,利用 GitHub Actions 资源免费运行 6 小时的 Kubernetes 集群类似。
利用 GitHub Actions 提供计算资源,使用 GitHub Repository、Issues 存储数据,这样的实现方式,对于使用者来说,成本为零。只要不滥用,比如用于挖矿、高频率使用、大规模的数据存储等,不会被 GitHub 封禁账号。
3. 使用 Upptime 搭建拨测服务
3.1 以 Upptime 项目为模板创建新仓库
点击 [Use this template] 选择 [Create a new repository]
- 勾选全部分支 [Include all branches],输出仓库名称
- 点击创建,等待完成
3.2 配置更新仓库的凭证
- 创建一个新的 Personal access tokens,用于更新仓库
打开页面 https://github.com/settings/tokens/new
勾选 [repo] [workflow] 权限,点击 [Generate token] 生成新的 token,如下图:
- 在刚才创建的仓库中,设置 Secrets
以我创建的 shaowenchen/upptime 为例,进入 https://github.com/shaowenchen/upptime/settings/secrets/actions
点击 [New repository secret] 添加一个名字为 GH_PAT
的 secret,值为刚才创建的 Personal access tokens, 如下图:
3.3 修改配置文件,添加监测服务
Upptime 项目的配置文件是 .upptimerc.yml
,在仓库的根目录下。以下说明几个关键的配置,其他配置项可以参考 https://upptime.js.org/docs/configuration
- 设置仓库的 owner 和 repo
|
|
- 设置仓库的 CNAME,用于自定义域名
Upptime 项目默认使用 https://<owner>.github.io/<repo>
的域名,如果需要自定义域名,可以设置 CNAME,如下所示。
|
|
- 设置监测的服务
|
|
这里的 maxResponseTime
是设置响应时间的阈值,如果超过这个阈值,就会触发告警。expectedStatusCodes
是设置期望的响应状态码,如果不是期望的状态码,也会触发告警。
上面有两个比较特殊的配置:
- “tcp-ping” 定义的是一个 tcp 的监测服务,用于监测端口是否可用
$WWW_URL
用于从环境变量中获取监测服务的地址,用来隐藏服务地址
在配置 GitHub Actions 时,在 .github/workflows/uptime.yml
中有一个有趣的写法:
|
|
SECRETS_CONTEXT
是一个环境变量,用于将所有的 secrets 中定义的变量直接都放到当前环境变量中。
因此在上面的配置示例中,我们只需要在 secrets 中定义一个 WWW_URL
的变量,就可以在配置文件中使用 $WWW_URL
来引用这个变量了,非常方便。
4. 配置告警通知
Upptime 的告警配置可以参考 https://upptime.js.org/docs/notifications ,这里我主要以 SendGrid 邮件告警为例,说明如何配置。
4.1 创建一个 SendGrid Sender Authentication
点击进入 https://app.sendgrid.com/settings/sender_auth ,选择 [Single Sender Verification],点击 [Create Sender],输入一组信息验证邮件地址,如下图:
4.2 创建 SendGrid API Key
点击进入 https://app.sendgrid.com/settings/api_keys ,选择 [Create API Key],输入一个名字,选择 [Full Access],点击 [Create & View],如下图:
4.3 在 GitHub Secrets 中配置 SendGrid 相关参数
邮件必须设置的参数有:
|
|
|
|
5. 验收与总结
5.1 验收
打开网站 https://upptime.chenshaowen.com/ 就可以看到监测的结果了,如下图:
点击监控项可以查看历史记录,如下图:
当触发告警时,会创建一个 issue,如下图:
当告警恢复时,会自动关闭 issue。当然,也能收到告警触发、恢复的邮件通知,如下图:
5.2 总结
本篇文章主要介绍了如何使用 Upptime 来监测网站的可用性,以及如何配置告警通知。Upptime 项目的配置非常简单,而且提供了很多的监测方式,可以满足大部分的监测需求。
但使用 GitHub Actions 来运行 Upptime 项目,可能存在滥用的风险,如果自己有服务器,可以接入到 GitHub Actions 作为 Self-hosted runner,是一个更好的选择。同时,Self-hosted runner 作为自定义检测点,可以在更接近用户的地方提供检测,具有更佳的准确性。