部署 OCManager 智能运维平台并集成 AI 服务实现EKS节点的监控和维护

image-20260709110257535

当你手上有几十上百台 Linux 服务器需要管理时，"逐台 SSH 登录、手动敲命令排查"很快就会变成灾难。OpenCloudOS 的 OCManager 正是为集中式运维而生的一套开源方案：一个 Web 控制台统管所有机器，每台被管主机上跑一个轻量 Agent 负责采集数据与执行指令，再叠加一个内嵌的 AI 助手把"看数据、判断问题、给建议"这些原本靠人脑的环节交给大模型。

这套系统由四个相对独立又彼此配合的部分组成，分散在多个开源仓库里。本文尝试从控制平面部署，到 Agent 通过 AWS SSM 批量下发到 EKS 节点，再到 AI 助手接入大模型，实现通过ocmanager监控和诊断eks节点的方案。

到底有哪几个组件

动手之前，务必先搞清楚这套系统的组成

体系 仓库 一句话定位
运维管控核心 ocmanager（含内置 tms） 控制平面主体：Vue 前端 + Go 后端 + 数据通道
ocm-agent 部署在每台被管主机上的采集/执行代理
AI 智能体系 ocai-service AI 能力后端（"大脑"：LLM 推理 + RAG + 编排）
ocai-agent 终端原生 AI Agent（独立的命令行 TUI 客户端）

需要特别说明两点：

  • tms 不是独立仓库，它在 ocmanager 仓库内部（ocmanager/tms/），是 manager 的必装组件，承担所有 Agent 的接入侧能力（mTLS 网关、资产管理、心跳、任务下发等 7 个 tRPC 服务）。
  • ocai-agent 是一个跑在开发者终端里的 Go TUI 程序，类似开源版的命令行 AI Agent，本文不涉及。我们要部署的 AI 后端是 ocai-service。

它们的运行时关系如下图所示：

flowchart TD User([运维人员浏览器]) subgraph CP["控制平面（单机部署）"] Manager["ocmanager/manager<br/>frontend / footstone / msg-etl / sysdiagnose"] OCAI["ocai-service<br/>（AI 大脑）"] TMS["ocmanager/tms（数据通道，必装）<br/>gateway :8989(mTLS) / api / asset-manager / ..."] Infra[("共享 infra<br/>MySQL / Redis / Kafka / ClickHouse")] end subgraph Hosts["被管主机集群（EKS 节点）"] Agent["ocm-agent ×N<br/>采集指标 / 执行任务"] end User -->|"HTTP :13070"| Manager Manager <-->|"/api/v2/ocai/*"| OCAI Manager -->|"TMS=http://127.0.0.1:8080"| TMS TMS --- Infra TMS -->|"TCP + mTLS :8989"| Agent Agent -.->|"上报数据"| TMS

