AI Agent人工智能大模型RAG运维可观测性根因分析后端【免费下载链接】ongridAn ops AI Agent that understands your infrastructure, finds the root cause, and fixes it — right from Slack, Telegram, Lark or DingTalk.项目地址https://gitcode.com/gh_mirrors/on/ongrid点击查看免费下载Ongrid 是一个运维 AI Agentops AI Agent它理解你的基础设施、自动定位故障根因并修复——全程可从 Slack、Telegram、Lark 或 DingTalk 发起。本文带你拆解它的 Go 项目分层架构iam / manager / edgeagent 三大业务上下文如何隔离依赖边界以及零入站端口隧道、接口倒置、控制面/数据面拆分等关键设计决策。无论你是想读懂这个开源仓库的架构师还是刚接触 Go 大型项目的新手这篇文章都能在 10 分钟内建立完整的 Ongrid 架构认知。一、整体架构两个二进制、三大业务上下文Ongrid 采用典型的云-边Cloud-Edge架构最终只编译出两个可执行文件二进制入口职责ongrid云端 Managercmd/ongrid/main.go装配 iam manager 两个业务上下文对外提供 HTTP API、Prometheus 指标ongrid-edge边端 Agentcmd/ongrid-edge/main.go装配 edgeagent 业务上下文向外建立隧道、上报主机指标、执行工具 RPC三个业务上下文Bounded Context简称 BC分别是iam—— 身份与访问用户、组织、Casbin 权限manager—— 云端控制中枢告警、拓扑、设备、K8s、AIOps Agent、IM 桥接等 20 子域edgeagent—— 边端采集与执行指标采集器、bash 沙箱、抓包、WebShell、自升级。一个容易误解的点cmd/不是第四层它是唯一的装配层Composition Root负责把各 BC 的依赖注入串联起来。除此之外代码中不存在任何跨 BC 的直接 import。Ongrid 控制台的拓扑视图正是这套架构的数据出口——边端上报的指标最终汇聚成一张可交互的业务-集群-设备关系图二、Go 分层每个 BC 内部的标准五层打开任意一个业务上下文以 manager 为例目录结构惊人地一致internal/manager/ ├── server/ # HTTP 路由、中间件、请求解析与响应 ├── service/ # 服务入口校验与用例编排不直接依赖 data ├── biz/ # 业务用例 消费方 Repo 接口接口定义在这里 ├── data/ # 实现 biz 的 Repo 接口存储与外部数据访问 └── model/ # 领域与持久化数据结构不依赖任何上层这套分层对应 AGENTS.md 中的架构约定表核心规则有两条service 不得越过 biz 直接 import 同 BC 的 data——所有数据访问必须经过业务层抽象接口定义在消费方biz实现在 data通过构造函数注入——这是 Go 社区典型的依赖倒置让 biz 层可以脱离数据库单测。以 edge 子域为例你可以对照 internal/manager/biz/edge/用例与 Repo 接口、internal/manager/data/edge/store/存储实现和 internal/manager/server/edge/HTTP 层三层同名子包感受接口在消费方的落点。三、依赖边界.go-arch-lint.yml把规则变成代码口头约定没有约束力Ongrid 用.go-arch-lint.yml把架构规则写成正向白名单CI 中通过make arch-lint强制执行。规则摘要规则说明iam / manager / edgeagent 两两禁止互 import跨 BC 只允许通过接口装配、API 或事件协作internal/pkg/**共享层不得依赖任何 BC共享基础设施必须业务无关各 BC 内 service 不得直连 data强制走 biz只有cmd可以 import 所有 BC且cmd/ongrid-edge不得 import iam/manager靠 review 与 CODEOWNERS 把关这是本文最值得借鉴的做法之一把架构边界从文档变成 lint 规则任何违反依赖方向的 PR 会在 CI 直接失败而不是靠资深工程师肉眼发现。四、三大 BC 逐个剖析4.1 iam权限中枢与枢轴收缩iam 是三个 BC 中最小的负责用户认证、组织与 Casbin RBAC 授权。它的子包布局internal/iam/biz/、internal/iam/data/、internal/iam/server/http.go同样遵循五层。有意思的是.go-arch-lint.yml顶部注释提到的ADR-005 枢轴iam 曾包含 user/org/membership 三个子域后来收缩为只剩 userorg/membership 已删data 存储也从 MySQL 迁到 SQLite。这说明该架构允许 BC 内部随产品方向演进而 lint 组件用**glob 表达目录增删无需改规则。4.2 manager最大的业务中枢manager 承载了绝大部分产品能力biz下有 20 子域目录包括aiopsAI 运维 Agent、alert、edge、k8s、apm、imbridgeSlack/Telegram/飞书/钉钉桥接、topology、marketplace等。其中aiops是核心Coordinator Agent 把任务分派给 SRE、网络、磁盘等 Specialist 子 Agent自动巡检、关联指标/日志/追踪、把根因写回 IM 聊天。相关代码在 internal/manager/biz/aiops/设计决策记录见 docs/adr/ 与 docs/design/HLD-002-application-performance-monitoring.md。下图是一次真实的 RCA根因分析会话Agent 依次调用query_devices、get_topology工具再委派给磁盘专家子 Agent 输出增长趋势报告——这正是 manager BC 内biz/aiops编排tools与investigator的运行时形态4.3 edgeagent零入站端口的边端 Agent边端是 Ongrid 架构中最有特色的部分。它不开放任何入站端口无需暴露 22/80/443而是主动向云端 brokerfrontier拨号建立一条多路复用、双向发起的 RPC 隧道。核心抽象在 internal/pkg/tunnel/ 的包注释中写得很清楚负责建立并维持隧道、把入站反向 RPC 分派到注册处理器。edgeagent 内部子包按能力切分internal/edgeagent/collector/ —— 主机/进程指标采集与 scrape 配置internal/edgeagent/biz/ —— Agent 核心、SNMP 探测、抓包、升级包处理internal/edgeagent/cmdpolicy/ internal/edgeagent/bash/ —— 命令策略与 bash 沙箱保证远程执行只读且全程审计internal/edgeagent/k8s/ —— K8s 集群注册、inventory list/watch、只读查询与写动作internal/edgeagent/upgrademachine/ —— 自升级状态机含回滚、boot checkinternal/edgeagent/webshell/ —— 反向隧道 WebShell。边端支持 Windows 与 Linux 双平台平台差异通过capabilities_linux.go/capabilities_windows.go等按 build tag 拆分的文件处理见 cmd/ongrid-edge/。五、关键设计决策解读5.1 隧道而非入站端口安全边界的取舍零入站端口是 Ongrid 最鲜明的卖点边端只出站防火墙几乎零配置即可纳管设备。代价是隧道协议要同时支持边端上报与云端反向调用如 AIOps 工具调用get_host_load因此 internal/pkg/tunnel/ 同时定义了消息形状messages.go和双向 RPC 分派。这也是为什么tunnel放在共享层internal/pkg而非 edgeagent 内部——云端 manager 的 frontierbound 服务需要复用同一套消息契约。5.2 写操作门禁AI 可以诊断动手前要审批运维 AI 最大的风险是误操作。Ongrid 的处理方式是审批门禁approval gateAgent 生成的修复建议以可观察 / 低危 / 高危分级展示高危操作必须人工确认后执行且每次调用进入审计。告警详情页中的根因报告就带建议动作列表每条命令标注风险等级对应地manager BC 中有独立的biz/approval、biz/audit子域见 internal/manager/biz/approval/K8s 侧的写动作同样走审批后执行路径审计能力入口在 cmd/ongrid/k8s_action_audit_test.go 有完整测试覆盖。5.3 控制面与数据面分离ADR-029ADR-029 是近期最重要的架构演进K8s 边缘控制器原本单 Pod 同时承担控制面tunnel、inventory watch、写动作和遥测数据面OTel Collector 接收 traces/logs/metrics内存互相挤占OOMKill 时两类能力同时中断。决策是拆成三个独立故障域Controller 只管控制面、遥测 Collector 独立部署、KSM scrape 独立。这个 ADR 回答了一个新手常问的问题为什么不直接加副本——因为相同 controller identity 会引发隧道冲突与重复 watch单副本 故障域拆分才是正解。5.4 共享层internal/pkg只向上不向下internal/pkg下约 40 个基础设施包auth、tunnel、llm、logquery、promwrite、tenantctx等遵循同一条铁律不得 import 任何 BC。这让共享包可以安全地被三个 BC 复用也倒逼开发者把业务逻辑留在 BC 内。LLM 多模型路由、日志查询抽象Loki/Elasticsearch 后端切换等横切能力都沉淀在这里例如 internal/pkg/llm/ 支持 Anthropic / OpenAI / GLM / DeepSeek / Gemini 热切换路由。六、给初学者的架构启示分层一致性地胜过框架server → service → biz → data model 五层在每个 BC 重复出现新人只需学会一次即可读懂全局用工具守护架构.go-arch-lint.yml白名单 make arch-lint让不许跨 BC import成为 CI 事实而非文档口号接口定义在消费方biz 持有 Repo 接口data 负责实现换取可测试性与可替换存储iam 从 MySQL 迁 SQLite 时业务层几乎无感用 ADR 记录取舍docs/adr/ 中 6 篇 ADRK8s 遥测拆分、Edge 资产外置、Elasticsearch 直写日志、APM 等都遵循背景 → 决策 → 理由结构是理解项目演进的最好入口装配收口在 cmd依赖注入只发生在cmd/ongrid和cmd/ongrid-edge的 main 中业务包之间保持纯净。总结Ongrid 的 Go 架构可以用一句话概括一个单模块仓库两个可执行文件三大互不 import 的业务上下文统一的五层内部分工加上 go-arch-lint 强制的依赖白名单。云-边之间靠零入站端口隧道连接AI 的写操作靠审批门禁兜底K8s 控制面与数据面按 ADR 拆分故障域。这套设计对任何想构建可治理的大型 Go 项目的团队都有直接参考价值——如果你想动手验证可以 clone 仓库后先运行make arch-lint与make test感受这套规则的落地方式。赞分享AI Agent人工智能大模型RAG运维可观测性根因分析后端【免费下载链接】ongridAn ops AI Agent that understands your infrastructure, finds the root cause, and fixes it — right from Slack, Telegram, Lark or DingTalk.项目地址https://gitcode.com/gh_mirrors/on/ongrid点击查看免费下载相关推荐Activepieces core 包架构activepieces/core-* 依赖边界与模块分层设计Activepieces core 包架构activepieces/core 依赖边界与模块分层设计 导读 本文讲解 Activepieces 仓库中 pa工作流自动化低代码AI 应用人工智能AI AgentMCP 服务后端前端RustFS 架构深度解析分层数据流、Crate 依赖边界与启动序列RustFS 架构深度解析分层数据流、Crate 依赖边界与启动序列 本文以仓库根目录的 ARCHITECTURE.md https://link.gitco后端对象存储分布式存储sparse-voxel-octrees错误调试与常见问题解决从编译错误到运行时问题的排查指南sparse voxel octrees错误调试与常见问题解决从编译错误到运行时问题的排查指南 sparse voxel octrees是一个CPU稀疏体素八图形学创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考