免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


Aiops探索:用n8n+jumpserver+k8s+prometheus+Loki落地aiops的方案

发布日期:2025-10-17 17:48:46 浏览次数: 1539
作者:阿铭linux

微信搜一搜,关注“阿铭linux”

推荐语

探索如何利用n8n、Jumpserver、K8s等工具构建AIOps系统,实现自动化运维与智能修复。

核心内容:
1. AIOps系统的四层架构设计:交互与意图层、决策与编排层、监控与数据层、执行与控制层
2. 各组件在系统中的角色与功能,如n8n作为核心工作流引擎,Prometheus提供监控指标
3. 分阶段实现路径,从基础自动化与告警闭环开始,逐步构建完整的AIOps智能体

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
↑ 点击关注,分享IT技术|职场晋升技巧|AI工具

我的环境大体上有这些东西:n8n+jumpserver+k8s+prometheus+Loki,而我的设想是:1)识别人类意图并自动下发和执行指令;2)监控故障并自我修复;3)问题发现并给出修复方案。暂时先这3条需求。

一、 核心架构设计

首先来说,这个AiOps 智能体不是一个单一程序,而是一个由多个组件协同工作的系统。我们可以将其分为四个层次:

1、交互与意图层:智能体的“耳朵”和“嘴巴”,负责接收指令和反馈结果。
2、决策与编排层 :智能体的“大脑”,负责理解意图、分析数据、做出决策并编排后续任务。
3、监控与数据层 :智能体的“眼睛”和“记忆”,负责收集系统状态、日志和指标。
4、执行与控制层:智能体的“手”,负责在目标系统上执行具体的修复或操作指令。

二、 各组件在架构中的角色

组件
在 AIOps 智能体中的角色
核心功能
n8n 核心工作流引擎 / 系统总线
连接所有组件,编排自动化流程,处理 Webhook 触发,是整个智能体的“中枢神经系统”。
Prometheus 监控指标来源
实时收集 K8s 和其他服务的性能指标(CPU、内存、请求延迟等),并触发告警。
Loki 日志数据来源
聚集所有 K8s Pod 和服务的日志,为问题诊断提供上下文。
Kubernetes (K8s) 主要操作对象
应用运行的底层平台,智能体的很多操作(如重启、扩缩容)都直接作用于 K8s API。
Jumpserver 安全执行通道
当需要在 K8s 节点或虚拟机上执行高危命令时,通过 Jumpserver 的 API 安全地执行,并记录所有操作。
LLM (大语言模型) 智能决策核心
 用于自然语言意图识别、根因分析、生成修复脚本。可以是 OpenAI API、 DeepSeek以及本地部署的模型。

三、 功能实现路径(分阶段落地)

建议从简单到复杂,分阶段实现,逐步构建你的 AIOps 智能体。

阶段一:基础自动化与告警闭环

这是最核心、最能立即产生价值的一步。

目标: 实现 Prometheus 告警 -> n8n 自动处理 -> 执行修复 -> 结果反馈的完整闭环。

实现步骤:

1. 配置 Prometheus 告警

  • 在 Prometheus 中定义关键的告警规则,例如 K8sPodCrashLoopingHighCPUUsageServiceDown
  • 配置 Alertmanager,将告警路由发送到 n8n 的 Webhook URL。

2. 在 n8n 中创建告警处理工作流

  • 触发节点:使用 Webhook 节点接收来自 Alertmanager 的告警 JSON 数据。
  • 决策节点:使用 IF 或 Switch 节点,根据告警的标签(如 alertname)来判断是什么类型的问题。
  • 执行节点:
    • 对于 K8s 问题 :使用 HTTP Request 节点调用 K8s API。例如,收到 PodCrashLooping 告警,可以调用 API 删除 Pod,让 K8s 自动重建。
    • 对于节点问题 :使用 HTTP Request 节点调用 Jumpserver 的 API,创建一个自动化任务,在指定节点上执行命令(如 systemctl restart docker)
  • 通知节点:使用 SlackEmail 或 DingTalk 节点,将处理结果(成功/失败)发送给运维团队。

示例工作流:处理 Pod 崩溃)

Webhook (接收告警) -> IF (判断 alertname == K8sPodCrashLooping) -> Code (解析 JSON, 提取 namespace, pod_name) -> HTTP Request (调用 K8s API 删除 Pod) -> Slack (发送 "Pod {pod_name} 已重启" 消息)


阶段二:问题诊断与日志关联

目标: 当告警发生时,智能体能自动查询相关日志,提供更丰富的上下文,甚至给出初步的修复建议。

实现步骤:

1. 扩展 n8n 工作流

  • 在阶段一的工作流中,决策节点之后、执行节点之前,增加日志查询步骤。
  • 日志查询节点:使用 HTTP Request 节点,根据告警信息(如 pod_name, namespace)构建 Loki 的查询语句(LogQL),查询该 Pod 最近一段时间的错误日志。
  • 日志分析节点:
    • 简单规则 :使用 Code 节点(如 JavaScript)检查日志中是否包含特定关键词(如 OutOfMemoryError, Connection refused)。
    • 智能分析 (进阶):将查询到的日志作为上下文,调用 LLM API,让 LLM 总结日志内容并给出可能的原因。

2. 增强决策逻辑

  • 根据日志分析的结果,动态选择不同的修复策略。
  • 例如:如果日志发现是 OutOfMemoryError,则执行 K8s patch 操作,增加 Pod 的 memory limits;如果是 Connection refused,则检查相关的 Service 和 Endpoints。

阶段三:意图识别与指令下发

目标: 让运维人员可以通过自然语言与智能体交互,实现“说人话”就能运维。

实现步骤:

1. 搭建交互入口

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

最后介绍下我的大模型课:我的运维大模型课上线了,目前还在预售期,有很大优惠。AI越来越成熟了,大模型技术需求量也越来越多了,至少我觉得这个方向要比传统的后端开发、前端开发、测试、运维等方向的机会更大,而且一点都不卷!

扫码咨询优惠(邀你进免费交流群)

··············  END  ··············
哈喽,我是阿铭,《跟阿铭学Linux》作者,曾就职于腾讯,有着18年的IT从业经验,现全职做IT类职业培训:运维、k8s、大模型。日常分享运维、AI、大模型相关技术以及职场相关,欢迎围观。

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询