数据流方向为：agent 采集 → gateway 接入 → Kafka → msg-etl 消费 → 数据库 → 前端展示。

  • manager 通过 HTTP 调用 tms，tms 反过来不依赖 manager；
  • ocai-service 则通过 /api/v2/ocai/* 挂在前端 nginx 后面。
flowchart LR A["ocm-agent<br/>采集指标"] -->|mTLS| G["tms/gateway"] G --> DP["tms/data-proxy"] DP --> K[("Kafka")] K --> M["manager/msg-etl<br/>消费"] M --> CH[("ClickHouse / MySQL")] CH --> F["manager/frontend<br/>整机监控 / 主机详情"]

本次部署的控制平面环境：

  • 操作系统：Amazon Linux 2023
  • Docker：25.0.8（含 Compose v5.0.1 插件）
  • Go：1.25
  • 控制平面内网 IP：172.31.1.2

OCManager 的部署脚本 scripts/deploy.sh 会先跑一遍 check-environment.sh 做环境自检——检查 CPU/内存/磁盘、Docker、Go、必要工具、.env 配置、端口占用等。整套流程按 infra → tms → manager 的顺序拉起，因为 manager 启动时要调用 tms，所以 tms 必须先起。

部署控制平面（infra + tms + manager）

准备配置

cd /home/ec2-user/ocmanager
cp config/env.example config/.env

关键配置项（config/.env）：

SERVER_HOST=172.31.1.2          # 控制平面内网 IP
FRONTEND_PORT=13070               # 前端访问端口
OC_NETWORK_SUBNET=172.32.0.0/24   # Docker 网络子网

注意：.env 默认的 OC_NETWORK_SUBNET=172.22.0.0/24，如果宿主机上已有其他 Docker 网络占用了 172.22.0.0/16，创建 ocmanager-net 时会报 Pool overlaps with other one on this address space。解决办法就是换一个没被占用的段，比如 172.32.0.0/24。

处理镜像源

由于腾讯云镜像不可达，需要把 infra/docker-compose.yml 和各 Dockerfile 里的镜像换成可访问的源。我使用的是毫秒镜像加速器（docker.1ms.run）配合华为云镜像（swr.cn-north-4.myhuaweicloud.com/ddn-k8s/）。

最终各基础组件的镜像：

服务 镜像
MySQL docker.1ms.run/mysql:8.0.35
Redis docker.1ms.run/redis:7.2.3-alpine
ZooKeeper swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/bitnami/zookeeper:3.8.3
Kafka swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/bitnami/kafka:3.5.1
ClickHouse swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/clickhouse/clickhouse-server:23.8.9.54

本次环境实际生效的是 docker-compose 独立 CLI（v5.0.1），而不是 docker compose 插件，直接敲 docker compose 会返回 'compose' is not a docker command。此外，Docker Compose v5 构建镜像时要求 buildx ≥ 0.17，而环境里的 buildx 显示 v0.0.0+unknown（等于没装好），会报 compose build requires buildx 0.17 or later。

我最终下载了 buildx-v0.17.1.linux-amd64 放到 ~/.docker/cli-plugins/docker-buildx 并 chmod +x，docker buildx version 正常显示 v0.17.1 后，构建就顺畅了。

部署动作直接运行如下脚本即可

bash scripts/deploy.sh          # 交互式，会先做环境检查再确认

脚本依次完成：启动 infra → 生成 mTLS CA 证书 → 启动 tms 7 个服务 → 上传 sysdiagnose 制品并回写 MD5 → 编译 manager Go 二进制并构建镜像 → 启动 manager 业务。

部署完成后的健康检查输出：

[HEALTH] ✓ MySQL / Redis / Kafka / ClickHouse / Zookeeper  全部就绪
[HEALTH] ✓ Footstone / MSG-ETL / Sysdiagnose / 前端服务    全部运行中
[HEALTH] ✓ 前端 HTTP (port 13070) / Footstone HTTP (port 21000)
成功率: 94%
访问前端: http://172.31.1.2:13070   默认账号 admin / Admin123456@

至此控制台可以访问了。但此时它还没有任何被管主机。UI界面如下图所示，我这个是已经将主机注册到ocmanager了，初始化的主机总数为0。

image-20260709103649219

关于 mTLS CA

部署 tms 时会自动生成 mTLS CA 证书（/data/ocm/ca/），其中 server 证书的 SAN 需要包含 Agent 将来连接的地址：

Subject Alternative Name:
  DNS:gateway, DNS:localhost, IP Address:127.0.0.1, IP Address:172.31.1.2

这里 SAN 校验的是服务端身份：Agent 连接 gateway 时会验证"我连的这个地址是否在证书 SAN 里"。因为部署时 SERVER_HOST 已经是 172.31.1.2，证书自动包含了它，所以后续装 Agent 无需重新生成 CA。

只有当你要新增对外地址（如绑公网 IP）时，才需要 sudo EXTRA_SAN="IP:x.x.x.x" bash tms/deploy/scripts/init-ca.sh --force 重签。

构建并分发 Agent 到 EKS 节点

控制平面是"大脑"，Agent 才是伸到每台机器里的"手和眼"。本次的被管目标是一个 EKS 集群的两个 worker 节点。

构建 Agent 安装包

Agent 源码在独立仓库 ocm-agent。构建时通过 GATEWAY_ADDR 把控制平面地址注入配置：

cd /home/ec2-user
git clone https://gitee.com/OpenCloudOS/ocm-agent.git
cd ocm-agent
GATEWAY_ADDR=172.31.1.2:8989 bash scripts/build-tar.sh
# 产物：../bin/ocm-agent-linux-amd64.tar.gz

注意事项（Go 版本）：Agent 的 go.mod 声明了 go 1.25.0，而环境里是 1.24.1，构建会直接失败：go.mod requires go >= 1.25.0。升级 Go 即可——下载 go1.25.0.linux-amd64.tar.gz 解压到 /usr/local/go，go version 确认为 1.25.0 后重新构建。构建过程会同时编译 os-monitor 和 sysinfo-collector 两个采集插件，并把 CA 证书、config.yaml 一起打进 tar 包。

构建成功后，文件直接在压缩包根目录，没有子目录——这一点后面写 SSM Document 时很关键：

./ocm-agent          # 主程序
./config.yaml        # 已注入 gateway_addrs: 172.31.1.2:8989
./install.sh         # systemd 安装脚本
./ca.crt             # CA 证书
./plugins/           # 采集插件

通过 AWS SSM 批量部署

被管目标是 EKS 节点，恰好可以选择用 AWS Systems Manager (SSM) Run Command 批量下发，而不是逐台 SSH。整体思路是把 tar 包传到 S3，写一个 SSM Document 让节点自己从 S3 拉取并安装。

先把安装包上传到 S3：

aws s3 mb s3://ocm-agent-deployment-xxxxx --region cn-north-1
aws s3 cp ../bin/ocm-agent-linux-amd64.tar.gz s3://ocm-agent-deployment-xxxxx/

具体执行SSM Document出现两个问题

  • aws:downloadContent 的 S3 路径格式。 用 SSM 内置的 aws:downloadContent action 时，sourceInfo 里的 path 必须是完整的 s3://bucket/key 形式，只写 bucket/key 会报 invalid S3 path parameter。因此改用 aws:runShellScript 里直接 aws s3 cp 下载，更直观可控。
  • 解压目录假设错误。 Document 假设解压后有 ocm-agent-* 子目录，结果报 Could not find extracted agent directory。但是 tar 包是扁平结构，文件就在解压当前目录，根本没有子目录。改成"解压后直接在当前目录执行 install.sh"即可。

修复后的 SSM Document 核心逻辑如下：

WORK_DIR=/tmp/ocm-agent-install
rm -rf "$WORK_DIR" && mkdir -p "$WORK_DIR" && cd "$WORK_DIR"
aws s3 cp s3://{{S3Bucket}}/{{S3Key}} ./ocm-agent.tar.gz   # 直接 cp
tar -xzf ./ocm-agent.tar.gz                                # 扁平解压，不进子目录
[ -f ocm-agent ] && [ -f install.sh ] || { echo 'extraction failed'; exit 1; }
bash install.sh                                            # 原地安装

创建 Document 并对两个节点下发：

aws ssm create-document --name "DeployOCMAgent-Simple" \
  --document-type "Command" --document-format "JSON" \
  --content file://ssm-document-simple.json --region cn-north-1

aws ssm send-command --document-name "DeployOCMAgent-Simple" \
  --targets "Key=instanceids,Values=i-0ba60751e31aeb396,i-0c39e26c274a61ed6" \
  --region cn-north-1

监控结果，两个节点都 Success。健康检查输出确认 Agent 真正跑起来了：

OCM Agent service is active
● ocm-agent.service - OCManager Agent
     Active: active (running)
   ... connected to gateway  addr: 172.31.1.2:8989
   ... registration successful  agent_id: 2932678800052938363
   ... fingerprint detected  ip: 192.168.19.155
   ... Loaded plugin: os_monitor / sysinfo_collector
   ... Received message  plugin: sysinfo_collector  data_len: 65004

验证 manager 与 Agent 的配合

Agent 装上后，最直接的验证就是——控制台里能不能看到这两台机器？从 tms gateway 的日志能看到连接注册：

agent connected, agent_id: 2466270181439347380, ip: 192.168.3.6
agent connected, agent_id: 2932678800052938363, ip: 192.168.19.155

再查后端数据库，footstone.instances 表里正好有 2 条记录 对应这两个节点。

image-20260709103649219

我们可以查看节点的具体详情

image-20260709104443339

在监控界面我们可以看到不同层面的指标信息

image-20260709104535722

此后我们不仅要疑惑，Agent 到底采集了哪些信息？ 直接查 ClickHouse 的 msg_etl 库最直观：

msg_etl.os_monitor:        22,070 行
msg_etl.sysinfo_collector:  8,770 行

短时间内两台机器就上报了三万多条数据。它由两个插件分工采集：

  • os_monitor：27 种实时指标——CPU 使用率（细分到每核、user/system/iowait/steal 等）、负载、内存、磁盘使用率与 IO、网络收发/丢包。
  • sysinfo_collector：12 大类系统信息——基本信息、CPU/内存/磁盘/网卡硬件、内核模块、软件包、PCI 设备、systemd 服务、登录用户等。

一条真实的 CPU 采样：

ip: 192.168.3.6      metrics_name: cpu_usage   num_data: 1.97   tags: {cpu_id: all}
ip: 192.168.19.155   metrics_name: cpu_usage   num_data: 4.10   tags: {cpu_id: all}

当然，对比netdata的指标（ https://www.netdata.cloud/ ）来说，这些指标的粒度和丰富度仍旧需要进一步加强，期待后续加入更多维度和粒度指标。

接入 AI 助手（OCAI）

到这一步，平台已经能"集中看数据、批量下命令"了。但看懂数据、判断问题、给出方案这些环节仍然靠人脑。OCAI 就是把这几步交给大模型——它不是全自动无人运维，而是给运维人员配一个能读你机器数据的 AI 副手。

OCManager 只自带 OCAI 的前端聊天窗口，不自带 AI 推理后端。没部署后端时，点控制台右上角的 OCAI 图标会报 HTTP 502（前端请求打到不存在的 ocai-service 上游）。要消除 502，就得把 ocai-service 这个独立后端部署起来。

克隆并启用

cd /home/ec2-user
git clone https://gitee.com/OpenCloudOS/ocai-service.git
# 打开开关
sed -i 's/ENABLE_OCAI_DEPLOY=false/ENABLE_OCAI_DEPLOY=true/' /home/ec2-user/ocmanager/config/.env

.env 里的 LLM 接入信息（本次指向 AWS Bedrock）：

OCAI_LLM_DEFAULT_HOST=https://bedrock-mantle.us-east-1.api.aws/v1
OCAI_LLM_DEFAULT_NAME=moonshotai.kimi-k2.5
OCAI_LLM_DEFAULT_API_KEY=（已配置）

deploy.sh 会自动把 ocmanager 的 .env 软链到 ocai-service 需要的位置，无需手动配 ocai-service 的配置。

ocai-service 是 Python FastAPI 服务，镜像基于 Debian，构建时会卡在下载境外资源上。 Dockerfile 有三处需要换国内源加速：

注意事项（apt 源）：apt-get install（bubblewrap/curl/tini 等）走 Debian 官方源 deb.debian.org，极慢甚至卡死。在 apt-get update 前用 sed 把源换成阿里云：

RUN sed -i 's|deb.debian.org|mirrors.aliyun.com|g; s|security.debian.org|mirrors.aliyun.com|g' \
 /etc/apt/sources.list.d/debian.sources && apt-get update && ...

注意事项（uv 与 base 镜像）：Dockerfile 用 COPY --from=ghcr.io/astral-sh/uv:latest 拉 uv 工具，ghcr.io（GitHub 容器仓库）国内难访问。换成 swr.cn-north-4.myhuaweicloud.com/ddn-k8s/ghcr.io/astral-sh/uv:latest。base 镜像 python:3.12-slim 同理换成 docker.1ms.run/library/python:3.12-slim。

RUN uv sync --frozen 会下载全部 Python 依赖，默认走 PyPI 官方源，设置 UV_INDEX_URL（它会重定向实际下载源到镜像，同时校验相同的 hash）：

ENV PIP_INDEX_URL=https://mirrors.aliyun.com/pypi/simple/ \
 UV_INDEX_URL=https://mirrors.aliyun.com/pypi/simple/ \
 UV_DEFAULT_INDEX=https://mirrors.aliyun.com/pypi/simple/

部署与验证

export PATH=/usr/local/go/bin:$PATH
cd /home/ec2-user/ocmanager && bash scripts/deploy.sh ocai up

构建 45 秒、容器启动、健康检查通过：

✔ Image ocai-service:latest Built    45.2s
✔ Container ocai-service   Up (healthy)   0.0.0.0:18000->8000/tcp

OCAI 不是独立网址，而是嵌在控制台里：打开 http://172.31.1.2:13070，点右上角 OCAI 图标，弹出聊天窗口后直接提问，比如"帮我介绍一下当前管理的机器""192.168.3.6 的 CPU 使用率怎么样"。它会自动拉取采集到的数据来回答。

image-20260709105300363

用了一会儿 OCAI 后，很自然会冒出一个问题：既然每台机器上都装了 ocm-agent，OCAI 能不能直接让 agent 在机器上跑命令？答案是不能。

系统里实际存在命令执行路径，即受控命令下发：manager/sysdiagnose → task-manager → gateway →(mTLS)→ agent——在控制台触发，带 mTLS、MD5 制品校验、任务状态机与审计，追求"可信、受控、可追溯"。

flowchart TD subgraph Controlled["受控命令下发"] direction LR SD["manager/sysdiagnose"] --> TM["tms/task-manager"] TM --> GW["tms/gateway"] GW -->|"mTLS + MD5 制品校验"| AG["ocm-agent"] AG --> H1["目标机"] end

这里我们根据AI的回复创建一个自定义指令

image-20260709105540077

并下发到指定的节点回显响应

image-20260709105545711

不得不说，OCAI service无法直接执行命令还是有点麻烦的，或许可以自动将命令创建自定义脚本，并由人工审批和推送到节点运行，提升运维效率。

结语

把这套系统的价值在于理解每一层的职责边界和它们如何协作：

  • manager 与 agent 是一对"大脑与手"——单独看任何一个都没意义，只有配对工作、数据从 agent 流到 manager 的界面上，集中运维才成立。机器越多，这套系统的价值越明显。
  • 数据通道（tms）是被刻意独立出来的接入层——mTLS、资产管理、任务下发都收敛在这里，manager 只管业务、不碰 agent 协议细节。
  • AI 助手是"锦上添花的副手"而非"取代人"——它加速判断、自动拉数据给建议，但关键操作仍需人确认；而且它对被管机的访问被刻意限制在"只读数据 + 独立 SSH 旁路诊断"，无法借用 agent 的受控命令通道，这条边界正是安全与灵活的分工。

目前该项目也只聚焦在指标层面，官方提到二期将继续开源 OCManager 在深度运维场景上的能力：

  • 实例信息 — 更细粒度的实例画像与资产视图
  • 健康检查 — 定期主动巡检与基线管理
  • 性能平台 — 性能基线、回归、调优工具集
  • Dmesg 日志 — 内核日志智能化采集与分析
  • CrashBuddy — 内核宕机分析平台（自动分析 + 批量修复 + 失败重试）
  • MCP 工具集 — 更多 OS 能力以 MCP 协议暴露给 Agent 生态

可以持续关注一下吧。

参考资料

posted @ 2026-07-09 11:04  zhaojie10  阅读(2)  评论(0)    收藏  举报