运维也有 AI Agent 了:一个开源项目帮我们查故障根因

最近看了一个开源项目，叫 Ongrid。

它给自己的定位挺直接：面向运维的 AI Agent。

如果只看这个说法，容易觉得又是一个把 AI 包在监控面板外面的聊天机器人。现在这类项目不少，接个大模型，连一下 Prometheus，再加个聊天框，就敢说自己是 AIOps。

但 Ongrid 有个地方让我愿意多看几眼。

它不是只想让 AI 回答“CPU 为什么高”。它想把告警、指标、日志、链路、拓扑、Runbook、代码仓库这些东西放到同一个上下文里，让 Agent 帮运维查故障根因。

这个方向对运维来说是有吸引力的。

值班时最累的事，很多时候不是不会查，而是在几个系统之间来回切：

人脑在中间做胶水。

Ongrid 想做的，就是把这层胶水尽量交给 Agent。

当然，这里面也有风险。只要一个工具开始靠近生产环境、远程执行、WebShell、自动调查、自动修复这些词，运维就不能只看宣传图。

我更关心的是：它能不能先把证据找齐，而不是一上来就替人改机器。

Ongrid 是一个开源、自托管的运维 AI Agent 项目。

按照官方文档的说法，它面向 SRE、DevOps 和平台工程团队，目标是让 Agent 理解你的基础设施，并根据 metrics、logs、traces、topology 和 source code 来定位故障原因。

翻成运维能听懂的话，大概是这样：

你不再只问一句“为什么服务挂了”，然后等 AI 编一个看起来很合理的回答。

更理想的流程是：

这个方向，其实比单纯的“AI 写脚本”更接近运维现场。

因为真正排障时，最大的问题不是少一个命令，而是上下文太散。

很多公司不是没有监控。

指标有，日志也有，链路追踪可能也接了一部分。问题是这些东西经常分散在不同系统里。

比如一次接口变慢：

这些信息单独看都不完整。

运维要做的是把它们串成一条时间线，再判断到底是资源问题、依赖问题、网络问题、数据库问题，还是代码变更问题。

Ongrid 的思路是：让 Agent 帮你跑这段关联过程。

它内置了 Prometheus、Loki、Tempo、Grafana、Qdrant 等组件，也支持接入已有的可观测性系统。主机侧通过 ongrid-edge 收集信号，服务端通过 Manager 统一调度。

这个设计有个好处：它不是只站在聊天层面看问题，而是有自己的数据采集、拓扑、知识库和工具调用能力。

这也是我觉得它值得写的原因。

我对“运维聊天机器人”一直比较谨慎。

因为很多工具做到最后，就是把文档搜索和大模型问答套在一起。问它“CPU 高怎么办”，它会给你一套通用步骤：

top

free -m

iostat

journalctl

这些建议不能说错，但离真正排障还很远。

Ongrid 想做得更深一点。

官方文档里提到，它的 Agent 会由 Coordinator 拆解问题，再分发给不同的 specialist agents，比如 SRE、network、compute、disk、ops 这类角色。底层可以调用 bash、主机探测、PromQL 查询、日志搜索、拓扑展开、代码搜索等工具。

这就有点像把一个值班工程师的排障动作拆成几个步骤：

如果它真的能把这些步骤跑顺，价值就不是“AI 会聊天”，而是“AI 能少让人复制粘贴十几次”。

这很现实。

运维现场里，省下来的不一定是技术难度，更多是切系统、找上下文、对时间线这些脏活。

Ongrid 的架构文档里，把系统拆成四层。

第一层是主机或集群侧的信号收集。每台主机上跑一个 ongrid-edge，再配合日志、指标、链路相关插件。

第二层是可观测性数据。Prometheus、Loki、Tempo 负责存指标、日志和链路数据。

第三层是智能分析。Coordinator 调度不同 Agent 和工具，把问题拆开查。

第四层是告警和通知。告警可以进入 Slack、Telegram、飞书、钉钉、企业微信等渠道。

这个结构我比较关注两点。

第一，Edge 是出站连接。

官方文档里强调，Edge 到 Manager 走 outbound tunnel，主机侧不需要暴露入站端口。这一点对生产环境很重要。很多运维工具看起来功能强，但一上来要求你开放一堆端口，安全同事基本不会开心。

第二，它把 control plane 和 data plane 分开。

控制面负责 Edge 和 Manager 之间的请求响应，数据面负责日志、链路这类遥测数据上传。这个设计比“所有东西都塞进一个通道”清楚一些，后面做权限、审计和扩展也更容易讲明白。

当然，架构写得清楚，不等于落地就稳。真要接入生产，还要看高可用、备份、升级、权限模型、资源消耗和故障隔离。

这类工具，架构图只是第一关。

Ongrid 的 Quickstart 说，目标是在一台 Linux 机器上用 docker compose 跑完整套栈，包括 Manager、frontier broker、Prometheus、Loki、Tempo、Grafana、Qdrant、SearXNG。

基础要求大概是：

这不是一个“随便找台小云主机就无脑跑”的小工具。

