回复
运维新突破：Prometheus+DeepSeek+Dify实现自动巡检 原创
整体思路
在日常运维中，经常会遇到类似的问题：明明系统前一天运行正常，第二天登录量突然下降，却要花费大量时间去手工检查日志、排查 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 之前, 请确保你的机器已满足最低安装要求：
- CPU >= 2 Core
- RAM >= 4 GiB
操作系统 | 软件 | 描述 |
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 源代码至本地环境。
# 假设当前最新版本为 0.15.3
git clone https://github.com/langgenius/dify.git --branch 0.15.3启动容器
进入 Dify 源代码的 Docker 目录：
cd dify/docker复制环境配置文件：
cp .env.example .env可以修改 .env 中 Nginx 的端口，默认的端口是 80 ，我们修改成 8085。避免与本机的 80 端口冲突。
EXPOSE_NGINX_PORT=8085启动 Docker 容器：
根据你系统上的 Docker Compose 版本，选择合适的命令来启动容器。你可以通过 $ docker compose version 命令检查版本，详细说明请参考 Docker 官方文档：
如果版本是 Docker Compose V2，使用以下命令：
docker compose up -d如果版本是 Docker Compose V1，使用以下命令：
docker-compose up -d运行命令后，你应该会看到类似以下的输出，显示所有容器的状态和端口映射：
[+] Running 11/11
✔ Network docker_ssrf_proxy_network Created 0.1s
✔ Network docker_default Created 0.0s
✔ Container docker-redis-1 Started 2.4s
✔ Container docker-ssrf_proxy-1 Started 2.8s
✔ Container docker-sandbox-1 Started 2.7s
✔ Container docker-web-1 Started 2.7s
✔ Container docker-weaviate-1 Started 2.4s
✔ Container docker-db-1 Started 2.7s
✔ Container docker-api-1 Started 6.5s
✔ Container docker-worker-1 Started 6.4s
✔ Container docker-nginx-1 Started 7.1s最后检查是否所有容器都正常运行：
docker compose ps在这个输出中，你应该可以看到包括 3 个业务服务 api / worker / web，以及 6 个基础组件 weaviate / db / redis / nginx / ssrf_proxy / sandbox 。
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
docker-api-1 langgenius/dify-api:0.6.13 "/bin/bash /entrypoi…" api About a minute ago Up About a minute 5001/tcp
docker-db-1 postgres:15-alpine "docker-entrypoint.s…" db About a minute ago Up About a minute (healthy) 5432/tcp
docker-nginx-1 nginx:latest "sh -c 'cp /docker-e…" nginx About a minute ago Up About a minute 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp
docker-redis-1 redis:6-alpine "docker-entrypoint.s…" redis About a minute ago Up About a minute (healthy) 6379/tcp
docker-sandbox-1 langgenius/dify-sandbox:0.2.1 "/main" sandbox About a minute ago Up About a minute
docker-ssrf_proxy-1 ubuntu/squid:latest "sh -c 'cp /docker-e…" ssrf_proxy About a minute ago Up About a minute 3128/tcp
docker-weaviate-1 semitechnologies/weaviate:1.19.0 "/bin/weaviate --hos…" weaviate About a minute ago Up About a minute
docker-web-1 langgenius/dify-web:0.6.13 "/bin/sh ./entrypoin…" web About a minute ago Up About a minute 3000/tcp
docker-worker-1 langgenius/dify-api:0.6.13 "/bin/bash /entrypoi…" worker About a minute ago Up About a minute 5001/tcp通过这些步骤，你可以在本地成功安装 Dify。通过 Docker Desktop 看到的就是如下图的样子。
启动 Dify
由于我们之前修改了入口的端口号， 这里需要通过 8085 端口访问 dify，如下：
http://127.0.0.1:8085/install接着会进入界面，设置管理员邮箱，名称和密码。
admin
c12345678然后按照下面页面的方式，登录就好了。
配置 LLM
在用户的“配置”界面，点击“模型供应商”，添加如下图所示的供应商。
这里 DeepSeek 用来做模型推理，使用 SILICONFLOW 提供的 BAAI 模型完成向量数据库的嵌入操作。
创建 workflow
工作流步骤描述如下：
- 获取参数（参数提取器）：从用户的自然语言中，提取登录总人数，登录异常人数等信息。
- 得到方案（代码执行）：通过代码判断异常登录比例，从而提供基本解决方案。
- 细化方案（知识检索）：输入基本解决方案，通过知识库检索详细解决方案。在知识库中保存着所有运维的解决方案信息。
- 生成报表（ LLM）：根据详细解决方案生成运维报表。
提取参数
参数提取器，需要将自然语言转化为参数，说白了就是要提取自然语言中的关键信息。本例中，登录的总人数和登录异常人数就是关键信息。此处会使用 LLM 帮助我们提取信息，因此需要给 LLM 指令如下：
提取 “总登录人数”：文本中 “一共 XX 人登录” 里的 “XX” 数值，对应参数名 “total_login_count”（仅保留数字，如 “15680”）；
提取 “成功登录人数”：文本中 “成功 XX 人” 里的 “XX” 数值，对应参数名 “success_login_count”（仅保留数字，如 “14739”）；
提取 “失败登录人数”：文本中 “失败 XX 人” 里的 “XX” 数值，对应参数名 “failed_login_count”（仅保留数字，如 “941”）；获取关键信息之后，会通过“代码执行”判断采取的具体方案。由于“代码执行”是“参数提取器”的下游节点，所以在“代码执行”中会对标“参数提取器”中的两个输出参数，作为自己节点的输入参数。如下图所示，total_login 和 failed_login_count 作为“参数提取器”输出参数，并作为“代码执行”的输入参数，输入到“PYTHON3”的函数脚本中。
执行代码
在完成提取参数之后，我们得到了登录总人数和登录失败人数的关键信息，接着需要得到初步的解决方案。这里需要用到代码执行器，按照登录失败的比例进行判断，给出方案信息。
代码执行器，python 脚本如下：
def main(total_login: int, failed_login_count: int) -> dict:
"""
参数:
total_login: 总登录人数
anomaly_count: 异常登录人数
返回:
包含处理建议的字典
"""
# 边界情况处理
if total_login == 0:
return {"result": "总登录人数为0，无法计算异常率，请检查指标采集是否正常"}
# 计算异常率(保留2位小数)
anomaly_rate = round(failed_login_count / total_login * 100, 2)
# 1级：轻微异常（异常率≤2%）
if anomaly_rate <= 2:
suggestion = """
1. 监控层面：开启5分钟粒度的异常趋势跟踪，无需触发告警
2. 操作层面：抽样检查3-5条异常日志，确认是否为用户操作失误
3. 后续跟进：若10分钟内异常率持续上升至2%以上，手动升级处理
""".strip()
# 2级：一般异常（2%<异常率≤5%）
elif anomaly_rate <= 5:
suggestion = """
1. 服务检查：执行kubectl get pods | grep login-service确认服务存活
2. 日志分析：按错误类型统计（4xx/5xx），排查是否集中在特定区域
3. 处理动作：重启异常服务实例，清理登录相关缓存
4. 通知：同步当日值班运维工程师关注
""".strip()
# 3级：中度异常（5%<异常率≤10%）
elif anomaly_rate <= 10:
suggestion = """
1. 紧急排查：检查服务资源使用率（CPU<80%、内存<85%），分析登录SQL慢查询
2. 控制影响：封禁1分钟内失败次数>20次的IP（临时1小时），启用缓存降级
3. 协同响应：通知运维团队全员，同步开发查看近期代码变更
4. 进度跟踪：每15分钟输出一次异常处理进展
""".strip()
# 4级：严重异常（10%<异常率≤20%）
elif anomaly_rate <= 20:
suggestion = """
1. 资源扩容：登录服务实例紧急扩容至原数量×2，数据库连接数调至2000
2. 服务降级：关闭登录积分等非核心功能，对非会员启用验证码
3. 应急响应：电话通知运维负责人（15分钟内到场），启动应急预案
4. 进度同步：每10分钟向技术总监汇报处理进度
""".strip()
# 5级：紧急异常（异常率>20%）
else:
suggestion = """
1. 全网告警：触发短信+电话告警（技术总监、运维/开发负责人）
2. 系统处理：启动灾备系统，实施流量限流（仅允许30%正常流量）
3. 业务协同：通知业务负责人评估影响，成立临时应急小组
4. 高层汇报：每5分钟在应急群更新进展，30分钟向管理层汇报
""".strip()
return {"result": suggestion}如上脚本所示，它是针对登录系统异常的自动化分析与处置建议工具，核心功能是基于总登录人数与异常登录人数，通过计算异常率（保留 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 模型用于将文本转化为向量表示，助力后续检索等操作）。
这里需要补充一下，知识库嵌入时需要文本切割和上下文覆盖（分段覆盖）的原因：
- 文本切割：大语言模型（LLM）在处理文本时，存在上下文窗口限制（即能同时处理的文本长度有限）。知识库中的文本可能很长，若不进行切割，超出模型上下文窗口的部分就无法被有效处理。通过按照一定规则（如基于 token 数量、特定分隔符等）切割文本，能让每一段文本都处于模型可处理的长度范围内，从而保证文本能被 Embedding 模型正确编码为向量，便于后续的检索、匹配等操作。
- 上下文覆盖（分段覆盖）：文本在自然语义上是连贯的，当进行切割时，可能会把一个完整的语义单元（比如一个完整的知识点、逻辑表述）分割到两个不同的文本段中。设置分段重叠长度，能让相邻的文本段之间有部分内容重叠。这样一来，在后续基于向量检索等操作时，即使一个问题或查询涉及的内容处于两个文本段的 “分割处”，由于有重叠部分，也能更好地捕捉到完整的语义信息，避免因文本切割而丢失上下文关联，提升知识库检索和问答的准确性。
接着，我们就可以设置“知识检索”的内容，如下图所示，选择“查询变量”为“代码执行”的 result 也就是返回的“结果”，我们可以回想一下在“代码执行”中会返回“初步的方案”，这里以result 变量的方式输入到“知识检索”中。
换句话说，就是将“代码执行”得到的初步解决方案放到知识库中进行检索，从而得到细化之后的解决方案。
大模型生成报告
好了，到了这里就需要将细化之后的解决方案生成运维报告，指导运维工程师处理登录异常的问题。我们需要利用大模型加上提示词完成，如下图所示，在系统提示词中处理登录总人数和失败人数以外，还需要加入“上下文”。 这个“上下文”就是从知识库中检索出来的细化之后的方案。
测试工作流
通过上面一顿操作，工作流就创建完毕了，接着让我们测试工作流是否正常运行。
如下图所示，在工作流的“开始”节点，添加参数“user_query”，顾名思义就是用输入的参数，用来接受用户输入的内容。然后，点击右上角的“运行”按钮，在“user_query”中输入请求。
输入请求内容如下，很明显包含了登录总人数，成功登录人数，以及失败人数的信息。
一共 2350 人登录，成功 2218 人，失败 132 人。
可以在右边栏中看到结果和追踪信息。如下图所示，可以查看工作流每个步骤的执行时间和执行内容， 在“结束”节点中可以看到最终结果。
Agent 接入工作流
在完成工作流之后，我们还可以将工作流接入到 Dify 的 Agent 中，这是为了方便客户端进行更好的使用，比如我们可以与工作流进行对话，询问一些运维相关的处理意见。
需要注意的是，在本例中这个步骤属于支线任务，可做可不做，接入 Agent 的做法是让我们对 Dify 工作流有更好的使用。并不是仅仅给自动化巡检任务赋能，还可以一鱼多吃，把工作流接入到对话应用中。如果对这个不感兴趣的同学，可以直接跳过这个环节。
在接入 Agent 之前，需要发布工作流，并且“发布为工具”，如下图所示。
在 Agent 中会通过工具调用的方式引用工作流的能力。
接着， 如下图所示，创建 Agent。
然后，编辑 Agent 内容，如下图所示。
提示词的部分，如下：
接受登录相关信息。
例如：“一共 2350 人登录，成功 2218 人，失败 132 人。” 得到登录异常的处理方法。
调用工作流 login_inspect通过举例的方式告诉 Agent 提示词“长什么样子”（Few-Shot），并且告诉 LLM 调用对应的工作流：login_inspect。 这个名字就是我们把工作流发布为工具的时候，起的名字。
在右上方选择一个处理用户自然语言的模型，这里选择我们已经定义的 DeepSeek 模型。然后就可以在下方的输入框中提问，让 Agent 调用工作流给出答案了。
输入如下问题：
一共 2350 人登录，成功 2218 人，失败 132 人。提问之后，可以通过下图看到结果。
很明显，在输入与登录相关的信息之后，Agent 会调用工作流 login_inspect ，并且从工作流返回的字段 "tool response" 明显看到返回的信息。 在最下方，是 Agent 结合 LLM 润色得到的最终回复。
当然，我们可以通过右上角的“发布”按钮，将 Agent 发布给其他的运维人员使用。
编写定时任务脚本
完成工作流的开发之后，我们需要由一个定时任务获取 Prometheus Server 的指标数据，也就是用户登录的数据，然后再调用 Dify 工作流对其进行详细方案的分析。
具体而言，脚本的主要作用是对用户登录情况进行自动化巡检与报告生成。它会定期从 Prometheus 中获取关键指标，包括总登录次数、登录成功次数和失败次数，并通过指定路径的 jq 工具进行数据解析与汇总。随后，脚本会将整理后的结果转换为结构化文本，调用本地 Workflow 服务进行进一步分析，并输出直观的中文结果。为了保证结果的可追溯性，脚本会将每次的分析结果按时间戳保存为 JSON 文件存放在 report 目录中。
先上脚本，再展开讲解。
#!/bin/bash
# ===== 配置部分 =====
API_KEY="app-QO7DYA9uxq2HApfSVSKKHC0Y"
BASE_URL="http://127.0.0.1:8085/v1"
USER_ID="local-user-001"
PROM_URL="http://localhost:9090"
LOG_FILE="inspector.log"
# ===== jq 路径 =====
JQ_CMD="/Users/cuihao/opt/anaconda3/bin/jq"
# ===== 日志函数 =====
log() {
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")
echo "[$TIMESTAMP] $1" | tee -a "$LOG_FILE"
}
log "脚本开始执行"
# ===== 查询 Prometheus 指标 =====
log "查询 Prometheus: 总登录次数"
TOTAL_LOGINS=$(curl -s "${PROM_URL}/api/v1/query?query=user_login_total" \
| $JQ_CMD '[.data.result[] | .value[1] | tonumber] | add')
TOTAL_LOGINS=${TOTAL_LOGINS:-0}
log "总登录次数: $TOTAL_LOGINS"
log "查询 Prometheus: 登录成功次数"
SUCCESS_LOGINS=$(curl -s "${PROM_URL}/api/v1/query?query=user_login_total" \
| $JQ_CMD '[.data.result[] | select(.metric.login_status=="success") | .value[1] | tonumber] | add')
SUCCESS_LOGINS=${SUCCESS_LOGINS:-0}
log "登录成功次数: $SUCCESS_LOGINS"
log "查询 Prometheus: 登录失败次数"
FAIL_LOGINS=$(curl -s "${PROM_URL}/api/v1/query?query=user_login_total" \
| $JQ_CMD '[.data.result[] | select(.metric.login_status=="failed") | .value[1] | tonumber] | add')
FAIL_LOGINS=${FAIL_LOGINS:-0}
log "登录失败次数: $FAIL_LOGINS"
# ===== 生成 Workflow 输入文本 =====
INPUT_TEXT="用户登录统计：总登录次数: ${TOTAL_LOGINS}，登录成功: ${SUCCESS_LOGINS}，登录失败: ${FAIL_LOGINS}"
SAFE_INPUT_TEXT=$(echo "$INPUT_TEXT" | $JQ_CMD -Rs .)
log "生成 Workflow 输入文本: $INPUT_TEXT"
# ===== 调用 Workflow =====
log "🚀 正在调用 Workflow ..."
RESPONSE=$(curl -s -X POST "${BASE_URL}/workflows/run" \
-H "Authorization: Bearer ${API_KEY}" \
-H "Content-Type: application/json" \
-d "{
\"inputs\": {
\"user_query\": $SAFE_INPUT_TEXT
},
\"response_mode\": \"blocking\",
\"user\": \"${USER_ID}\"
}")
log "收到 Workflow 原始响应: $RESPONSE"
# ===== 输出结果 =====
echo "✅ Workflow 返回结果："
RESULT=$(echo "${RESPONSE}" | $JQ_CMD -r '.data.outputs["tool response"]')
echo "$RESULT"
log "Workflow 中文结果: $RESULT"
log "脚本执行完成"
# ===== 保存报告 =====
TIMESTAMP=$(date +"%Y%m%d%H%M%S")
REPORT_DIR="/Users/cuihao/docker/dify/report"
mkdir -p "$REPORT_DIR"
REPORT_FILE="${REPORT_DIR}/inspector_${TIMESTAMP}.json"
echo "$RESULT" > "$REPORT_FILE"
log "Workflow 结果已保存到: $REPORT_FILE"
log "脚本执行完成"脚本分为四步：
配置与日志
定义了 API_KEY、Prometheus 地址、Workflow 服务地址、日志文件等基本参数。
使用 log() 函数统一记录执行过程和结果，保证排查时可追溯。
采集指标
通过 curl 调用 Prometheus 的 HTTP API，分别获取三个核心指标：
- 总登录次数
- 登录成功次数
- 登录失败次数
用 jq 解析 Prometheus 返回的 JSON 数据，并计算对应数值。
生成分析输入 & 调用 Workflow
将三个指标拼接成一句中文描述（如“总登录次数 100，成功 95，失败 5”）。
通过 jq 将文本转为 JSON 安全字符串。
调用本地运行的 Workflow 服务接口，把指标数据作为输入，等待返回分析结果。
结果输出与归档
在终端和日志中打印 Workflow 的中文结果。
同时将结果保存为 JSON 文件，按时间戳命名，存放在 report 目录下，方便后续留存和比对。
细心的你可能发现了，这个脚本中定义了工作流的 key，我们需要通过它调用 Dify 的工作流。下面就来看看如何申请这个 Key。
生成 workflow API 密钥
如下图所示，在 Dify 工作室右上角点击“API 密钥” 按钮，在弹出框中选择“创建密钥”，请保存好你的密钥。
生成好的密钥大概长下面这个样子。
app-QO7DYA9uxq2HApfSVSKKHC0Y接着可以通过如下命令执行脚本，从而测试能否调用 Dify 的工作流。
执行脚本命令如下：
chmod +x inspector.sh
./inspector.sh如果执行完毕之后，在 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 -e在 crontab 中输入如下内容，指定要执行的文件和日志输出文件。
*/5 * * * * /bin/bash /Users/cuihao/docker/dify/inspector.sh >> /Users/cuihao/docker/dify/inspector.log 2>&1这里执行的文件就是我们的inspector.sh 脚本文件，它帮助我们调用 Dify 的工作流，并且返回详细的方案信息，接着生成报告。另外日志输出文件，是针对 crontab 的执行情况的日志。
查看 crontab 任务：
crontab -l查看 crontab 任务执行状态：
sudo launchctl list | grep cron测试整体流程
好了，万事俱备只欠东风，通过如下程序生成 Metrics 指标数据写入到 Prometheus 中，这样就有了测试数据。
from prometheus_client import start_http_server, Counter
import random
import time
# 定义登录指标（与告警规则中的标签完全匹配）
LOGIN_COUNT = Counter(
'user_login_total',
'用户登录总次数及状态统计',
['user_type', 'login_status', 'ip_region'] # 包含规则中用到的user_type、login_status
)
def simulate_login(failure_rate=0.2):
"""模拟登录行为，可指定失败率（默认20%，确保触发15%阈值）"""
# 70%普通用户，30%管理员（与规则2的admin类型匹配）
user_type = random.choices(['normal', 'admin'], weights=[0.7, 0.3])[0]
# 按指定失败率生成登录状态（默认20%失败，超过15%阈值）
login_status = random.choices(
['success', 'failed'],
weights=[1 - failure_rate, failure_rate]
)[0]
# 随机地区（规则未用到，但不影响）
ip_region = random.choice(['beijing', 'shanghai', 'guangzhou'])
# 记录指标（标签与规则中的筛选条件完全对应）
LOGIN_COUNT.labels(
user_type=user_type,
login_status=login_status,
ip_reginotallow=ip_region
).inc()
# 打印失败日志，方便观察触发情况
if login_status == 'failed':
print(f"[失败] 用户类型: {user_type}，地区: {ip_region}")
if __name__ == '__main__':
# 启动指标服务（9091端口，与Prometheus配置一致）
start_http_server(9091)
print("Exporter运行中：http://localhost:9091/metrics")
print("开始模拟登录（高失败率，确保触发告警）...")
# 持续模拟登录（每0.5秒1次，快速累积数据，匹配规则的2分钟窗口）
while True:
simulate_login(failure_rate=0.3) # 20%失败率，超过15%阈值
time.sleep(0.5)此时，crontab 已经开始运行了，由于我们设置的是 5 分钟执行一次crontab 定义的inspector.sh 脚本。 所以，稍微等待就可以看看inspector_crontab.log 文件中 crontab 任务的执行情况了。
如下所示：
[2025-09-16 15:45:00] 脚本开始执行
[2025-09-16 15:45:00] 查询 Prometheus: 总登录次数
[2025-09-16 15:45:00] 总登录次数: 10113
[2025-09-16 15:45:00] 查询 Prometheus: 登录成功次数
[2025-09-16 15:45:00] 登录成功次数: 7117
[2025-09-16 15:45:00] 查询 Prometheus: 登录失败次数
[2025-09-16 15:45:00] 登录失败次数: 2996
[2025-09-16 15:45:00] 生成 Workflow 输入文本: 用户登录统计：总登录次数: 10113，登录成功: 7117，登录失败: 2996
[2025-09-16 15:45:00] 🚀 正在调用 Workflow ...
......
### **电商平台登录异常应急响应执行报告**
**报告生成时间：** 2023-10-27 15:00
**事件主题：** 电商平台登录接口失败率异常告警
**报告人：** 运维工程师
---
#### **一、 事件摘要**
* **事件发生时间：** 2023-10-27 14:30 (监控系统触发告警)
* **事件级别：** **紧急异常（5级）**
* **核心指标：**
* 登录请求总数：11,888
* 登录失败数：3,527
* **计算失败率：** (3,527 / 11,888) * 100% ≈ **29.7%**
* **事件现象：** 平台登录接口出现大量失败请求，失败率高达29.7%，远超2%的健康阈值，严重影响用户正常登录体验，存在重大业务风险。
* **初步判断：** 此失败率属于灾难性级别，可能原因包括：认证服务集群故障、数据库连接池耗尽、缓存（Redis）失效或过载、网络分区、或遭受恶意撞库攻击等。由于篇幅有限，我们展示一部分的 crontab 日志。从日志中可以看出，脚本采集到 Prometheus Server 的 Metrics 数据，以及启动 Dify 工作流都成功了，并且看到了详细的处理方案和执行步骤。
最后，来到 report 目录下面。如图所示，可以看到以 report+时间为名字的 json 文件被创建，并且文件中可以看到报告内容。
作者介绍
崔皓，51CTO社区编辑，资深架构师，拥有18年的软件开发和架构经验，10年分布式架构经验。
©著作权归作者所有，如需转载，请注明出处，否则将追究法律责任
赞
收藏
回复
相关推荐
