bpstatus：GitHub 零成本监控状态页技术分析
一、概述
1. 简介
A. 是什么
bpstatus 是一个基于 Upptime 框架构建的开源状态监控系统，由用户 Bob Pony 创建并维护。该系统利用 GitHub 原生基础设施（GitHub Actions、GitHub Pages、GitHub Issues）实现了完全免费的服务可用性监控和状态展示。
B. 为什么值得关注
- 零成本运行：无需购买服务器或云服务
- 开箱即用：基于 GitHub 仓库即可部署
- 自动化监控：通过 GitHub Actions 定时检查服务状态
- 可视化展示：生成响应时间图表和可用性统计
C. 技术亮点
- 利用 GitHub Issues 作为事故报告系统
- 使用 GitHub Actions 作为监控任务调度器
- 通过 GitHub Pages 托管静态状态页面
- 完全无服务器架构（Serverless）
2. 技术背景
A. Upptime 框架
Upptime 是一个开源的 uptime monitor 和 status page 生成器，采用独特的「GitHub 原生」架构设计。其核心理念是将监控系统的各个组件映射到 GitHub 的现有服务上。
B. 技术栈
- 监控执行：GitHub Actions
- 数据存储：Git 仓库
- 状态展示：GitHub Pages
- 事故管理：GitHub Issues
- 前端框架：原生 JavaScript（无依赖）
二、系统架构
1. 整体架构设计
graph TB
subgraph "GitHub Actions"
A1[Uptime CI<br/>可用性检查]
A2[Response Time CI<br/>响应时间检查]
A3[Graphs CI<br/>图表生成]
A4[Static Site CI<br/>静态站点构建]
A5[Summary CI<br/>摘要更新]
end
subgraph "Git 仓库"
R1[.github/workflows/<br/>工作流配置]
R2[history/<br/>历史数据]
R3[site/<br/>静态站点源码]
end
subgraph "GitHub 服务"
G1[GitHub Issues<br/>事故报告]
G2[GitHub Pages<br/>状态页面托管]
end
A1 -->|写入监控数据| R2
A2 -->|写入响应时间| R2
A3 -->|生成图表| R2
R2 --> A4
A4 -->|构建站点| G2
A5 -->|更新摘要| R3
R3 --> G2
A1 -.服务异常.-> G1
User[用户] --> G2
User --> G1
2. 核心组件
A. GitHub Actions 工作流
- Uptime CI：定时检查目标服务的可用性
- Response Time CI：测量服务响应时间
- Graphs CI：生成响应时间趋势图
- Static Site CI：构建和部署静态站点
- Summary CI：更新整体状态摘要
B. 数据存储层
- history 目录：存储每次监控的结果数据（JSON 格式）
- 配置文件：定义监控目标、检查间隔、告警规则
C. 展示层
- GitHub Pages：托管生成的静态 HTML 页面
- 状态徽章：SVG 格式的实时状态指示器
3. 数据流向
sequenceDiagram
participant GA as GitHub Actions
participant Target as 监控目标
participant Git as Git 仓库
participant GP as GitHub Pages
participant User as 用户
GA->>Target: HTTP 探测请求
Target-->>GA: 响应/超时
alt 服务异常
GA->>Git: 创建 GitHub Issue
Git-->>User: 事故通知
end
GA->>Git: 提交监控数据
GA->>GP: 触发站点构建
GP-->>User: 访问状态页面
三、bpstatus 实例分析
1. 监控配置
根据 bpstatus 仓库的公开信息，该实例监控以下服务：
| 服务名称 | 状态 | 响应时间 | 可用性 |
|---|---|---|---|
| Main website | 正常 | 143ms | 100% |
| Downloads | 正常 | 565ms | 99.85% |
2. 工作流配置
bpstatus 使用了五个独立的 GitHub Actions 工作流：
- Uptime CI：定时执行可用性检查
- Response Time CI：记录响应时间数据
- Graphs CI：生成历史趋势图表
- Static Site CI：构建和部署静态页面
- Summary CI：更新状态摘要信息
3. 自动化机制
- 定时触发：通过 cron 表达式配置检查频率
- 自动告警：服务异常时自动创建 GitHub Issue
- 自动恢复：服务恢复后自动关闭相关 Issue
四、技术原理深度解析
1. GitHub Actions 监控机制
A. 定时任务调度
使用 GitHub Actions 的 schedule 事件，通过 cron 表达式定义执行频率：
on:
schedule:
- cron: '*/5 * * * *' # 每 5 分钟执行一次B. 状态探测逻辑
工作流脚本执行 HTTP 请求，根据以下标准判断服务状态：
- 状态码检查：2xx 状态码视为正常
- 响应时间阈值：超过预设阈值视为降级
- 连接超时：无法连接视为服务中断
C. 数据持久化
监控结果以 JSON 格式提交到 Git 仓库的 history 目录：
{
"timestamp": "2025-01-16T00:00:00Z",
"status": "up",
"responseTime": 143,
"code": 200
}2. 静态站点生成
A. 构建流程
- 读取 history 目录中的所有历史数据
- 计算可用性百分比（24小时、7天、30天、全部时间）
- 生成响应时间图表（SVG 格式）
- 渲染 HTML 页面
B. 状态徽章
每个监控服务都有对应的 SVG 徽章，显示当前状态：
- 绿色：服务正常
- 红色：服务中断
- 黄色：服务降级
3. 事故报告机制
A. 自动创建 Issue
当监控检测到服务异常时，自动创建 GitHub Issue：
- 标题：包含服务名称和异常类型
- 标签：自动分配「incident」标签
- 内容：包含异常时间、初步诊断信息
B. 自动恢复标记
服务恢复后，自动关闭对应 Issue 并添加「resolved」标签
五、优缺点分析
1. 优势
A. 成本优势
- 完全免费：利用 GitHub 免费账户即可使用
- 无需维护：无需管理服务器、数据库或监控系统
- 零运维成本：GitHub 负责基础设施维护
B. 技术优势
- 简单部署：Fork 仓库即可快速创建自己的监控
- 版本控制：所有配置和数据都有历史记录
- 开源透明：完全可审计和定制
C. 功能优势
- 多种展示方式：状态页面、徽章、API
- 历史数据分析：自动生成可用性统计
- 事故跟踪：与 Issues 深度集成
2. 局限性
A. 技术限制
- 检查频率限制：GitHub Actions 有执行时间限制
- 单点故障：依赖 GitHub 平台可用性
- 网络位置：探测源固定在 GitHub 的数据中心
B. 功能限制
- 监控类型：仅支持 HTTP/HTTPS 探测
- 告警渠道：仅支持 GitHub 通知
- 数据保留：受 Git 仓库大小限制
C. 商业限制
- GitHub 使用条款：需遵守 GitHub 的服务条款
- 私有仓库：高级功能需要付费账户
六、适用场景
1. 推荐场景
- 个人项目监控：开源项目、个人博客等
- 小团队状态页：初创公司、小团队服务状态展示
- 演示项目：学习 Upptime 和 GitHub Actions
2. 不推荐场景
- 企业级监控：需要高精度、多地区探测的场景
- 实时告警：需要秒级响应和多样化告警渠道
- 复杂监控：需要 TCP、Ping、数据库等多种监控类型
七、技术延伸
1. 类似项目对比
| 项目 | 技术栈 | 部署方式 | 成本 |
|---|---|---|---|
| Upptime | GitHub Actions + Pages | Git 仓库 | 免费 |
| Uptime Kuma | Node.js + Docker | 自托管 | 服务器成本 |
| StatusCake | 商业 SaaS | 云服务 | 按监控点计费 |
| Pingdom | 商业 SaaS | 云服务 | 按监控点计费 |
2. 技术趋势
- Serverless 监控：利用云平台原生服务构建监控系统
- GitOps 实践：将基础设施状态纳入版本控制
- 低成本监控：开源工具替代商业监控服务
八、总结
bpstatus 是 Upptime 框架的典型实例，展示了如何巧妙利用 GitHub 原生服务构建功能完整的监控系统。这种「GitOps」风格的监控方案，特别适合个人开发者和小团队，通过零成本的方案实现了服务可用性监控、状态展示和事故管理的核心功能。
其创新性在于将监控系统的各个组件映射到 GitHub 的现有服务上，形成了一个自包含、可复制、易部署的解决方案。虽然在企业级应用中存在局限性，但其设计理念和实现方式为 Serverless 架构提供了很好的参考案例。