适用场景

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

配置步骤（告警规则设计）

# 症状型告警（推荐）
groups:
- name: 业务健康
  rules:
  - alert: 服务错误率高
    expr: |
      sum(rate(http_requests_total{code=~"5.."}[5m])) by (service)
        / sum(rate(http_requests_total[5m])) by (service) > 0.05
    for: 5m
    labels: { severity: P1 }
    annotations:
      summary: "{{ $labels.service }} 5xx 错误率 > 5%"
      runbook: "https://kb.example.com/runbook/5xx"
  - alert: 接口耗时劣化
    expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)) > 1.2
    for: 10m
    labels: { severity: P2 }

关键参数与建议

  • 服务侧 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 高告警，业务没事也响，值班疲于应付
  • 没有 for 持续时间，抖动就告警
  • 没有 runbook 链接，收到告警不知道干什么
  • 一条规则覆盖所有服务，阈值对核心服务太松、对边缘服务太紧
  • 告警只有群没有电话，P1 半夜没人看
  • 告警不收敛，一次故障几百条

验证与巡检

# 告警质量检查
1) 每条告警是否有 for、severity、runbook？
2) P1 是否走电话？P2/P3 是否走群/工单？
3) 本月告警总量与有效比例？
4) 是否有重复/相关告警收敛？
  • 巡检：规则要素齐全、P1 通道可达、有效比例上升、月度告警治理有报告

小结

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

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