2. 监控体系搭建：核心指标（黄金信号）、监控工具选型与告警策略
监控体系，说白了就是系统的眼睛和耳朵。没有它，你就像在黑夜里开车，出了事只能听天由命。我见过太多团队，一上来就堆各种监控工具，结果告警满天飞，真正出问题时反而被淹没了。
今天咱们聊聊怎么搭一套靠谱的监控体系。核心就三件事：盯什么指标、用什么工具、怎么告警。
2.1 黄金信号：四个必须盯死的指标
Google 的 SRE 团队总结过四个黄金信号，我用了这么多年，确实管用。你想想看，系统出问题，无非就这四种情况。
| 信号 | 含义 | 我踩过的坑 |
|---|---|---|
| 延迟（Latency） | 请求处理耗时 | 只看平均值会骗人，P99 才是真相 |
| 流量（Traffic） | 系统承载的请求量 | 流量突增不一定是好事，可能是攻击 |
| 错误（Errors） | 请求失败率 | HTTP 200 也可能是业务错误，别只看状态码 |
| 饱和度（Saturation） | 资源使用程度 | CPU 100% 不一定有问题，要看是否在排队 |
核心原则：先盯这四个，别贪多。我见过有人一上来就配了 200 个指标，结果没一个能用的。
2.1.1 延迟：别被平均值骗了
延迟是最容易出问题的指标。为什么？因为平均值会掩盖真相。
举个例子，你看到平均延迟是 50ms，觉得挺好。但 P99 延迟可能已经飙到 5 秒了。这意味着 1% 的用户在忍受 5 秒的等待。我在项目中遇到过，用户投诉说系统卡，我看平均延迟才 30ms，差点就忽略了。后来一查 P99，好家伙，8 秒。
我的习惯：同时监控 P50、P95、P99 三个分位值。P50 看整体趋势，P99 抓异常尾巴。
2.1.2 流量：不只是看 QPS
流量指标，大家第一反应是 QPS。但我觉得，还得看流量来源和分布。
比如，某个接口 QPS 突然翻倍，可能是好事（用户多了），也可能是坏事（被爬虫扫了）。我建议把流量按来源、接口、地域拆开看。这样出问题时，你能快速定位是哪个环节出了问题。
2.1.3 错误：HTTP 500 只是冰山一角
错误率是红线指标。但注意，HTTP 状态码只是最表层的东西。
我记得有一次，系统返回全是 200，但业务方说数据不对。查了半天，原来是接口返回了「成功」，但业务逻辑执行失败了。从那以后，我要求所有核心接口必须上报业务错误码。HTTP 200 + 业务码 500，这才是完整的错误视图。
避坑指南：我曾经因为只看 HTTP 状态码，漏掉了一次严重的业务故障。现在我的规则是：错误率 = (HTTP 5xx + 业务错误) / 总请求数。
2.1.4 饱和度：资源快用尽的前兆
饱和度是预警指标。CPU、内存、磁盘、网络带宽，这些资源用到了 80%，就该引起注意了。
但这里有个细节：饱和度不等于利用率。比如 CPU 利用率 100%，如果任务都在并行执行，没有排队，那其实还好。真正要警惕的是「排队现象」—— 请求开始等待了，这才是饱和的信号。
2.2 监控工具选型：别盲目追新
工具选型这事儿，我吃过不少亏。早期喜欢用最新的、最炫的，结果运维成本高得吓人。现在我的原则是：够用就好，团队能 hold 住就行。
下面是我用过的几类工具，给你做个参考。
| 类型 | 代表工具 | 适用场景 | 我的评价 |
|---|---|---|---|
| 指标监控 | Prometheus + Grafana | 通用场景，云原生首选 | 生态好，但学习曲线略陡 |
| 日志监控 | ELK (Elasticsearch, Logstash, Kibana) | 日志分析、故障排查 | 搜索强，但存储成本高 |
| 链路追踪 | Jaeger, Zipkin | 微服务调用链分析 | 定位慢调用必备 |
| 拨测监控 | 自建 + 商业服务 | 用户端体验监控 | 能发现你测不到的问题 |
我的建议：小团队先用 Prometheus + Grafana 搭一套指标监控，成本低、见效快。等规模大了，再补日志和链路追踪。
2.2.1 Prometheus：为什么我推荐它
Prometheus 现在基本是监控界的事实标准了。原因很简单：拉模式 + 多维数据模型。
拉模式的意思是，Prometheus 主动去目标机器抓数据。这样目标挂了，Prometheus 能立刻知道。推模式的话，目标挂了就没人推数据了，你都不知道它是挂了还是没数据。
多维数据模型更实用。你可以给指标打标签，比如 method="GET"、status="200"。查询时按标签聚合，非常灵活。
# 一个典型的 Prometheus 配置示例
scrape_configs:
- job_name: 'web-app'
static_configs:
- targets: ['localhost:8080']
metrics_path: '/metrics'
scrape_interval: 15s小技巧：抓取间隔别设太短。15 秒够用了，设成 5 秒只会增加存储压力，对排查问题帮助不大。
2.3 告警策略：少而精，别让告警变成噪音
告警策略是监控体系里最难搞的部分。搞不好，告警就变成了「狼来了」的故事。
我总结了一个原则：每条告警都必须 actionable。收到告警后，你必须有明确的动作可以做。如果只是看看，那就不该发告警。
2.3.1 告警分级：别什么都 P0
我习惯把告警分成三级：
- P0（紧急）：系统不可用，用户受影响。必须立即响应，7x24 小时。
- P1（重要）：功能受损，但核心链路还在。需要尽快处理，工作时间响应。
- P2（一般）：资源预警、非关键错误。记录即可，定期 review。
我见过最离谱的团队，把磁盘使用率 80% 也设成 P0。结果半夜被叫起来，一看还有 20% 空间，气得想骂人。
避坑指南：我曾经把「错误率 > 1%」设成 P0，结果某个接口正常波动就超过 1%，告警响了一整夜。后来改成「错误率 > 1% 且持续 5 分钟」，世界清净了。
2.3.2 告警抑制：别让风暴淹没你
告警风暴是每个 SRE 的噩梦。一个核心服务挂了，下游所有服务都跟着告警，瞬间几百条消息涌进来。
解决方案是告警抑制。比如，如果上游服务已经告警了，下游服务的告警就自动静默。或者，同一个服务 5 分钟内只发一条告警。
# Prometheus Alertmanager 抑制规则示例
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'instance']这段配置的意思是：如果某个实例已经发了 critical 告警，那它发的 warning 告警就自动被抑制。说白了，别在伤口上撒盐。
2.3.3 告警通知：选对渠道
通知渠道也很重要。P0 用电话或短信，P1 用即时消息，P2 用邮件。别反过来，否则大家会麻木。
我个人的习惯是：P0 告警必须确认收到。没确认就自动升级，直到找到人。这个机制救过我很多次。
最后说一句：监控体系不是一蹴而就的。先搭骨架（黄金信号），再填血肉（工具和告警），最后持续优化。别想着一步到位，那是不可能的。
嗯，这一章就聊到这儿。下一章咱们聊聊容量规划，那又是一个容易踩坑的地方。