2、监控体系设计：监控的黄金信号与分层架构
监控体系设计，说白了就是回答三个问题：看什么？怎么看？怎么存？
我刚开始做运维那会儿，监控就是“CPU满了没？内存够不够？”——太粗了。后来踩了不少坑，才慢慢摸清楚一套靠谱的监控体系该怎么搭。
今天咱们就聊聊监控的黄金信号、分层架构和数据模型。嗯，这三个东西搞明白了，你设计的监控系统至少能扛住80%的线上故障。
2.1 监控的黄金信号：四个维度锁定问题
Google的SRE团队提过四个黄金信号——延迟、流量、错误、饱和度。我个人习惯把这四个词贴在工位上，每次设计监控都对着看一遍。
2.1.1 延迟（Latency）
延迟就是“用户等多久”。注意，这里有个坑——平均延迟是骗人的。
我曾经遇到一个案例：接口平均延迟50ms，看起来很美。但实际有5%的请求延迟超过5秒。为什么？因为那5%的慢请求被大量快请求平均掉了。
举个例子，一个API的延迟分布可能是这样的：
| 百分位 | 延迟 | 说明 |
|---|---|---|
| P50 | 30ms | 一半用户感觉很快 |
| P95 | 200ms | 95%的用户体验还行 |
| P99 | 2s | 1%的用户在摔手机 |
2.1.2 流量（Traffic）
流量就是“系统承受了多少压力”。QPS、TPS、带宽使用率，这些都是流量指标。
我记得有一次大促，流量突然暴涨到平时的10倍。监控图上那条曲线直接冲破了天花板——嗯，然后系统就挂了。后来我学乖了，给流量加了同比/环比告警。流量突然下降50%？可能是上游挂了。流量突然上升200%？可能是被攻击了。
2.1.3 错误（Errors）
错误分两种：显式错误和隐式错误。
- 显式错误：HTTP 500、超时、异常堆栈——这些好抓。
- 隐式错误：返回200，但业务逻辑错了。比如支付成功但没到账，这种最要命。
我曾经踩过一个坑：一个服务返回200，但body里是{"code": -1, "msg": "系统繁忙"}。监控只看HTTP状态码，完全没发现。从那以后，我要求所有业务接口必须上报业务错误码。
2.1.4 饱和度（Saturation）
饱和度就是“系统还能撑多久”。CPU使用率80%不代表快满了，但CPU排队长度突然飙升，那才是真危险。
2.2 监控分层架构：从基础设施到业务
监控不能只盯一个层面。我习惯把监控分成三层：基础设施层、应用层、业务层。每一层关注的点不一样。
2.2.1 基础设施层
这层最基础，也最容易做。CPU、内存、磁盘、网络——说白了就是“机器还活着吗？”
但注意，基础设施监控不能只做“死没死”的检测。我建议加上趋势分析。比如磁盘使用率，今天80%，按这个增长速度，7天后会满。提前告警比事后补救强一百倍。
2.2.2 应用层
应用层监控关注的是“服务跑得怎么样”。包括接口响应时间、错误率、JVM堆内存、GC情况、线程池状态等。
我个人习惯在应用层做全量采集。为什么？因为采样会漏掉偶发问题。比如一个接口每1000次请求才超时一次，采样率1%的话，很可能根本抓不到。
2.2.3 业务层
业务层监控最贴近用户。比如订单量、支付成功率、用户活跃度、转化率。
我曾经遇到一个案例：所有技术指标都正常，但业务方说“今天订单少了一半”。查了半天，发现是某个上游渠道的接口返回了错误数据，但技术层面没报错。从那以后，我坚持业务指标必须和技术指标分开监控。
2.3 监控数据模型：指标、日志、链路追踪
数据模型这块，我把它总结成三个字：点、线、面。
- 指标（Metrics）：点——某个时间点的数值。比如CPU 80%。
- 日志（Logs）：线——事件发生的详细记录。比如“用户A在10:00:00下单失败”。
- 链路追踪（Traces）：面——一次请求经过的所有服务。比如“下单请求经过网关→订单服务→支付服务→数据库”。
2.3.1 指标（Metrics）
指标是最轻量的数据模型。我常用的指标类型有三种：
| 类型 | 例子 | 用途 |
|---|---|---|
| Counter（计数器） | 请求总数、错误总数 | 只增不减，适合统计量 |
| Gauge（仪表盘） | CPU使用率、内存使用量 | 可增可减，适合瞬时值 |
| Histogram（直方图） | 请求延迟分布 | 适合百分位统计 |
嗯，这里要注意：指标不能替代日志。指标告诉你“系统出问题了”，但日志告诉你“为什么出问题”。
2.3.2 日志（Logs）
日志是排查问题的第一手资料。但我见过太多团队把日志当垃圾堆——什么都打，什么都存。
我建议日志分级：
- ERROR：需要立即处理的问题。比如数据库连接失败。
- WARN：值得关注但不紧急。比如重试了3次才成功。
- INFO：关键业务流程。比如订单创建成功。
- DEBUG：开发调试用，线上别开。
2.3.3 链路追踪（Traces）
链路追踪是微服务时代的必备技能。一次请求经过10个服务，哪个环节慢了？链路追踪一目了然。
我常用的链路追踪工具是Jaeger和Zipkin。核心概念就三个：
- Trace：一次完整的请求链路。
- Span：链路中的一个步骤。比如调用数据库、调用下游服务。
- SpanContext：传递上下文信息，比如Trace ID。
举个例子，一个下单请求的链路追踪数据可能是这样的：
Trace ID: abc123
├── Span: 网关 (耗时: 5ms)
│ ├── Span: 订单服务 (耗时: 50ms)
│ │ ├── Span: 查询用户信息 (耗时: 10ms)
│ │ ├── Span: 扣减库存 (耗时: 30ms)
│ │ └── Span: 创建订单 (耗时: 10ms)
│ └── Span: 支付服务 (耗时: 200ms)
│ └── Span: 调用第三方支付 (耗时: 180ms)
看到没？支付服务花了200ms，其中调用第三方支付就占了180ms。问题出在哪？一目了然。
2.4 小结：黄金信号 + 分层架构 + 数据模型 = 靠谱监控
最后总结一下我的经验：
- 黄金信号：延迟看P99，流量看趋势，错误分显隐，饱和度看队列。
- 分层架构：基础设施保底，应用层抓细节，业务层看结果。
- 数据模型：指标做告警，日志做排查，链路做定位。
这三样东西搭好了，你的监控体系就稳了。下一章咱们聊聊具体的监控工具选型——Prometheus、Grafana、ELK这些到底怎么选？