type
status
date
slug
summary
tags
category
icon
password
在 FlinkCDC 群里经常看到这么一个问题，这应该也是大部分用户的刚接触的主要疑问，一种方案是根据日志来判断，根据代码，在 JobManager 会打印这么一段日志：
然而根据日志来判断太麻烦，有没有更智能的方案呢？其实这个问题在官方 2.1 发版的时候就有说明：
其中，
currentEmitEventTimeLag 指标记录的是 Source 发送一条记录到下游节点的时间点和该记录在 DB 里产生时间点差值，用于衡量数据从 DB 产生到离开 Source 节点的延迟。用户可以通过该指标判断 source 是否进入了 binlog 读取阶段：- 即当该指标为 0 时，代表还在全量历史读取阶段；
- 当大于 0 时，则代表进入了 binlog 读取阶段。
所以可以通过拉取这个指标判断任务是否完成了全量阶段。
（不过目前这个指标展示仍有问题，需要等待这个pr[]解决以后才生效）
源码
我们简单的浏览一下这个指标的代码实现。
全局搜索
currentEmitEventTimeLag 这个字段，找到指标被创建的代码接下来去看下
emitDelay 变量的定义，EmitTime - messageTimestamp 就是发送一条记录到下游节点的时间点和该记录在 DB 里产生时间点差值。然后看下这两个时间是怎么产生的，找到
reportMetrics 方法。可以看到,
EmitTime 是取程序运行发送数据的时间，那么 messageTimestamp 呢？看下
getMessageTimestamp 方法：messageTimestamp 是从记录里的 source.ts_ms 字段取出来的，而这个参数就需要追溯到 debezium 的代码了。在 Debezium 中，source.ts_ms 是一个代表数据库表中特定行最后更新时间戳的字段。因此通过计算 EmitTime - messageTimestamp 可以得到数据从写入源库到被 cdc 发送到下游的时间差。
那么，为什么全量阶段的
currentEmitEventTimeLag 值是0呢，我们可以看下 reportMetrics 方法的调用时机：原来做了一个判断处理，只有
DataChangeRecord 类型的数据才会更新这个指标，也就是增量数据阶段。