通过 Upptime 监控网站状态

2024年5月2日

Upptime 是一个开源、完全基于 GitHub Actions, Issues 和 Pages 的网站监控项目。这篇文章将会简单介绍 Upptime，并提供一些 Upptime 的使用方法。

最近我加入了开往的群聊凑热闹。前天，林林在群里放出了开往服务状态监控的 UptimeRobot 链接；到了昨天，有一个群友好奇为什么不自建一个网站状态监控程序（比如 Uptime Kuma）。因为 Uptime Kuma 是自托管的网站状态检测程序、不支持使用 Vercel, Heroku 这类容器搭建，故林林表示：

开往就那么两个服务器。如果服务器没崩，开往的服务应该也不会掉；如果服务器崩了，这个状态监控也监控不了了。

随后，有另外一个群友推荐自建一个 UptimeRobot 监控页，但这不是我们关心的点，先暂时不说。因为我自己就在使用本文的主角 Upptime，所以我在群里面推荐了一下，至少我认为 Upptime 的功能完善、并且不需要订阅什么付费计划，这是 UptimeRobot 比不上的一点。而前面提到的自定义 UptimeRobot 监控页用的就是 UptimeRobot 接口，就算是自建也依赖 UptimeRobot，同样不及 Upptime。（暴论）

为什么是 Upptime

可能在大多数站长的印象里，好用的网站状态监控或许只有 UptimeRobot 和 Uptime Kuma 这两个......吧？但就上面的描述而言，它俩在此的弊端已十分明显：

UptimeRobot 免费版的功能太少，如果想要更多的功能，你只能交钱；
Uptime Kuma 成熟、功能完善且免费，但正如林林所言： 如果服务器没崩，开往的服务应该也不会掉；如果服务器崩了，这个状态监控也监控不了了。

那么，有没有完美解决上面这两个弊端的方案呢？嗯，真有，便是今天的主角：Upptime。

根据开头第一段，你已经知道了 Upptime 完全基于 GitHub Actions, Issues 和 Pages，这正是 Upptime 的妙处：

用 GitHub Issues 报告网站的故障状态，同时也可以提起一个站点维护的 Issue；
用 GitHub Pages 发布网站状态监控页；
用 GitHub Actions 获取网站状态数据，同时处理 Issues 内的网站维护信息。

依靠 GitHub 的这三个服务，你就可以获得一个免费的、功能完善的网站状态监控服务。实在是妙不可言。

那么，如何使用？

Upptime 的官方文档并没有中文版本，所以看起来可能会比较吃力。不过，Upptime 大部分配置都集中在 .upptimerc.yml 中、只有少数配置需要配置仓库的 Secrets，所以问题不是很大。这里会稍微讲一下我是怎么配置的。

请多加注意：这里的 仓库的 Secrets 是仓库设置里的侧边栏的 Secrets and variables 项的 Actions 子项的 Secrets 部分。 请不要选到 Variables 部分！！！

在你的个人账号 / 组织下创建一个 Upptime 模板

Upptime 仓库的 Star 旁边有一个 Use this template，你只需要选中它的 Create a new repository 子项、选择这个模板仓库的所有者（即 Owner，看你想要在个人账号还是组织下创建）以及仓库名称即可。

Include all branches 必须要勾选，别问为什么。

Upptime 每个月都需要使用数千分钟的构建时间，因此我建议将这个仓库设为公开。如果你将其设置为私密，那就得交钱，得不偿失。

启用 GitHub Pages

这里默认假定你已经创建好了 Upptime 的模板仓库。请前往仓库的 Settings，并找到侧边栏的 Pages 项。

让我们看到 Build and deployment 这一部分。第一个 Source 需要改为 Deploy from a branch；第二个 Branch 的分支选择 gh-pages、目录保持 root 即可。做完这一切之后，点击 Save，这部分就算完成了。

修改 Upptime 配置文件

上面已经说到，Upptime 大部分配置都集中在 .upptimerc.yml 中、只有少数配置需要配置仓库的 Secrets。所以我们首先将精力投在这个配置文件上。

配置仓库信息

Upptime 的 Action 将会把获取到的数据都存在仓库里，而它的网页便是通过 GitHub API 从仓库获取这些数据。而 Upptime 并不知道你的仓库的所有者是谁、仓库名称又是什么，所以需要你手动配置。

.upptimerc.yml · yaml

# Change these first
owner: s-complex # Your GitHub organization or username, where this repository lives
repo: upptime # The name of this repository

Upptime 甚至在配置文件的第一行加了一句 # Change these first，让你意识到这个配置十分的重要。

添加需要监控的网站

仓库配置的下面便是需要检测的网站的配置了。如果主打一个简单粗暴、并且要求不复杂的话，这么写就可以了：

