凌晨三点的古法运维凌晨告警响了服务 api-service 的 P99 延迟从 45ms 飙到 2.3s。SRE 在收到告警后打开笔记本电脑连上 VPN 和跳板机凭自己印象跳到这个告警服务的虚拟机ps aux | grep apinetstat -tlnptail -f /var/log/nginx/error.log。顺着调用链每个服务去确认进程是否还活着、端口是否正常监听、有没有正在刷的错误日志、它依赖了哪些服务。切到阿里云控制台看 ECS 监控、安全组规则等确认机器本身的 CPU/内存/带宽是否打满或安全组有没有被人改过导致流量中断。还要去 Prometheus 查对应时间段的 JVM 指标和连接数以排除应用层面的资源泄漏或下游依赖瓶颈。如果怀疑是变更引起的还需要打开 GitLab 翻最近的 PR 和部署记录。最后去群里问一句 “刚才谁动了什么”以排除人工操作、手动改配置、临时脚本这些东西不在任何工具的记录里。故障分析的证据散落在各个工具角落得自己拼五六个工具、七八次上下文切换、三十分钟过去了。这就是还在坚持古法运维的工程师日常。过去大家在尝试用 AI 解决这个问题。如果仔细看大多数产品走了两条路。第一条路全栈替换式。“你要用我的AI 平台那就把监控、告警、CMDB全切换到我这儿。” 这样做的好处是数据格式可以从头开始约束统一给到AI直接用。但是企业抛弃原有运维团队建设且在稳定运行的 Prometheus、Zabbix、Grafana、Elasticsearch 等工具重新迁移的成本谁来承担谁来保证工具迁移过程的业务可用性第二条路对话外挂式。不替换工具在现有工具上套一层 Chat UI然后 Agent 通过 API 去查。这条路的优势是轻量且不改现有架构。但 AI 拿到的是每次查询返回的独立结果Prometheus 返回一段 JSONK8s 返回一段 YAML阿里云返回一段 XML。这就导致了AI 缺少对环境的整体认知跨工具推理时的上下文断裂根因最终还是得人肉去拼。归根结底是数据归属关系这个东西没有被打通。第一条路的解法是把数据全搬进来统一管理代价太大第二条路压根没碰这个问题。如今的大模型已经具备足够强大的推理大脑。它缺少的其实是一双能触达生产环境的手脚。只要像对待一位真实的运维同事那样赋予它合规的操作权限它就能像人类专家一样自主规划排查路径把散落的孤岛信息自动串联成一条完整的证据链。因此与其他 AIOps 产品不同我们 Ontox 正式发布新一代企业级 Agentic Ops 运维平台 的设计理念是对你现有的工作流完全无侵入因为迁移这些工具链的成本太高而且没有必要。Ontox 连接器做的事让 Agent 替运维人员伸手够数据在排障的过程中SRE 表面上在操作五个工具实际在串一条调查链从告警出发查服务的部署位置查机器的运行状态查关联数据库的连接数查最近的变更记录把线索串起来形成判断Ontox 的连接器想做的其实是同一件事区别在于现在走这条调查链的是 Agent。连接器替 Agent 解决的是一个很具体的问题Agent 有推理能力但没手没脚。它想查一台机器的进程列表但进不去公司的跳板机。它想拉一段 Prometheus 指标但不知道 Prometheus 的地址。它想翻最近的 GitLab PR但没有 GitLab 的 token。连接器就是 Agent 的手和脚。你接好之后Agent 的调查路径变成这样SSH 连接器 → 上去看进程、查连接数、拉错误日志 K8s 连接器 → 查 Pod 状态、看最近部署历史、拉容器日志 Prometheus 连接器 → 拉对应时间段的 JVM 指标、数据库连接数趋势 云连接器 → 查 ECS 规格、安全组规则、RDS 实例状态 GitLab 连接器 → 翻最近两小时的 PR 和变更记录Agent 不会去替代工具Agent 只是获得了操作它们的能力。连接器给 Agent 配了一双可以伸入生产环境的手让它能像运维工程师一样打开这些工具的界面、把分散在各处的证据收集回来。故障场景下 Agent 利用连接器可以给你什么但这里有一个很容易被忽略的问题SRE 收到一份排查报告凭什么信它“数据库连接数过高建议调大 max_connections。”语气很笃定但 SRE 心里一定会追着问几个问题这个结论是从哪来的刚才看了哪些指标怎么排除了其他可能性跟最近那次变更有没有关系排查报告的信任度不取决于结论有多笃定取决于证据链是否完整。比如症状、关联、变更、历史、被排除的方向缺了任何一环SRE 都不敢直接动手改配置。那 Ontox 在这个场景下是如何做的呢Ontox 的连接器跑完一圈之后Agent 会把采回来的数据整理成了一份排查报告当前症状Prometheus 连接器api-service 从 03:12 开始 P99 延迟从 45ms 飙到 2.3s用户下单成功率下降了 16%影响面通过语义网络的调用关系图Agent 找到了关联的订单服务和支付服务——inventory-api 正常但 payment-api 也出现了延迟。部署路径通过语义网络的调用关系图部署架构也是直接可见——服务 api-service当前版本 v2.3运行在 172.30.0.41 上机器是云虚拟机 i-0abc123依赖检查关联的 RDS mysql-prod-02 连接数从 47 飙到 389最近变更GitLab 连接器直接可查到 2 小时前有人 mysql-prod-02 的 max_connections 从 100 调到 200历史参考语义网络知识库上次类似的连接数异常定位为 order-api 连接池 idle timeout 配置过长导致连接泄漏建议动作先看 mysql-prod-02 的慢查询日志确认是连接泄漏还是正常业务高峰Agent 通过连接器自动采、自动关联、自动翻译出来的中间没有一条数据是人工整理的。SRE 只需对 Agent 说一句api-service 慢了剩下的证据链串联和修复方案的事 Agent 它自己走完了。伸手的前提为什么敢让 Ontox 进生产环境聊到这肯定会想Ontox 怎么进的机器SSH 密钥给谁了它会不会乱下命令整个链路的设计原则是三件事密钥不出本地环境、操作默认只读、执行分级审批。真正伸手的是跑在跳板机上的 Ontox Daemon一个轻量可执行文件零外部依赖。SSH 密钥、K8s 集群凭证、云账号 RAM Role全在本地机器上加密存着。Daemon 主动向外发起一条出站加密长连接环境不需要开放任何入站端口。只读操作自动放行高风险操作必须在执行前等审批每一次操作都记录在审计日志里。Ontox 做的是替人动手不是给智能体开了免审批权限。关于安全护栏的三层防线AST 语法审查、策略引擎分级处置、Daemon 硬编码黑名单以及完整的三方信任分离设计详见 《Ontox 正式发布》 一文。五、Agent 的手能伸到哪些地方目前 Ontox 连接器覆盖的范围主机和 VMSSH 连接器Agent 能 SSH 上去看进程、查配置、拉日志自动发现操作系统信息、监听端口、定时任务。排障时这是最直接的现场取证手段服务慢了先上机器看 CPU、内存、连接数、错误日志。K8s 集群K8s 连接器Agent 能进集群看 Pod 状态、查部署历史、拉容器日志、获取 Workload 环境变量。排障时用来回答服务跑在哪、最近是不是有人部署过、Pod 有没有重启。公有云AWS / 阿里云 / 腾讯云 / 火山引擎是目前用得最多的一类连接器。接好之后 Agent 能在云主机上执行命令、拉取文件、查询云资源。排障时一整条链路走通先上云主机执行top看实时负载、cat关键进程的错误日志如果日志量大可以直接拉回完整文件做分析同时顺手查同一时间段 RDS 的连接数有没有异常飙高、安全组规则有没有被人动过。不需要 SSH 密钥也不需要开放入站端口Agent 通过云平台自己的命令通道就能进机器。监控系统Prometheus、Zabbix 等Agent 排障时能直接拉对应时间段的指标历史。不仅支持公网 Prometheus通过 Daemon 也能连接部署在内网的 Prometheus、Zabbix 等监控系统。内网监控数据不需要暴露到公网Agent 通过出站隧道就能拉到。代码和配置GitLab、GitHub 等Agent 能翻最近的 PR、变更记录、部署历史。排障时用来回答故障时间窗口内有没有人改过东西。同样部署在内网的 GitLab 通过 Daemon 也能接进来。自动化工具Ansible、TeleportAgent 能对接已有的运维自动化资产把现有的 Ansible Playbook 和堡垒机体系复用起来不是推倒重建。这些连接器的真正价值在协同。单独看每个都是查询工具串在一起告警 → 指标 → 拓扑 → 机器 → 变更一条证据链贯通。五类连接器各贡献一类证据Agent 交叉验证后形成结论。每一类连接器接上去之后Agent 自动获得了一个新的调查能力。而且这些能力是叠加的接的越多Agent 跨工具关联证据的能力越强。只接 SSHAgent 能巡检机器再接上 Prometheus排障时就能把指标异常和机器现场关联起来再接上 GitLab就能判断是不是变更引起的。证据链一层一层加厚Agent 的结论越来越不需要猜。Ontox 的连接器在持续迭代中会逐步支持更多基础设施和工具类型。如果有特别想接入的系统比如某个监控平台、日志系统、CI/CD 工具欢迎在评论区或加入交流群告诉我们我们会优先排期支持。连接器的权限边界个人私有与团队共享的严格隔离聊到这可能会想我在机器上配的 SSH 私钥团队其他成员和 Agent 对话时可以直接用吗不能。Ontox 把连接器分成了两类从创建那一刻就决定了谁能用。个人连接器绑定的是你个人的身份标识。比如你个人的 SSH 密钥、GitHub Token、云账号 AK/SK 在接入 Ontox 创建连接器的时候设置为个人连接器那这些凭证就只跟你绑定。别人在聊天里让 Agent 排查故障时Agent 根本看不到你的个人连接器。你的密钥就是你的别人碰不了。团队连接器绑的是你在 Ontox 的组织工作区。比如 K8s 集群的 ServiceAccount、公用的 Prometheus 地址、跳板机的共享账号这些在接入的时候连接器类型选团队这样整个组织的团队成员都能用。Agent 做排障时自动就能拿到团队连接器的数据不需要每个人各接一遍。个人连接器做身份识别和权限控制团队连接器做能力共享。不管是哪种连接器Agent 的每一次操作都带着操作人的身份落审计日志。你用个人 SSH 上机器查进程审计日志记的是你同事通过团队 Prometheus 查指标审计日志记的是同事。区别只在于个人连接器的凭证只有你自己能用没人能顶着你的身份进你的机器。实操3 台 VM 1 个 K8s 集群从零接入全记录说这么多接一个连接器到底要多久我拿一个真实环境跑了一遍。我的环境3 台 Linux 虚拟机172.30.0.41/42/43跑着 Nginx Nacos MySQL Redis 的微服务栈1 个 K8s 集群。初识Agent 能做什么我没上来就动手而是先在对话里问 Agent“我刚接触 Ontox你能帮我做什么”Agent 梳理了核心能力故障排查与根因分析、基础设施发现与管理、连接基础设施、变更与事件管理、成本优化然后主动问我你的基础设施是什么样的我告诉 Agent 我有 3 台 Linux 虚拟机和一个 K8s 集群。Agent 据此给出了两套接入方案。轻量化部署能不能只装一个 DaemonAgent 先给出了常规的部署脚本。但我提了一个需求。“能不能只在其中一台 VM 上装一个 Daemon让它通过 SSH 去连另外两台三台 VM 只需要一个 Daemon。”Agent 确认可行调整了架构方案VM1 作为主节点安装 Ontox DaemonVM2 和 VM3 由 VM1 作为跳板通过 SSH 代理访问K8s 集群单独部署一个 Daemon。关键细节不用每台机器都装 Daemon。一台 Daemon 当跳板剩下的机器走 SSH 代理接进来即可。机器多了也一样不需要一台一台去装。按生产环境、测试环境、办公网这些隔离域每个域找一台跳板机装上 Daemon这个域里的机器就全通了。维护量就是这几台跳板机上的 Daemon不是几百上千台机器各装一个。VM Daemon 部署在终端执行安装命令即可完成 Daemon 安装然后配置到另外2台机器 41 和 43 的 SSH 免密登录即可。我跟 Agent 反馈 “VM 的 Daemon 安装好了” Agent 就会刷新状态表以确认 VM1 在线、SSH 代理已创建可连 VM2/VM3、K8s 待部署。然后 Agent 主动贴出 K8s 的一键部署命令引导下一步。K8s Daemon 部署在目标 K8s 操作机上执行同样的安装命令即可一键完成。K8s Daemon 上线创建 K8s 连接器。然后 Agent 反馈目前已经通过 2 个 Daemon 2 个连接器把整个测试环境的基础设施都接入 Ontox 了。小结全程我只做了 3 件事问 Agent 能做什么、描述了环境提了一个轻量化部署的需求装了两个 Daemon、通知 Agent 确认上线其余从方案提出、方案调整、提供 Daemon 安装脚本、到连接器的创建全是 Agent 团队自己干的。跑腿的事交给 Agent判断的事留给人以前排障是这样的。告警响了挨个打开监控面板、日志系统、GitLab 提交记录、群聊消息。每开一个工具心里拼上一块拼图。拼完了结论才出来。Ontox 做的事其实很简单。告警触发的那一刻Agent 已经在替人查了。该拉的指标、该翻的日志、该核对的变更记录。坐下来打开屏幕一份整理好的证据汇总已经在那儿了。不是少了一个排障工具而是多了一个能替人跑腿的调查助理。它不替代现有的 Prometheus、K8s、阿里云控制台。它只是让人不用半夜三点在这些工具之间来回切。后记连接器是 Ontox 的手和脚让 Agent 能伸进生产环境拿到数据。下一篇聊摸底——连接器接好之后Agent 怎么把你的基础设施一次摸清楚产出一份完整的资源现状报告。以及我们也谈谈背后 Ontox 的采集链路是怎么设计的。如果想立即亲身体验可前往 console.ontox.cn或扫码文末的二维码均可直达注册抢先体验注册即送 2000 积分够接三台服务器跑完整采集和排障场景。如果你也在关注 AIOps、Agent 运维、可观测性、生产环境中的 AI 安全边界欢迎扫码加入Ontox交流群一起探索 AI 运维的正确打开方式。
