4. 监控告警体系：监控指标分类（RED/USE方法）、Prometheus与Grafana实战、告警规则设计与降噪

监控告警这事儿，说白了就是运维的「眼睛」和「耳朵」。

我见过太多团队，一上来就堆指标，恨不得把CPU的每个晶体管都监控起来。结果呢？告警风暴一来，谁也分不清哪个是真问题。今天这一章，咱们就聊聊怎么把监控做「精」，而不是做「多」。

4.1 监控指标分类：RED 与 USE 方法

先问个问题：你监控一个服务，到底该看什么？

我个人习惯，先分两类看：服务型指标和资源型指标。对应的就是 RED 方法和 USE 方法。

4.1.1 RED 方法：面向服务的三大黄金指标

RED 是 Google SRE 总结出来的，专门用来衡量「用户体验」的。三个字母分别代表：

指标 全称 含义 举例
R Rate 请求速率 每秒多少请求（QPS）
E Errors 错误数 HTTP 5xx、超时、业务异常
D Duration 响应时长 P50、P95、P99 延迟

核心观点：只要这三个指标没问题，用户大概率是满意的。其他的，都是辅助。

我在项目中遇到过一件事：有个服务 QPS 很高，延迟也正常，但用户老说「卡」。后来一查，是 P99 延迟从 200ms 飙到了 2s，但 P50 才 50ms。你看，只看平均值是会骗人的。所以我建议，延迟一定要看分位数，尤其是 P99。

4.1.2 USE 方法：面向资源的四大核心指标

USE 方法专门用来排查「资源瓶颈」。比如 CPU、内存、磁盘、网络。四个字母：

指标 全称 含义 举例
U Utilization 利用率 CPU 使用率 90%
S Saturation 饱和度 CPU 运行队列长度、内存 swap 用量
E Errors 错误数 磁盘 I/O 错误、网络丢包

一个小技巧：看资源时，先看「饱和度」。利用率高不一定有问题，但饱和度高了，说明资源真的不够用了。我曾经排查过一个 MySQL 慢查询问题，CPU 利用率才 30%，但运行队列长度到了 20。嗯，这就是典型的「CPU 在等锁」。

4.2 Prometheus 与 Grafana 实战

理论说完了，咱们上手。Prometheus + Grafana 是目前最流行的监控组合，没有之一。

4.2.1 Prometheus 核心概念

Prometheus 是个「拉模式」的时序数据库。说白了，就是它定期去你的服务上「抓」指标。

几个关键概念你得记住：

  • Metric（指标）：比如 http_requests_total
  • Label（标签）：比如 method="GET"、status="200"
  • Sample（样本）：一个具体的数值 + 时间戳

举个例子，一个典型的指标长这样：

http_requests_total{method="POST", handler="/api/v1/order", status="200"} 1024

这个指标的意思是：到目前这一刻，POST 请求 /api/v1/order 接口，返回 200 的次数是 1024 次。

注意：Prometheus 的指标是「累计值」。你要算 QPS，得用 rate() 函数。千万别直接拿这个值画图，不然你会看到一条永远向上的线。

4.2.2 实战：搭建一个简单的监控

假设你有一个 Go 服务，暴露了 /metrics 端点。Prometheus 配置如下：

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'my-service'
    static_configs:
      - targets: ['localhost:8080']

启动 Prometheus：

./prometheus --config.file=prometheus.yml

然后打开 Grafana，添加 Prometheus 数据源。写一个简单的面板，展示 QPS：

rate(http_requests_total[1m])

这个查询的意思是：过去 1 分钟内，每秒的平均请求数。我个人习惯用 [1m] 或 [5m]，太短了抖动大，太长了反应慢。

4.2.3 Grafana 面板设计心得

Grafana 面板不是越花哨越好。我见过有人一个面板放 20 个图，结果谁也看不清。我的建议是：

  • 一个面板只聚焦一个维度：比如「延迟」一个面板，「错误率」一个面板。
  • 用颜色区分严重程度：绿色正常，黄色警告，红色严重。
  • 加上阈值线：比如延迟超过 500ms 就画一条红线，一眼就能看出问题。

避坑指南：我曾经把 Grafana 的刷新时间设成了 1s，结果 Prometheus 服务器直接被查挂了。嗯，Grafana 的刷新频率不要低于 Prometheus 的抓取频率，否则就是白费力气。

4.3 告警规则设计与降噪

告警设计得好，你是救火英雄。设计得不好，你就是那个「狼来了」里的孩子。

4.3.1 告警规则设计原则

我总结了三句话：

  1. 告警要可行动：收到告警，你得知道该干嘛。如果不知道，那就别告警。
  2. 告警要可容忍：偶尔抖动一下，别急着报警。加个持续时间，比如持续 5 分钟才报警。
  3. 告警要有优先级：P0 是服务挂了，P1 是延迟高了，P2 是磁盘快满了。别把 P2 和 P0 混在一起。

举个例子，一个合理的告警规则：

# 如果过去 5 分钟，错误率超过 5%，且持续了 3 分钟，就报警
- alert: HighErrorRate
  expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
  for: 3m
  labels:
    severity: critical
  annotations:
    summary: "错误率超过 5%"

4.3.2 告警降噪：别让告警变成噪音

告警降噪，说白了就是「少发告警，多发有用的告警」。我常用的几个方法：

  • 聚合告警：同一个服务、同一个错误类型，合并成一条告警。别一个 Pod 报错就发一条。
  • 抑制告警：如果已经有一个 P0 告警了，相关的 P1、P2 告警先别发。比如服务挂了，就别再报「磁盘使用率高」了。
  • 静默告警：已知的维护窗口、已知的发布窗口，提前静默掉。

一个小技巧：我习惯在告警规则里加上 runbook_url。这样收到告警的人，点开就能看到处理步骤。别让值班的人半夜起来还要想「这个告警怎么处理」。

4.3.3 实战：用 Alertmanager 做告警管理

Prometheus 本身不负责发送告警，它只负责「评估」。真正发告警的是 Alertmanager。

一个典型的 Alertmanager 配置：

# alertmanager.yml
route:
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
    - match:
        severity: warning
      receiver: 'email'

receivers:
  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: 'your-key'
  - name: 'email'
    email_configs:
      - to: 'ops@example.com'

这个配置的意思是：P0 告警发到 PagerDuty（打电话），P1 告警发邮件。嗯，这样值班的人就不会被邮件吵死了。

注意：Alertmanager 的 group_by 和 group_wait 参数很重要。设置不好，你会收到一堆重复告警。我一般设置 group_wait: 30s，意思是 30 秒内的同类告警合并成一条。

4.4 本章小结

监控告警这事儿，说难不难，说简单也不简单。核心就三点：

  • 用 RED 和 USE 方法，知道该看什么指标
  • 用 Prometheus + Grafana，把指标可视化
  • 用合理的告警规则 + 降噪策略，让告警真正有用

最后送你一句话：监控不是为了看数据，而是为了发现问题。如果数据看了半天也不知道问题在哪，那这个监控就是失败的。

下一章，咱们聊聊「日志分析与 ELK 实战」。到时候见。

← 上一章 📖 返回目录 下一章 →