.upptimerc.yml · yaml

sites:
  - name: Ou's Intro
    url: https://www.gxres.net
  - name: Restent's Notebook
    url: https://blog.gxres.net

当然，Upptime 在这一块的配置项非常的多：标头、端口 TCP 测试、指定网站 icon、预期的 HTTP 状态码，等等。这里就看各位自己的需求、按文档的指示来添加了。 ~~因为项太多，我实在不想一条条搬过来~~

设定 CI 运行时间表

Upptime 给出了一个基于 Cron 语法的 CI 运行的时间表的配置项，供你按自己的喜好来设定运行时间。 注意：间隔时间不能低于五分钟。

.upptimerc.yml · yaml

workflowSchedule:
  graphs: "0 */4 * * *"
  responseTime: "0 23 * * *"
  staticSite: "0 1 * * *"
  summary: "0 0 * * *"
  updateTemplate: "0 0 * * *"
  updates: "0 3 * * *"
  uptime: "*/5 * * * *"

如果你实在不知道怎么配置，保持默认即可，不要动。

设定监控网页的配置

再下来便是状态监控网页的相关配置了。

首先将目光放在链接的配置上：Upptime 允许你指定一个自定义域名，或是使用 GitHub Pages 启用后的默认域名（比如 s-complex.github.io/upptime）。如果你需要使用自定义域名，请解除 cname 项的注释、填写你的自定义域名，再将 baseUrl 注释回去；如果你需要使用 GitHub Pages 启用后的默认链接，操作步骤和自定义域名的相反，注意 baseUrl 项只需要你填写域名后面的部分（比如 /upptime）。

这一步不能忽视，因为 cname 项和 baseUrl 项不能同时存在。

再来看到老生常谈的 logoUrl 项和 name 项，分别代表这个网页的图标（Favicon）和名称。这个就不需要多说了。

接着就是 navbar 项，也不需要多言、你配置的项将会放置在网页标题的右侧。

我的仓库里还有一个 singleCommit 项，这会在上传网页内容到 gh-pages 分支时、强制将 Commits 数量重置为 1。这个看你喜好吧......

下述是这一块的配置的示例：

.upptimerc.yml · yaml

status-website:
  # Add your custom domain name, or remove the `cname` line if you don't have a domain
  # Uncomment the `baseUrl` line if you don't have a custom domain and add your repo name there
  cname: status.slirv.vip
  # baseUrl: /upptime
  logoUrl: https://library.gxres.net/images/icons/favicon.webp
  name: Ou's Site Status
  navbar:
    - title: Index
      href: /
    - title: GitHub
      href: https://github.com/$OWNER/$REPO
    - title: HomePage
      href: https://www.gxres.net
  singleCommit: true

设置用户代理（User agent）

若需要向 GitHub API 发出请求，请求方必须要包含一个有效的用户代理标头。Upptime 官方建议使用自己的 GitHub 用户名作为标头：

.upptimerc.yml · yaml

user-agent: "slivermoe (https://github.com/s-complex/upptime)"

这里是写的 SliverRiver 的 GitHub 用户名。目前 SliverRiver 的 GitHub 账号主要负责 CI 任务相关的事宜。

写到这里就差不多了。将你写好的这些内容提交到分支，观察一下 GitHub Actions 有没有开始工作。没有的话，可以选中侧边的 Setup CI，接着手动触发这个 workflow 即可。

配置 Telegram 通知

由于 Telegram 通知是我的 Upptime 项目里唯一一个需要配置仓库 Secrets 的项，所以就单独拎出来讲了。

其实原理也并不复杂，在仓库的 Secrets 里添加这三个项：

NOTIFICATION_TELEGRAM，值是 true；
NOTIFICATION_TELEGRAM_BOT_KEY，值是你的 Telegram 机器人密钥；
NOTIFICATION_TELEGRAM_CHAT_ID，值可以是你的账户 ID，可以是你的群聊 ID，甚至是频道 ID，看你自己的需求。

这里已经假设你创建好了 Telegram 机器人、并获得了对应的机器人密钥。

如果你不知道你的账户 ID / 群聊 ID / 频道 ID，请自行私聊 @userinfobot，并将你的个人发言 / 群聊里的发言 / 频道的消息转发给这个机器人。
指正：对于群聊，这个方法仅适用于群里有管理员开启了匿名发言的情况。你可以考虑用 @raw_data_bot 代替。

配置好之后，我个人是手动触发了一次 Setup CI。因为我的 NOTIFICATION_TELEGRAM_CHAT_ID 配置到了我的通知频道，所以一旦网站出现问题，Upptime 便会通过我的机器人在这个频道发送故障通知、并附带上关联的 GitHub Issue 链接。

指南

Upptime

网站状态监控