运维新突破：Prometheus+DeepSeek+Dify实现自动巡检

发布时间：2025-11-05 02:43:08 来源：创站工坊 作者：人工智能

作者 | 崔皓

审校 | 重楼

整体思路

在日常运维中，新突现自经常会遇到类似的动巡问题：明明系统前一天运行正常，第二天登录量突然下降，新突现自却要花费大量时间去手工检查日志、动巡排查 Prometheus 指标，新突现自再整理成报告发给业务方。动巡这类重复、新突现自耗时的动巡工作不仅影响效率，还容易出现遗漏。新突现自于是动巡，我就产生了一个想法：能不能把这种巡检工作自动化？新突现自正好最近在研究 Prometheus 指标采集、定时任务和大模型工作流，动巡于是新突现自就设计了一个小实验，把“登录统计”作为切入点，动巡完整演示了如何实现自动化巡检的新突现自闭环。

通常在日常运维中，我们会关注 CPU、磁盘、内存等硬件资源的健康状况，而这里我将巡检对象替换成了“用户登录信息”，以此作为示例。流程是这样的：首先通过自定义的 Prometheus Exporter 生成用户登录相关的指标数据；然后由 Prometheus Server 来采集这些指标；接着使用 crontab 配合定时脚本（inspector.sh）周期性地巡检和获取数据；最后，脚本会调用 Dify 的工作流，免费信息发布网将巡检结果进一步加工，结合知识库和脚本逻辑生成一份清晰的报告。这样做的意义在于：不仅实现了定时化、自动化的巡检，而且把数据采集、指标处理和智能化的结果生成串联起来，形成一个可复用的运维自动化方案。换句话说，这篇文章的核心，是通过“登录指标替代传统硬件指标”的例子，向读者展示如何用 Prometheus + 定时任务 + Dify 工作流，把常见的运维巡检场景落地成一个完整的自动化闭环。

接下来，我们来整理一下文章的顺序。我们会先创建 Dify 工作流，工作流中根据采集到的用户登录情况，创建初步的运维方案，然后通过工作流内置的知识库检索生成详细运维方案。然后在创建定时巡检的香港云服务器脚本 Inpector.sh 利用它调用工作流。接着设置定时任务，定时从 Prometheus 中拉取 Metrics 指标数据作为要监控的信息，并且调用Inpector.sh 让 Dify 工作流返回的信息作为方案生成最终的运维执行报告。

安装 Dify

首先我们尝试安装 Dify，这里我们会选择在本地使用 Docker 安装 Dify。

前提条件

安装 Dify 之前, 请确保你的机器已满足最低安装要求：

操作系统

软件

描述

macOS 10.14 or later

Docker Desktop

为 Docker 虚拟机（VM）至少分配 2 个虚拟 CPU(vCPU) 和 8GB 初始内存，否则安装可能会失败。

Linux platforms

Docker 19.03 or later

Docker Compose 1.28 or later

请参阅安装 Docker 和安装 Docker Compose

以获取更多信息。

Windows with WSL 2 enabled

Docker Desktop

我们建议将源代码和其他数据绑定到 Linux 容器中时，将其存储在 Linux 文件系统中，而不是 Windows 文件系统中。

克隆 Dify 代码仓库

克隆 Dify 源代码至本地环境。

启动容器

进入 Dify 源代码的 Docker 目录：

复制环境配置文件：

可以修改 .env 中 Nginx 的端口，默认的端口是 80 ，我们修改成 8085。避免与本机的 80 端口冲突。

启动 Docker 容器：

根据你系统上的 Docker Compose 版本，选择合适的命令来启动容器。你可以通过 $ docker compose version 命令检查版本，详细说明请参考Docker 官方文档：

如果版本是亿华云 Docker Compose V2，使用以下命令：

如果版本是 Docker Compose V1，使用以下命令：

运行命令后，你应该会看到类似以下的输出，显示所有容器的状态和端口映射：

最后检查是否所有容器都正常运行：

在这个输出中，你应该可以看到包括 3 个业务服务 api / worker / web，以及 6 个基础组件 weaviate / db / redis / nginx / ssrf_proxy / sandbox 。

通过这些步骤，你可以在本地成功安装 Dify。通过 Docker Desktop 看到的就是如下图的样子。

启动 Dify

由于我们之前修改了入口的端口号， 这里需要通过 8085 端口访问 dify，如下：

接着会进入界面，设置管理员邮箱，名称和密码。

然后按照下面页面的方式，登录就好了。

配置 LLM

在用户的“配置”界面，点击“模型供应商”，添加如下图所示的供应商。

这里 DeepSeek 用来做模型推理，使用 SILICONFLOW 提供的 BAAI 模型完成向量数据库的嵌入操作。

创建 workflow

工作流步骤描述如下：

提取参数

参数提取器，需要将自然语言转化为参数，说白了就是要提取自然语言中的关键信息。本例中，登录的总人数和登录异常人数就是关键信息。此处会使用 LLM 帮助我们提取信息，因此需要给 LLM 指令如下：

