prometheus（Prometheus监控与告警）Skill 是什么？如何安装使用？

Prometheus监控与告警Skill：让 AI 替你写对每一条 PromQL 和告警规则

一句话定位：这是一款专攻 Prometheus 云原生可观测性的 AI 技能，把 PromQL 查询、抓取配置、告警规则、记录规则、服务发现与 relabel 这些「容易写错、写错就出事」的工作交给 AI 来协助完成。
边界非常清晰：它只做 Prometheus 监控与告警相关的事，不做仪表板（那是 Grafana 的活），也不做日志分析（那是日志可观测性技能的活），因此给出的建议更聚焦、更少跑偏。
内置工程最佳实践：指标命名约定、标签基数治理、症状告警优先于原因告警、记录规则预聚合、SLO 错误预算燃烧率告警等，都被写进了技能的行为准则里。
可落地而非只给答案：技能被允许读取、检索、编辑、写入文件并执行命令，意味着它可以直接改你的 prometheus.yml、alerts/*.yml，再用 promtool 校验语法。
触发即用：只要在对话中出现「指标」「promql」「告警规则」「抓取」「导出器」「SLO」等触发词，技能就会被唤起，不需要记复杂命令。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

基本信息

项目	内容
技能中文名	Prometheus监控与告警Skill
技能英文名	prometheus
技能ID	13489
技能定位	云原生可观测性中的 Prometheus 监控与告警专家
允许使用的工具	Read、Grep、Glob、Edit、Write、Bash

它解决什么问题

Prometheus 本身不难上手，难的是「写对」。真实工作中的痛点往往集中在以下几个地方：

PromQL 写法有陷阱：计数器必须配 rate() 或 increase()，直接对计数器求平均是经典错误；直方图分位数要用 histogram_quantile() 配 le 标签聚合，聚合维度写错就得到一条毫无意义的曲线。
抓取配置与 relabel 难调试：Kubernetes 服务发现里 __meta_kubernetes_pod_annotation_prometheus_io_scrape 一类的元数据标签、keep/drop/replace/labelmap 的动作组合，写错一个正则就很难发现，因为 Prometheus 启动时不会报错，但目标就是抓不到。
告警要么太吵要么太哑：缺少 for 子句导致告警抖动，按「原因」告警导致告警风暴，注释里没有 runbook 链接导致收到告警的人不知道怎么办。
指标治理没章法：指标命名不规范、单位不统一、把用户 ID 和完整 URL 当标签用，时间序列基数爆炸，最后把 Prometheus 自己拖垮。

一键安装的思路与步骤

这类 AI 技能通常以「技能包」形式分发，接入支持技能机制的 AI 客户端或命令行助手后即可使用。具体安装入口、目录路径与版本命名以官方说明为准，通用流程如下：

确认安装前提：拥有一个支持自定义技能/工具扩展的 AI 客户端或 CLI 环境；具备本地文件读写权限（因为该技能需要读取你的 Prometheus 配置和规则文件）。
获取技能包：在技能市场或官方发布的技能仓库中检索技能英文名 prometheus 或技能ID 13489，下载对应技能包。
安装到技能目录：按客户端要求，将技能包放入本地技能目录，或在客户端内通过「安装技能 / 添加技能」入口导入。
刷新或重启生效：多数客户端需要重启会话或刷新技能列表，技能才会被加载。
验证是否生效：新建一个会话，发送一句包含触发词的话，例如「帮我写一条 PromQL，计算最近 5 分钟的 5xx 错误率」。如果回复围绕 PromQL 与 Prometheus 最佳实践展开，说明技能已被成功唤起。
进阶验证：让技能读取你本地的 prometheus.yml 并做一次配置审查。由于技能具备 Read / Grep 能力，它可以定位文件、检索关键字段，并给出修改建议。

提示：安装命令、技能仓库地址、是否需要账号授权等细节，请以官方说明为准。本文不对未公开的安装参数作任何假设。

该技能的主要功能和特点

能做什么

PromQL 查询编写与审查：覆盖即时向量与范围向量选择器、正则匹配器、rate/irate/increase、错误率与成功率、histogram_quantile 分位数、topk/bottomk、predict_linear 磁盘耗尽预测、offset 同比环比、absent() 缺失检测、group_left/group_right 向量匹配等。
抓取目标配置：静态配置、基于文件的服务发现、Kubernetes（Pod / Service / Node / Endpoints）服务发现、Consul、EC2、DNS SRV 等多种服务发现方式。
relabel 重标记设计：按注释过滤目标、提取自定义 metrics 路径与端口、用 labelmap 批量复制 Kubernetes 标签、用 labeldrop/labelkeep 降低基数、用 hashmod 做水平分片。
告警规则设计：编写带 for 子句的告警规则，配置 severity、team、env 等标签，补充 summary / description / runbook / impact 等注释，并区分「症状告警」与「原因告警」。
Alertmanager 配置：路由树、分组、抑制规则（inhibit_rules）、静默、多接收器（Slack、PagerDuty、邮件）、基于时间区间的路由。
记录规则与预聚合：把昂贵的查询预计算成 level:metric:operations 形式的记录规则，降低查询压力。
应用埋点指导：给出 Go、Python（Flask）等语言的客户端库示例，正确使用计数器、仪表、直方图、摘要四种指标类型。
SLO 与错误预算：多窗口多燃烧率告警、Apdex 分数计算等进阶查询模式。
Kubernetes 原生集成：ServiceMonitor、PodMonitor、PrometheusRule、Prometheus 自定义资源（CRD）的编写。
故障排查：promtool check config、promtool check rules、/api/v1/targets、/api/v1/status/tsdb 等排查命令与接口的使用。

和普通工具比强在哪

不是一个通用问答机器人：技能的描述里明确写了「不要使用：用于构建仪表板（使用 /grafana）、日志分析（使用 /logging-observability）」，这种边界约束让它在自己的领域内更专业，也避免了对不属于自己范围的问题乱给答案。
把最佳实践固化成默认行为：普通 AI 可能会给你一条能跑但不符合规范的 PromQL；这个技能默认就会遵循「计数器加 _total 后缀」「持续时间统一用秒」「比率用 0.0–1.0 而非 0–100」「每个标签值控制在 10 个以内」等约定。
能直接动手改文件：因为被授予了 Read / Grep / Glob / Edit / Write / Bash，它不只是「告诉你怎么写」，而是可以在你确认后直接修改配置文件，再跑一遍校验命令。
配置示例是完整的：它给出的 YAML 不是片段，而是带注释的完整配置块，省去大量拼接和查文档的时间。

如何使用该技能？

第 1 步：准备上下文

把 Prometheus 配置文件目录告诉技能，或者直接让它检索。例如：

「这是我的 Prometheus 配置目录 /etc/prometheus，请先看看 prometheus.yml 和 alerts/ 下的规则文件。」

技能会利用 Read / Glob 能力定位文件，理解你现有的 job 命名、标签体系和规则组织方式，后续建议才会贴合你的实际环境。

第 2 步：用触发词描述需求

技能会在检测到「指标」「promql」「告警」「告警规则」「记录规则」「抓取」「目标」「标签」「服务发现」「重新标记」「导出器」「检测」「slo」「错误预算」等关键词时被唤起。描述需求时尽量带上三个要素：对象（哪个服务/指标）、目标（想得到什么）、约束（命名约定、标签、阈值）。

输入示例 1（查询编写）：

「我们的 HTTP 指标叫 http_requests_total，标签有 method、endpoint、status。帮我写一条 PromQL，按 service 维度计算最近 5 分钟的 5xx 错误率，再写一条 P95 延迟查询，延迟指标是 http_request_duration_seconds 直方图。」

输出预期：技能会给出类似下面的查询，并解释为什么这样写：

sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)

histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)
)

同时它会提醒：分母必须与分子保持相同的聚合维度，否则会出现空结果或维度错配。

输入示例 2（告警规则）：

「给上面的错误率加一条告警，连续 5 分钟超过 5% 才触发，严重级别 critical，归属 backend 团队，要带 runbook 链接和用户影响描述。」

输出预期：一条完整的告警规则，含 expr、for: 5m、labels 与 annotations，并使用 humanizePercentage 把比值格式化成百分比展示。

输入示例 3（Kubernetes 服务发现）：

「我们有一套 Kubernetes 集群，只有打了 prometheus.io/scrape=true 注释的 Pod 才需要被抓取，端口和路径也从注释里取，另外要把 namespace、pod 名称和 app 标签带进时间序列。请给我完整的 scrape_configs 片段。」

输出预期：一段包含 kubernetes_sd_configs 与多段 relabel_configs 的配置，其中 keep 负责过滤目标、replace 负责改写 __metrics_path__ 与 __address__、labelmap 与 replace 负责补充标准标签。

第 3 步：让技能落盘修改

确认方案没问题后，可以让技能直接改文件：「请把这条规则写入 alerts/symptom_based.yml，追加到 symptom_alerts 这个 group 下。」技能会使用 Edit / Write 完成修改，尽量保持追加而不破坏原有结构。

第 4 步：校验与验证

改完之后一定要校验。可以让技能执行：

promtool check config prometheus.yml
promtool check rules alerts/*.yml

再让它用一个具体查询做冒烟测试：

promtool query instant http://localhost:9090 'up'

第 5 步：迭代优化

如果告警太吵，可以继续追问：「最近这条告警经常抖动，帮我把 for 调整到 10 分钟，并补充一条抑制规则：当 ServiceDown 触发时，抑制同一 service 下的实例级告警。」技能会基于抑制规则的最佳实践给出配置，而不会简单地让你调阈值。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
Prometheus监控与告警Skill（本技能）	垂直领域的 AI 可观测性助手	PromQL、抓取配置、告警/记录规则、服务发现与 relabel、埋点指导、SLO 设计、K8s CRD	低：安装技能包即可，需具备本地文件读写环境	日常写查询、改配置、治理告警	优势：边界清晰、内置最佳实践、可直接改文件并校验；不足：不做仪表板与日志，长期存储架构细节需结合文档确认
通用大模型对话（通用 AI 助手）	通用问答	什么都能问一点	极低：打开网页即可	快速了解概念、泛泛提问	优势：门槛最低；不足：PromQL 细节容易出错，不熟悉 relabel 语义，不会主动校验文件
官方文档 + 人工查阅	权威参考	完整的配置项与函数说明	中：需要自行定位章节并理解上下文	精确核对参数、查函数签名	优势：最权威、版本准确；不足：不针对你的环境给建议，排查问题耗时
资深 SRE 人工支持	人力专家	架构设计、告警治理、故障复盘	高：依赖人力排期与成本	重大架构决策、事故复盘	优势：经验丰富、能担责任；不足：成本高、响应慢，不适合日常重复劳动

需要说明的是，这几类方案并非互斥关系。比较务实的组合是：用本技能完成日常的查询编写、配置修改与规则审查，用官方文档做最终参数核对，把资深 SRE 的时间留给架构设计和事故复盘这类高价值工作。

该技能的典型应用场景与实际体验情况

场景一：后端工程师给新服务补齐监控

角色与痛点：一位后端工程师刚把新服务上线，代码里没有任何埋点，只知道「要加监控」，但不清楚该用计数器还是直方图、桶怎么划分、命名怎么规范。

使用方式：把服务的技术栈告诉技能（例如 Python + Flask），说明要监控的核心指标（请求量、错误量、延迟、并发连接数），让技能给出埋点代码与配套的抓取配置。

实际体验：上手难度很低。技能会直接给出四个指标类型的完整定义，并自动套用命名约定——计数器带 _total 后缀、持续时间统一用秒、直方图桶覆盖从毫秒到十秒的区间。注意事项：技能给的是模板代码，业务标签（如 endpoint）的具体取值仍需你自己确认，避免把路径参数写进标签造成基数爆炸。

场景二：SRE 治理告警风暴

角色与痛点：某团队一周收到上千条告警，其中大部分是「高内存使用」「磁盘空间低」这类原因告警，真正影响用户的告警反而被淹没。

使用方式：把现有告警规则文件交给技能，请它按「症状优先、原因降级」的原则做一次审查，并补充抑制规则。

实际体验：效果比较明显。技能会把「高内存使用」这类规则降级为 warning 并加长 for 时间，同时建议新增基于错误率和 SLO 燃烧率的 critical 告警，再配置「critical 触发时抑制同实例 warning」的抑制规则。注意事项：告警治理是渐进过程，建议一批一批改，每批改完观察一段时间，不要一次性重构全部规则。

场景三：平台工程师配置 Kubernetes 服务发现

角色与痛点：集群里有几百个 Pod，希望只抓取显式声明了监控注释的 Pod，并且要把 namespace、pod、app 等标签带进时间序列，但 relabel 的正则总是调不对。

使用方式：描述注释约定（scrape / port / path / scheme），让技能输出完整的 scrape_configs 片段，并逐段解释每个 relabel_config 的作用。

实际体验：技能会把 keep、replace、labelmap 的分工讲得很清楚，尤其是从 __address__ 中提取并替换端口的那段正则，避免了手工推导。注意事项：一定要用 promtool check config 校验，并且到 /api/v1/targets 页面确认目标真的被抓到了——配置语法正确不等于抓取成功。

场景四：团队落地 SLO 与错误预算

角色与痛点：团队想从「阈值告警」升级到「SLO 告警」，但不知道 14.4 倍燃烧率这类参数怎么用，也不清楚多窗口策略怎么设计。

使用方式：告诉技能当前的 SLO 目标（例如 99.9%）和统计窗口，让它生成基于错误预算燃烧率的告警规则，并解释参数含义。

实际体验：技能会给出多窗口多燃烧率的组合写法，并说明为什么短窗口负责快速发现、长窗口负责减少误报。注意事项：SLO 的目标值应由业务方共同确定，技能只负责把目标翻译成规则，不能替代业务决策。

该技能能为用户带来的价值

1. 把「查文档 + 试错」变成「一次写对」 PromQL 和 relabel 的试错成本很高，因为写错了通常不会有明显报错，只会得到一条错误的曲线或一个抓不到的目标。技能内置的查询模式与配置范式，能把大量隐性经验前置到写作阶段，显著减少反复调试的时间。

2. 降低可观测性建设的门槛 过去要给服务加监控，通常需要有经验的人来设计指标、划分桶、写告警。现在一位普通后端工程师借助技能，也能产出符合团队规范的埋点代码和告警规则，团队对个别专家的依赖明显下降。

3. 直接改善告警质量，减少无效打扰 症状告警优先、for 子句抑制抖动、抑制规则削减噪音、runbook 链接提升可操作性——这几条是告警质量的核心杠杆，技能把它们作为默认输出，能实实在在减少「狼来了」式的无效告警。

4. 从源头控制成本 标签基数失控是 Prometheus 最常见的隐性成本来源。技能在生成指标与标签时会主动提醒「避免把用户 ID、IP、时间戳、完整 URL 作为标签」，并建议用记录规则预聚合高基数指标，这对控制存储与查询压力有长期价值。

5. 让配置变更更安全 技能可以直接修改文件，并且能用 promtool check config、promtool check rules 做语法校验，把「改完直接上线」的风险降低一个档次。

6. 沉淀团队规范 当技能反复以同一套命名约定、标签规范、告警模板输出内容时，这些规范会自然变成团队的事实标准，新成员不需要翻旧文档也能写出风格一致的配置。

常见问题 FAQ

Q1：这个技能怎么安装？我需要在 Prometheus 服务器上装什么吗？

不需要在 Prometheus 服务器上安装任何东西。这个技能是给 AI 客户端用的技能包，安装在你使用 AI 助手的本地环境中，通过技能市场或技能目录导入后即可使用。它属于「辅助写配置」的工具，本身不采集数据、不运行监控。具体安装入口与命令请以官方说明为准。

Q2：这个技能收费吗？

技能本身的计费方式取决于你使用的 AI 客户端或技能平台的策略，本文不对价格作任何说明，请以官方说明为准。需要区分的是：Prometheus 自身是开源软件，而本技能是帮助你和 Prometheus 打交道的 AI 能力，两者是不同层面的东西。

Q3：它和直接问通用大模型有什么区别？我为什么不直接问？

区别主要在三点：一是领域边界，该技能被明确限定在 Prometheus 监控与告警范围内，不会被拉到仪表板或日志分析的岔路上；二是默认最佳实践，它输出的命名、单位、基数、告警分级都遵循行业约定，不需要你每次都叮嘱；三是可操作，它能读你的配置文件、改文件、跑 promtool 校验，是「动手」而不只是「建议」。

Q4：它适合谁用？我是新手会不会看不懂？

三类人收益最大：一是后端/应用开发工程师，需要给自己的服务加埋点和告警；二是SRE 与运维工程师，需要治理告警噪音、维护大规模抓取配置；三是平台工程师，需要处理 Kubernetes 服务发现与 Prometheus Operator 相关资源。新手也能用，但建议从一个具体小需求开始（比如「帮我写一条错误率查询」），逐步建立对 PromQL 的理解，而不是一次性让它生成整套监控体系。

Q5：让它直接改我的配置文件安全吗？

技能被授予了 Edit / Write / Bash 能力，因此确实具备修改文件和执行命令的权限。建议遵循三条原则：一是改之前确保配置目录在版本控制下，随时可回滚；二是让它改完后必须执行 promtool check config 和 promtool check rules 校验；三是在生产环境采用「先生成、再人工确认、最后落盘」的流程，而不是让它全自动改生产配置。

Q6：它和 Grafana 类的技能怎么分工？

按技能自身的边界说明：本技能负责指标采集、查询与告警（Prometheus + Alertmanager 这一层），仪表板可视化交给 Grafana 相关技能，日志分析交给日志可观测性相关技能。实际工作中常见做法是：用本技能写好后端查询与告警规则，再把同样的 PromQL 交给 Grafana 侧做面板。