适用场景

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

配置步骤（RED 与 USE 指标落地）

# 服务侧 RED（按 service 维度）
Rate     : sum(rate(http_requests_total[5m])) by (service)
Errors   : sum(rate(http_requests_total{code=~"5.."}[5m])) by (service)
           / sum(rate(http_requests_total[5m])) by (service)
Duration : histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

# 资源侧 USE（按 instance 维度）
Utilization : 1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)
Saturation  : node_load1 / count by (instance)(node_cpu_seconds_total{mode="idle"})
Errors      : rate(node_network_receive_errs_total[5m]) by (instance)

# 数据库/中间件补位指标
- 连接数使用率、慢查询速率、主从延迟、队列堆积

关键参数与建议

  • 服务侧 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 年，避免存储爆炸
  • 基线：记录业务正常时段的指标基线，告警阈值基于基线而非拍脑袋

容易踩的坑

  • 只采 CPU/内存，服务错误率与耗时没人管
  • 平均值代替 P95，长尾问题被掩盖
  • 指标标签塞 user_id，基数爆炸把 Prometheus 打挂
  • 每个服务口径不同，跨服务对比无意义
  • 只采不设基线，告警阈值全是拍脑袋
  • 指标保留策略没设，磁盘几周就满

验证与巡检

# 指标健康检查
1) 核心服务是否都有 RED 三项？
2) 资源是否都有 USE 三项？
3) 单指标基数 Top10 是否 < 10 万？
4) 是否有基线数据（正常时段值）？
  • 巡检：RED/USE 覆盖核心服务、基数可控、基线已记录、存储水位正常

小结

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

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