3、监控体系设计原则：分层监控与告警分级
监控体系怎么搭？我见过不少团队一上来就堆工具，Prometheus 配 Grafana，再挂个 Alertmanager，看起来挺全。结果呢？数据延迟了没人知道，链路断了查半天才发现是传输层挂了。说白了，监控不是堆工具，是搭骨架。
我个人习惯，先把监控体系拆成四层：数据源层、传输层、存储层、应用层。每层盯每层的事，出了问题能快速定位。再配上告警分级，P0/P1/P2，让该响应的声音足够大，不该吵的别乱叫。
核心原则：分层监控解决「哪里出了问题」，告警分级解决「谁该在什么时候处理」。两者缺一不可。
3.1 分层监控：四层架构
先看这张图，我画的是最常用的分层模型。你想想看，数据从产生到被消费，中间经过多少环节？每一环都可能出问题。
3.1.1 数据源层
数据源层是起点。业务数据库、日志文件、埋点数据、外部接口，都算。这一层监控什么？说白了，就是看源头数据有没有按时产生。
- 数据产生时间戳：每条数据是否带有业务时间？比如订单表的 create_time。
- 数据量波动：平时每小时 10 万条，突然降到 1000 条，大概率上游挂了。
- 源端可用性：数据库连接是否正常？接口响应是否超时？
我的经验：数据源层最容易忽略的是「数据空洞」。我曾经遇到一个场景，业务库凌晨 2 点做归档，导致那一个小时的数据量骤降。如果只看总量，会误报。后来我加了「按业务时间窗口对比」的逻辑，才把误报压下去。
3.1.2 传输层
传输层是数据从源头到存储的通道。ETL 任务、Kafka 管道、DataX 同步、实时流处理，都归这层管。
这一层监控的核心指标：
- 传输延迟：数据从源端产生到进入存储，花了多久？超过阈值就是延迟。
- 数据丢失率：源端发了 100 条，存储只收到 95 条？丢数据了。
- 任务状态：ETL 任务是否成功？重试次数是否过多？
注意：传输层是新鲜度问题的重灾区。我见过最离谱的一次，Kafka 消费者挂了 3 小时没人发现，因为监控只看了生产者端。记住，传输层要两端都盯——入口和出口。
3.1.3 存储层
数据到了存储层，不等于万事大吉。数据仓库、数据湖、消息队列、缓存，这些组件本身也会引入延迟。
存储层监控要点：
- 分区数据就绪时间：Hive 分区是否按时生成？ClickHouse 表是否完成合并？
- 数据版本一致性：同一份数据在不同存储中，版本是否对齐？
- 存储水位：磁盘快满了，写入性能会下降，新鲜度自然受影响。
3.1.4 应用层
应用层是数据最终被消费的地方。数据服务 API、报表系统、实时看板、推荐引擎，都依赖新鲜的数据。
这一层监控什么？
- 数据服务响应时间：接口返回的数据，时间戳是否在预期范围内？
- 报表数据时间：日报表展示的是昨天的数据，还是前天的？
- 用户侧感知：最终用户看到的数据，新鲜度是否达标？
分层监控的价值：当应用层报出「数据延迟」，你可以快速判断是存储层没更新，还是传输层堵了，还是源头就没产生数据。不用再像无头苍蝇一样到处查。
3.2 告警分级：P0/P1/P2
监控搭好了，告警怎么发？我见过最夸张的团队，一天收到 2000 条告警，最后全员把告警群屏蔽了。告警分级，说白了就是让正确的人在正确的时间处理正确的事。
我习惯把告警分成三级：
| 级别 | 定义 | 响应时间 | 通知方式 | 典型场景 |
|---|---|---|---|---|
| P0 | 核心数据不可用，影响线上业务 | 立即响应（≤5分钟） | 电话 + 短信 + 即时消息 | 实时交易数据延迟超过 10 分钟 |
| P1 | 重要数据延迟，影响运营决策 | 快速响应（≤30分钟） | 即时消息 + 邮件 | 日报表数据延迟超过 1 小时 |
| P2 | 非核心数据异常，不影响主要流程 | 正常处理（≤4小时） | 邮件 + 工单 | 历史归档数据延迟超过 1 天 |
3.2.1 P0：天塌了
P0 告警意味着核心数据链路断了。比如实时风控依赖的数据延迟超过 5 分钟，或者交易系统的对账数据迟迟不更新。这种告警必须能直接打到值班工程师的手机上。
我个人习惯，P0 告警要满足三个条件：
- 有明确的业务影响：不只是技术指标异常，要能说清「哪个业务方受影响」。
- 有自动止损动作：比如触发告警后自动切换到备用链路。
- 有值班确认机制：告警发出后 2 分钟没人确认，自动升级到 leader。
避坑指南：我曾经把「某张表数据延迟 5 分钟」设成 P0，结果业务方说那张表只是内部测试用的。从那以后，我定 P0 之前一定会找业务方确认：「这个数据延迟了，你们真的会死吗？」
3.2.2 P1：得盯着
P1 告警是「重要但不致命」。比如日报表数据延迟了 1 小时，运营同学没法准时看数据，但系统还能跑。这种告警需要快速响应，但不用半夜打电话。
P1 的典型场景：
- ETL 任务失败，但还有重试机会
- 数据量异常波动，但未超过业务容忍上限
- 传输延迟超过阈值，但未达到 P0 标准
3.2.3 P2：记下来
P2 告警是「知道了，有空再看」。比如历史数据归档延迟、非核心报表数据异常。这种告警发邮件就行，不用打扰值班人员。
但注意，P2 不等于不处理。我建议 P2 告警也要有闭环机制：
- 每天生成一份 P2 告警汇总
- 每周 review 一次，看是否有升级为 P1 的趋势
- 长期未处理的 P2 告警，自动升级为 P1
我的做法：P2 告警我一般设一个「静默期」，比如同一个告警 24 小时内不重复发送。不然早上打开邮箱，200 封一样的告警邮件，谁受得了？
3.3 分层与分级的联动
分层监控和告警分级不是两张皮。我习惯把它们组合成一个矩阵：
| 层级 | P0 场景 | P1 场景 | P2 场景 |
|---|---|---|---|
| 数据源层 | 核心业务库不可用 | 数据量突降 50% | 数据量波动 10% |
| 传输层 | 实时管道中断 | 传输延迟 > 5 分钟 | 传输延迟 > 30 分钟 |
| 存储层 | 核心表分区未生成 | 存储写入性能下降 | 磁盘使用率 > 80% |
| 应用层 | 核心 API 返回旧数据 | 报表数据延迟 | 非核心接口超时 |
这个矩阵的好处是，告警触发时你能同时知道「哪一层」和「多严重」。比如「传输层 P0」，那就是实时管道断了，得立刻处理。「存储层 P2」，可能就是磁盘快满了，明天再扩容也行。