Checkmate 自托管监控平台实战指南Docker Compose 部署、配置项与监控生命周期原理【免费下载链接】CheckmateCheckmate is an open-source, self-hosted tool designed to track and monitor server hardware, uptime, response times, and incidents in real-time with beautiful visualizations. Dont be shy, join here: https://discord.com/invite/NAb6H3UTjK :)项目地址: https://gitcode.com/GitHub_Trending/checkm/CheckmateCheckmate 是一个完全开源、可自托管的服务器可用性与基础设施监控平台仓库同时包含前端与后端实现能够以实时可视化跟踪服务器硬件状态、可用性、响应时间与故障事件。本文以项目德语版 README 为骨架结合仓库源码与配置逐一展开从快速体验 Demo、功能特性全景到 Docker Compose 与 Kubernetes 部署、环境变量详解再到监控生命周期背后的状态机实现帮助读者完整掌握这套自托管监控方案。项目概览Checkmate 能做什么Checkmate 定位为开源可用性与基础设施监控应用An open source uptime and infrastructure monitoring application由 bluewave-labs 社区维护仓库内同时包含前端client/与后端server/两大部分。它定期检查服务器或网站是否可达、运行是否健康并针对被监控服务的可用性、停机时间与响应时间提供实时告警与报告。值得强调的是它的自托管属性整个应用可以部署在自己的服务器或家用设备例如 Raspberry Pi 4/5上数据完全掌握在自己手中。除了主应用Checkmate 还有一个名为Capture的配套 Agent用于从远程服务器采集数据。Capture 并非运行 Checkmate 的必需组件但启用后可以提供服务器的 CPU、内存、磁盘与温度等额外信息。它基于 Go 编写可运行在 Linux、Windows、macOS、Raspberry Pi 以及任何能运行 Go 的设备上其仓库内附带独立的安装说明。从仓库结构看前端基于 React 与 MUI 构建client/src后端基于 Node.js 与 MongoDBserver/src检查逻辑、调度器与告警管线均集中在 server/src/worker 与 server/src/service 目录。快速体验在线 Demo无需安装即可体验最新构建版本访问 Checkmate 官方演示站点使用演示账号demouserdemo.com/ 密码Demouser1!登录。由于演示服务器会不定期更新重建如果暂时无法访问可以在项目的 Discussions 频道反馈。功能特性全景根据德语版 README 并结合仓库源码 server/src/domain/monitors/monitor.type.ts 中的MonitorTypes定义Checkmate 的能力可以归纳为以下几大类多样的监控类型德语 README 重点列举了 Uptime、Docker、Ping、SSL、Port、Game-Server 等选项而源码中MonitorTypes [http, ping, pagespeed, hardware, docker, port, game, grpc, websocket, dns, unknown]给出了更完整的清单——即 HTTP、Ping、PageSpeed、硬件hardware、Docker、端口、游戏服务器、gRPC、WebSocket、DNS 共 10 类监控器。其中 HTTP 监控支持 SSL 证书到期检测。Page Speed 监控支持desktop与mobile两种策略PageSpeedStrategies并采集性能、可访问性、最佳实践、SEO 四类评分见 server/src/domain/checks/check.type.ts 中的CheckAudits与 Lighthouse 审计字段。基础设施监控内存、磁盘使用、CPU 性能、网络等硬件指标需要配合 Capture Agent。支持选择性磁盘监控mountpoint 选择对应Monitor上的selectedDisks: string[]字段。事件与状态页故障事件一目了然状态页Status Pages支持主题切换。源码 server/src/domain/status-pages/status-page.type.ts 定义了StatusPageThemes [refined, modern, bold, editorial, minimal]即目前共 5 套主题德语版 README 写作 4 套以源码为准支持auto/light/dark模式与自定义 CSS并可通过STATUS_PAGE_THEMES_ENABLED环境变量关闭主题切换。丰富的通知渠道邮件、Webhooks、Discord、Slack、PagerDuty、Matrix、Microsoft Teams、Telegram、Pushover、TwilioSMS。实际仓库中 server/src/domain/notifications/providers 目录下实现了 13 个提供者discord、email、matrix、ntfy、pagerduty、pushover、rocketChat、signalgrid、slack、teams、telegram、twilio、webhook——即还额外支持 ntfy、Rocket.Chat 与 SignalGrid。计划维护Scheduled maintenance支持为维护窗口创建排期期间监控状态切换为maintenance。JSON 查询监控支持jsonPath、expectedValue、matchMethodequal/include/regex等高级匹配能力。多语言支持德语 README 列出的语言为阿拉伯语、简体中文、繁体中文台湾、捷克语、英语、芬兰语、法语、德语、日语、葡萄牙语巴西、俄语、西班牙语、泰语、土耳其语、乌克兰语、越南语而仓库 client/src/locales 目录下实际包含 19 份语言文件含加泰罗尼亚语、意大利语、波兰语说明多语言矩阵还在持续扩充。安装部署前置条件安装 Docker安装 GitDocker Compose 快速启动推荐方式当前仓库采用all-in-one架构应用被封装进单一镜像ghcr.io/bluewave-labs/checkmateMongoDB 独立运行不内嵌在应用镜像中。参考的 docker/docker-compose.yaml 同时启动 Checkmate 应用与 MongoDB 两个服务。该 Compose 文件的核心结构如下services: checkmate: image: ghcr.io/bluewave-labs/checkmate:latest pull_policy: always restart: always ports: - 52345:52345 environment: - DB_CONNECTION_STRINGmongodb://mongodb:27017/uptime_db - CLIENT_HOST${CLIENT_HOST:-http://localhost:52345} - JWT_SECRET${JWT_SECRET:?set JWT_SECRET in your environment} - ENCRYPTION_KEY${ENCRYPTION_KEY:-} stop_grace_period: 60s healthcheck: test: [CMD, node, -e, require(http).get(http://localhost:52346/livez,rprocess.exit(r.statusCode200?0:1)).on(error,()process.exit(1))] interval: 15s timeout: 3s start_period: 60s start_interval: 2s retries: 3 depends_on: mongodb: condition: service_healthy mongodb: image: mongo:8.0 restart: always command: [mongod, --quiet, --bind_ip_all] volumes: - mongo-data:/data/db volumes: mongo-data:快速启动的推荐命令如下curl -O https://raw.githubusercontent.com/bluewave-labs/checkmate/master/docker/docker-compose.yaml JWT_SECRET$(openssl rand -hex 32) docker compose up -d然后访问http://localhost:52345。如果应用通过其他源域名或局域网 IP访问需要相应设置CLIENT_HOST。如需自行构建镜像可在仓库检出目录执行docker build -f docker/Dockerfile -t checkmate .如果需要 HTTPS可在 52345 端口前置任意反向代理Caddy、Traefik、nginx。环境变量配置详解镜像完全通过服务端容器上的环境变量配置。这一点在 server/src/config/envValidation.ts 中有完整的 Zod 校验实现——启动时若缺少必填变量或格式非法进程会打印错误并退出process.exit(1)。下表汇总了核心变量变量必填说明DB_CONNECTION_STRING是MongoDB 连接串例如mongodb://mongodb:27017/uptime_dbJWT_SECRET是用于签署认证令牌的密钥可用openssl rand -hex 32生成CLIENT_HOST是用户访问应用的 URL如https://checkmate.example.com用于 CORS 以及通知/邮件中的链接ENCRYPTION_KEY否加密存储的 Docker TLS 客户端私钥用openssl rand -base64 32生成。支持逗号分隔多密钥第一个密钥负责加密所有密钥均可解密。API 与所有 worker 必须使用相同配置。滚动轮换时先全量部署OLD_KEY,NEW_KEY再全量部署NEW_KEY,OLD_KEY等待 worker 重加密全部数据行后移除OLD_KEYPORT否API 与 Web 客户端监听端口默认52345HEALTH_PORT否运行作业 worker 的进程暴露/livez、/readyz、/metrics的端口默认52346NODE_ENV否development/production/test默认development。development会禁用通用 API 限流正式部署请设置为productionLOG_LEVEL否服务端日志级别error/warn/info/debug默认debugTOKEN_TTL否签发的认证令牌有效期如12h或7d默认99dQUEUE_MODE否primary默认运行 API、Web 客户端与作业调度器worker仅运行作业处理 worker不提供 APIQUEUE_PRIMARY_PROCESSES否true默认或false。控制primary节点是否也亲自处理监控作业当由独立worker节点承担全部检查时设为false。worker模式下忽略STATUS_PAGE_THEMES_ENABLED否true默认或false。为false时状态页忽略主题设置始终渲染默认主题以上默认值与校验逻辑均可在 server/src/config/envValidation.ts 中逐一核对例如PORT默认52345、HEALTH_PORT默认52346、TOKEN_TTL默认99d。Web 客户端默认不需要额外配置它会调用其所在源的/api/v1。当默认不适用时例如 API 与其他源不同服务端会在运行时通过以下可选变量把覆盖值渲染给客户端变量说明CLIENT_CONFIG_API_BASE_URL客户端调用 API 的完整基础 URL例如https://api.example.com/api/v1默认同源/api/v1CLIENT_CONFIG_CLIENT_HOST客户端构建绝对链接邀请、状态页时使用的源默认浏览器当前源CLIENT_CONFIG_LOG_LEVEL浏览器控制台日志级别error/warn/info/debug默认error升级注意旧的UPTIME_APP_*变量UPTIME_APP_API_BASE_URL、UPTIME_APP_CLIENT_HOST、UPTIME_APP_LOG_LEVEL已不再读取。多数场景无需替换——同源默认即可覆盖若曾把客户端指向其他源请改用上表的CLIENT_CONFIG_*变量。旧的checkmate-client、checkmate-backend、checkmate-mongo与checkmate-backend-mono-multiarch镜像已停止更新请切换到ghcr.io/bluewave-labs/checkmate保留现有 MongoDB 服务与数据卷。校验器也会对残留的UPTIME_APP_*变量打印告警日志见validateEnv中legacyClientVars的处理。Kubernetes / Helm 部署德语版 README 提供了指向 Helm chart 的安装入口。仓库内 charts/helm/checkmate/INSTALLATION.md 是一份完整的 Kubernetes 部署指南要点包括前置条件一个可用的 Kubernetes 集群、安装并配置好 Helm CLI、配置好kubectl。部署步骤克隆仓库并进入charts/helm/checkmate编辑values.yaml修改client.ingress.host与api.ingress.host、api.protocol替换secrets段中所有change_me占位值JWT_SECRET、邮件凭据、API Key 等然后执行helm install checkmate ./charts/helm/checkmate验证kubectl get pods与kubectl get svc全部 Pod 处于Running与Ready后即可通过配置的 ingress host 访问。升级注意该 chart 已从旧的server.*值块迁移到api.*旧值仍兼容但会覆盖同名新值捆绑的 Redis 已被移除各层的镜像 tag 默认跟随 chart 的appVersion推荐固定版本号而非latest以保证可回滚。扩展能力可将worker.enabled设为true拆分出独立 worker 层配合 KEDA 基于 MongoDB 中积压作业数进行水平扩缩容backlogPerReplica、minReplicaCount、maxReplicaCount等参数并支持 cert-manager 自动签发 Lets Encrypt 证书。其他一键部署方式德语版 README 还提到可以利用 Coolify、Elestio、PikaPods、Sive Host、Cloudzy 等托管平台快速拉起 Checkmate 实例注意其中部分平台可能仍基于较旧的镜像架构部署前请核实版本差异。使用 Capture 监控基础设施如需监控服务器基础设施CPU、内存、磁盘、温度等需要额外部署 Capture Agent。Capture 独立于 Checkmate 主仓库其自身仓库中附有安装说明。启动后即可在 Checkmate 中创建hardware类型监控器并借助cpuAlertThreshold、memoryAlertThreshold、diskAlertThreshold、tempAlertThreshold等字段见 server/src/domain/monitors/monitor.type.ts设置阈值告警。使用自定义 CA 监控内网 HTTPS 端点如果需要监控使用私有证书颁发机构如 Smallstep签发证书的内部 HTTPS 端点可以参考仓库内的自定义 CA 信任指南其中提供了对应的 Docker 配置方案。更多文档资料位于仓库的 docs 目录。性能表现据项目 README 声明得益于大量优化Checkmate 的内存占用极低仅需很少的 RAM 与 CPU。其给出的示例是一台每分钟检查 323 台服务器的 Node.js 实例配合同一台服务器上约 398 MB 的 MongoDB以及德语 README 提到的 15 MB Redis即可支撑同等数量的监控目标。同时项目声明已使用 1000 活跃监控器进行过压力测试未出现明显问题或性能瓶颈。这些数据来自项目官方文档的说明具体数值会随版本与负载环境变化生产部署时应以实测为准。监控生命周期与状态机原理德语版 README 用 6 步概括了监控器的完整生命周期这一流程在源码中可以得到精确印证执行检查监控器执行一次检查HTTP / Ping / Port或经 Capture Agent 的硬件检查。后端对应 server/src/service/network 目录下的一组 ProviderHttpProvider、PingProvider、PortProvider、HardwareProvider、DockerProvider、PageSpeedProvider、GameProvider、GrpcProvider、WebSocketProvider、DNSProvider等由 server/src/service/networkService.ts 统一编排。存储结果检查结果成功/失败 响应时间被持久化。数据结构见 server/src/domain/checks/check.type.ts 中的Check接口——不仅包含status、responseTime、statusCode、message硬件监控还带有cpu、memory、disk、host、net等详细字段Docker 监控则带有containers与containerSummary。阈值评估近期检查结果会与监控器配置的状态变更阈值进行比对。每个Monitor带有statusWindow: boolean[]、statusWindowSize、statusWindowThreshold等字段server/src/domain/monitors/monitor.type.ts用于判定状态是否应翻转。状态变更当阈值被满足且当前状态与前一状态不同时监控器状态发生迁移。合法的状态集合在源码中定义为MonitorStatuses [up, down, paused, initializing, maintenance, breached]——即初始化的initializing、在线up、离线down、阈值超限breached、维护中maintenance与暂停paused。事件开闭状态变更时根据当前状态创建或关闭一个事件Incident。server/src/worker/worker.monitor-status-policy.ts 中的MonitorStatusPolicy.evaluate精确实现了这一决策逻辑监控器进入down时创建事件并发送通知原因status_down进入breached硬件阈值超限时同样创建事件原因threshold_breach当从down/breached恢复为up时则解析事件并发送恢复通知。触发通知根据配置向各通知渠道邮件、Webhook、Discord、Slack、PagerDuty 等推送告警。通知消息的组装见 server/src/domain/notifications/notification.message-builder.ts实际投递由 server/src/domain/notifications/providers 下各 Provider 完成调度与投递链路由 server/src/worker 目录下的 producer、pipeline、evaluator 与 reactor 组件协作实现。这套检查 → 存储 → 阈值评估 → 状态迁移 → 事件管理 → 通知的流水线正是 Checkmate 能够同时支撑可用性监控 硬件监控 事件管理 通知分发这一整套能力的关键架构。技术栈前端React、MUIReact 组件库、Recharts图表库源码位于 client/src其中图表组件集中在 client/src/Components/common/charts。后端Node.js、MongoDB源码位于 server/src监控执行与 worker 调度见 server/src/worker。基础设施Docker 镜像与参考 Compose 文件见 dockerKubernetes/Helm 部署文件见 charts/helm/checkmate。此外还集成了大量其他开源组件。参与贡献项目维护团队会为个人与企业的基础设施监控提供支持并欢迎社区以多种方式参与阅读贡献指南、从good-first-issue标签入手、发现 Bug 时提交 Issue、通过 Pull Request 贡献新功能或修复。若想深入了解代码架构可以结合仓库内的 CLAUDE.md、CONTRIBUTING.md 与 docs 目录下的技术文档如 coding-conventions.md继续深入。总而言之Checkmate 的定位非常清晰一套开源、自托管、可视化的可用性 基础设施监控平台。通过本文介绍的 Docker Compose 或 Helm 部署路径配合 Capture Agent你可以在自己的设备上快速搭建出覆盖 HTTP/Ping/Docker/硬件等场景、具备事件管理与多渠道通知能力的完整监控体系。【免费下载链接】CheckmateCheckmate is an open-source, self-hosted tool designed to track and monitor server hardware, uptime, response times, and incidents in real-time with beautiful visualizations. Dont be shy, join here: https://discord.com/invite/NAb6H3UTjK :)项目地址: https://gitcode.com/GitHub_Trending/checkm/Checkmate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Checkmate 自托管监控平台实战指南：Docker Compose 部署、配置项与监控生命周期原理
Checkmate 自托管监控平台实战指南Docker Compose 部署、配置项与监控生命周期原理【免费下载链接】CheckmateCheckmate is an open-source, self-hosted tool designed to track and monitor server hardware, uptime, response times, and incidents in real-time with beautiful visualizations. Dont be shy, join here: https://discord.com/invite/NAb6H3UTjK :)项目地址: https://gitcode.com/GitHub_Trending/checkm/CheckmateCheckmate 是一个完全开源、可自托管的服务器可用性与基础设施监控平台仓库同时包含前端与后端实现能够以实时可视化跟踪服务器硬件状态、可用性、响应时间与故障事件。本文以项目德语版 README 为骨架结合仓库源码与配置逐一展开从快速体验 Demo、功能特性全景到 Docker Compose 与 Kubernetes 部署、环境变量详解再到监控生命周期背后的状态机实现帮助读者完整掌握这套自托管监控方案。项目概览Checkmate 能做什么Checkmate 定位为开源可用性与基础设施监控应用An open source uptime and infrastructure monitoring application由 bluewave-labs 社区维护仓库内同时包含前端client/与后端server/两大部分。它定期检查服务器或网站是否可达、运行是否健康并针对被监控服务的可用性、停机时间与响应时间提供实时告警与报告。值得强调的是它的自托管属性整个应用可以部署在自己的服务器或家用设备例如 Raspberry Pi 4/5上数据完全掌握在自己手中。除了主应用Checkmate 还有一个名为Capture的配套 Agent用于从远程服务器采集数据。Capture 并非运行 Checkmate 的必需组件但启用后可以提供服务器的 CPU、内存、磁盘与温度等额外信息。它基于 Go 编写可运行在 Linux、Windows、macOS、Raspberry Pi 以及任何能运行 Go 的设备上其仓库内附带独立的安装说明。从仓库结构看前端基于 React 与 MUI 构建client/src后端基于 Node.js 与 MongoDBserver/src检查逻辑、调度器与告警管线均集中在 server/src/worker 与 server/src/service 目录。快速体验在线 Demo无需安装即可体验最新构建版本访问 Checkmate 官方演示站点使用演示账号demouserdemo.com/ 密码Demouser1!登录。由于演示服务器会不定期更新重建如果暂时无法访问可以在项目的 Discussions 频道反馈。功能特性全景根据德语版 README 并结合仓库源码 server/src/domain/monitors/monitor.type.ts 中的MonitorTypes定义Checkmate 的能力可以归纳为以下几大类多样的监控类型德语 README 重点列举了 Uptime、Docker、Ping、SSL、Port、Game-Server 等选项而源码中MonitorTypes [http, ping, pagespeed, hardware, docker, port, game, grpc, websocket, dns, unknown]给出了更完整的清单——即 HTTP、Ping、PageSpeed、硬件hardware、Docker、端口、游戏服务器、gRPC、WebSocket、DNS 共 10 类监控器。其中 HTTP 监控支持 SSL 证书到期检测。Page Speed 监控支持desktop与mobile两种策略PageSpeedStrategies并采集性能、可访问性、最佳实践、SEO 四类评分见 server/src/domain/checks/check.type.ts 中的CheckAudits与 Lighthouse 审计字段。基础设施监控内存、磁盘使用、CPU 性能、网络等硬件指标需要配合 Capture Agent。支持选择性磁盘监控mountpoint 选择对应Monitor上的selectedDisks: string[]字段。事件与状态页故障事件一目了然状态页Status Pages支持主题切换。源码 server/src/domain/status-pages/status-page.type.ts 定义了StatusPageThemes [refined, modern, bold, editorial, minimal]即目前共 5 套主题德语版 README 写作 4 套以源码为准支持auto/light/dark模式与自定义 CSS并可通过STATUS_PAGE_THEMES_ENABLED环境变量关闭主题切换。丰富的通知渠道邮件、Webhooks、Discord、Slack、PagerDuty、Matrix、Microsoft Teams、Telegram、Pushover、TwilioSMS。实际仓库中 server/src/domain/notifications/providers 目录下实现了 13 个提供者discord、email、matrix、ntfy、pagerduty、pushover、rocketChat、signalgrid、slack、teams、telegram、twilio、webhook——即还额外支持 ntfy、Rocket.Chat 与 SignalGrid。计划维护Scheduled maintenance支持为维护窗口创建排期期间监控状态切换为maintenance。JSON 查询监控支持jsonPath、expectedValue、matchMethodequal/include/regex等高级匹配能力。多语言支持德语 README 列出的语言为阿拉伯语、简体中文、繁体中文台湾、捷克语、英语、芬兰语、法语、德语、日语、葡萄牙语巴西、俄语、西班牙语、泰语、土耳其语、乌克兰语、越南语而仓库 client/src/locales 目录下实际包含 19 份语言文件含加泰罗尼亚语、意大利语、波兰语说明多语言矩阵还在持续扩充。安装部署前置条件安装 Docker安装 GitDocker Compose 快速启动推荐方式当前仓库采用all-in-one架构应用被封装进单一镜像ghcr.io/bluewave-labs/checkmateMongoDB 独立运行不内嵌在应用镜像中。参考的 docker/docker-compose.yaml 同时启动 Checkmate 应用与 MongoDB 两个服务。该 Compose 文件的核心结构如下services: checkmate: image: ghcr.io/bluewave-labs/checkmate:latest pull_policy: always restart: always ports: - 52345:52345 environment: - DB_CONNECTION_STRINGmongodb://mongodb:27017/uptime_db - CLIENT_HOST${CLIENT_HOST:-http://localhost:52345} - JWT_SECRET${JWT_SECRET:?set JWT_SECRET in your environment} - ENCRYPTION_KEY${ENCRYPTION_KEY:-} stop_grace_period: 60s healthcheck: test: [CMD, node, -e, require(http).get(http://localhost:52346/livez,rprocess.exit(r.statusCode200?0:1)).on(error,()process.exit(1))] interval: 15s timeout: 3s start_period: 60s start_interval: 2s retries: 3 depends_on: mongodb: condition: service_healthy mongodb: image: mongo:8.0 restart: always command: [mongod, --quiet, --bind_ip_all] volumes: - mongo-data:/data/db volumes: mongo-data:快速启动的推荐命令如下curl -O https://raw.githubusercontent.com/bluewave-labs/checkmate/master/docker/docker-compose.yaml JWT_SECRET$(openssl rand -hex 32) docker compose up -d然后访问http://localhost:52345。如果应用通过其他源域名或局域网 IP访问需要相应设置CLIENT_HOST。如需自行构建镜像可在仓库检出目录执行docker build -f docker/Dockerfile -t checkmate .如果需要 HTTPS可在 52345 端口前置任意反向代理Caddy、Traefik、nginx。环境变量配置详解镜像完全通过服务端容器上的环境变量配置。这一点在 server/src/config/envValidation.ts 中有完整的 Zod 校验实现——启动时若缺少必填变量或格式非法进程会打印错误并退出process.exit(1)。下表汇总了核心变量变量必填说明DB_CONNECTION_STRING是MongoDB 连接串例如mongodb://mongodb:27017/uptime_dbJWT_SECRET是用于签署认证令牌的密钥可用openssl rand -hex 32生成CLIENT_HOST是用户访问应用的 URL如https://checkmate.example.com用于 CORS 以及通知/邮件中的链接ENCRYPTION_KEY否加密存储的 Docker TLS 客户端私钥用openssl rand -base64 32生成。支持逗号分隔多密钥第一个密钥负责加密所有密钥均可解密。API 与所有 worker 必须使用相同配置。滚动轮换时先全量部署OLD_KEY,NEW_KEY再全量部署NEW_KEY,OLD_KEY等待 worker 重加密全部数据行后移除OLD_KEYPORT否API 与 Web 客户端监听端口默认52345HEALTH_PORT否运行作业 worker 的进程暴露/livez、/readyz、/metrics的端口默认52346NODE_ENV否development/production/test默认development。development会禁用通用 API 限流正式部署请设置为productionLOG_LEVEL否服务端日志级别error/warn/info/debug默认debugTOKEN_TTL否签发的认证令牌有效期如12h或7d默认99dQUEUE_MODE否primary默认运行 API、Web 客户端与作业调度器worker仅运行作业处理 worker不提供 APIQUEUE_PRIMARY_PROCESSES否true默认或false。控制primary节点是否也亲自处理监控作业当由独立worker节点承担全部检查时设为false。worker模式下忽略STATUS_PAGE_THEMES_ENABLED否true默认或false。为false时状态页忽略主题设置始终渲染默认主题以上默认值与校验逻辑均可在 server/src/config/envValidation.ts 中逐一核对例如PORT默认52345、HEALTH_PORT默认52346、TOKEN_TTL默认99d。Web 客户端默认不需要额外配置它会调用其所在源的/api/v1。当默认不适用时例如 API 与其他源不同服务端会在运行时通过以下可选变量把覆盖值渲染给客户端变量说明CLIENT_CONFIG_API_BASE_URL客户端调用 API 的完整基础 URL例如https://api.example.com/api/v1默认同源/api/v1CLIENT_CONFIG_CLIENT_HOST客户端构建绝对链接邀请、状态页时使用的源默认浏览器当前源CLIENT_CONFIG_LOG_LEVEL浏览器控制台日志级别error/warn/info/debug默认error升级注意旧的UPTIME_APP_*变量UPTIME_APP_API_BASE_URL、UPTIME_APP_CLIENT_HOST、UPTIME_APP_LOG_LEVEL已不再读取。多数场景无需替换——同源默认即可覆盖若曾把客户端指向其他源请改用上表的CLIENT_CONFIG_*变量。旧的checkmate-client、checkmate-backend、checkmate-mongo与checkmate-backend-mono-multiarch镜像已停止更新请切换到ghcr.io/bluewave-labs/checkmate保留现有 MongoDB 服务与数据卷。校验器也会对残留的UPTIME_APP_*变量打印告警日志见validateEnv中legacyClientVars的处理。Kubernetes / Helm 部署德语版 README 提供了指向 Helm chart 的安装入口。仓库内 charts/helm/checkmate/INSTALLATION.md 是一份完整的 Kubernetes 部署指南要点包括前置条件一个可用的 Kubernetes 集群、安装并配置好 Helm CLI、配置好kubectl。部署步骤克隆仓库并进入charts/helm/checkmate编辑values.yaml修改client.ingress.host与api.ingress.host、api.protocol替换secrets段中所有change_me占位值JWT_SECRET、邮件凭据、API Key 等然后执行helm install checkmate ./charts/helm/checkmate验证kubectl get pods与kubectl get svc全部 Pod 处于Running与Ready后即可通过配置的 ingress host 访问。升级注意该 chart 已从旧的server.*值块迁移到api.*旧值仍兼容但会覆盖同名新值捆绑的 Redis 已被移除各层的镜像 tag 默认跟随 chart 的appVersion推荐固定版本号而非latest以保证可回滚。扩展能力可将worker.enabled设为true拆分出独立 worker 层配合 KEDA 基于 MongoDB 中积压作业数进行水平扩缩容backlogPerReplica、minReplicaCount、maxReplicaCount等参数并支持 cert-manager 自动签发 Lets Encrypt 证书。其他一键部署方式德语版 README 还提到可以利用 Coolify、Elestio、PikaPods、Sive Host、Cloudzy 等托管平台快速拉起 Checkmate 实例注意其中部分平台可能仍基于较旧的镜像架构部署前请核实版本差异。使用 Capture 监控基础设施如需监控服务器基础设施CPU、内存、磁盘、温度等需要额外部署 Capture Agent。Capture 独立于 Checkmate 主仓库其自身仓库中附有安装说明。启动后即可在 Checkmate 中创建hardware类型监控器并借助cpuAlertThreshold、memoryAlertThreshold、diskAlertThreshold、tempAlertThreshold等字段见 server/src/domain/monitors/monitor.type.ts设置阈值告警。使用自定义 CA 监控内网 HTTPS 端点如果需要监控使用私有证书颁发机构如 Smallstep签发证书的内部 HTTPS 端点可以参考仓库内的自定义 CA 信任指南其中提供了对应的 Docker 配置方案。更多文档资料位于仓库的 docs 目录。性能表现据项目 README 声明得益于大量优化Checkmate 的内存占用极低仅需很少的 RAM 与 CPU。其给出的示例是一台每分钟检查 323 台服务器的 Node.js 实例配合同一台服务器上约 398 MB 的 MongoDB以及德语 README 提到的 15 MB Redis即可支撑同等数量的监控目标。同时项目声明已使用 1000 活跃监控器进行过压力测试未出现明显问题或性能瓶颈。这些数据来自项目官方文档的说明具体数值会随版本与负载环境变化生产部署时应以实测为准。监控生命周期与状态机原理德语版 README 用 6 步概括了监控器的完整生命周期这一流程在源码中可以得到精确印证执行检查监控器执行一次检查HTTP / Ping / Port或经 Capture Agent 的硬件检查。后端对应 server/src/service/network 目录下的一组 ProviderHttpProvider、PingProvider、PortProvider、HardwareProvider、DockerProvider、PageSpeedProvider、GameProvider、GrpcProvider、WebSocketProvider、DNSProvider等由 server/src/service/networkService.ts 统一编排。存储结果检查结果成功/失败 响应时间被持久化。数据结构见 server/src/domain/checks/check.type.ts 中的Check接口——不仅包含status、responseTime、statusCode、message硬件监控还带有cpu、memory、disk、host、net等详细字段Docker 监控则带有containers与containerSummary。阈值评估近期检查结果会与监控器配置的状态变更阈值进行比对。每个Monitor带有statusWindow: boolean[]、statusWindowSize、statusWindowThreshold等字段server/src/domain/monitors/monitor.type.ts用于判定状态是否应翻转。状态变更当阈值被满足且当前状态与前一状态不同时监控器状态发生迁移。合法的状态集合在源码中定义为MonitorStatuses [up, down, paused, initializing, maintenance, breached]——即初始化的initializing、在线up、离线down、阈值超限breached、维护中maintenance与暂停paused。事件开闭状态变更时根据当前状态创建或关闭一个事件Incident。server/src/worker/worker.monitor-status-policy.ts 中的MonitorStatusPolicy.evaluate精确实现了这一决策逻辑监控器进入down时创建事件并发送通知原因status_down进入breached硬件阈值超限时同样创建事件原因threshold_breach当从down/breached恢复为up时则解析事件并发送恢复通知。触发通知根据配置向各通知渠道邮件、Webhook、Discord、Slack、PagerDuty 等推送告警。通知消息的组装见 server/src/domain/notifications/notification.message-builder.ts实际投递由 server/src/domain/notifications/providers 下各 Provider 完成调度与投递链路由 server/src/worker 目录下的 producer、pipeline、evaluator 与 reactor 组件协作实现。这套检查 → 存储 → 阈值评估 → 状态迁移 → 事件管理 → 通知的流水线正是 Checkmate 能够同时支撑可用性监控 硬件监控 事件管理 通知分发这一整套能力的关键架构。技术栈前端React、MUIReact 组件库、Recharts图表库源码位于 client/src其中图表组件集中在 client/src/Components/common/charts。后端Node.js、MongoDB源码位于 server/src监控执行与 worker 调度见 server/src/worker。基础设施Docker 镜像与参考 Compose 文件见 dockerKubernetes/Helm 部署文件见 charts/helm/checkmate。此外还集成了大量其他开源组件。参与贡献项目维护团队会为个人与企业的基础设施监控提供支持并欢迎社区以多种方式参与阅读贡献指南、从good-first-issue标签入手、发现 Bug 时提交 Issue、通过 Pull Request 贡献新功能或修复。若想深入了解代码架构可以结合仓库内的 CLAUDE.md、CONTRIBUTING.md 与 docs 目录下的技术文档如 coding-conventions.md继续深入。总而言之Checkmate 的定位非常清晰一套开源、自托管、可视化的可用性 基础设施监控平台。通过本文介绍的 Docker Compose 或 Helm 部署路径配合 Capture Agent你可以在自己的设备上快速搭建出覆盖 HTTP/Ping/Docker/硬件等场景、具备事件管理与多渠道通知能力的完整监控体系。【免费下载链接】CheckmateCheckmate is an open-source, self-hosted tool designed to track and monitor server hardware, uptime, response times, and incidents in real-time with beautiful visualizations. Dont be shy, join here: https://discord.com/invite/NAb6H3UTjK :)项目地址: https://gitcode.com/GitHub_Trending/checkm/Checkmate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考