适用场景

指标不在于多，而在于能回答两个问题：服务健康吗、资源够用吗。RED 管服务（请求量、错误率、耗时），USE 管资源（利用率、饱和度、错误）。先定这两个框架，再写查询与告警。

配置步骤（PromQL 常用模式）

# 1) 错误率（5 分钟窗口，排除健康检查）
sum(rate(http_requests_total{code=~"5..", path!~"/health.*"}[5m])) by (service)
  / sum(rate(http_requests_total{path!~"/health.*"}[5m])) by (service)

# 2) P95 / P99 耗时
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

# 3) 同比与环比（看是否异常）
# 当前 5 分钟 vs 1 小时前
sum(rate(http_requests_total[5m]))
  / sum(rate(http_requests_total[5m] offset 1h))

# 4) 饱和度（队列/连接池）
max by (instance) (mysql_global_status_threads_connected) / max by (instance)(mysql_global_variables_max_connections)

# 5) Top N 慢接口
topk(10, sum(rate(http_request_duration_seconds_sum[5m])) by (path))

关键参数与建议

  • 服务侧 RED：Rate（QPS）、Errors（错误率）、Duration（P95/P99）
  • 资源侧 USE：Utilization（使用率）、Saturation（排队/饱和度）、Errors
  • 标签规范：service、instance、env、version 四个必备，禁止高基数标签（如 user_id、URL 全路径）
  • 聚合口径：先 rate 再 sum，避免平均值掩盖长尾
  • 告警规则：基于症状（错误率、耗时）而不是原因（CPU 高），并设置持续时间
  • 告警分层：P1 电话、P2 群、P3 工单；每条告警有明确的处置动作
  • 指标保留：原始 15 天、降采样 1 年，避免存储爆炸
  • 基线：记录业务正常时段的指标基线，告警阈值基于基线而非拍脑袋

容易踩的坑

  • 直接对 counter 求和，重启后出现负值或跳变
  • 忘了 label 对齐，除法的分子分母维度不一致报错
  • 用 irate 做告警判断，抖动导致误报
  • 时间窗口与告警频率不匹配，告警风暴
  • 用 offset 做同比但没考虑业务周期（周末/工作日）
  • 查询写在 Grafana 里没沉淀，换人就得重写

验证与巡检

# 规则校验（Prometheus 自带）
promtool check rules /etc/prometheus/rules/*.yml
promtool check config /etc/prometheus/prometheus.yml

# 关键规则必须有 for 持续时间，避免瞬时抖动误报
  • 巡检：规则语法通过、每条告警有 for 时间、查询口径统一、常见查询已沉淀成看板

小结

指标验收：随便问一个服务「现在健康吗」，能立刻给出错误率与 P95 的趋势图，并说清与上周同期比是否异常。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。