1. 监控体系总览：为什么需要监控、监控的黄金指标、监控 vs 可观测性
大家好，我是老张。做数据流水线这些年，我踩过最大的坑就是——系统挂了，我是最后一个知道的。
记得有一次，凌晨三点被电话吵醒。ETL 任务跑了 6 个小时，结果在最后一步写入时挂了。第二天老板开会问：为什么数据没更新？我哑口无言。从那以后，我给自己定了个规矩：没有监控的流水线，不上线。
这一章，咱们聊聊监控体系最核心的东西。不扯虚的，全是实战经验。
1.1 为什么需要监控？
你想想看，数据流水线就像一条高速公路。路上有没有堵车？有没有车祸？有没有路段在施工？你总得知道吧。
监控要解决三个核心问题：
- 出了什么问题 —— 任务失败、数据延迟、资源打满
- 什么时候出的 —— 是偶发还是持续？是白天还是凌晨？
- 影响有多大 —— 影响了下游几个报表？耽误了多少业务决策？
我在项目中遇到过最典型的情况：一个 Spark 任务跑了 2 小时，看起来一切正常。但仔细一看，shuffle 阶段花了 1 小时 50 分钟。没有监控的话，你根本不知道性能瓶颈在哪。
核心观点：监控不是用来「看」的，是用来「动」的。没有告警的监控，等于没监控。
1.2 监控的黄金指标
业界有很多监控方法论。我个人最常用的是这三套：USE、RED、Four Golden Signals。它们各有侧重，但组合起来几乎能覆盖所有场景。
1.2.1 USE 方法（资源视角）
USE 是 Brendan Gregg 提出的，专门用来分析资源的健康状况。说白了就是看你的服务器、数据库、网络有没有「生病」。
| 指标 | 含义 | 例子 |
|---|---|---|
| Utilization（利用率） | 资源被占用的比例 | CPU 使用率 90%、内存使用率 80% |
| Saturation（饱和度） | 资源排队等待的程度 | 磁盘 I/O 等待队列长度、网络缓冲区溢出 |
| Errors（错误） | 资源层面的错误计数 | 磁盘坏道、网络丢包、内存 OOM |
举个例子。我曾经排查过一个 Kafka 集群性能问题。CPU 利用率只有 30%，看起来很正常。但一看饱和度指标，磁盘 I/O 等待队列已经排了 200 多个请求。这就是典型的「表面正常，内部快炸了」。
我的习惯：USE 方法适合基础设施层。我一般会在 Grafana 上建一个 USE 仪表盘，把 CPU、内存、磁盘、网络的 U/S/E 指标都放一起。一眼就能看出问题在哪。
1.2.2 RED 方法（服务视角）
RED 是 Google SRE 团队推广的，专门用来衡量服务的健康状况。它比 USE 更贴近用户视角。
| 指标 | 含义 | 例子 |
|---|---|---|
| Rate（速率） | 每秒处理的请求数 | API 请求量 1000 req/s、Kafka 消息吞吐 5000 msg/s |
| Errors（错误） | 请求失败的占比 | HTTP 5xx 错误率、数据写入失败率 |
| Duration（持续时间） | 请求处理耗时 | P99 延迟 200ms、平均查询时间 50ms |
我建议你把 RED 用在数据流水线的每个环节。比如：
- 数据接入层：Kafka 消费速率、消费延迟、消费失败率
- 数据处理层：Spark 任务执行速率、任务失败率、任务执行时长
- 数据存储层：写入速率、写入失败率、写入延迟
1.2.3 Four Golden Signals（综合视角）
这是 Google SRE 圣经《Site Reliability Engineering》里提出的四个黄金信号。它把 USE 和 RED 融合在一起，形成一个更完整的监控框架。
- 延迟（Latency） —— 请求处理需要多久？注意区分「成功请求的延迟」和「失败请求的延迟」。失败请求往往很快返回，会拉低平均值，掩盖真正的问题。
- 流量（Traffic） —— 系统当前承受的负载有多大？对于数据流水线，就是每秒处理多少条数据、每小时处理多少 GB。
- 错误（Errors） —— 显式错误（如 HTTP 500）和隐式错误（如返回了错误数据但状态码是 200）都要监控。
- 饱和度（Saturation） —— 系统还有多少余量？当资源接近极限时，服务质量会急剧下降。
避坑指南：我曾经只监控了平均延迟，结果 P99 延迟已经飙到 5 秒了，平均延迟才 200ms。因为大部分请求是小数据，少数大请求把尾巴拖得很长。从那以后，我必看 P99、P95、P50 三个分位值。
1.3 监控 vs 可观测性
这两个概念经常被混用。我简单说说我的理解。
监控是你提前定义好「什么算异常」，然后盯着这些指标。比如：CPU > 90% 就告警。这是「已知的未知」——你知道可能会出问题，所以提前设了阈值。
可观测性是你不知道会出什么问题，但你有能力去探索。比如：用户反馈数据不对，你通过链路追踪、日志分析、指标关联，一步步找到根因。这是「未知的未知」——你没法提前定义所有异常。
打个比方：
- 监控就像汽车仪表盘上的故障灯。亮了你就知道该去修车了。
- 可观测性就像你打开引擎盖，用万用表、示波器去测量各个部件的状态。你不需要等故障灯亮，就能提前发现隐患。
在实际工作中，我建议这样搭配：
| 场景 | 用监控 | 用可观测性 |
|---|---|---|
| 已知的已知 | ✅ 设置阈值告警 | ❌ 没必要 |
| 已知的未知 | ✅ 设置动态阈值 | ✅ 辅助排查 |
| 未知的未知 | ❌ 无法提前定义 | ✅ 探索式分析 |
我的建议：先做好监控，再谈可观测性。很多团队连基本的 USE/RED 指标都没配齐，就急着上链路追踪、APM，结果数据太多反而看不清楚。先把「仪表盘」装好，再考虑「引擎盖」的事。
1.4 本章知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作后续章节的导航图。
这张图把本章的三个核心模块串起来了：为什么需要监控（解决三个核心问题）、黄金指标（USE/RED/Four Golden Signals）、监控 vs 可观测性（先做好监控，再谈可观测性）。
嗯，这一章就到这里。内容不多，但都是基础中的基础。后面的章节，我们会一步步把这些指标落地到实际的数据流水线中。