监控体系设计：三大支柱与黄金信号
监控体系怎么搭？这个问题我当年也头疼过。刚做流计算那会儿，觉得能看个吞吐量就差不多了。结果线上出问题，查了半天不知道根因在哪。后来才明白，监控不是堆数据，而是搭骨架。
今天聊的这套体系，说白了就是两个核心：三大支柱（指标、日志、链路追踪）和四个黄金信号（延迟、吞吐、错误率、饱和度）。这两块搭起来，你才能对系统有真正的掌控感。
三大支柱：缺一不可
我习惯把监控比作三脚架。少一条腿，站不稳。三条腿分别是：
- 指标（Metrics）：数值化的系统快照。比如每秒处理多少条、当前延迟多少。适合做告警和趋势分析。
- 日志（Logs）：事件的详细记录。出问题时，日志能告诉你“发生了什么”。
- 链路追踪（Traces）：请求的完整路径。从数据进来到出去，每一步花了多久，卡在哪。
这三者各有侧重，但必须打通。我记得有一次线上延迟飙升，指标先报警了。我查日志，发现某个算子频繁报超时。再追链路追踪，定位到是下游数据库连接池满了。你看，少了任何一环，排查都得绕远路。
核心原则：指标告诉你“出问题了”，日志告诉你“出了什么问题”，链路追踪告诉你“问题出在哪”。三者联动，才是完整的监控。
黄金信号：四个维度看透系统
Google SRE 那本书里提过四个黄金信号。我这些年用下来，确实管用。它们分别是：
| 信号 | 含义 | 流处理中的典型指标 |
|---|---|---|
| 延迟 | 处理一条数据需要多久 | 端到端延迟、算子处理时间、背压时间 |
| 吞吐 | 单位时间能处理多少数据 | 每秒输入/输出条数、每秒字节数 |
| 错误率 | 失败请求的比例 | 处理失败率、序列化失败率、超时率 |
| 饱和度 | 系统资源用了多少 | CPU 使用率、内存占用、线程池活跃度 |
这四个信号，我建议你全部覆盖。缺一个，都可能漏掉关键线索。举个例子，吞吐正常但延迟高了，可能是背压在积累。错误率低但饱和度高了，说明系统快扛不住了，得提前扩容。
我的习惯：每个黄金信号至少配两个指标。一个用于实时告警，一个用于趋势分析。比如延迟，我既看 P99 延迟（实时），也看平均延迟的 5 分钟滑动窗口（趋势）。
三大支柱 × 黄金信号：矩阵式监控
把三大支柱和黄金信号组合起来，就是一个监控矩阵。每个支柱都能覆盖四个信号，但侧重点不同。
我画了张图，帮你理清这个关系：
你看，每个格子都是一个具体的监控项。指标适合做全局概览和告警，日志适合做详细排查，链路追踪适合做根因定位。三者配合，才能覆盖所有黄金信号。
避坑指南：我曾经踩过的坑
讲几个我实际遇到的教训：
- 指标太多，反而看不清：我曾经在一个项目里配了 200 多个指标。结果告警天天响，没人知道该看哪个。后来砍到 30 个核心指标，反而更清晰了。
- 日志不结构化：纯文本日志，查起来全靠 grep。后来改成 JSON 格式，配合日志平台，排查效率翻倍。
- 链路追踪采样率太低：为了省存储，采样率设了 1%。结果线上出问题，根本找不到对应的 Trace。我建议核心链路至少 10% 采样，错误链路 100% 采样。
特别注意：监控本身也会消耗资源。指标采集、日志写入、Trace 上报，都会占用 CPU 和网络。我见过一个极端案例，监控 agent 把业务进程的 CPU 吃掉了 30%。所以，监控的监控，也得做。
落地建议：从哪开始
如果你是从零开始搭监控体系，我建议按这个顺序来：
- 先搭指标：选一个时序数据库（比如 Prometheus），把四个黄金信号的核心指标先配齐。
- 再上日志：统一日志格式，集中采集到 ELK 或 Loki。确保关键操作都有日志。
- 最后加链路追踪：用 Jaeger 或 Zipkin，先覆盖核心数据流。逐步扩展到全链路。
嗯，这套体系搭起来之后，你会发现排查问题不再是“猜谜游戏”。指标报警 → 查日志 → 追链路，三步走，大部分问题都能在 10 分钟内定位。