
如果你管过几百甚至上千台的 Linux 服务器,下面这套组合拳应该不陌生:
- 监控用 Prometheus/Grafana 拼一套
- 日志用 ELK 拼一套
- CMDB 自己写一套
- 主机批量执行用 Ansible/SaltStack
- 出了问题,几个工具切来切去,凭经验拼凑现场
这套打法在几台、几十机器规模下还能凑合。但当你的机器到了成千上万台量级——每天 700 万条软件包风险告警,2000 起宕机事件,上百种软件版本,几十个 OS 发行版本。人是不够用的,工具链是断的,知识是装在老员工脑子里的。
OCManager 是 OpenCloudOS 团队为这件事给出的答案——一个把集群管理、整机监控、AI 智能运维整合在同一个 Web 控制台的一体化平台。今天我们正式把它开源了。
一、OCManager 是什么
OCManager 是 OpenCloudOS 智能管家,核心解决大规模 Linux 集群"看不全、管不住、查不出、修不快"的闭环问题。

如上图所示,OCManager 采用四层结构:被管主机运行 Agent 插件,通过 mTLS 通道上报数据;后端基于 tRPC-Go 微服务 + Footstone 基础服务(机器管理、权限校验等),存储依赖 MySQL / ClickHouse / Kafka / Redis;前端 Vue2 + TDesign 在 Web 控制台统一交付所有功能。
OCManager 平台包含四大核心特性:
- 一体化、开箱即用:各核心模块共享同一套机器视图、权限体系和 Agent 通道,无需再“手搓”或拼装。
- 全 Web管理:从主机纳管到批量操作,从指标看板到异常诊断,从命令执行到 AI 对话,全部在 Web 控制台完成。这将大幅提升使用效率、统一操作入口、可审计可回溯。
- 多 OS 适配,不锁死:一期支持 OpenCloudOS 9 / OpenCloudOS 8,及其商业版TencentOS 全系。二期会扩展到第三方主流开源 OS;机房里跑什么,OCManager 就能管什么。
- 大规模业务场景验证:开源前,OCManager 已在腾讯内部跑了三年多,服务 300 万+台异构服务器,日处理 700 万条 CVE/软件包风险告警,自动分析 2000+ 起宕机事件。开源的第一天,它就带着 300 万台机器的生产经验上岗。
五大核心模块解读
在平台一期能力建设中,我们开源了集群管理、整机监控、命令助手、OCAI (含智能诊断、智能问答助手)五大核心模块。下面将逐一展开,方便你了解每个模块的应用场景及价值。
2.1 集群管理
集群管理作为 OCManager 的底座,由 Footstone 基础服务承担。它通过微服务架构提供统一的主机纳管、标签化分组、大批量导入导出功能,并支持 RBAC 权限校验与全生命周期的操作审计日志。面对百万级以上机器的规模化纳管,Footstone 可通过云原生机制进行多 Pod 水平扩展,并基于双向证书认证(mTLS)通道与被管端建立高并发长连接。
在控制台中,主机纳管、分组、标签、批量导出、批量命令执行等,全部在 Web 端完成。

示例图:主机管理控制台 — 支持多条件筛选与批量操作
(限于篇幅,详细分组、主机状态功能暂未做展示)
2.2 整机监控
OCManager 监控模块专为系统级排障设计,解决传统监控“只能看整机虚高、无法定位具体硬件瓶颈”的被动局面。单机指标采集深度覆盖CPU、内存、磁盘 I/O、网络四大维度的 26 项核心参数:
- CPU 负载解构:同步呈现 CPU 使用率与 CPU 平均负载(支持 1/5/15 分钟区间走势对比),并提供负载区间 TOP 排行,识别多核负载不均;
- 内存精细画像:细化追踪物理内存使用量与反映系统实际内存分配的启用内存使用量,以 GB 级粒度提供四维统计,精准捕捉隐性内存泄漏;
- 设备级磁盘 I/O:下钻至具体物理设备及逻辑分区维度(如 vda、vdb1),独立统计磁盘使用率与磁盘 I/O 读写占比,让慢盘与慢 I/O 无所遁形;
- 网卡级流量测绘:以单物理/虚拟网卡维度(如 eth1、br0)精确定位入、出方向流量,快速捕获网络带宽瞬时毛刺。

