其他
需要编写、验证或优化 Prometheus/Mimir…
在 Prometheus/Mimir/Grafana Cloud 上查询指标、构建告警/仪表板、排查 PromQL 错误时适用。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 35/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 38/100 ×0.15
适用场景
需要编写、验证或优化 Prometheu特定
解决思路
- 遵守黄金规则：rate()/increase() 需要范围向量，窗口 ≥ 4× scrape interval；例如 60s scrape 至少用 [5m]。
- 指向 Prometheus/Mimir 端点：PROM=http://localhost:9090 或 https://prometheus-prod-XX.grafana.net/api/prom；Grafana Cloud 使用 metrics endpoint 并在每个 curl 中加 basic auth（-u "<metrics_user>:<token>"）。
- 草拟查询，例如 5xx 每服务错误率：EXPR='sum(rate(http_requests_total{status_code=~"5.."}[5m])) by (service)'。
- 验证语法和指标/标签是否存在：curl -sG --data-urlencode "query=${EXPR}" "$PROM/api/v1/query" | jq '.status, (.data.result|length)'；期望 "success" 且结果数 > 0。
- 如果结果数为 0，检查标签拼写和抓取活动：curl -sG --data-urlencode "match[]=http_requests_total" "$PROM/api/v1/series" | jq '.data | length'。
- 人工核对量级：打开 Grafana Explore，粘贴表达式，对照已知真实值（k6 运行、日志计数等）确认数值正确。
- 复制常用模式：按状态码的请求速率（在 rate 之后聚合）：sum(rate(http_requests_total{job="api"}[5m])) by (status_code)。
- 复制常用模式：p95 延迟（内层聚合必须保留 le）：histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))。
- 复制常用模式：带除零保护的错误率：sum(rate(http_requests_total{status_code=~"5.."}[5m])) / (sum(rate(http_requests_total[5m])) > 0)。
- 查阅完整模式库：references/patterns.md，包含 recording rules、SLO burn-rate、offsets、cardinality hunt、native histograms。
- 将慢查询转为 recording rule：挑选慢表达式，给它 recording-rule 名称；例如 YAML： groups: - name: http_request_rates interval: 1m rules: - record: job:http_request_duration_p95:rate5m expr: | histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, job))
- 规则加载后，验证新指标存在：curl -sG --data-urlencode "query=job:http_request_duration_p95:rate5m" "$PROM/api/v1/query" | jq '.data.result | length'；结果应 > 0。
- 验证 recording rule 至少在一个采样窗口内与原表达式一致：两个查询在同一时间戳应产生相同值。
- 将仪表板面板表达式替换为 recording-rule 指标。
- 修复 histogram_quantile 返回 NaN：检查内层聚合是否遗漏 by (le)。
- 修复 "No data"：检查指标是否存在（/api/v1/series），且窗口 ≥ 4× scrape interval。
- 修复 rate 量级错误：检查是否在 rate() 之前聚合了 counter（始终先 rate()）。
- 修复查询超时：序列数过高；使用 topk(...) + recording rule + 丢弃高基数标签（见 references/patterns.md）。
- 对于未展开的模式（rate vs irate vs increase、label matchers 与 regex、sum/avg/topk/by/without 聚合、classic 与 native histogram_quantile、除零保护比率、absent/changes 检测 staleness、time offsets 与 predict_linear、SLO + burn-rate 数学、cardinality-hunting playbook），参阅 references/patterns.md 获取具体做法。
适用边界 · 注意事项
- 不适用于非 Prometheus 兼容的监控系统（如 Datadog、CloudWatch、Zabbix），除非有 PromQL 兼容查询层。
- 不适用于没有可查询的 Prometheus/Mimir/Grafana Cloud 端点或没有指标数据的场景。
- 不适用于主要依赖日志或链路追踪的根因分析，PromQL 只处理指标。