观测云 Agent 让告警先到，分析随后
本文介绍如何通过观测云 Agent 构建“告警先到、分析随后”的智能故障响应流程：事件触发后即时推送原始告警，同时由 Agent 异步结合观测数据完成分析并补充 AI 总结，兼顾告警时效、分析质量与使用成本，帮助团队提升故障定位与协同排障效率。
一、场景：既要告警及时，也要分析有用
在日常运维中，把监控事件推送到企业微信、钉钉或飞书群聊已经非常常见。随着 AI 进入故障响应流程，团队通常还希望机器人能够结合观测数据给出分析结论，帮助值班工程师更快缩小故障范围。
真正的难点不在于“能不能分析”，而在于如何同时满足两种不同诉求：原始事件必须第一时间送达，AI 分析则可以稍后到达，但结论必须准确、可解释，并能为下一步排障提供方向。
| 通知阶段 | 发送内容 | 核心要求 | 是否消耗 AI Token |
|---|---|---|---|
| 第一次 | 原始事件信息 | 时效优先。事件产生后应尽快进入群聊，避免等待 AI 分析。 | 否 |
| 第二次 | 基于事件及平台数据生成的 AI 分析 | 质量优先。结合相关观测数据缩小故障范围，并给出排障方向。 | 是 |
核心思路：让 Agent 在收到事件后先原样转发，再异步完成调查与总结。这样既不会让告警通知被模型推理阻塞，也能把 AI 能力放在真正需要分析的环节。实际 Token 消耗取决于事件数量、分析上下文和模型配置。
整体链路：监控器触发事件 → 告警策略把事件交给 Agent → Agent 即时转发到群聊 → Agent 调查分析 → 群聊收到 AI 总结。
二、开始前的准备
开始配置前，请确认以下条件已经满足：
- 观测云工作空间中可以进入 Obsy Agent Teams，并具备创建 Agent、告警策略、消息渠道和任务接入的权限。
- 准备一台用于运行 Agent 的主机。本文示例使用 4 核 8 GB 及以上配置的 ECS，并使用 root 权限完成安装。
- 已经在目标 IM 平台创建机器人应用，并获得接入消息渠道所需的凭证。本文以飞书的 App ID 和 App Secret 为例。
- 工作空间中至少有一个可触发的监控器，便于进行端到端验证。
三、创建并部署 Agent
1. 从模板创建“故障响应专家”
在工作空间右上角打开「Obsy AI」，选择「进入 Obsy Agent Teams」，然后新建 Agent。
图 1｜从 Obsy AI 进入 Obsy Agent Teams
在 Agent 模板中选择「故障响应专家」。该模板已经预置了面向生产故障响应的身份定义和行为边界，适合作为本实践的起点。
图 2｜选择“故障响应专家”模板
检查引导页中的身份定义、可用范围和行为边界。若暂时不需要定制，可保持模板默认设置并继续。
图 3｜确认 Agent 的身份定义与行为边界
完成创建后，安装引导会生成与当前 Agent 对应的安装命令。复制命令，然后点击「完成」。
图 4｜复制 Agent 运行服务安装命令
2. 在 ECS 上安装运行服务
登录准备好的 ECS，使用 root 权限执行刚刚复制的安装命令。安装完成后，按照终端提示检查 obs-agent 服务状态。
图 5｜在 ECS 上执行安装命令
图 6｜检查 obs-agent 服务运行状态
返回 Agent 工作台。当 Agent 状态显示为「在线」时，说明运行服务已经成功接入工作空间。
图 7｜确认 Agent 已在线
四、把事件交给 Agent
1. 在告警策略中将 Agent 设为通知成员
创建或编辑一条告警策略，根据实际需求关联监控器和通知配置。在本文示例中，策略关联 CPU 利用率阈值监控器，并把「全部」等级的事件发送给「故障响应专家」。
图 8｜在告警策略中关联监控器并选择 Agent
调试监控器，确认事件可以正常触发。最直接的检查方式是在「事件中心」中找到该监控器产生的事件。
图 9｜在事件中心确认监控事件已产生
如果事件中心没有数据，请先解决监控器触发问题；如果事件已经产生但 Agent 没有收到任务，请重点检查告警策略是否关联了正确的 Agent。
五、把 Agent 接入群聊
1. 创建消息渠道
消息渠道用于把 Agent 接入微信、企业微信、钉钉、飞书等外部消息平台，从而实现事件通知和群内 @Agent 互动。本文以飞书为例。
在 Agent 工作台中进入「消息渠道」，点击「新建消息渠道」。
图 10｜在 Agent 工作台****中新建消息渠道
按照飞书开放平台的接入指引配置机器人应用，再把 App ID 和 App Secret 填入观测云消息渠道。
图 11｜填写飞书机器人凭证
保存后，确认消息渠道状态显示为「已连接」。
图 12｜确认飞书消息渠道连接成功
2. 将 Agent 加入目标群聊
把机器人加入用于接收告警的飞书群聊，并通过一次简单对话确认机器人能够正常响应。
图 13｜在飞书群聊中验证 Agent 可正常对话
六、配置任务接入：先转发，再分析
「任务接入」负责把工作空间事件或外部业务系统消息交给指定 Agent 自动处理。本场景需要编辑工作空间级别的事件任务，并把处理结果投递到刚刚创建的飞书消息渠道。
在 Agent 工作台中进入「配置」-「任务接入」，找到对应的工作空间任务并打开编辑。
图 14｜找到工作空间级别的任务接入
在「消息渠道投递」中选择目标飞书群聊，并打开「收到事件时立即发送」开关，然后保存。
图 15｜选择消息渠道并开启“收到事件时立即发送”
| 字段 | 推荐配置 | 说明 |
|---|---|---|
| 名称 | 按团队规范自定义 | 建议包含业务、场景或 Agent 名称，便于后续识别。 |
| 执行周期 | 立即处理 | 收到事件后立即开始转发和分析。若选择 1、2、5 或 15 分钟，Agent 会按周期聚合该时间段内的事件后再分析。 |
| 消息渠道投递 | 选择目标群聊 | 选择前一步已经接入并验证成功的消息渠道。 |
| 收到事件时立即发送 | 开启 | 开启后，Agent 先发送原始事件，再在分析完成后发送 AI 总结；关闭后只发送 AI 总结。 |
本实践的关键组合是「执行周期：立即处理」+「收到事件时立即发送：开启」。前者决定任务何时开始，后者决定群聊是否先收到原始事件。
七、验证端到端效果
配置完成后，建议同时观察观测云工作空间、Agent 工作台和飞书群聊，验证事件是否及时到达，以及 AI 分析是否随后补充。本文示例的结果如下。
1. 工作空间产生事件
监控器在 17:12 产生一条 CPU 利用率阈值事件。
图 16｜观测云工作空间中的事件数据
2. Agent 在同一分钟收到并处理事件
Agent 工作台显示该任务在 17:12 收到事件，符合「立即处理」的配置预期。
图 17｜Agent 在 17:12 收到事件任务
打开任务记录，可以查看 Agent 接收事件、查询数据、形成判断并生成总结的处理过程。
图 18｜查看 Agent 的事件处理过程
3. 群聊先收到原始事件
飞书群聊在 17:12 收到工作空间事件信息，证明原始告警没有等待 AI 分析完成。
图 19｜飞书群聊第一时间收到原始事件
4. 分析完成后补充 AI 总结
Agent 随后继续调查，并在工作台中保留分析过程，便于回看与复核。
图 20｜Agent 完成事件调查与分析
飞书截图显示 AI 分析在 5:14 PM 发送，对应 24 小时制的 17:14。与 17:12 的原始事件相比，分析总结约在两分钟后到达。
图 21｜飞书群聊收到 AI 分析总结
| 时间 | 链路节点 | 验证结果 |
|---|---|---|
| 17:12 | 观测云监控器产生事件 | 事件中心可见事件详情 |
| 17:12 | Agent 收到事件并转发到群聊 | 原始事件在同一分钟送达 |
| 17:14 | Agent 完成分析并发送 AI 总结 | 分析耗时约 2 分钟 |
八、结语
通过观测云 Agent，团队可以把传统“只负责转发”的告警机器人升级为故障响应助手：事件发生时先把事实及时送到人，随后再利用平台内的观测数据补充 AI 分析。这样的双阶段通知方式兼顾了时效、信息质量与使用成本，也为后续在群聊中继续追问、协同排障和沉淀经验打下基础。
建议从一个低风险、容易复现的监控器开始试点，验证事件接入、消息投递和分析质量后，再逐步扩大到更多业务系统和告警场景。
