Ongrid 的值班助手如何在即时通讯工具中直接调查事故

想象一个典型的值班场景。凌晨三点，警报响起：API 响应时间飙升了五倍。你迷迷糊糊地打开笔记本电脑，在 Grafana 的十几个仪表板中眯着眼睛查看，然后通过堡垒机 SSH 登录到各个节点，疯狂地在日志中搜索。找到根因需要半小时，而问题可能只是一个崩溃的 Pod 或一个卡住的事务。

开源项目 Ongrid 的作者们决定将这类日常工作交给专门的 AI 代理组合和现成的可观测性堆栈来处理。

系统功能

Ongrid 充当自主值班工程师的角色。它连接到 Telegram 或 Slack 等即时通讯工具，监听传入的警报，并立即开始调查。

该系统基于协调器和专项专家架构构建。当警报到来时，主代理会为根因分析创建一个工作进程。该工作进程向数据库、网络或 SRE 代理发起查询，收集指标、日志和链路追踪数据，构建依赖关系图，并向聊天窗口推送一份现成的事故报告，指出具体的代码行或故障服务。

安全性和访问控制

每个系统管理员听到"生产环境中的代理"时最担心的是模型幻觉执行危险命令导致数据库宕机。Ongrid 的开发者们务实地解决了这个问题。

首先，主机工具和 bash 沙箱默认以只读模式运行。代理可以执行诊断命令、检查进程状态或查看套接字状态，但不会静默重启服务器。

其次，所有潜在破坏性操作都受到特殊的审批网关保护。在应用修复之前，机器人会在聊天窗口或 Web 界面中向值班工程师请求审批。

第三，目标主机不需要任何开放的入站端口。轻量级的 Edge 代理安装在目标服务器上，它向 Ongrid 服务器本身建立出站连接。Web 终端的 SSH 访问通过反向隧道实现，无需向外暴露 22 端口，也无需在堡垒机上配置密钥。每次调用都会记录日志以供审计。

可观测性、拓扑图和 Kubernetes

系统内部已预配置了 Prometheus、Loki、Tempo 和 Grafana 堆栈。不同之处在于代理本身会编写查询语句，将事件时间戳与 OpenTelemetry 链路追踪关联起来。

最近项目新增了 Kubernetes 集群管理功能。代理通过 Edge 连接集群，跟踪工作负载事件，协助管理升级，并将 Pod 投影到共享的拓扑图上。

拓扑图有助于评估事故的影响范围。如果交换机或数据库宕机，系统会可视化所有依赖的服务，过滤掉误报。

知识库和技能扩展

任何 LLM 离开了关于你基础设施的上下文都毫无用处。Ongrid 包含一个知识库，你可以上传运行手册、以往的事后分析报告和代码仓库。基于 Qdrant 的向量搜索能找到相关指令，并在事故分析过程中将其提供给代理。

如果标准工具不够用，你可以通过 MCP（Model Context Protocol）添加更多工具，或在可视化工作流编辑器中构建自己的场景。

生成的报告和仪表板保存在制品中心，便于在事后分析时与团队分享。

底层架构和模型堆栈

平台后端使用 Go 编写，前端使用 React 和 TypeScript 构建。该解决方案可以在你自己的服务器上完全自主部署，采用 AGPLv3 许可证。

至于语言模型，该项目不依赖单一供应商。你可以使用 Anthropic 的 Claude、OpenAI、DeepSeek、Gemini 或本地实例，根据任务复杂度动态切换模型路由。

如何在自有服务器上部署

在 Ubuntu、Debian 或 Rocky Linux 上的安装通过现成的脚本完成：

# Для архитектуры AMD64
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

对于 ARM64，只需将归档文件名替换为对应的版本即可。脚本会启动服务器组件和 Web 界面，之后只需配置即时通讯工具连接并在主机上安装 Edge 代理即可。

适用人群

Ongrid 对中小型运维团队特别有用，这些团队没有全天候运行的网络运维中心（NOC），开发人员轮流值班。它能在事故发生时立即收集日志并将问题定位到清晰的总结，缓解最初那波恐慌情绪。

该项目还很年轻（GitHub 上约有 700 颗星），但架构上得益于对安全性的重视和对开放遥测标准的采用，显得相当成熟。