一、告警哲学：为什么需要告警？告警的黄金指标

说实话，我做了这么多年监控，见过太多团队把告警当成「开关」来用——系统出问题了，告警就响；系统好了，告警就停。但告警的本质远不止这么简单。

告警是什么？说白了，它是你系统的「痛觉神经」。没有告警，系统挂了你还蒙在鼓里。但告警太多，就像一个人全身都在痛，你反而不知道哪里真正出了问题。

1.1 为什么需要告警？

我刚开始做运维那会儿，有个项目上线后，半夜三点数据库连接池爆了。没有告警，第二天早上用户投诉了才知道。嗯，那次之后我养成了一个习惯：任何关键系统，必须配告警。

告警的核心价值就三个：

• 发现问题——系统出故障了，你得第一时间知道。不是等用户来骂你。
• 定位根因——告警信息能帮你快速缩小排查范围。比如CPU飙高，你至少知道是计算密集型问题。
• 量化服务健康度——告警频率、响应时间、恢复时间，这些数据能直接反映你的系统稳不稳。

1.2 告警的黄金指标：USE 与 RED 方法

你可能会问：那到底该监控哪些指标？我个人的经验是，别贪多。你想想看，指标成百上千，真正能帮你快速判断系统状态的，就那么几个。

这里我推荐两个经典方法：USE 和 RED。

USE 方法（资源视角）

USE 是 Utilization、Saturation、Errors 的缩写。它从资源的角度看问题：

指标	含义	例子
Utilization（利用率）	资源被使用的百分比	CPU 使用率 85%
Saturation（饱和度）	资源排队或过载的程度	磁盘 I/O 等待队列长度
Errors（错误）	资源层面的错误计数	磁盘读写错误、网络丢包

我记得有一次排查线上问题，CPU 利用率才 30%，但请求延迟高得离谱。后来一看，是磁盘饱和度爆了——I/O 队列排了上千个任务。这就是 USE 方法的威力：利用率正常不代表系统健康。

RED 方法（服务视角）

RED 是 Rate、Errors、Duration 的缩写。它从服务的角度出发：

指标	含义	例子
Rate（流量）	每秒请求数（QPS）	API 网关 QPS 5000
Errors（错误）	请求失败的比例或数量	5xx 错误率 2%
Duration（延迟）	请求处理耗时	P99 延迟 200ms

这两个方法结合起来，基本覆盖了系统监控的方方面面。我个人习惯是：基础设施用 USE，业务服务用 RED。

1.3 黄金指标的四个维度

Google SRE 那本书里提过四个黄金指标，其实跟上面说的是一回事。我把它拆开来讲：

• 延迟（Latency）——请求处理花了多久。注意区分「成功请求的延迟」和「失败请求的延迟」。我曾经踩过坑：只看成功请求的延迟，结果失败请求因为快速返回，延迟很低，反而掩盖了问题。
• 流量（Traffic）——系统承载的请求量。QPS、带宽、并发连接数都算。流量突增往往是故障的前兆。
• 错误（Errors）——显式错误（5xx、4xx）和隐式错误（返回成功但内容错误）。隐式错误最难抓，我建议加一些业务层面的校验。
• 饱和度（Saturation）——系统还能承受多少压力。CPU、内存、磁盘、网络，哪个最先到瓶颈，哪个就是你的短板。

1.4 知识体系结构图

下面这张图是我自己总结的告警哲学知识体系，你可以对照着看：

1.5 告警设计的核心原则

有了指标，怎么配告警？我总结了几条原则：

1. 告警要有 actionable 信息——告警来了，你得知道该干什么。别只发一句「CPU 高」，要带上进程列表、最近变更、关联日志。
2. 避免告警风暴——一个故障触发几十条告警，等于没有告警。我建议做告警聚合和依赖关系分析。
3. 告警阈值要动态调整——业务有高峰低谷，阈值不能一成不变。比如凌晨的 CPU 告警阈值可以比白天宽松一些。
4. 告警要有生命周期——从触发、确认、处理到关闭，每个状态都要有记录。我曾经因为告警没人认领，故障拖了半小时。

1.6 一个简单的告警规则示例

最后，给你看一个我常用的告警规则模板。以 Prometheus 为例：

# 高延迟告警：P99 延迟超过 500ms 持续 5 分钟
- alert: HighLatency
  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "P99 延迟超过 500ms"
    description: "服务 {{ $labels.service }} 的 P99 延迟为 {{ $value }}s"

# 错误率告警：5xx 错误率超过 5% 持续 3 分钟
- alert: HighErrorRate
  expr: rate(http_requests_total{status=~"5.."}[3m]) / rate(http_requests_total[3m]) > 0.05
  for: 3m
  labels:
    severity: critical
  annotations:
    summary: "5xx 错误率超过 5%"
    description: "服务 {{ $labels.service }} 的错误率为 {{ $value | humanizePercentage }}"

这个例子很简单，但包含了核心要素：指标、阈值、持续时间、严重级别、可读的描述。你想想看，如果告警来了只显示一个数字，你根本不知道问题在哪。

好了，告警哲学这部分就聊到这儿。记住一句话：告警不是目的，稳定才是。下一节我们会深入讲告警规则的具体设计方法。

---