NAS 上的服务越堆越多，动不动就默不作声地挂了。与其等自己发现，不如让 Checkmate 盯着，出事第一时间推通知。
我家里那台 NAS 现在跑了十几个容器，外加几个小服务。以前状态好不好基本靠心血来潮打开管理面板扫一眼，或者等服务真用不上才意识到出了问题。体验过几次“怎么连不上了→登录排查→原来三天前就挂了”之后，我决定找个自托管、轻量、能把告警推到手机的监控面板。
Checkmate 就是最近试下来比较顺的一个。它在 GitHub 上已经超过 1 万 stars，AGPL-3.0 开源，最近一次发版是 2026 年 7 月底的 v3.10.0，主分支几乎每天还在提交。相比 Beszel、Uptime Kuma 这类同行，它的特色是监控类型全 + 界面现代 + 对外状态页好看，对 NAS 这种“家里的小数据中心”尤其合适。
它能监控什么
Checkmate 不是只能 ping 一下。它支持的监控类型覆盖了我日常用得上的绝大多数场景：
HTTP/HTTPS 服务可用性。我的博客、面板、下载器、媒体服务都可以作为 HTTP monitor 加进去，不仅看通不通，还能记录响应时间，设置状态码或响应内容断言。
Ping、TCP 端口、SSL 证书。适合盯路由管理口、数据库端口、SMTP、代理端口这些不一定有 HTTP 的服务。SSL 到期提醒对我这种 Let’s Encrypt 证书一堆的人来说很实在。
Docker 容器状态。如果你 NAS 上跑的是 Docker，Checkmate 可以直接读取容器运行状态，某个容器退出或反复重启时会触发告警。
基础设施指标。CPU、内存、磁盘、温度这些需要额外装一个 Capture agent。它是一个 Go 写的轻量二进制，几 MB 大小，跑在被监控主机上，把数据推给 Checkmate。对我来说，这个功能属于“锦上添花”，先把 uptime 监控搭起来更紧迫。
页面速度和 JSON 查询。页面速度适合盯博客首页加载时间；JSON 查询则可以监控 API 返回的某个字段是否异常，有点进阶，暂时用不上。
为什么选它而不是 Uptime Kuma
Uptime Kuma 我也用过，简单够用，社区生态好。但 Checkmate 有几个点更对我胃口：
界面和状态页更现代。Uptime Kuma 的功能没问题，UI 多少有点“工程味”。Checkmate 用 React + MUI 做的面板，对外状态页有四种主题，如果你需要把状态页挂出来给别人看，它看起来更像一个正经产品。
监控生命周期更严谨。它不是“一次失败就炸你通知”，而是有 initializing、up、down、breached 几个状态，可以设置连续失败几次才告警。这个功能对 Wi-Fi 偶发抖动、容器重启瞬间这种误报场景很关键。
通知渠道足够全。邮件、Telegram、Slack、Discord、PagerDuty、Twilio SMS、Pushover、Microsoft Teams、Matrix、Rocket.Chat、Webhook 都支持。我习惯用 Telegram bot 推消息，一分钟配好。
多语言支持。包括简体中文，家里其他人偶尔看面板也问题不大。
怎么部署
Checkmate 从 v3.10.0 开始换成了单容器镜像，部署比过去四镜像组合简单很多。以 Docker Compose 为例，最简路径是：
mkdir checkmate && cd checkmate
curl -O https://raw.githubusercontent.com/bluewave-labs/Checkmate/develop/docker-compose.yaml
# 按说明改环境变量，尤其是 DB_CONNECTION_STRING
vim .env
docker compose up -d
它依赖 MongoDB 作为数据库，Redis 用于任务调度。官方 compose 文件里已经带了，不需要自己额外搭。对外默认端口是 52345，我一般用反向代理给它加 TLS。
装好以后第一件事是注册管理员账号，然后依次添加 monitor。每个 monitor 填写地址、类型、检查频率、失败阈值、告警通道即可。对于 NAS 上跑的关键服务，我建议：
- HTTP 服务：30 秒检查一次，连续 2 次失败再告警；
- TCP 端口：60 秒一次，连续 3 次失败告警；
- SSL 证书：每天检查一次，到期前 14 天提醒。
Capture agent 的安装更轻量，下载对应平台的二进制，配好 Checkmate 的 endpoint 和 token，后台跑着就行。我暂时只在一台设备上试了，后续可能会把它铺开。
几个实际要注意的坑
1. 升级路径要跟着镜像名走。v3.10.0 之前的 checkmate-client、checkmate-backend 这些旧镜像已经停止更新，必须切到 ghcr.io/bluewave-labs/checkmate 单镜像标签。旧 compose 直接拉 latest 会停在旧版本。
2. MongoDB 数据要持久化。默认 compose 已经挂了 volume，但如果你自己改目录或者装到 sqlite 党的大脑里，记得确认 volume 路径。监控历史丢起来很痛苦。
3. 公网暴露状态页要收紧 CSP。v3.10.0 修复了状态页自定义 CSS 注入和 CSP 配置的问题。如果你要把状态页挂到公网，建议升到最新版，避免自定义样式被利用。
4. Capture agent 和被监控主机要能互相访问。它不是被动采集，而是 agent 主动把数据 POST 到 Checkmate。跨 VLAN 或者代理环境要注意网络可达性。
5. AGPL-3.0 协议。自用没问题，但如果你要基于它二次开发并对外提供服务，得遵守 AGPL 的源码公开要求。对普通 NAS 用户没有影响。
适合谁
如果你和我一样，NAS 上跑了一堆服务，又懒得每天手动检查，Checkmate 属于那种半天就能搭完、之后省很多心的工具。它比纯 ping 工具功能全，又比 Prometheus + Grafana 那套轻得多，个人 homelab 场景刚刚好。
但如果你只有一台设备、两个服务，Uptime Kuma 可能更省事。工具选型最终还是看规模，没必要为了上监控而上监控。对我来说，Checkmate 已经够进常驻栈了。