获取关键信息之后，会通过“代码执行”判断采取的具体方案。由于“代码执行”是“参数提取器”的下游节点，所以在“代码执行”中会对标“参数提取器”中的两个输出参数，作为自己节点的输入参数。如下图所示，total_login 和 failed_login_count 作为“参数提取器”输出参数，并作为“代码执行”的输入参数，输入到“PYTHON3”的函数脚本中。

执行代码

在完成提取参数之后，我们得到了登录总人数和登录失败人数的关键信息，接着需要得到初步的解决方案。这里需要用到代码执行器，按照登录失败的比例进行判断，给出方案信息。

代码执行器，python 脚本如下：

如上脚本所示，它是针对登录系统异常的自动化分析与处置建议工具，核心功能是基于总登录人数与异常登录人数，通过计算异常率（保留 2 位小数）并匹配 5 级异常分级标准，输出精准的对应处理方案。脚本首先会处理 “总登录人数为 0” 的边界情况，提示检查指标采集有效性；在正常计算场景下，会根据异常率≤2%（轻微异常）、2%-5%（一般异常）、5%-10%（中度异常）、10%-20%（严重异常）、>20%（紧急异常）的不同区间，分别生成从监控跟踪、日志抽样到资源扩容、灾备启动、跨团队协同响应等不同粒度的操作建议，涵盖监控策略、服务检查、资源调整、人员通知、进度跟踪等全流程动作。

需要注意的是，这里返回的“建议”方案只是初步方案会为后期详细方案的搜索和生成提供重要指引。

创建知识库

在完成初步方案的生成之后，我们需要针对初步方案搜索“运维知识库”，从而生成更加详细的方案。这里需要提前将知识库建立起来。

如下图所示，在 Dify 中点击“知识库”，并且“创建知识库”。

如下图所示，通过“选择文件”导入文件。

这里导入的文件就是我们的“运维知识库”。如下图所示，文件内容按照操作类型，使用场景进行分类。可以通过“代码执行”提供的解决方案在该文档中查找更多信息，从而细化解决方案。

接着选择文档切割的方式以及文本嵌入的方式，如下图所示。

界面中可设置文本分段相关参数，如分段标识符（这里是\n\n，即两个换行符，用于标识文本分段位置）、分段最大长度（500 tokens，tokens 是模型处理文本的基本单位，限制单段文本长度）、分段重叠长度（50 tokens，控制相邻分段间重叠的 token 数量）；还有文本预处理规则，比如替换连续空格、换行符等；以及索引方式（提供 “高质量” 和 “经济” 两种，影响检索精度与成本）和Embedding 模型（这里选择的是BAAI/bge - m3，Embedding 模型用于将文本转化为向量表示，助力后续检索等操作）。

这里需要补充一下，知识库嵌入时需要文本切割和上下文覆盖（分段覆盖）的原因：

接着，我们就可以设置“知识检索”的内容，如下图所示，选择“查询变量”为“代码执行”的 result 也就是返回的“结果”，我们可以回想一下在“代码执行”中会返回“初步的方案”，这里以result 变量的方式输入到“知识检索”中。

换句话说，就是将“代码执行”得到的初步解决方案放到知识库中进行检索，从而得到细化之后的解决方案。

大模型生成报告

好了，到了这里就需要将细化之后的解决方案生成运维报告，指导运维工程师处理登录异常的问题。我们需要利用大模型加上提示词完成，如下图所示，在系统提示词中处理登录总人数和失败人数以外，还需要加入“上下文”。 这个“上下文”就是从知识库中检索出来的细化之后的方案。

测试工作流

通过上面一顿操作，工作流就创建完毕了，接着让我们测试工作流是否正常运行。

如下图所示，在工作流的“开始”节点，添加参数“user_query”，顾名思义就是用输入的参数，用来接受用户输入的内容。然后，点击右上角的“运行”按钮，在“user_query”中输入请求。

输入请求内容如下，很明显包含了登录总人数，成功登录人数，以及失败人数的信息。

一共 2350 人登录，成功 2218 人，失败 132 人。

可以在右边栏中看到结果和追踪信息。如下图所示，可以查看工作流每个步骤的执行时间和执行内容， 在“结束”节点中可以看到最终结果。

Agent 接入工作流

在完成工作流之后，我们还可以将工作流接入到 Dify 的 Agent 中，这是为了方便客户端进行更好的使用，比如我们可以与工作流进行对话，询问一些运维相关的处理意见。

需要注意的是，在本例中这个步骤属于支线任务，可做可不做，接入 Agent 的做法是让我们对 Dify 工作流有更好的使用。并不是仅仅给自动化巡检任务赋能，还可以一鱼多吃，把工作流接入到对话应用中。如果对这个不感兴趣的同学，可以直接跳过这个环节。

在接入 Agent 之前，需要发布工作流，并且“发布为工具”，如下图所示。

在 Agent 中会通过工具调用的方式引用工作流的能力。

接着， 如下图所示，创建 Agent。

然后，编辑 Agent 内容，如下图所示。

提示词的部分，如下：

