监控系统是 Uptime Kuma 的核心功能,负责检查各种服务的状态并生成心跳。它为服务监控、状态跟踪、通知触发和正常运行时间计算提供了基础。本页面记录了监控系统的架构、组件和功能。
有关处理警报发送的通知系统的更多信息,请参阅 通知系统。
监控系统围绕 Monitor 类构建,该类管理不同类型的监控器及其生命周期。每个监控器会根据其配置定期检查外部服务或资源,并生成反映状态的心跳。
来源
Monitor 类是处理监控过程的核心组件。它被定义为 BeanModel(使用 RedBean ORM),包含管理监控配置、执行检查和处理心跳的方法。
toJSON() - 为前端返回监控数据toPublicJSON() - 为公共状态页面返回非敏感数据start(io) - 使用心跳间隔启动监控过程check() - 根据监控类型执行实际检查getTags() - 获取与监控器关联的标签来源
Uptime Kuma 使用数字常量来表示监控状态
| 常量 | 值 | 描述 |
|---|---|---|
| DOWN | 0 | 服务已关闭或无法访问 |
| UP | 1 | 服务运行正常 |
| 待处理 (PENDING) | 2 | 初始状态或等待首次检查 |
| MAINTENANCE | 3 | 处于计划维护模式 |
来源
Uptime Kuma 支持多种监控类型,用于检查不同的服务和协议。每种监控类型都有特定的配置选项和检查逻辑。
| 类别 | 监控类型 |
|---|---|
| 通用 | HTTP(s)、TCP 端口、Ping、SNMP、Keyword(关键词)、JSON Query(JSON 查询)、gRPC、DNS、Docker Container(Docker 容器)、Real Browser(Chrome) |
| 被动 | 推送 |
| 数据库 | MySQL/MariaDB、PostgreSQL、MongoDB、SQL Server、Redis |
| 消息传递 | MQTT、RabbitMQ、Kafka Producer(Kafka 生产者) |
| 游戏 | Steam Game Server(Steam 游戏服务器)、GameDig |
| 其他 | Radius、Tailscale Ping |
来源
每种监控类型都继承自基类 MonitorType,并实现其自身的检查逻辑。例如,SNMP 监控类型
来源
监控器的生命周期包括创建、启动/停止、检查和生成心跳。
来源
心跳是每次监控检查的记录。它们存储每次检查的状态、响应时间和任何相关消息。
当监控器检查服务时,它会创建一个心跳 bean,其中包含:
HeartbeatBar 组件通过显示代表过去心跳的彩色块系列来可视化监控器的历史状态。
来源
HTTP 监控类型是最常用的类型之一。其工作原理如下:
来源
监控系统使用多个数据库表来存储配置和结果。
| 表名 | 目的 |
|---|---|
| monitor | 存储监控器配置(类型、URL、间隔等) |
| heartbeat | 存储单个检查结果(状态、ping、消息) |
| monitor_tag | 将监控器与标签关联 |
| monitor_notification | 将监控器与通知提供程序关联 |
| monitor_tls_info | 为 HTTPS 监控器存储 TLS 证书信息 |
| maintenance | 存储监控器处于维护模式下的维护窗口 |
来源
监控系统包含多个前端组件,用于创建、显示和管理监控器。
来源
Uptime Kuma 的设计是可扩展的,允许开发者添加新的监控类型。
要创建新的监控类型:
server/monitor-types/ 中创建一个新的文件,该文件继承 MonitorType 类check(monitor, heartbeat, server) 方法SNMP 监控类型演示了如何实现新的监控类型
来源
在计划维护期间,监控器可以被置于维护模式。
此功能有助于在计划停机期间避免误报。
来源
监控器的状态在 UI 的各个部分都有显示
来源
监控系统是Uptime Kuma的核心,提供广泛服务和协议的灵活强大的监控能力。理解监控的创建、配置以及它们如何生成心跳,对于使用和扩展Uptime Kuma都至关重要。
该系统的模块化架构使得在保持核心功能一致性的同时,可以轻松添加新的监控类型。监控与通知的分离也允许对每个系统进行专注的开发和维护。