监控体系总览：全链路监控的层次划分与指标分类

做 CDC 同步，最怕什么？

我最怕半夜被电话吵醒，说数据对不上了。但更怕的是——你根本不知道哪里出了问题。

所以这一章，咱们先把监控体系的全貌搭起来。说白了，就是搞清楚：看哪里、看什么、怎么看。

全链路监控的四个层次

CDC 链路其实不复杂。数据从源端出来，经过采集、传输，最后落到目标端。我习惯把这四个环节拆成独立的监控域，每个域盯各自的关键指标。

第一层：源端监控

源端是所有数据的起点。这里出问题，后面全是白搭。

我盯源端，主要看三个东西：

• Binlog 位置与存活状态——MySQL 的 binlog 是不是在正常写入？有没有突然切换？
• 主库压力——QPS、连接数、慢查询。采集端如果读得太猛，源端扛不住。
• DDL 变更——有人改了表结构，CDC 链路可能直接断掉。这个坑我踩过不止一次。

第二层：采集端监控

采集端是 CDC 的咽喉。Canal、Debezium 这些组件，说白了就是 binlog 的搬运工。

采集端最容易出问题的点：

• 解析延迟——从 binlog 读到内存，到解析成事件，这个时间差就是解析延迟。
• 内存积压——采集端一般有环形缓冲区。如果下游消费慢，缓冲区满了就会丢数据。
• 连接稳定性——采集端和源端的 TCP 连接是不是正常？重连次数是不是异常升高？

我记得有一次，Canal 的 dump 线程因为网络抖动频繁重连，每次重连都要重新拉取 binlog，导致延迟从 1 秒飙升到 5 分钟。当时告警阈值设得太宽，等发现时已经积压了几百万条变更。

第三层：传输端监控

传输端通常是 Kafka 或 Pulsar。这一层是缓冲地带，也是最容易藏问题的地方。

指标	正常范围	告警阈值	说明
Lag（积压量）	< 1000 条	> 10000 条	消费端跟不上生产端
生产速率	稳定波动 < 20%	突降 > 50%	采集端可能挂了
消费速率	接近生产速率	持续低于生产速率	目标端写入瓶颈
磁盘使用率	< 70%	> 85%	日志留存时间过长

这里有个细节：Kafka 的 Lag 指标其实有坑。如果你用 consumer group 的 offset 算 lag，遇到 rebalance 时数据会不准。我一般同时看生产端的 offset 和消费端的 offset，两个都监控。

第四层：目标端监控

目标端是数据的终点。写入性能、数据完整性、查询一致性，这三样缺一不可。

• 写入延迟——从消息到达目标端，到真正落盘，这个时间差就是写入延迟。
• 写入失败率——比如 ClickHouse 的 TooManyParts 错误，或者 ES 的 mapping 冲突。
• 数据校验——源端和目标端的数据行数、校验和是不是一致？

四大指标分类

不管哪一层，监控指标都可以归到四类里。我管这叫「四维监控」。

1. 延迟

延迟是 CDC 最敏感的指标。从源端产生变更，到目标端可见，这个时间差就是端到端延迟。

怎么拆？我习惯把延迟拆成三段：

• 采集延迟（源端 → 采集端）
• 传输延迟（采集端 → 传输端）
• 写入延迟（传输端 → 目标端）

哪一段高了，就盯哪一段。别只看总延迟，否则你永远不知道瓶颈在哪。

2. 吞吐量

吞吐量决定了 CDC 能不能扛住业务高峰。

我一般看两个维度：

• 峰值吞吐——每秒处理的最大事件数。这个决定了集群的容量上限。
• 均值吞吐——日常的平均处理能力。如果均值接近峰值，说明集群快撑不住了。

3. 错误率

错误率是健康度的直接体现。但要注意，不是所有错误都要告警。

我的分类法：

• 可重试错误——网络超时、连接断开。这种错误会自动恢复，告警阈值可以设高一点。
• 不可重试错误——数据格式错误、表结构不匹配。这种错误必须人工介入。

4. 数据一致性

这是 CDC 的终极目标。延迟再低、吞吐再高，数据对不上，一切都是零。

一致性校验怎么做？

• 行数校验——源端和目标端的总行数对比。
• 校验和校验——对关键字段做 CRC32 或 MD5，对比两边的值。
• 抽样校验——随机抽取 1000 条数据，逐字段对比。

小结一下

这一章我们把监控体系的全貌搭起来了。四个层次、四类指标，构成了 CDC 监控的骨架。

你想想看，如果每一层都有独立的延迟、吞吐、错误率监控，再加上定期的数据一致性校验，是不是心里踏实多了？