告警来了它自己查原因，这个开源运维 AI Agent 有点东西！

阅读全文

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

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

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

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

半夜被告警吵醒这件事，干过运维的都懂。爬起来登机器、翻监控、对日志，运气好半小时定位，运气不好天亮还在猜。Ongrid 想干的就是这一段，告警来了它自己去查，查完把结论发进群。

半夜告警，它自己把原因找出来

对话里提问后它开始自己查

先交代它是什么。Ongrid 是一个开源的、自己部署的运维 AI Agent，语言是 Go，许可证是 AGPLv3，五月下旬建的库，仓库现在一千一百多 Star。

部署形态分两头。每台被监控的主机装一个轻量 edge 端，管理端跑在你自己的服务器上，大模型的推理也放在管理端这边。它把指标、日志、调用链、服务拓扑和源码串在一起查问题，查完用大白话告诉你根因在哪。

它面向的是 SRE、DevOps 和平台团队。这类团队手里一般不缺监控信号，Prometheus、Loki、Tempo、journald、k8s 都有，缺的是把信号拼起来的那个人，平时查个问题要在五六个页面之间来回切。

它内部的 agent 也分了工，一个协调者负责判断这次该找谁，再派给 SRE、网络、数据库这些专家子 agent，各查各的那一段。

从告警到某一行代码

一般监控系统的流程是告警响了、人登上去、看指标翻日志查调用链，折腾半小时。Ongrid 把这个流程反过来，告警触发的时候它自动拉起一个调查 worker，先走一遍服务拓扑看这次故障影响多大，再把指标、日志、调用链对在一起查，查出来的根因直接写回聊天频道。

一次根因调查的完整会话

官方文档里的例子值得完整看一遍。订单服务下午两点多开始丢请求，agent 先展开拓扑看上下游，查 PromQL 发现支付服务的 5xx 在涨，翻日志看到熔断器打开了，再查调用链发现错误来自上游的 cardholder-api。到这里它没有停，而是直接去读代码仓库，把问题钉在 payments/circuit_breaker.go 第 42 行，熔断阈值是 30 秒内 3 次。

大部分接进 IM 的问答机器人，顶多告诉你哪个服务出了问题。它给的是改哪一行、什么配置、怎么改。这套顺序也是它和普通告警机器人最直接的差别，先看影响面、再对时间、再往上追来源，最后落到代码。

主机不开端口，出事能追到人

服务拓扑图

被监控的主机不需要开任何端口。edge 端只向外拨一条隧道，主机上 22、80、443 一个都不用开，数据面和控制面分开走。

远程操作走的是反向隧道。浏览器里能直接开 SSH 进任意一台主机，不用配密钥，不用跳板机，所有操作都记审计日志。机器不用对外暴露，也就少了一整类被扫端口和被爆破的风险。主机在内网、安全团队不让开入站端口的场景，这套设计基本就是为它准备的。

模型可以换成国内在用的那几个

它不绑定模型厂商。DeepSeek、Kimi、智谱 GLM 都能直接填 key 用，也支持任何 OpenAI 兼容接口，公司自己用 vLLM 或者 Ollama 部署的模型同样能接进来。官方当前的清单里还有 Anthropic、OpenAI 和 Gemini，而且支持热切换，不同的活可以分给不同的模型干。

对国内团队来说还有一层好处，整个平台部署在自己的服务器上，运维数据不出门，模型挑国内能正常用的就行。

权限这块设计得比同行克制

写操作的审批与入门界面

agent 手上是 26 个以上的只读巡检工具，外加一个 bash 沙箱。沙箱里配了命令策略，rm、sed -i、systemctl restart 这类写操作直接拒掉。

真要动生产，比如重启一个服务，得走审批门，人点了确认才执行。每一次工具调用都留审计记录。这套设计说明作者在生产环境里干过，知道让 AI 裸奔是什么下场。

内置监控面板

可观测性这块它自带一套。Prometheus、Loki、Tempo、Grafana 都接好了，装完就有，agent 查问题的时候自己写 PromQL、LogQL、TraceQL，不用人教。监控面板直接嵌在它自己的页面里，日志能实时 tail，调用链能按条件搜。集成清单里还有 OpenTelemetry 与 Qdrant，前者用来收开放标准的追踪数据，后者是它的向量库。

除此之外还有几样。工作流编排把触发器、agent、工具和通知串成一条自动化流程，在界面上拖拽就能画；知识库可以把 runbook、事故记录、Markdown、PDF、DOCX 建索引，也能同步 Git 仓库，人和 agent 查的是同一份资料；技能目录、MCP server 接入、产物中心这些也都有。另外它还能纳管 Kubernetes 集群、管网络设备，把集群资源映射进拓扑。

装起来大概十分钟

知识库界面

官方说单机十分钟，安装文档的步骤确实不多。准备一台 Linux 机器，Ubuntu 22.04、Debian 12 或者 RHEL 9 都行，4G 内存起步、建议 8G，装好 docker。

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

arm64 的机器把文件名里的 amd64 换成 arm64。国内拉 GitHub 慢的话，把下载地址换成官方 CDN。

install.sh 会用 docker compose 把整套东西拉起来，装完打印一个管理员密码，只显示这一次，记得当场抄下来。之后浏览器打开服务器地址登录，到 Settings 的 Models 里填模型 key，再点 Edges 建一个节点，页面会给一条命令，拿到要监控的机器上用 root 跑一遍，edge 就注册上线了。回到 Chat 页面问一句「哪台机器负载最高」，能看到它一步步调工具、出结果。

谁适合用，谁可以先等等

ongridio/ongrid 仓库首页，Star 1.1k

三类团队最合适。没有专职 SRE 的小团队，告警靠人盯、半夜出问题靠运气醒，它能把大部分机械排查挡掉。已经在用 Prometheus 的团队也合适，数据都是现成的，缺的就是一个把数据自动串起来查的工具。还有主机在内网、安全要求不让开入站端口的场景，edge 只向外拨号这个设计正好对上。

我的看法是方向对。运维里最耗人的不是处理故障本身，是告警到定位中间那段重复劳动，它砍的正是这段。只读工具加审批门这套权限设计，比那些上来就让 AI 随便执行命令的项目靠谱，零入站端口也容易过安全团队那关。

也说两点保留。项目五月下旬才开源，版本号刚到 0.17.6，拿它直接管核心生产环境，我也不太敢。另一点更实际，它查根因的上限取决于你喂给它的数据，监控本身不全、日志乱打，它也查不出什么花样。

真要用的话，建议先找几台测试机装上，喂真实的告警跑两周，看它查得准不准，再决定要不要扩大范围。它自己给出的定位质量和你现有的监控质量是绑在一起的，这一步省不掉。

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