值得做的前提：指标本身是干净的
自然语言生成 PromQL 的收益很直接，但它放大的是你已有的指标体系：命名规范、标签一致，结论就稳；反过来，指标缺失或标签混乱时，Agent 会用语法完全正确的查询给出错误结论，比人工写错更难发现。所以第一步不是接 MCP，而是确认数据源可用。
PromQL 的学习门槛与痛点
在运维复杂的微服务集群时，编写精准的 PromQL 查询（如 histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))）对非专业 SRE 人员而言门槛较高。
通过部署 Prometheus MCP Server，工程师可以直接用自然语言提问：
- “过去 30 分钟内，订单服务的 P99 延迟有没有异常突增？”
- “找出当前 Pod 中 CPU 内存使用率持续超过 85% 的微服务名称。”
Agent 会自主生成合规的 PromQL 并通过 MCP 工具向 Prometheus 实例发包，将统计图表与结论以 Markdown 表格形式清晰展示。
1. 先证明端点可查
curl -sG 'http://localhost:9090/api/v1/query' \
--data-urlencode 'query=count(up)'
返回 status 为 success 且 data.result 非空，说明实例可达、有数据。这一步不过关就不要往下配：MCP 侧报的"查不到"多半就是抓取本身没工作。
2. 只暴露读接口
工具面应当严格限制在查询类端点上：/api/v1/query、/api/v1/query_range、/api/v1/series、/api/v1/labels、/api/v1/targets。
对应的服务端约束也别漏：不要开启管理接口（--web.enable-admin-api），远程写入能力不要经这层暴露。原因很直接——一次被注入的提示词只要能构造出写请求，代价就是篡改或清空监控数据。指标范围也要收：允许查询的指标前缀按业务列白名单，避免高基数指标被全量拉出。
3. 把指标字典一起喂给 Agent
模型猜标签名的准确率远低于猜函数用法。成本最低的做法是维护一份精简映射表，作为资源或系统提示的一部分注入：
| 业务意图 | 指标前缀 | 查询形态 |
|---|---|---|
| 请求延迟分布 | http_request_duration_seconds | _bucket + histogram_quantile |
| 错误率 | http_requests_total | rate(...[5m]) 按比例聚合 |
| 资源用量 | container_* | 按 namespace、pod 聚合 |
聚合维度必须写清（by (service) 还是 by (pod)），这一栏决定了结果是不是团队想看的那个口径。已经反复使用的查询，落成 recording rule 让规则名成为稳定词汇，比每次现编更可靠。
4. Grafana 侧接什么
Grafana 的价值不在重复查询，而在呈现与关联：把面板 JSON 作为只读资源暴露，Agent 能引用既有面板而不是重画一张；需要标注发布、演练事件时走注解接口（字段以官方文档为准）。展示给工程师的结论，最好带一条可点回 Grafana 的链接——复核成本会显著下降。
怎么验证真的可用
三条判据：
- 用一条人写的等价 PromQL 与 Agent 生成的查询比对结果数值，误差应为 0；
- 问一个数据源里根本没有指标的领域，它应当回答"无对应指标"，而不是给出空图表加一段合理叙述；
- 检查生成查询的时间窗口：
rate()的区间短于抓取间隔若干倍时结果会是空的或抖动的，这属于典型错误。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 查询返回空 | 标签名与真实序列不一致 | 用 labels/series 接口核对 |
| P99 恒为 0 或 NaN | 缺 _bucket 序列 | 确认直方图指标已上报 |
| 结果明显偏大 | 忘了 rate() 或多实例重复求和 | 补 sum by (...) 聚合 |
| 大范围查询超时 | 时间区间过宽、基数过高 | 缩短区间、提高聚合粒度 |
| 结论正确但图很乱 | 未复用既有面板口径 | 按第 4 节引用面板 |
小结
这套监控问答是否可信，取决于一个判断标准：每一次结论能否被复制成一条可复核的查询。因此要求 Agent 始终输出实际执行的 PromQL 是硬性约定——只要这一条在，错误就是可诊断的；丢了这一条，自然语言运维退化成一个会说漂亮话的黑盒。