通过举例的方式告诉 Agent 提示词“长什么样子”（Few-Shot），并且告诉 LLM 调用对应的工作流：login_inspect。 这个名字就是我们把工作流发布为工具的时候，起的名字。

在右上方选择一个处理用户自然语言的模型，这里选择我们已经定义的 DeepSeek 模型。然后就可以在下方的输入框中提问，让 Agent 调用工作流给出答案了。

输入如下问题：

提问之后，可以通过下图看到结果。

很明显，在输入与登录相关的信息之后，Agent 会调用工作流 login_inspect ，并且从工作流返回的字段 "tool response" 明显看到返回的信息。 在最下方，是 Agent 结合 LLM 润色得到的最终回复。

当然，我们可以通过右上角的“发布”按钮，将 Agent 发布给其他的运维人员使用。

编写定时任务脚本

完成工作流的开发之后，我们需要由一个定时任务获取 Prometheus Server 的指标数据，也就是用户登录的数据，然后再调用 Dify 工作流对其进行详细方案的分析。

具体而言，脚本的主要作用是对用户登录情况进行自动化巡检与报告生成。它会定期从 Prometheus 中获取关键指标，包括总登录次数、登录成功次数和失败次数，并通过指定路径的 jq 工具进行数据解析与汇总。随后，脚本会将整理后的结果转换为结构化文本，调用本地 Workflow 服务进行进一步分析，并输出直观的中文结果。为了保证结果的可追溯性，脚本会将每次的分析结果按时间戳保存为 JSON 文件存放在 report 目录中。

先上脚本，再展开讲解。

脚本分为四步：

定义了 API_KEY、Prometheus 地址、Workflow 服务地址、日志文件等基本参数。

使用 log() 函数统一记录执行过程和结果，保证排查时可追溯。

通过 curl 调用 Prometheus 的 HTTP API，分别获取三个核心指标：

用 jq 解析 Prometheus 返回的 JSON 数据，并计算对应数值。

将三个指标拼接成一句中文描述（如“总登录次数 100，成功 95，失败 5”）。

通过 jq 将文本转为 JSON 安全字符串。

调用本地运行的 Workflow 服务接口，把指标数据作为输入，等待返回分析结果。

在终端和日志中打印 Workflow 的中文结果。

同时将结果保存为 JSON 文件，按时间戳命名，存放在 report 目录下，方便后续留存和比对。

细心的你可能发现了，这个脚本中定义了工作流的 key，我们需要通过它调用 Dify 的工作流。下面就来看看如何申请这个 Key。

生成 workflow API 密钥

如下图所示，在 Dify 工作室右上角点击“API 密钥” 按钮，在弹出框中选择“创建密钥”，请保存好你的密钥。

生成好的密钥大概长下面这个样子。

接着可以通过如下命令执行脚本，从而测试能否调用 Dify 的工作流。

执行脚本命令如下：

如果执行完毕之后，在 report 目录下看到 report 文件，说明执行成功了。

配置定时任务

由于我用的 Mac OS，为了方便使用 crontab 协助我完成定时任务的执行。crontab 是类 Unix 操作系统（如 Linux、macOS）中用于定时执行任务的工具，其核心是通过 crontab 命令管理定时任务列表（即 crontab 文件），并由系统后台的 cron 守护进程持续监听、触发任务。用户可通过 crontab -e 编辑任务，每条任务需遵循 “分 时 日 月 周 命令” 的固定时间格式（例如 0 2 * * * /home/backup.sh 表示每天凌晨 2 点执行备份脚本），支持使用通配符（如 * 代表所有值）、范围符（如 1-5 代表周一到周五）灵活设定执行周期，适用于日志切割、数据备份、系统监控等重复性操作，无需人工干预即可实现任务的自动化定时运行。

通过如下命令，打开当前用户的 crontab 文件（通常是 vim / nano）。

在 crontab 中输入如下内容，指定要执行的文件和日志输出文件。

这里执行的文件就是我们的inspector.sh 脚本文件，它帮助我们调用 Dify 的工作流，并且返回详细的方案信息，接着生成报告。另外日志输出文件，是针对 crontab 的执行情况的日志。

查看 crontab 任务：

查看 crontab 任务执行状态：

测试整体流程

好了，万事俱备只欠东风，通过如下程序生成 Metrics 指标数据写入到 Prometheus 中，这样就有了测试数据。

此时，crontab 已经开始运行了，由于我们设置的是 5 分钟执行一次crontab 定义的inspector.sh 脚本。 所以，稍微等待就可以看看inspector_crontab.log 文件中 crontab 任务的执行情况了。

如下所示：

由于篇幅有限，我们展示一部分的 crontab 日志。从日志中可以看出，脚本采集到 Prometheus Server 的 Metrics 数据，以及启动 Dify 工作流都成功了，并且看到了详细的处理方案和执行步骤。

最后，来到 report 目录下面。如图所示，可以看到以 report+时间为名字的 json 文件被创建，并且文件中可以看到报告内容。

作者介绍

崔皓，51CTO社区编辑，资深架构师，拥有18年的软件开发和架构经验，10年分布式架构经验。

相关文章