PostgreSQL × Debezium × Kafka CDC（Change Data Capture）监控体系

生产级的全链路 CDC（Change Data Capture）监控体系，涵盖：

• Debezium 端

• Kafka 端

• PostgreSQL 端

• 下游消费端

• 运行时参数

• 容量压力

• 延迟链路

---

🧭 CDC 全链路必监控指标

CDC 管道一般分为：

PostgreSQL → WAL → Debezium Connector → Kafka → 下游消费者

因此监控分成 5 大类：

---

1️⃣ 数据库端（PostgreSQL）监控

CDC 的根源在数据库，因此 PG 的监控非常关键。

🔸 必须监控的 PostgreSQL 指标：

指标	意义	原因
WAL 生成速率（bytes/sec）	单位时间产生日志量	WAL 激增会导致 Debezium backlog
WAL 段积压（Replication Slot Lag）	Debezium 未用完的 WAL 字节数	最重要指标之一，表示 Debezium 是否追上数据库
PG Replication Slot count	CDC slot 是否快满	超过 max_slot 会导致数据库阻塞
WAL 文件堆积	是否无限增长（败坏磁盘）	Debezium 延迟会导致 WAL 无法被回收
Checkpoint 延迟	PG 性能波动	Checkpoint 慢会造成 WAL 雪崩式增长
数据库负载（CPU/IO）	性能瓶颈	会影响 WAL 写入速度与 Debezium 延迟
长事务	WAL 日志无法被 truncate	长事务是 CDC 的天敌，会撑爆磁盘

推荐 Prometheus exporter

• postgres_exporter

• pg_stat_replication（用于 WAL slot lag）

---

2️⃣ Debezium Connector 端监控

这是 CDC 的核心环节。

🔸 Debezium 必监控指标：

指标	含义/为何重要
CDC 延迟（DB → Debezium）	你的上一条回答：payload.ts_ms - payload.source.ts_ms
WAL 位点滞后（LSN Lag）	Debezium 与数据库进度的真实距离
Debezium Lag in Millis	Debezium 暴露的标准 lag 指标
Connector Task 状态	任务是否停止、fail、重启
Error Count / Exception Rate	是否发生解析错误或任务崩溃
Queue size / Buffer usage	Debezium 内部队列满了会阻塞 CDC
Heartbeat 成功率	判断 pipeline 是否卡死
重启次数	严重不稳定信号
事务大小（batch size）	大事务会卡 Debezium pipeline 秒级甚至分钟

Debezium 自带指标（JMX）：

• debezium.source.stats.*

• debezium.task.queueRemainingCapacity

• debezium.task.lastProcessingDurationMs

---

3️⃣ Kafka 端监控（CDC 的最后一公里）

Kafka 的性能直接影响整个 CDC 延迟。

🔸 必监控 Kafka 指标

指标	为什么要监控
Topic 写入延迟（broker side）	Kafka 负载高会导致 CDC 暂停/堆积
Broker 消息堆积（Lag）	表示 Debezium 正在 block
ISR 同步状态	若 ISR 不健康，会影响 Kafka 写速度
Topic 大小 / 分区数量	是否需要扩容
Consumer Group Lag（下游）	下游消费压力与延迟来源
Broker CPU / I/O / 磁盘使用率	Kafka 慢会导致 CDC 延迟雪崩

推荐 exporter：

• kafka_exporter / burrow

• prometheus-kafka-adapter（若使用）

---

4️⃣ 下游消费者端监控（Sink 端）

Debezium 把消息推到 Kafka 后，下游消费速度是否匹配也非常关键。

下游必须监控：

指标	说明
Consumer Lag	下游是否落后
处理速度 TPS	下游消费能力
消费错误率 / 重试次数	下游逻辑错误不会影响 Debezium，但会产生延迟
Sink 写入延迟（ES / MySQL / Redis ...）	例如写目标库失败导致慢消费
是否出现阻塞批次（slow batch）	大表大事务会导致反压

---

5️⃣ 全链路延迟监控（最重要的部分）

你可以通过 Debezium 事件中的三个时间字段构建：

1. DB → Debezium 延迟

cdc_delay_ms = payload.ts_ms - payload.source.ts_ms

表示 Debezium 是否追上数据库 WAL。

---

2. Debezium → Kafka 延迟

kafka_delay_ms = kafka_timestamp - payload.ts_ms

Kafka timestamp 即 Kafka 内部写入时间。

---

3. DB → Kafka 总链路延迟

end_to_end_delay_ms = kafka_timestamp - payload.source.ts_ms

用于 SLA 和全链路性能监控。

---

6️⃣ CDC 健康度监控（稳定性维度）

推荐监控：

指标	意义
Debezium 是否卡死（Heartbeat 失败）	无心跳表示 connector 无响应
Connector Task 是否 Unassigned	配置、权限、网络问题
Schema Registry 错误	schema 注册失败导致 CDC 中断（如 Kafka Connect + Schema 注册）
Restart Loop（重启风暴）	配置错误、低内存、JVM OOM

---

7️⃣ 数据质量监控（Data Quality）

CDC 的最终目的是保证"数据一致"，所以你还可以加：

项目	意义
是否发生乱序事件（out of order）	大事务可能导致乱序
是否丢事件（most critical）	若下游数量与源库不一致需报警
Schema 演变失败监控	表结构改变时需要特别关注

多数公司都会在 CDC 管道外加一个 一致性校验服务 来比对源库 vs 目标库。

---

8️⃣ 资源监控（Host / JVM / Container）

包括：

• CPU

• 内存

• GC 时间

• JVM Heap 使用率

• 线程数

• 网络带宽

• I/O 延迟

连接器本质上是一个 JVM 进程，非常依赖：

✔ GC 性能

✔ 线程池

✔ 内存大小

容易因为 GC 过长导致任务卡死或延迟猛涨。

---

🧱 最终总结：CDC 监控的 5 大关键能力

类别	核心目标
数据库端监控	保证 WAL 能持续生成并被回收
Debezium 端监控	保证 connector 不落后、不卡死
Kafka 端监控	保证消息能被及时写入 Kafka
下游消费监控	保证数据不堆积、不丢失
全链路延迟监控	识别延迟是来源于 DB、Debezium、Kafka 或下游

---