示例图:整体监控看板——重点覆盖系统层级亚健康状态
2.3 命令助手
日常运维中充斥着大量高频、细碎且容错率极低的底层指令,批量执行不仅效率低,一旦出错结果不可预期。OCManager 命令助手将底层命令行操作重构为标准化、可复用的 Web 端作业模板,核心解决"一条命令推给多少台机器"的问题:
- 批量目标选择:通过选择主机面板直接勾选已纳管机器,一次下发即可覆盖全量目标;
- 参数化命令模板:命令内容以结构化卡片呈现,含名称、类型、作用范围、描述及带注释的示例命令,参数以 {arch} 等占位符标注,降低误输概率;
- 安全闭环:命令经白名单审核后通过沙箱下发,执行结果实时回传 Web 控制台并自动归档,全程可追溯。


示例图:命令助手命令模版&支持参数化命令批量下发
2.4 OCAI
OCAI 是本次开源中升级幅度最大的模块。在去年的功能开源基础上,我们新增了除 Shell 端以外的 Web 端交互,并将「通用问答助手」与「智能诊断」能力整合到同一入口,内置 OpenCloudOS 专属知识库,具备完整的推理与执行链路:
- 诊断结论与执行建议一体化:用户描述异常现象(如"内存使用率 98% 紧急排查"),OCAI 自动完成多维度分析,输出结构化诊断报告——包括基线负载判定、异常事件归因(如"凌晨 2 点 ~ 7 点 CPU 飙高 76%~99%,结合 ClickHouse 用户活跃,判断为 Merge/Mutation 后台任务")、离线机器告警汇总,以及按优先级排序的总结与建议格,每行附带可直接执行的操作命令。
运维/开发者面对异常时,拿到的是一份带推理过程、带优先级的诊断报告,以及可直接执行的修复建议。 - 可解释的推理过程:诊断结论不是黑盒,OCAI 会展示完整的分析链路——从验证接入状态(如 systemctl status ocm-agent)、到逐条确认需要排查的事项(接入文档、安装包路径、服务端地址),再到最终归因,每一步推理过程均对用户可见;
- 通用问答与深度诊断统一入口:日常技术咨询(如版本特性、兼容性)走对话式问答;需要根因分析的场景自动创建诊断任务,由底层 LangGraph + MCP 工具链驱动,调用平台日志、指标、配置等数据源完成深度排查;
- 多轮上下文与知识沉淀:对话历史自动归档,新的故障处理经验可持续补充进 OS 专属知识库,供后续诊断复用。