原因也好理解。它不是单个二进制加一个页面，而是把可观测性、Agent、知识库、聊天入口、Edge 管理放在一起。

如果只是想体验，我建议单独找一台测试机。

不要一开始就接生产机器，更不要一上来给写权限。

先做几件低风险的事就够了：

这一步如果都不稳，就不要谈自动排障。

Ongrid 里面有几个词，运维看到会本能警惕：

这些能力不是不能有。

但它们一定要分层。

我会把 AI 运维 Agent 分成三个阶段看。

第一阶段：只读助手。

它可以查指标、查日志、查链路、查拓扑，帮你整理报告。但它不能改配置，不能重启服务，不能执行危险命令。

这个阶段风险最小，也最适合先落地。

第二阶段：建议助手。

它可以给出处理建议，比如扩容、回滚、调整限流阈值、检查某个依赖服务。但这些建议必须由人确认。

这个阶段的重点不是“AI 多聪明”，而是建议里有没有证据。

第三阶段：受控执行。

只有在明确的审批、审计、回滚、权限边界下，才考虑让 Agent 执行部分动作。比如固定 Runbook 里的低风险命令，或者只对测试环境执行。

如果一个团队还没有完善的权限管理、审计日志和回滚流程，我不建议直接跳到第三阶段。

AI Agent 越像人，越不能按“工具脚本”的方式放进生产。

脚本错了，通常是按你写的逻辑错。

Agent 错了，有时是它看起来很合理地错。

我的判断是：适合观察，适合测试，不适合直接吹成生产救火神器。

从 GitHub 数据看，Ongrid 还不是那种非常成熟的大项目。截至我查看时，仓库大约 600 多个 star。Release 更新很频繁，2026 年 8 月 5 日还有 v0.11.1 发布。

这说明它在快速迭代。

快速迭代是好事，也意味着使用者要接受变化。

如果你想拿它做学习和验证，我觉得可以试：

如果你想直接放进生产核心链路，我会先打住。

生产环境里，最怕的不是工具不能用，而是工具看起来能用。

尤其是这种靠近故障处置的 AI Agent，它需要回答几个问题：

这些问题没想清楚，Agent 越强，风险越大。

如果我现在要试 Ongrid，不会先接 Kubernetes 生产集群。

我会这样来：

第一步，准备一台干净测试机。

按照 Quickstart 跑 Manager，记录好安装过程、资源占用、端口要求和默认账号信息。

第二步，注册一台测试 Edge。

最好是一台没有敏感业务的 Linux 机器。确认 CPU、内存、磁盘、日志这些基础信号能进来。

第三步，配置一个便宜、稳定、可控的模型。

如果是国内环境，可以优先看 DeepSeek、Kimi、GLM 或 OpenAI-compatible endpoint。关键不是模型名字，而是可用性、成本和上下文长度。

第四步，只问只读问题。

比如：

列出当前所有 Edge，并告诉我哪台机器负载最高。

查看 prod-web-01 最近 10 分钟是否有明显错误日志。

帮我分析 10:42 左右 CPU 升高时，进程、日志和系统负载有什么变化。

第五步，看证据链。

我不会只看最后一句结论。我会看它调用了什么工具，查了什么指标，搜了哪些日志，时间范围是否正确，结论有没有跳。

AI 运维工具的好坏，很大程度上要看它“查证据”的过程，而不是看它最终说得多像专家。

我觉得 Ongrid 这类项目的出现，说明 AI 运维正在从“问答”往“工作流”走。

早一点的 AI 运维，很多还停留在问一句、答一句。

比如：

CPU 高怎么办？

然后它给你一套排查清单。

这种东西有用，但价值有限。

真正有用的是：

今天 14:02 开始 order-service 错误率升高，帮我看一下影响范围和可能原因。

然后它能自动去查：

这个方向如果做成，运维的工作会发生一点变化。

不是不用查故障了，而是从“到处找线索”变成“审核 Agent 找出来的线索”。

这对有经验的运维是好事。

因为经验越多，越知道哪些结论不靠谱，哪些建议不能动，哪些命令会把小故障放大。

AI Agent 能提高速度，但生产判断还是要靠人守住。

Ongrid 这个项目我会继续观察。

它现在最吸引我的地方，不是“自动修复”，而是它把运维排障里最麻烦的一段拿了出来：告警、指标、日志、链路、拓扑和知识库之间的关联。

这正是很多团队每天都在消耗时间的地方。

如果你是运维、DevOps 或 SRE，可以找台测试机跑一遍。

不要急着接生产写权限。

先看它能不能把只读调查做好。

只要能把一次故障的证据链整理清楚，这类工具就已经有价值了。至于自动修复，先别急。生产环境不是演示视频，按钮按下去以后，凌晨三点接电话的人还是我们。

文章转自python运维技术，侵删

免费公开课分享

深夜告警来袭，顶级大厂是如何线上应急救火的？

⏰ 9 月 22 日 20:00

树森老师拆解全球真实故障案例

带你掌握线上应急思路，提升故障复盘能力！

扫码免费报名公开课，课后还有配套课件可领