当前环境主要包含n8n、Jumpserver、K8s、Prometheus和Loki等组件。本方案旨在实现以下三个核心需求:1)识别并自动执行人类意图指令;2)监控故障并进行自我修复;3)发现问题并提供修复方案。
一、 核心架构设计
AIOps智能体并非单一程序,而是一个由多个组件协同工作的系统。其架构可分为四个层次:
- 交互与意图层:作为智能体的指令接收与反馈通道,负责接收用户指令并反馈处理结果。
- 决策与编排层:作为智能体的分析与调度中枢,负责理解用户意图、分析数据、做出决策并编排后续任务。
- 监控与数据层:作为智能体的数据采集与存储中心,负责收集系统状态、日志和性能指标。
- 执行与控制层:作为智能体的操作执行单元,负责在目标系统上执行具体的修复或操作指令。
二、 各组件在架构中的角色
| 组件 | 在 AIOps 智能体中的角色 | 核心功能 |
|---|---|---|
| n8n | 核心工作流引擎 / 系统总线 | 连接所有组件,编排自动化流程,处理 Webhook 触发,是整个智能体的“中枢神经系统”。 |
| Prometheus | 监控指标来源 | 实时收集 K8s 和其他服务的性能指标(CPU、内存、请求延迟等),并触发告警。 |
| Loki | 日志数据来源 | 聚集所有 K8s Pod 和服务的日志,为问题诊断提供上下文。 |
| Kubernetes (K8s) | 主要操作对象 | 应用运行的底层平台,智能体的很多操作(如重启、扩缩容)都直接作用于 K8s API。 |
| Jumpserver | 安全执行通道 | 当需要在 K8s 节点或虚拟机上执行高危命令时,通过 Jumpserver 的 API 安全地执行,并记录所有操作。 |
| LLM (大语言模型) | 智能决策核心 | 用于自然语言意图识别、根因分析、生成修复脚本。可以是 OpenAI API、 DeepSeek以及本地部署的模型。 |
三、 功能实现路径(分阶段落地)
建议从简单到复杂,分阶段实现,逐步构建您的 AIOps 智能体。
阶段一:基础自动化与告警闭环
这是最核心且能立即产生价值的第一步。
目标:实现 Prometheus 告警 -> n8n 自动处理 -> 执行修复 -> 结果反馈的完整闭环。
实现步骤:
- 配置 Prometheus 告警:
- 在 Prometheus 中定义关键的告警规则,例如
K8sPodCrashLooping、HighCPUUsage、ServiceDown。 - 配置 Alertmanager,将告警路由发送到 n8n 的 Webhook URL。
- 在 Prometheus 中定义关键的告警规则,例如
- 在 n8n 中创建告警处理工作流:
- 触发节点:使用
Webhook节点接收来自 Alertmanager 的告警 JSON 数据。 - 决策节点:使用 IF 或 Switch 节点,根据告警的标签(如 alertname)来判断问题类型。
- 执行节点:
- 对于 K8s 问题:使用 HTTP Request 节点调用 K8s API。例如,收到 PodCrashLooping 告警,可以调用 API 删除 Pod,让 K8s 自动重建。
- 对于节点问题:使用 HTTP Request 节点调用 Jumpserver 的 API,创建一个自动化任务,在指定节点上执行命令(如
systemctl restart docker)。
- 通知节点:使用
Slack、Email或DingTalk节点,将处理结果(成功/失败)发送给运维团队。
- 触发节点:使用
示例工作流:(处理 Pod 崩溃)
Webhook (接收告警) --> IF (判断 alertname == K8sPodCrashLooping) --> Code (解析 JSON, 提取 namespace, pod_name) --> HTTP Request (调用 K8s API 删除 Pod) --> Slack (发送 "Pod {pod_name} 已重启" 消息)
阶段二:问题诊断与日志关联
目标:当告警发生时,智能体能自动查询相关日志,提供更丰富的上下文,甚至给出初步的修复建议。
实现步骤:
- 扩展 n8n 工作流:
- 在阶段一的工作流中,决策节点之后、执行节点之前,增加日志查询步骤。
- 日志查询节点:使用 HTTP Request 节点,根据告警信息(如 pod_name, namespace)构建 Loki 的查询语句(LogQL),查询该 Pod 最近一段时间的错误日志。
- 日志分析节点:
- 简单规则:使用 Code 节点(如 JavaScript)检查日志中是否包含特定关键词(如
OutOfMemoryError,Connection refused)。 - 智能分析 (进阶):将查询到的日志作为上下文,调用 LLM API,让 LLM 总结日志内容并给出可能的原因。
- 简单规则:使用 Code 节点(如 JavaScript)检查日志中是否包含特定关键词(如
- 增强决策逻辑:
- 根据日志分析的结果,动态选择不同的修复策略。
- 例如:如果日志发现是
OutOfMemoryError,则执行 K8spatch操作,增加 Pod 的 memory limits;如果是Connection refused,则检查相关的 Service 和 Endpoints。

阶段三:意图识别与指令下发
目标:让运维人员可以通过自然语言与智能体交互,实现“说人话”就能运维。
实现步骤:
- 搭建交互入口:
- 可以是一个聊天机器人(如 Slack Bot, Teams Bot),或者一个简单的 Web 界面。
- 用户的指令通过 Webhook 发送到 n8n。
- 在 n8n 中创建意图识别工作流:
- 触发节点:
Webhook节点接收用户的自然语言指令(如“把生产环境的 user-service 扩容到 5 个副本”)。 - 意图识别节点:
- 调用 LLM API。设计一个高质量的 Prompt,要求 LLM 将自然语言转换为结构化的 JSON。
- Prompt 示例:
你是一个运维指令解析器。请将用户的指令解析为 JSON 格式,包含 action, target, namespace, replicas 等字段。如果无法解析,返回 {"error": "invalid command"}。 用户指令: "把生产环境的 user-service 扩容到 5 个副本" 输出 JSON:
- 指令执行与反馈:
- 代码节点:解析 LLM 返回的 JSON。
- 执行节点:根据 action 字段,调用不同的执行模块(如 K8s API, Jumpserver API)。
- 反馈节点:将执行结果(如“已成功将 user-service 扩容至 5 个副本”)通过聊天机器人返回给用户。
- 触发节点:
{
"action": "scale",
"target": "deployment/user-service",
"namespace": "production",
"replicas": 5
}
