Aiops探索:基于jumpserver+dify的aiops方案设计
作者：微信文章↑↑↑ 点击关注，分享IT技术|职场晋升技巧|AI工具
最近一直在探索和研究智能运维平台的可落地方案，说实话难度很大，因为很多细节在当前的技术背景下落地难度还是有点大。我们不妨曲线救国，与其做平台要考虑各种复杂场景，不如先实现和落地某一项功能模块。所以，当前我研究的方向为自动化运维智能体！
前几天发表了一篇n8n+jumpserver的文章（Aiops探索：基于jumpserver+n8n的aiops方案设计），有个同学想让我出个dify版本的。其实，我想说的是做aiops用n8n更灵活一些，优于dify或者coze。但，既然同学提了这个需求，那我就搞一下吧。
整体的架构设计如下：
Dify 和 JumpServer 在这个 AIOps 平台中扮演的角色：
1）Dify (大脑与交互层):
AI 大脑:
负责理解运维人员的自然语言指令（如“重启生产环境的 web01 服务器”）、分析告警信息、从知识库中检索解决方案。
工作流引擎:
编排和自动化一系列运维操作。
交互入口:
提供聊天机器人（Web、Slack、飞书等）或 API，作为运维人员与系统交互的统一入口。
2）JumpServer (手脚与安全守卫):
安全执行层:
提供对服务器、数据库、网络设备等资产的统一、安全的访问入口。所有命令都通过 JumpServer 执行，确保操作可审计、可追溯。
权限管理中心:
精细化控制谁（用户）能在什么时间、通过什么方式、对哪些资产执行什么操作。
操作审计:
记录所有会话和命令，为事后追溯和合规性检查提供数据源。工作流程是这样的：1）输入:运维人员通过 Dify 提供的聊天界面输入指令，或者监控系统将告警发送到 Dify 的 Webhook。2）理解与决策:Dify 的 LLM 模型理解输入意图，并查询知识库，判断需要执行什么操作。3）安全编排:Dify 通过工作流调用 JumpServer 的 API。4）认证与授权:JumpServer 验证 API 请求的合法性，并检查 Dify 的 API 账号是否有权限执行目标操作。5）执行与审计:JumpServer 连接到目标资产，执行命令（如 systemctl restart nginx），并详细记录操作过程。6）反馈:JumpServer 将执行结果返回给 Dify，Dify 将结果以自然语言的形式反馈给运维人员。分享几个应用场景思路：场景一：智能运维助手
运维人员可以直接用自然语言与系统对话，完成日常操作。
用户发起意图："帮我查一下 k8s-node-3 这台服务器的 CPU 使用率和内存占用情况。"
Dify会做下面5件事情:
1）识别意图：查询服务器状态。
2）识别实体：服务器名为 k8s-node-3。
3）调用 JumpServer API，在 k8s-node-3 上执行 top -bn1 | grep "Cpu(s)" 和 free -m 命令。
4）解析返回的命令结果。
5）用自然语言组织回答："k8s-node-3 的 CPU 使用率是 35%，内存已用 8GB，总共 16GB。"
JumpServer: 安全地执行命令并记录日志。
场景二：告警智能分析与自愈
监控系统（如 Prometheus）触发告警后，自动进行分析和修复。
触发: Prometheus 检测到prod-web-01 服务器的 Nginx 进程宕机，发送告警到 Dify Webhook。
Dify会做：
1）接收告警，解析出关键信息：服务器 prod-web-01，服务 Nginx，问题 down。
2）查询知识库，找到 "Nginx 进程宕机" 的标准处理预案（SOP）。
3）按照预案自动执行：
a. 调用 JumpServer API，执行 systemctl status nginx 确认状态。
b. 调用 JumpServer API，执行 systemctl restart nginx 尝试重启。
c. 再次调用 JumpServer API，执行 systemctl status nginx 确认是否恢复。
4）如果恢复，发送通知："告警已处理，prod-web-01 的 Nginx 已成功重启。"
5）如果未恢复，升级告警，通知高级运维工程师，并附上所有执行日志。
JumpServer: 提供了所有自动化操作的安全通道和审计记录。
场景三：运维知识库智能构建与查询
将 JumpServer 的审计日志作为数据源，反哺 Dify 的知识库。
构建: 定期脚本从 JumpServer 拉取高危操作、高频命令、故障处理会话等审计日志，经过清洗和总结后，自动上传到 Dify 的知识库。
查询:
用户: "上次处理 Redis 内存溢出是怎么做的？"
Dify: 从知识库中检索相关的历史会话记录和解决方案，并给出总结。
Dify中的工作流构建
这是整个方案的核心。我们以“智能运维助手”为例。
1）创建应用: 在 Dify 中创建一个新的“Agent”或“Workflow”类型应用。2）配置知识库 (可选但推荐): 上传你的运维文档、SOP、历史故障报告等，让 AI 更专业。3）设计工作流:
开始节点: 接收用户输入。LLM 节点 (意图识别):
Prompt 示例: "你是一个运维助手。分析用户的意图，并提取出关键信息，如服务器名、要执行的命令等。如果意图不明确或操作危险，请拒绝并询问。用户输入：{{input}}"输出变量: intent (查询/执行), server_name, command 等。
条件判断节点:
如果 intent 是 "查询"，则进入查询分支。如果 intent 是 "执行"，则进入执行分支。如果意图不明，则让 LLM 直接回复用户。
执行分支 - HTTP 请求节点 (调用 JumpServer API):
这是与 JumpServer 交互的关键。URL:http://<your-jumpserver-url>/api/v1/authentication/auth/ (先获取 Token) 或直接使用其他需要 Token 的 API。方法: POSTHeaders: 设置 Content-Type: application/json 和 Authorization: Token <your-jumpserver-token>。Body: 根据 JumpServer API 文档构建请求体。例如，执行命令的 API 可能需要 asset_id 和 command。如何获取 asset_id? 你可能需要先调用另一个 JumpServer API (/api/v1/assets/assets/) 来根据 server_name 查询 asset_id。这可以通过在 LLM 节点后加一个 HTTP 请求节点来实现。
代码节点 (处理复杂逻辑 - 可选): 如果 API 调用逻辑复杂（如需要先获取 Token 再调用业务 API），可以使用代码节点（如 Python）来处理。LLM 节点 (结果总结):
将 HTTP 请求节点返回的原始命令输出作为输入。Prompt 示例: "这是服务器 '{{server_name}}' 执行命令 '{{command}}' 的结果：{{http_response_result}}。请用自然语言总结一下这个结果。"
结束节点: 将最终结果返回给用户。
最后介绍下我的大模型课：我的运维大模型课上线了，目前还在预售期，有很大优惠。AI越来越成熟了，大模型技术需求量也越来越多了，至少我觉得这个方向要比传统的后端开发、前端开发、测试、运维等方向的机会更大，而且一点都不卷！
扫码咨询优惠（邀你进免费交流群）
··············END··············哈喽，我是阿铭，《跟阿铭学Linux》作者，曾就职于腾讯，有着18年的IT从业经验，现全职做IT类职业培训：运维、k8s、大模型。日常分享运维、AI、大模型相关技术以及职场相关，欢迎围观。
页:
[1]