示例图:OCAI 对话界面 & 诊断报告— 含异常归因、分级修复建议、知识输出
如何部署OCManager
备注:由于公众号篇幅受限,详细部署流程请见:https://gitee.com/OpenCloudOS/ocmanager/blob/master/docs/QUICKSTART.md
3.1 Docker 一键部署(官方推荐方式):
1)前置依赖与环境要求
- Docker 20.10+(含 Compose v2)、 Go 1.24+(deploy.sh 会在本机静态编译后端二进制,再 COPY 进镜像)
- 当前用户能直接调用 docker(root 或在 docker 组里,非 docker 组用户可执行:sudo usermod -aG docker $(id -un) && newgrp docker)
- 当前用户能 sudo
- 硬件量级(经验级、非 SLA):建议服务器配置至少在 4 核 / 8 G ;含 MySQL、Redis、Kafka、ZooKeeper、ClickHouse、manager 三进程、数据通道七服务时,更稳妥从 8核 / 16 G起做功能验证。
- 不要在 docker 数据目录的挂载目录里跑脚本——脚本会在 manager/backend/bin/ 写入临时二进制并清理。
2)执行步骤
# clone 仓库
git clone https://gitee.com/OpenCloudOS/ocmanager.git
# 进到仓库根目录
cd ocmanager
# 复制配置文件
cp config/env.example config/.env
# 更改配置
备注:至少确认 SERVER_HOST。本地体验可直接用默认值,无需修改。如需其他配置,如OCAI-Agent要使用的模型时,请注意配置,详见4)
vi config/.env
# 一键构建镜像并启动全部服务,脚本会自动构建前后端镜像,并拉起 MySQL / Redis / Kafka / ClickHouse 等所有依赖
bash scripts/deploy.sh
完成后访问:
http://127.0.0.1:13070
默认账号/密码:admin / Admin123456@
# 登录后请立即修改密码
备注:上述一键构建脚本,将按 infra → 数据通道 → manager 顺序拉起全栈(manager 业务侧的 sysdiagnose 通过 .env 里 TMS= 调用 tms/api,所以数据通道必须先于 manager 启动;制品上传也安排在两者之间,让 MD5 在 manager 启动前已经回写到 .env。
3.2 OCAI-Service部署(可选)
OCAI-Service 是控制台内嵌的 AI 助手(详见 https://gitee.com/OpenCloudOS/ocmanager/blob/master/docs/architecture/frontend-app.md)。前端已默认集成;AI 后端由独立仓库 ocai-service 提供。若暂不部署 OCAI-Service,保持 ENABLE_OCAI_DEPLOY=false(默认)即可;也可在 Header.vue 中隐藏
一键启用(需先克隆 ocai-service 到 oc-manager 同级目录):
# config/.env
ENABLE_OCAI_DEPLOY=true
OCAI_JWT_SECRET=your-jwt-secret
OCAI_LLM_DEFAULT_API_KEY=sk-your-key
bash scripts/deploy.sh up # 自动拉起 ocai-service + nginx 反代
3.3 被关节点上部署Agent
控制平面(infra + 数据通道 + manager)跑起来后只是服务端——要让被管节点上报数据 / 接收命令,需要在每台目标主机上部署 Agent。Agent 与控制平面(具体是 tms/gateway)走 mTLS 长连接互信,所以必须先把 控制平面对外可达地址签进 server 证书的 SAN。
详细部署流程见:
https://gitee.com/OpenCloudOS/ocmanager#方式三在被管节点上部署-agent
如需更多部署方式,如本地开发部署,请见项目Quickstart 文档:https://gitee.com/OpenCloudOS/ocmanager/blob/master/docs/QUICKSTART.md
Coming Soon · 二期开源规划
本次我们重点解决了"看到机器、监控机器、问机器、诊断机器"的闭环,二期将继续开源 OCManager 在深度运维场景上的能力:
- 实例信息 — 更细粒度的实例画像与资产视图
- 健康检查 — 定期主动巡检与基线管理
- 性能平台 — 性能基线、回归、调优工具集
- Dmesg 日志 — 内核日志智能化采集与分析
- CrashBuddy — 内核宕机分析平台(自动分析 + 批量修复 + 失败重试)
- MCP 工具集 — 更多 OS 能力以 MCP 协议暴露给 Agent 生态
同时还将扩展更多第三方主流开源 OS 的适配。
欢迎大家部署、体验 OCManager,同时也欢迎大家来 OCManager 主仓库和各分支项目仓库提PR/Issue,参与各类技术共建。
- OCManager开源代码仓库:
https://gitee.com/OpenCloudOS/ocmanager - OCM-Agent开源代码仓库:
https://gitee.com/OpenCloudOS/ocm-agent
- OCAI-Service开源代码仓库:
https://gitee.com/OpenCloudOS/ocai-service
- OCAI-Agent开源代码仓库:
https://gitee.com/OpenCloudOS/ocai-agent
OpenCloudOS 开源社区是由操作系统、云平台、软硬件厂商与个人携手打造中立开放、安全稳定且高性能的 Linux 操作系统及生态。目前已实现从源社区、商业版、到社区稳定版全链路覆盖,旨在输出经海量业务验证的企业级稳定操作系统版本,为行业解决国产操作系统上下游供应问题,促进基础软件可持续发展。
