flink 端到端延迟以及flinkcdc 同步mysql时的延迟存在突刺，怎么寻找排查原因？

一些相关配置：

• promethues 配置：

以下延迟指标 都是flink 内部提供的相关指标，prometheusReporter 推送到pushgateway 的间隔是 60s , 具体配置如下：

prometheus 拉取间隔为 30s ：

• 状态后端Rocksdb配置:

  

问题1 ：flink 端到端延迟突刺

flink_taskmanager_job_latency_source_id_operator_id_operator_subtask_index_latency 指标用来检测端到端延迟，开启时的配置参数如下图：

任务1 ：

• 这个任务的sql 以及 dag 图如下 ：

• 通过对比发现 flink 端到端延迟从 source 到 sink 端延迟 与 source 到 join 算子的 延迟 图形一致，基本可以确定是延迟增大就是 flinkSQL中regular join阶段引起的，以下是 flink 到 join 算子的延迟监控图：
  
  大部分时间延迟都是在一个较小的范围 100ms 以内

• 当前任务 join算子链的 flink_taskmanager_job_task_operator_numRecordsInPerSecond 指标，总体上在以下时间段在有数据的情况下每分钟 2-3 （0.033 * 60）条左右
  

• Checkpoint:
  

当前任务是全量checkpoint，对于全量做checkpoint ，通过对比发现当延迟增大的时候，一般 checkpoint 时长也会很大（增量checkpoint 现象不明显）

其他状况：

• 在历史数据中发现，当source 到join的延迟指标增大时，并没有发现存在输入，即下图情况：
  
  
  
  去数据源kafka 中查询也并未查询到出现延迟时有数据输入

• 此时的checkpoint如下：
  

job2：

• 这个任务的checkpoint 也是全量，但是状态更大，对应的端到端延迟的最大值以及突刺的平均值也更大

job3:

• 这个任务的checkpoint是增量的，
  
• 对应的 延迟和checkpoint 的关系如下：
  

具体问题：

• 对于以上3个任务，似乎状态越大，在regular join 阶段的延迟就会越大，但是也存在没有数据输入时端到端延迟飙高

问题2：flinkcdc 同步mysql 延迟

• 当前使用的flink-sql-connector-mysql-cdc版本是 2.4.1
• 使用的指标是 cdc 源码中提供的 currentFetchEventTimeLag这一指标来表示flinkcdc 同步时的 binlog 延迟，这一指标是从数据在数据库提交操作后生成的时间点到进入flinkcdc source 之间的时间差
• 内网机器间的网络传输，通过 ping 主机，网络延迟较为稳定，大概在3ms左右，但是并没有对主机之间网络延时进行检测

例1 ：

• 延迟突刺达到 12s ,持续直到下一条数据到来

• Source的数据的输入是较为稳定的大概是 2.0 * 60s = 120

• writer 算子的numRecordsInPerSecond 指标如下图：

例2 ：

• 通过source 算子的numRecordsInPerSecond 指标发现存在数据输入，但是延迟指标却一直保持
  

• 而 writer 算子的numRecordsInPerSecond 指标则可以解释（所以这是为什么，是被过滤了吗，还是flinkcdc 心跳也算作 source 的输入吗）
  

具体问题：

• 影响currentFetchEventTimeLag 的因素相关的指标比较难找，去查找过对mysql监控的zabbix，没能找到相关的因素，可以从排查呢？