Uptime Kuma监控组：层级化管理实战
项目地址: https://gitcode.com/GitHub_Trending/up/uptime-kuma 痛点与解决方案
你是否面临以下监控管理困境？
- 数百个监控项杂乱无章，无法快速定位业务模块
- 团队成员权限交叉导致误操作风险
- 状态页展示信息与实际业务结构脱节
Uptime Kuma的监控组功能通过层级化设计，将彻底解决这些问题。本文将系统讲解从基础分组到高级嵌套的全流程实现，包含15个实战案例和7组对比表，帮助你构建企业级监控体系。
读完本文你将掌握：
- 监控组的CRUD核心操作
- 多层级嵌套的权限隔离方案
- 状态页与监控组的联动配置
- 大规模部署的性能优化技巧
核心概念与数据模型
监控组定义
监控组（Monitor Group）是Uptime Kuma中用于对监控项（Monitor）进行逻辑分组的核心功能，支持：
- 无限层级嵌套（父子关系）
- 自定义排序权重
- 独立的访问权限控制
- 批量操作与状态聚合
数据结构解析
class Group extends BeanModel {
async toPublicJSON(showTags = false, certExpiry = false) {
let monitorBeanList = await this.getMonitorList();
let monitorList = [];
for (let bean of monitorBeanList) {
monitorList.push(await bean.toPublicJSON(showTags, certExpiry));
}
return {
id: this.id,
name: this.name,
weight: this.weight,
monitorList,
};
}
async getMonitorList() {
return R.convertToBeans("monitor", await R.getAll(`
SELECT monitor.*, monitor_group.send_url, monitor_group.custom_url
FROM monitor, monitor_group
WHERE monitor.id = monitor_group.monitor_id
AND group_id = ?
ORDER BY monitor_group.weight
`, [this.id]));
}
}
关键属性说明：
| 属性名 | 类型 | 作用 | 约束 |
|---|---|---|---|
| id | INTEGER | 唯一标识 | 自增主键 |
| name | VARCHAR(255) | 组名称 | 非空，支持UTF-8 |
| parent_id | INTEGER | 父组ID | 顶级组为NULL |
| weight | INTEGER | 排序权重 | 数值越大越靠前 |
| is_public | BOOLEAN | 公开访问权限 | 影响状态页展示 |
| created_at | DATETIME | 创建时间 | 自动生成 |
| updated_at | DATETIME | 更新时间 | 自动更新 |
基础操作指南
创建监控组
通过管理界面创建基础监控组的3种方式：
-
快速创建
# API调用示例 curl -X POST http://localhost:3001/api/group \ -H "Content-Type: application/json" \ -d '{"name":"生产环境","parent_id":null,"weight":100}' -
批量导入
// groups-import.json [ {"name":"Web服务","parent_id":null,"weight":200}, {"name":"数据库","parent_id":null,"weight":150}, {"name":"Redis集群","parent_id":2,"weight":100} ] -
通过监控项创建 在添加监控时直接指定所属组，系统自动创建不存在的组
层级关系管理
Mermaid层级结构图：
创建多层级结构的SQL示例：
-- 创建顶级组
INSERT INTO group (name, weight) VALUES ('业务系统', 300);
-- 创建二级组
INSERT INTO group (name, parent_id, weight) VALUES
('用户服务', 1, 200),
('支付服务', 1, 180);
-- 创建三级组
INSERT INTO group (name, parent_id, weight) VALUES
('用户认证', 2, 150),
('用户画像', 2, 140),
('支付网关', 3, 150);
高级功能实战
权限控制矩阵
Uptime Kuma通过组层级实现权限隔离，支持以下角色配置：
| 角色 | 顶级组权限 | 子组权限 | 监控项权限 |
|---|---|---|---|
| 管理员 | 全部 | 全部 | 全部 |
| 业务负责人 | 查看/编辑 | 继承 | 查看/编辑 |
| 运维人员 | 查看 | 查看/编辑 | 查看/编辑 |
| 访客 | 查看(公开组) | 继承 | 查看(公开组) |
配置示例（server/auth.js）：
async function checkGroupPermission(userId, groupId, requiredPermission) {
// 获取用户角色
const userRole = await getUserRole(userId);
// 管理员直接通过
if (userRole === "admin") return true;
// 获取组的完整路径
const groupPath = await getGroupHierarchy(groupId);
// 检查路径上所有组的权限
for (const group of groupPath) {
const perm = await getGroupPermission(userId, group.id);
if (perm >= requiredPermission) return true;
}
return false;
}
监控数据聚合
组级别监控状态计算规则：
-
状态聚合算法：
- 只要有一个子组/监控项为DOWN，则父组状态为DOWN
- 所有子项为UP，则父组状态为UP
- 存在PENDING时，父组状态为PENDING
-
可用性计算：
async function calculateGroupUptime(groupId, days = 30) { const childGroups = await GroupService.getChildGroups(groupId); const monitors = await GroupService.getMonitorsInGroup(groupId); let totalUptime = 0; let count = 0; // 计算监控项可用性 for (const monitor of monitors) { const uptime = await MonitorService.calculateUptime(monitor.id, days); totalUptime += uptime; count++; } // 递归计算子组可用性 for (const child of childGroups) { const childUptime = await calculateGroupUptime(child.id, days); totalUptime += childUptime; count++; } return count > 0 ? totalUptime / count : 100; }
状态页集成
将监控组与状态页关联，实现业务视角的状态展示：
- 创建与组结构匹配的状态页
- 配置组的公开属性
- 设置自定义URL和描述
配置示例：
// 创建状态页时关联监控组
async function createStatusPageWithGroup(groupId, config) {
const statusPage = await StatusPage.create({
name: config.name,
slug: config.slug,
description: config.description,
isPublic: config.isPublic
});
// 关联监控组
await R.exec("INSERT INTO status_page_group (status_page_id, group_id) VALUES (?, ?)",
[statusPage.id, groupId]);
return statusPage;
}
性能优化策略
大规模部署建议
当监控组数量超过100个或监控项超过1000个时，建议：
-
数据库优化
- 为
group.parent_id创建索引 - 定期清理历史数据
- 使用Redis缓存组结构
- 为
-
查询优化
// 优化前：多次查询 for (const group of groups) { group.monitors = await getMonitorsByGroup(group.id); } // 优化后：一次查询 const groupMonitors = await getMonitorsByGroups(groups.map(g => g.id)); groups.forEach(group => { group.monitors = groupMonitors.filter(m => m.group_id === group.id); }); -
前端渲染优化
- 实现组的懒加载
- 使用虚拟滚动展示大量监控项
- 缓存展开/折叠状态
常见问题解决方案
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 组加载缓慢 | 层级过深或监控项过多 | 限制最大层级为5级，实现虚拟滚动 |
| 权限继承混乱 | 中间组权限设置错误 | 实现权限继承可视化工具 |
| 状态计算延迟 | 监控项状态更新频繁 | 引入消息队列异步更新组状态 |
| 导入失败 | JSON格式错误 | 增加导入验证和错误提示 |
最佳实践与案例
电商平台案例
某电商平台使用Uptime Kuma监控组实现的层级结构：
电商平台
├── 前端应用
│ ├── PC网站
│ ├── 移动端H5
│ └── 小程序
├── 后端服务
│ ├── 用户服务
│ ├── 商品服务
│ ├── 订单服务
│ └── 支付服务
├── 数据层
│ ├── MySQL集群
│ ├── Redis缓存
│ └── ElasticSearch
└── 基础设施
├── CDN
├── 负载均衡
└── 云服务器
关键实现：
- 为每个业务部门创建独立顶级组
- 按服务调用链设置子组顺序
- 为核心支付流程设置权重1000（最高）
- 配置跨组依赖告警
实施检查表
部署监控组前，请确认以下事项：
- 已规划监控层级结构
- 确定各层级负责人及权限
- 制定命名规范（如
业务线-系统-模块） - 设定合理的权重值范围（建议1-1000）
- 规划状态页与组的对应关系
- 配置监控数据保留策略
- 准备灾备方案
总结与展望
Uptime Kuma的监控组功能通过层级化设计，完美解决了大规模监控的管理难题。核心价值点：
- 结构清晰：业务视角的监控组织方式
- 权限精细：基于组的多层级权限控制
- 状态聚合：直观展示业务整体可用性
- 易于扩展：支持API集成与自动化管理
未来版本可能引入的功能：
- 组模板功能
- 跨组依赖告警
- 基于AI的异常检测分组
- 与CMDB系统的集成
掌握监控组功能后，建议进一步学习：
- 监控条件表达式高级用法
- 自定义通知模板设计
- 数据导出与报表生成
希望本文能帮助你构建更强大的监控体系，确保业务系统的稳定运行！
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
