DeepSeek 自动化生成 Prometheus 巡检脚本与告警规则实践

前阵子我们的监控值班连续出现两起“指标漏配”事件一台机器磁盘写满没有触发告警另一个接口错误率飙到 20% 才发现。翻日志复盘时我发现Prometheus 的规则文件和巡检脚本都在但都是上线前人工写死的一套后续新业务补了不少指标规则却没人同步更新。那段时间正好在试用 DeepSeek 处理各种文本生成任务我突发奇想能不能让它根据当前的指标清单、业务场景和已有监控配置自动生成巡检脚本和告警规则我跟团队说了这个想法大家的反应很一致大模型能写 YAML 和 Python但谁敢直接拿去当监控的准绳后来我们做了个小范围验证效果超出了预期也踩了不少坑。这篇文章就是这次实践的完整记录我们用 Prometheus 做指标采集用 DeepSeek 做配置生成把日常巡检中最费人力的三类事——脚本编写、规则配置、阈值调优——做成了半自动的流水线。如果你也在维护一套 Prometheus经常被“规则漏配”“阈值拍脑袋”困扰这篇文章应该能给你一个可以直接抄作业的起点。我会把 Prompt 模板、脚本示例、规则文件、调参思路和排错经验都展开讲。1. 先说清楚巡检脚本和告警规则到底在解决什么问题1.1 Prometheus 监控体系的日常痛点很多人以为 Prometheus 部署起来、配上 node_exporter 和几个 exporter监控就算做完了。但从我的经验看部署只是十分之一的工作日常真正消耗精力的其实是三件事第一是巡检。Prometheus 自带 Alertmanager 做告警但告警是“事后通知”巡检是“事前发现”。比如某个服务的连接池在缓慢增长按告警阈值还差得远但趋势已经不对。这时候我需要一个巡检脚本定时去查一系列 PromQL 表达式把结果汇总成报告。这个脚本看起来简单但要维护的查询列表非常多每接一个新中间件就要手改一次时间一长就没人愿意动了。第二是规则配置。Prometheus 的告警规则写起来门槛不高就是一套 YAML 加 PromQL 表达式。但“不高”和“不容易出错”是两回事。实际环境里各个服务的业务指标、基础指标混在一起告警阈值需要区分核心链路和边缘业务还要考虑周末和工作日流量差异。纯手写规则文件经常出现缩进错误、变量名写错、正则不匹配查起来非常耗时间。第三是规则上线后的验证。写好规则不等于规则正确。Prometheus 提供 promtool 可以做静态校验但很多团队根本没有把它接入 CI导致异常规则直接在线上加载等到半夜误报炸了才发现。这三个痛点的共同特征是重复劳动多、上下文依赖强、试错成本高。而 DeepSeek 这类大模型最擅长的事情之一就是“根据你给出的上下文批量产出结构化的文本”。它不懂你的业务但只要你把指标清单、采集周期、业务等级、历史阈值等喂给它它就能输出一套基础可用的脚本和规则再由人去审查和微调。这就是整个方案成立的前提。1.2 为什么选 DeepSeek 来生成配置选择 DeepSeek不是因为它比别的模型强多少而是因为我们需要一个能通过公开接口调用、支持较长的上下文窗口、同时能稳定输出 YAML 和 Python 代码的模型。实际对比过几个选项之后DeepSeek 在代码生成和中英文混合文本处理上的表现比较均衡尤其对 YAML 缩进和 JSON 结构这类细节理解得比较到位。我个人的经验是大模型生成 Prometheus 规则最大的障碍不是“不会写 PromQL”而是“不理解你的监控环境”。DeepSeek 的训练数据里包含大量的 Prometheus 文档、开源规则模板和社区问答它天然知道常见指标怎么配、for 参数怎么设、label 怎么写。但它不知道你线上到底采集了哪些指标也不知道你关心的业务指标叫什么名字。所以用它的关键是喂上下文而不是让它凭空发挥。我们验证后觉得这个方案的核心价值在于人工只需要维护“指标清单”和“业务上下文”让模型去生成“第一版配置”然后人工做审查。这比从纯白纸开始写要快得多也比单纯依赖模板要灵活得多。下一节我会详细讲如何准备环境以及如何设计 Prompt。2. 环境准备与 Prompt 设计2.1 最小可用环境清单先明确一件事这次实践不要求你有一个很大的监控集群一个最小可用的 Prometheus 实例就够了。我自己是在一台测试服务器上操作的配置大概是 4 核 8G 内存Prometheus 版本用的 2.47 系列指标来源是 node_exporter 和几个业务应用的 exporter。如果你的环境还是空的可以按下面这套命令快速搭起来。我假设你已经安装了 Docker这是最省事的方式mkdir -p /opt/prometheus cd /opt/prometheus cat prometheus.yml EOF global: scrape_interval: 15s evaluation_interval: 15s rule_files: - rules/*.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node static_configs: - targets: [localhost:9100] EOF mkdir -p rules docker run -d --name prometheus \ -p 9090:9090 \ -v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \ -v /opt/prometheus/rules:/etc/prometheus/rules \ prom/prometheus:v2.47.0再启动一个 node_exporter 容器用于采集基础主机指标docker run -d --name node-exporter \ --network host \ prom/node-exporter:v1.6.0等几十秒后访问 http://localhost:9090/targets 应该能看到两个 target 都是 UP 状态。这一步非常重要后续让 DeepSeek 生成规则时我们得保证至少有一个真实指标的查询结果可以用来验证它生成的表达式是否有效。如果你已经有现成的环境可以直接跳到 Prompt 设计。但我强烈建议不要跳过“真实指标验证”这一步因为大模型生成的 PromQL 再漂亮最终也要在真实的 metrics 上跑一遍才能确认。2.2 让 DeepSeek 理解业务背景的 Prompt 设计很多人在用 DeepSeek 生成配置时习惯把需求一句话丢过去“帮我写一个报警规则”。这种写法不是不行但生成出来的内容基本都是通用模板阈值要么偏高要么偏低labels 也乱七八糟。原因很简单模型没有你的指标上下文只能靠猜测。我实践下来比较有效的方式是“结构化指令 上下文信息 输出约束”三段式并且把上下文字段集中在 Prompt 末尾防止模型在生成过程中遗忘。下面是我用的一份简化版 Prompt 模板你可以直接复制去改你是一个熟悉 Prometheus 监控体系的 SRE 工程师。 现在需要为一套 MySQL 业务库生成巡检脚本和告警规则。 全局参数 - 采集间隔15s - 告警评估间隔15s - 环境生产环境 - 告警恢复后通知需要 指标清单来自实际采集不要编造 - mysql_upmysqld_exporter 暴露值 1 表示进程存活 - mysql_global_status_threads_connected当前连接数 - mysql_global_variables_max_connections最大连接数 - mysql_global_status_aborted_connects异常中断连接数 - mysql_global_status_slow_queries慢查询累计值 输出要求 1. 输出一个 Python 巡检脚本使用 requests 请求 Prometheus HTTP API。 2. 输出一个 Prometheus 告警规则文件rules 格式。 3. 阈值需要结合生产环境给出合理默认值。 4. 所有 PromQL 表达式必须严格基于上面给出的指标。 5. 不要生成无关内容。这个 Prompt 里最关键的是两句话一是“指标清单来自实际采集不要编造”二是“所有 PromQL 表达式必须严格基于上面给出的指标”。这两句能显著降低模型瞎编指标名的情况。为什么要在 Prompt 里把指标名明确列出来因为 Prometheus 的指标名是半结构化的模型训练时见过大量相似的命名它非常容易把 mysql_global_status_threads_connected 想象成 mysql_threads_connected结果生成一个根本查不到数据的表达式。列出真实采集到的指标名相当于把模型的搜索空间钉死在一块后面验证时出错概率会小很多。另外我建议在 Prompt 里固定 YAML 的缩进规范。大模型默认输出的 YAML 缩进通常是两个空格而 Prometheus 的规则文件接受这种格式。但如果是团队规范要求四个空格你必须在 Prompt 里显式说明否则生成后还要手动转换。3. 自动生成巡检脚本的完整流程3.1 从零写一份“健康巡检”脚本还是接着上面 MySQL 的例子。我们让 DeepSeek 基于指标清单生成巡检脚本它的第一版输出大致是这样的结构一个 Python 脚本先用 requests 请求 Prometheus 的 /api/v1/query 接口把几个核心指标拉下来然后做阈值判断最后输出一个文本报告。我实际用下来感觉这个结构的思路是对的但直接可用性只能算 70 分。主要问题是它生成的脚本把“查询 Prometheus API”和“判断告警条件”混在一起一旦指标多了就很难维护。我建议在大模型生成的脚本基础上做一次小重构把 PromQL 查询列表独立成一个常量字典每个指标对应一个查询表达式和一个判断规则。这样做的好处是下次让模型新增一个巡检项时只需要改这个字典不需要动主逻辑。下面是我整理后的一份简化版巡检脚本你可以直接跑起来试。这个脚本本身是 DeepSeek 辅助生成、我手工调整后的结果我加了比较详细的注释#!/usr/bin/env python3 # -*- coding: utf-8 -*- import requests import json from datetime import datetime PROMETHEUS_URL http://localhost:9090 # 巡检项配置名称 - (PromQL表达式, 告警阈值, 说明) CHECKS { mysql_up: ( mysql_up, 1, MySQL exporter 是否存活, ), connection_rate: ( mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100, 80, 当前连接数占最大连接数的百分比, ), aborted_connects: ( rate(mysql_global_status_aborted_connects[5m]), 5, 5分钟内平均每秒异常中断连接数, ), slow_query_rate: ( rate(mysql_global_status_slow_queries[15m]), 2, 15分钟内平均每秒慢查询数, ), } def query_promql(expr: str) - float: resp requests.get( f{PROMETHEUS_URL}/api/v1/query, params{query: expr}, timeout15, ) resp.raise_for_status() data resp.json() if data[status] ! success: raise RuntimeError(fPrometheus query failed: {data}) result data[data][result] if not result: # 没有数据时返回 None方便上层区分“正常”和“没有监控数据” return None return float(result[0][value][1]) def main(): now datetime.now().strftime(%Y-%m-%d %H:%M:%S) lines [f[巡检报告] {now}, - * 40] has_error False for name, (expr, threshold, desc) in CHECKS.items(): try: value query_promql(expr) except Exception as exc: has_error True lines.append(f[异常] {name}: 查询失败 - {exc}) continue if value is None: has_error True lines.append(f[警告] {name}: {desc} - 无数据返回检查 exporter 是否正常采集) continue status OK if value threshold else 异常 if status 异常: has_error True lines.append(f[{status}] {name} | {desc} | 当前值: {value:.4g} | 阈值: {threshold}) lines.append(- * 40) lines.append(结论: (存在异常请人工确认 if has_error else 全部正常)) print(\n.join(lines)) return 1 if has_error else 0 if __name__ __main__: raise SystemExit(main())这个脚本的核心逻辑很简单但有个细节容易忽略当某个 metrics 没有返回数据时脚本应该返回“异常”而不是“正常”。很多巡检脚本只做阈值判断忘了处理空值。Prometheus 查询一个不存在的指标并不会报错它只是返回空 result。如果你不做空值判断巡检报告里会出现“当前值 0、阈值 80、状态 OK”的假象这恰恰是监控最危险的情况。所以我在 Prompt 里特别说明了一句“所有指标都来自实际采集清单不要编造”同时在脚本里对 None 做了显式处理。这个设计是这次实践中我认为最值得保留的部分。3.2 把脚本接到定时任务和人工巡检入口脚本写好后下一个问题是怎么让它定期跑我采用的是最传统也最稳定的方案cron 定时任务加日志输出。# 每 10 分钟执行一次巡检结果写入日志文件 */10 * * * * cd /opt/prometheus-check /usr/bin/python3 check_mysql.py /var/log/mysql_check.log 21如果你不想每天清理日志可以在脚本里加一个简单的大小控制比如超过 20MB 就截断。这个逻辑没必要让大模型生成手动几行就能搞定但很多同学第一次做的时候容易忽略。定时任务只是“被动巡检”。我更推荐把它做成一个人工巡检入口也就是在运维平台上提供一个按钮点一下就能立即执行脚本并输出报告。我们这个项目里因为平台开发排期太长临时用了一个取巧的方式写了一个简短的 Web 接口封装脚本执行页面就是最简单的文本输出。后来验证效果不错才把这个能力并进了正式平台。这一步提到 Web 接口主要是想强调DeepSeek 生成的脚本本身是死的真正的价值在于它能不能作为一个原子能力被嵌入到更大的工作流里。如果只是每天 cron 跑一下、日志丢在服务器上没人看那这个自动生成的意义会大打折扣。我建议所有做监控巡检脚本的同学都要有一个“主动触发”的入口。4. 告警规则配置生成与调优4.1 直接可用的告警规则模板巡检脚本解决的是“周期性人工确认”告警规则解决的则是“7x24 自动通知”。两者可以共用同一套阈值和 PromQL但告警规则文件有它自己的语法结构groups、rules、expr、for、labels、annotations。我让 DeepSeek 基于同一份 MySQL 指标清单生成规则文件第一版就有模有样但有个问题它把 for 参数全设成了 0m。for: 0m 的含义是“只要表达式成立就立刻触发告警”这在高频采集且指标抖动明显的场景下会严重误报。比如线程连接数偶尔秒级冲到 85% 又回落这种瞬时的尖峰大多不影响业务不需要立刻告警。我们最终采用的规则文件如下我加上了注释说明每个 for 和阈值的调整理由groups: - name: mysql_availability rules: - alert: MySQLUpDown expr: mysql_up 0 for: 1m labels: severity: critical env: production annotations: summary: MySQL exporter 不可用 description: Prometheus 已无法从 mysqld_exporter 采集数据持续超过 1 分钟。 - name: mysql_performance rules: - alert: MySQLConnectionHigh expr: | mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 80 for: 10m labels: severity: warning annotations: summary: MySQL 连接数过高 description: 当前连接占比 {{ $value }}%持续 10 分钟需要关注是否有连接泄漏。 - alert: MySQLAbortedConnectsHigh expr: rate(mysql_global_status_aborted_connects[5m]) 5 for: 15m labels: severity: warning annotations: summary: MySQL 异常中断连接较多 description: 5 分钟窗口内异常中断速率约为 {{ $value }}可能是账号密码错误或网络不稳定。 - alert: MySQLSlowQueryHigh expr: rate(mysql_global_status_slow_queries[15m]) 2 for: 15m labels: severity: warning annotations: summary: MySQL 慢查询速率偏高 description: 最近 15 分钟慢查询速率约为 {{ $value }}建议检查慢查询日志并优化 SQL。这个文件有几点我想特别说明第一expr 用了多行写法Prometheus 的 YAML 支持这种形式但在表达式内部要注意 PromQL 的优先级。比如连接占比这个表达式如果不加括号 80会被解析成作用于整个除法结果这没问题。但如果你写的是a 80 or b 20这样的复合表达式就非常容易因为 or 的优先级产生误解。这也是大模型最容易犯错的地方后面我会单独讲。第二labels 里的 severity 和 env 不是 Prometheus 内置必须的但它们会传到 Alertmanager你的告警分组和路由规则通常依赖这两个字段。所以在 Prompt 里我要求模型在生成规则时同时生成 labels不然后续 Alertmanager 的 route 没法按级别分流。第三annotations.description 里用的{{ $value }}是 Go 模板语法。这个细节大模型一般知道但偶尔会写成{{ value }}少掉美元符号导致告警消息渲染失败。生成后要重点检查这个位置。4.2 rule 文件加载与告警路由对接规则文件生成后不是丢到 rules 目录就完事了。我习惯先用 promtool 做一次静态校验再通过 Prometheus 的 API 实时重载配置最后观察告警状态。先看静态校验# 在 Prometheus 二进制所在目录执行 ./promtool check rules /opt/prometheus/rules/mysql_rules.yml如果输出没问题再把规则文件挂载到容器或者直接复制进去然后触发热加载curl -X POST http://localhost:9090/-/reload去 Prometheus UI 的 Alerts 页面你应该能看到规则列表。此时规则状态应该是 Inactive等几分钟如果触发了会变成 Pending再持续一段时间变成 Firing。Pending 和 Firing 的区别很重要Pending 表示“条件满足但在 for 等待期内”Firing 才是真正进入告警。如果 Prometheus 和 Alertmanager 已经对接你还需要确认 Alertmanager 的 route 规则能识别 labels 里的 severity 和 env。比如下面这段简化配置route: group_by: [alertname, env] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: default routes: - matchers: - severitycritical receiver: page-critical这里最重要的是 group_by 和 repeat_interval 的配合。如果不做 group_by同一故障触发的多个告警会分别发送夜间连续收二三十条消息的情况就是这么来的。我们曾经因为没配置 repeat_interval一个持续告警每 20 分钟重复推送一次把值班同学搞得非常崩溃。这部分不是 DeepSeek 生成的但它是整个告警链路里必须人工把关的一环。4.3 阈值调优不是拍脑袋要基于数据回放上一节提到 for 参数和阈值这里我想单独展开一个很多人容易忽略的点阈值应该怎么定最差的方式是拍脑袋。比如“连接数 80% 告警”这个 80 从哪来的如果最大连接数设置得太高可能 80% 已经对应几百个连接业务早就卡死了如果太低可能平时业务高峰就是 70%告警天天发大家习以为常。我推荐的方式是把已经接入 Prometheus 的历史指标做一次回放统计一段时间内的基线。DeepSeek 可以帮你生成查询基线值的 PromQL但基线判定必须由人来做。比如# 近 7 天连接占比的平均值 avg_over_time( mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 [7d:1m] )拿到平均值和 p95 之后再把告警阈值设为“略高于 p95”而不是“拍脑袋 80%”。这个逻辑听起来很简单但实际操作中很少有人这么做因为要花时间去看历史数据。大模型的价值在于它可以把“计算 p95 的查询表达式”快速生成出来省去了写 PromQL 的调试时间。我自己遇到过一个真实案例某服务的错误率平时是 0.1%偶尔抖到 1%只有发布时才会到 5%。如果阈值定 5%发布时的错误很容易被忽略如果定 1%日常抖动会频繁触发。后来我让 DeepSeek 生成了一套“双阈值”方案1% 持续 30 分钟触发 warning5% 持续 5 分钟触发 critical。这就是借助模型把“一个阈值”扩展成“分级阈值”比单纯写一条规则要合理得多。5. 常见问题与排查技巧实录5.1 生成代码能用但不符合预期怎么办这是最常遇到的情况。DeepSeek 生成的脚本和规则第一眼看起来都挺正常一跑发现要么查询结果和预期差了十万八千里要么 YAML 加载失败要么告警规则根本没被 Prometheus 识别。我的处理顺序是固定的按照从外到内的顺序排查第一步先用 promtool 检查规则文件格式。Prometheus 的规则文件错误大多出在缩进和列表结构上比如 rules 下面少了一个- alert:的短横线或者 expr 的值没加引号导致解析异常。promtool 会把具体的行号错误直接抛出来这是定位问题最快的方式。第二步去 Prometheus UI 的 Alerts 页面看规则状态。如果规则列表里没有出现你新增的规则大概率是 rule_files 路径配错了或者热加载没生效。这时我会执行curl -X POST http://localhost:9090/-/reload并检查 Prometheus 容器日志热加载失败通常会有明确报错。第三步针对 PromQL 本身做单点验证。打开 Prometheus 的 Graph 页面把模型生成的表达式粘贴进去看有没有数据。没有数据时一种可能是指标名不存在另一种可能是表达式里用到了还没被采集到的新指标。这时候回过头去核对指标清单比在代码里瞎猜高效得多。我个人的经验是大模型生成的脚本如果报错不要直接让它“重写整个文件”而是把报错信息原样贴给它并且只要求它定位和修改报错那一部分。这样做准确率更高因为大模型在长上下文中重写时很容易把之前调好的内容也改坏。我用的是“局部修改”模式把错误信息、出错行、相关配置一起发给 DeepSeek明确说“只改这段不要动其他部分”。5.2 告警频繁误报和漏报的调参经验告警规则上线后最常见的反馈是“天天半夜响都麻木了”或者“这个告警从来没响过”。这两种情况看着相反本质是一样的阈值和业务节奏不匹配。我总结了一套调参流程供你参考先看告警触发记录找出时间规律。如果告警总在每天固定时段触发比如凌晨的定时任务、整点的缓存清理那就说明这个指标本来就有周期性高峰。处理办法不是盲目调高阈值而是给这条告警增加“静默时间”。Prometheus 本身不直接支持时间维度静默但可以通过 PromQL 的表达式或者 Alertmanager 的 mute 时间区间实现。如果用的是 Alertmanager可以在 route 规则里为这个 alertname 单独配一条接收 “null” 的静默路由。如果不想维护额外的静默配置就只能在生成规则时把阈值按照流量高峰来标定但这会牺牲敏感度。再检查 for 参数是否太短。我见过很多误报都是 for 设置成 0m 或 1m而实际指标只是瞬时抖动。一般来说CPU、内存、连接数这类指标建议 for 至少 5 到 10 分钟错误率这类直接影响业务的指标才建议 for 短一点。for 不是越小越灵敏太小了反而让值班团队疲惫真正严重的问题被淹没在低等级告警里。漏报的调法不太一样。漏报往往不是阈值太高而是表达式设计有问题。比如你用rate(metric[5m]) 5如果指标本身是 Counter 类型没问题但如果指标是 Gauge 类型rate 算出来就非常奇怪。这类问题大模型不一定能识别因为它的训练数据里没有你 exporter 的指标类型说明。最好的办法是人为确认指标类型并在 Prompt 里写明类型。比如mysql_global_status_*绝大多数是 Counter但mysql_global_variables_max_connections是 Gauge。这些信息不喂给模型它就很容易生成不合理的表达式。5.3 大模型生成配置的“幻觉”边界与控制方法最后说说大模型生成的固有风险。我在前几节反复强调“只使用给定指标”就是因为在实践中遇到过多次模型幻觉。最典型的表现是它生成一个 promql 表达式指标名看着很像但实际上不存在比如把 mysql_global_status_threads_connected 写成 mysql_global_status_threads_connect_count。Prometheus 对不存在的指标不会报编译错误只是查询结果为空。如果你的规则文件里混了三四个这种空查询指标告警就会全部变成“无数据”而很多人会把“无数据”误判为“正常”。控制幻觉的方法我实践下来最有效的是“分步生成 逐步验证”。第一遍只让 DeepSeek 生成 PromQL 表达式清单并强制要求它逐条列出依据的指标名。第二遍让它对每个 PromQL 去查询 Prometheus API返回真实值。这一步不能靠模型必须用脚本或者 Prometheus UI 验证。第三遍才让它生成完整的 YAML 规则文件。也就是说把“写表达式”和“写规则文件”拆成两个阶段而不是一次生成一大块。还有一个技巧是给 DeepSeek 提供“反例”。在 Prompt 里明确写“不要使用指标清单之外的任何指标名如果你拿不准请输出 NOT_SURE。”我印象很深的一次模型本来打算用一个不存在的指标看到这个约束后主动返回 NOT_SURE并说明原因。虽然它最后还是给出了一个备选方案但这个“拒绝编造”的行为比生成一个看起来很专业但实际无效的规则要安全得多。最后所有生成的规则和脚本都必须走版本控制并且在合并前至少过一个真实场景验证。我建议至少在 staging 环境跑一段时间等规则稳定了再上生产。大模型是提效工具不是质量保证工具。这一点想明白了整个方案就能稳定运行。如果后续你有精力扩展这个玩法可以考虑把“指标清单维护”也做成半自动让 DeepSeek 定期读取 Prometheus 的 /api/v1/status/tsdb 或者用 promtool 分析指标使用情况自动生成“未使用指标”和“疑似新指标”的清单。这样规则配置的维护就不会停留在“这次上线配一次”的状态而是形成一个持续更新的循环。至少在我自己的环境里这一步已经开始做了效果还在持续验证中。