⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/ongrid-agent-ops-platform/ 「芋道源码」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

干过运维的都清楚,找问题比修问题耗时间。监控看板平时就开着好几个,指标在 Prometheus,日志在 Loki,链路在 Tempo,真出了故障,人得在这几个系统之间来回翻,翻完还不一定对得上。

Ongrid 是一个开源的运维 AI Agent。告警一响,它自己先去翻监控、跑诊断、顺着拓扑找影响面,查完把结论写回群里。这篇把它的结构和用法理一遍。

主机上一个入站端口都不用开

它的结构分两块,Manager 装在服务器上,Edge 装在被管的主机上。Edge 只主动往外连,主机上一个入站端口都不用开,22、80、443 全关着也能被管。这个模式对分散在多个网络里的机器特别省事,不用先打通网络策略。

Ongrid 的整体结构

项目今年五月下旬才放出来,按官方的介绍,它想让 Agent 看懂基础设施,出问题自己找根因,找到了还能动手修。

主界面

告警响了,它先去翻一遍

平时告警响了,第一反应是登上去看,Ongrid 把这个动作自动化了。告警触发以后,它会拉起一个排查流程,自己去收集指标、日志、链路数据,再加上拓扑和设备信息。

告警触发的自动排查

根因分析给得比较具体,官方的说法是能把问题钉到源码的某一行上,前提是代码仓库喂进了知识库。

先看图,再追根因

服务、集群、设备之间的依赖关系,它画成一张拓扑图。告警来了先看图,哪些服务会被牵连,故障域有多大,图上都标着。这一步比翻日志快得多,因为依赖关系是平时攒下来的,出事时不用现推。

拓扑图

Kubernetes 的资源也能挂进这张图里。通过 Edge 把集群注册进来,工作负载、事件都能看,升级也能管,集群资源自动关联进拓扑图。手里有几套 K8s 的话,不用再来回切 kubectl 的 context。

K8s 集群视图

工具默认只读,写操作要你点头

它给 Agent 配的主机工具默认是只读的,一个 bash 沙盒加 26 个巡检工具,每次调用都有审计记录可查。涉及写操作的动作,要走审批闸门,人点头它才执行。

审批闸门

模型这块不绑定,自己带 Key。国内的 GLM、DeepSeek、Kimi 都支持,也兼容 Anthropic、OpenAI、Gemini 的接口,可以热切换。

网页里还能开个终端直接 SSH 到任何一台主机,走 Edge 的反向隧道,不用配密钥和跳板机,操作同样有审计记录。

监控、日志、知识都收在同一个工作台

主机健康、日志、链路、告警状态,都在同一个工作台里。Agent 排查取的是这里的数据,人看的也是这里,省得两头对不上。

自带的监控面板

它带一个工作流编排的功能,在画布上把触发器、条件、Agent、通知这些节点连起来,就能搭出一条自动化流程。触发方式有定时和事件两种,比如让告警来了自动跑一遍排查。

工作流编排

知识库里可以放 runbook、笔记、历史故障记录,也可以把整个代码仓库喂进去,它会自己建索引。放进去的东西人能搜,Agent 排查的时候也会拿来当上下文用。

知识库

巡检、排查这类重复做的操作,可以做成技能放进技能目录,下次直接调用,也能分享给团队其他人。攒得多了,团队自己的运维经验就沉淀在这里面了。

技能目录

IM 方面飞书、钉钉、企业微信都支持,配个机器人就能在群里跟它对话,每个通道还能单独设语言。MCP 服务器也能注册进来,上面的工具 Agent 可以直接调。

装起来就一条命令的事

准备一台 Ubuntu 22.04 以上的机器,Debian 12、RHEL 9 也行,装好 Docker 24 和 Docker Compose v2,内存 2G、磁盘 10G 就够。安装包是预编译好的,不需要装 Go 工具链,也不用自己编。然后下载、解压、跑脚本。

wget https://github.com/ongridio/ongrid/releases/download/v0.12.0/ongrid-v0.12.0-linux-amd64.tar.xz
tar -xf ongrid-v0.12.0-linux-amd64.tar.xz
cd ongrid-v0.12.0-linux-amd64
sudo ./install.sh

ARM 机器把包名里的 amd64 换成 arm64。有两个细节装之前要知道,Manager 只有 Docker Compose 这一种安装方式,没有 systemd 包;安装包本身不内嵌运行镜像,镜像是装的时候从 docker.cnb.cool 拉的,所以机器得能访问这个仓库。

GitHub 拉不动的话,官方给了国内 CDN 镜像,把下载地址换成这个。

wget https://ongrid.cloud/dl/ongrid-v0.12.0-linux-amd64.tar.xz

装完打开网页,设一个管理员账号,填一个模型的 API Key,整个栈就起来了。想在钉钉里用的话,在通道设置里配一下机器人就行。后面要管更多主机,在页面上生成 Edge 的安装命令,到目标机器上跑一下,主机就纳管进来了。

仓库首页

它适合什么团队

一类是团队小、没有 7x24 值班的,告警靠手机盯。让它先把查证做完,人只看结论。

一类是主机多而且分散,安全上不想给每台机器开入站端口。Edge 只出不进,这个模式正合适。

还有一类已经有 Prometheus 和 Grafana,但排查还是靠人肉翻。Ongrid 内置的监控栈装完就有,外部告警也能接进来。手里有 K8s 集群的,也能在一个地方看工作负载、事件和升级。团队攒了一堆 runbook 和历史故障记录躺着没人看的,喂进知识库,人和 Agent 都能查。

让 AI 碰生产,这一步没人敢跨

这类工具以后会是一个趋势。AI 在编码和查代码问题上的能力已经那么强,没道理不能拿来自动化运维。真要说差别,运维比写代码更怕「错一次就出事」,所以这类产品怎么管住风险,比它能做多少事更关键。

Ongrid 有个只读优先加审批闸门的设计,考虑得挺周到。不过哪怕这样,敢直接上生产的也不多。现在我们对 AI 能力不太怀疑,怕的是它偶尔发疯跑偏。

许可证是 AGPL-3.0,主语言 Go。仓库五月下旬建的,到现在一千一百多 Star,还在涨。对这个方向感兴趣的,可以先搭一个非生产环境玩玩。

仓库在 https://github.com/ongridio/ongrid

文章目录
  1. 1. 主机上一个入站端口都不用开
  2. 2. 告警响了,它先去翻一遍
  3. 3. 先看图,再追根因
  4. 4. 工具默认只读,写操作要你点头
  5. 5. 监控、日志、知识都收在同一个工作台
  6. 6. 装起来就一条命令的事
  7. 7. 它适合什么团队
  8. 8. 让 AI 碰生产,这一步没人敢跨