数据库改了一条记录，下游报表却迟迟没更新；更麻烦的是，连接器仍显示 RUNNING。近日，数据工程社区集中追问如何监控 Debezium 和 CDC、该为何告警，以及怎样判断下游作业是否健康。CDC（Change Data Capture）会持续捕捉数据库的新增、修改和删除，并把变化送往搜索、缓存或数仓。进入生产后，真正要看的不是单个进程是否存活，而是数据有没有及时、完整地走完全程。
据 Debezium 官方文档，其监控面板已覆盖事件吞吐、源端延迟、距上次事件的时间、错误、连接状态、队列利用率和快照进度。Kessel 官方文档则把端到端延迟拆成 Debezium 捕捉、Kafka 传递和消费者处理三段，并建议同时检查连接器状态、消费者积压和指标缺失。换句话说，告警也应分层：源头是否停滞，中间是否堵塞，下游是否落后。数据库侧同样不能漏掉；Aiven 指出，PostgreSQL 复制槽落后会让 WAL 日志持续堆积，带来磁盘压力。另据 Debezium 官方 FAQ，连接器崩溃后可能从较早位置恢复并重复发布事件，因此下游还要能识别重复数据。社区讨论尚未给出统一方案，但问题已很清楚：CDC 的健康，必须按整条链路来定义。