监控体系设计原则：可观测性三大支柱
聊到监控体系设计，有个概念你肯定绕不开——可观测性三大支柱：指标、日志、链路追踪。
说实话，我刚入行那会儿，觉得监控就是「出问题了看告警」。后来踩了不少坑才明白，真正的可观测性，是让你能回答三个问题：系统怎么了？为什么这样？具体哪里出了问题？
三大支柱，正好对应这三个问题。
指标：系统的「体温计」
指标，说白了就是数字。CPU使用率、QPS、错误率、延迟……这些是系统最直观的状态。
我个人习惯，先抓四个黄金信号：
- 延迟：请求处理花了多久
- 流量：系统承载的压力有多大
- 错误：请求失败的比例
- 饱和度：资源快用完了吗
举个例子，我在项目中遇到过线上服务突然变慢。一看指标，CPU才30%，内存也正常，但请求延迟从50ms飙到了2s。排查了半天，最后发现是数据库连接池满了——这就是饱和度的典型问题。
日志：系统的「黑匣子」
指标告诉你「出问题了」，但为什么出问题？得看日志。
日志这东西，说起来简单，做起来坑多。我曾经接手过一个项目，一天产生200GB日志，但90%都是「INFO: 开始处理请求」「INFO: 结束处理请求」这种废话。真出故障了，翻半天找不到关键信息。
好的日志应该遵循三个原则：
- 结构化：别用纯文本，用JSON格式。方便后续检索和分析
- 有上下文：每条日志带上请求ID、用户ID、耗时等关键字段
- 分级合理：ERROR才告警，WARN做预警，INFO只记录关键流程
嗯，这里要注意——千万别把敏感信息打进去。我见过有人把用户密码明文打到了日志里，那场面……
链路追踪：系统的「X光片」
微服务架构下，一个请求可能要经过十几个服务。指标和日志只能看到单个节点的状态，但请求到底卡在哪个环节？链路追踪就是干这个的。
我记得第一次用Jaeger排查性能问题，发现一个接口平均耗时3秒。看链路追踪才发现，其中2.5秒都花在一个Redis查询上——因为缓存没命中，每次都要查数据库。
链路追踪的核心概念就三个：
- Trace：一次完整的请求链路
- Span：链路中的每个环节
- Span Context：跨服务传递的上下文信息
关键点：链路追踪的采样策略很重要。全量采样成本太高，我一般用「头部采样+尾部采样」的组合策略——关键接口全量采样，普通接口按1%比例采样。
三大支柱怎么配合？
你想想看，指标、日志、链路追踪，单独用哪个都不够。它们的关系是这样的：
| 场景 | 用哪个 | 为什么 |
|---|---|---|
| 系统整体健康度 | 指标 | 一眼看出CPU、内存、QPS是否正常 |
| 排查具体错误 | 日志 | 看堆栈、看错误信息、看上下文 |
| 定位性能瓶颈 | 链路追踪 | 看每个环节耗时，找到最慢的那个 |
| 告警后快速定位 | 指标→链路→日志 | 先看指标确认范围，再看链路定位节点，最后看日志找原因 |
我在实际项目中，通常这样串联：
# 伪代码示例：告警处理流程
1. 指标告警触发（延迟 > 500ms）
2. 查看链路追踪，找到最慢的Span
3. 根据Span中的TraceID，关联查询日志
4. 日志中看到具体错误：数据库连接超时
5. 修复后，指标恢复正常落地建议
说了这么多，具体怎么落地？我个人的经验是分三步走：
- 先搭指标：Prometheus + Grafana，把四大黄金信号先覆盖了
- 再上日志：ELK或Loki，确保日志结构化和可检索
- 最后链路：Jaeger或Zipkin，从核心业务链路开始接入
别想着一步到位。我见过不少团队，一上来就想搞全链路追踪，结果搞了三个月还没上线。不如先让指标和日志跑起来，至少能解决80%的问题。
记住一句话：可观测性不是工具堆砌，而是让你在出问题时，能快速回答「发生了什么、为什么、怎么修」。三大支柱，缺一不可。