本文为您介绍Flink全托管支持的监控指标详情。
注意事项
云监控与Flink控制台数据差异说明
-
展示维度差异
Flink 控制台通过 PromQL 查询,仅展示最大延迟。这是因为在实时计算场景中,平均延迟极易掩盖数据倾斜或单分区阻塞等严重问题,仅最大延迟具备运维参考价值。 -
数值偏差
云监控采用预聚合机制计算指标。由于聚合窗口、采样时间点或计算逻辑的差异,云监控显示的“最大值”可能与 Flink 控制台展示的实时数值存在细微不一致。建议排查问题时以 Flink 控制台数据为准。
数据延迟与Watermark 配置的说明
-
延迟计算逻辑
当前的监控指标 Emit Delay 是基于事件时间(Event Time)计算的,具体公式为:Delay = 当前系统时间 - 数据体中的逻辑时间字段(如 PriceData.time)
这意味着该指标反映的是“数据的新鲜度”,而非“系统的处理速度”。只要数据本身是旧的,或者系统为了等待水位线(Watermark)对齐而主动暂停输出,该指标都会偏高。
-
调整建议
场景一:业务强依赖 Watermark(需保证计算逻辑正确),但数据源本身较旧
-
典型情况:
-
上游数据发送本身就有延迟(如埋点上报慢)。
-
正在进行历史数据回溯/重跑(Backfill),处理的是昨天的数据。
-
业务逻辑必须依赖 Watermark 解决乱序问题,不能关掉。
-
-
现象: 监控报警延迟很高,但 Kafka 消费组无积压(Lag ≈ 0),CPU 负载低。
-
建议:
-
忽略此延迟指标: 此时的高 Delay 是正常的业务表现(反映数据是旧的),不代表系统故障。
-
更换监控口径: 请运维人员转为监控 Kafka Consumer Lag(消费堆积量)。只要堆积量不持续上涨,就证明系统处理能力完全正常,无需介入。
-
场景二:追求实时性,且可以容忍少量乱序/数据丢失
-
典型情况:
-
大屏展示或实时风控,数据由于 Watermark 等待导致结果输出过慢。
-
业务上更在乎“当前几点收到的数据”,而不是“数据里写的几点”。
-
-
现象: 数据流本身是实时的,但因为 Watermark 设置了较大的容忍窗口(如允许迟到10秒),导致数据被强行延迟10秒才输出。
-
建议:
-
移除/关闭 Watermark: 改用处理时间(Processing Time)进行计算,或将 Watermark 的等待阈值设为 0。
-
预期结果: 延迟指标将瞬间下降(接近物理处理耗时),数据随到随出,不再等待对齐。
-
-
典型场景指标特征
指标仅反映当前组件的工作状态,并非判断问题根因的充分条件。请务必结合 Flink UI 的反压检测功能及其他辅助工具进行综合判断。
1. 算子反压
现象:下游处理能力不足,导致 Source 发送速率下降。
-
判断方式:首选 Flink UI 的反压监测面板。
-
指标特征:
-
sourceIdleTime 呈周期性上升。
-
currentFetchEventTimeLag 和 currentEmitEventTimeLag 持续增长。
-
极端情况:若算子完全卡死,sourceIdleTime 会持续上升。
-
2. Source 性能瓶颈
现象:Source 读取速度达到上限,但仍无法满足数据处理需求。
-
判断方式:作业中未检测到反压。
-
指标特征:
-
sourceIdleTime 维持在极低数值(Source 处于全负荷工作状态)。
-
currentFetchEventTimeLag 和 currentEmitEventTimeLag 数值接近,且均处于高位。
-
3. 数据倾斜或空分区
现象:上游 Kafka 分区数据分布不均,或存在空分区。
-
判断方式:观察不同 Source 的指标差异。
-
指标特征:
-
特定 Source 的 sourceIdleTime 显著高于其他 Source(表明该并行度处于闲置状态)。
-
4. 数据延迟分析
现象:作业整体延迟较高,需定位瓶颈位于 Source 内部还是外部系统。
-
判断方式:组合分析空闲时间、Lag 差值与堆积量。
-
指标特征:
-
sourceIdleTime 较高:
说明 Source 处于闲置状态。通常意味着外部系统的数据产出速率较低,而非 Flink 处理慢。 -
Lag 差值分析:
对比 currentEmitEventTimeLag 与 currentFetchEventTimeLag 的数值差异(即数据在 Source 算子内的驻留时间):-
差值较小(两指标接近):拉取能力不足。瓶颈在于网络 I/O 带宽或 Source 并发度不够。
-
差值较大:处理能力不足。瓶颈在于数据解析效率低下,或受到下游反压限制。
-
-
pendingRecords(如连接器支持):
直接反映外部滞留量。数值越高,说明数据在外部系统中的堆积越严重。
-
概览
|
指标 |
含义 |
详情 |
单位 |
支持的连接器 |
|
Num of Restarts |
作业错误恢复次数。 |
作业出错重启次数,不包含JM Failover次数。查看作业可用性,协助您查看作业状态。 |
次数 |
不涉及 |
|
current Emit Event Time Lag |
业务延时。 |
该延时较大时,说明作业可能在拉取数据或者处理数据上存在延时。 |
毫秒(ms) |
|
|
current Fetch Event Time Lag |
传输延时。 |
该延时较大时,说明作业可能在拉取数据上存在延时。您需要查看网络I/O或上游系统情况。结合currentEmitEventTimeLag,您可以通过两个指标的差值(即数据在Source中停留的时间)分析Source当前的处理能力。详情如下:
|
毫秒(ms) |
|
|
numRecordsIn |
所有Operator的输入的记录总数。 |
如果某个算子的numRecordsIn值长时间未增涨,可能存在上游把数据都吞掉的情况,需要查看上游数据。 |
条 |
所有内置连接器均支持。 |
|
numRecordsOut |
输出记录总数。 |
如果某个算子的numRecordsOut的值长时间未增涨,说明可能是作业代码逻辑错误,导致数据都被吞掉了,需要查看作业代码逻辑。 |
条 |
所有内置连接器均支持。 |
|
numRecordsInofSource |
每个Operator中仅source operator的输入记录。 |
查看上游数据输入情况。 |
条 |
|
|
numRecordsOutOfSink |
Sink端输出记录总数。 |
查看上游数据输出情况。 |
条 |
|
|
numRecordsInPerSecond |
整个数据流每秒钟输入的记录数。 |
用于需要监控整个数据流的处理速度的场景。例如,您可以使用numRecordsInPerSecond来观察整个数据流的处理速度是否达到了预期的水平,以及在不同的输入数据负载下性能的变化情况。 |
条/秒 |
所有内置连接器均支持。 |
|
numRecordsOutPerSecond |
整个数据流每秒钟输出的记录数。 |
用于测量整个数据流每秒钟输出的记录数,适用于需要监控整个数据流的输出速度的场景。 例如,您可以使用numRecordsOutPerSecond来观察整个数据流的输出速度是否达到了预期的水平,以及在不同的输出数据负载下性能的变化情况。 |
条/秒 |
所有连接器均支持。 |
|
numRecordsInOfSourcePerSecond (IN RPS) |
数据源Source端每秒输入记录数。 |
用于测量每个数据源每秒钟生成的记录数,适用于需要了解每个数据源的生成速度的场景。例如,在一个数据流中,不同的数据源可能会产生不同数量的记录,使用numRecordsInOfSourcePerSecond可以帮助您了解每个数据源的生成速度,并对数据流进行调整以达到更好的性能,同时该数据用于监控告警。 如果该值为0,说明可能存在上游把数据都吞掉的情况,需要查看上游数据是否一直未被消费,导致输出阻塞。 |
条/秒 |
|
|
numRecordsOutOfSinkPerSecond (OUT RPS) |
数据目的Sink端每秒输出记录数。 |
用于测量每个Sink端每秒钟输出的记录数,适用于需要了解每个Sink的输出速度的场景。例如,在一个数据流中,不同的Sink可能会输出不同数量的记录。 使用numRecordsOutOfSinkPerSecond可以帮助您了解每个Sink的输出速度,并对数据流进行调整以达到更好的性能。该数据用于监控告警,如果该值为0,说明可能是作业代码逻辑错误,导致全部数据被过滤了,需要查看作业代码逻辑。 |
条/秒 |
|
|
pendingRecords |
源端未读取数据的条数。 |
外部系统中尚未被Source拉取的数据条数。 |
条 |
|
|
sourceIdleTime |
源端未处理数据的时间。 |
该指标反映Source是否有闲置。如果该指标的值较大时,说明您的数据在外部系统中的产生速率较低。 |
毫秒(ms) |
|
|
busyTimePerSecond |
Task 繁忙时间。 |
每秒内 Task 线程处于繁忙状态(处理数据)的毫秒数。取值范围 0~1000,值越高表示 Task 负载越大。可用于识别性能瓶颈、评估资源利用率和指导自动调优。 |
毫秒(ms) |
不涉及 |
系统检查点
|
指标 |
含义 |
详情 |
单位 |
|
Num of Checkpoints |
Checkpoint数量。 |
总览Checkpoint状态,协助您设置Checkpoint告警。 |
个 |
|
lastCheckpointDuration |
最近一个Checkpoint的持续时间。 |
如果Checkpoint耗时过长或者超时,可能由于状态过大、临时网络原因、Barrier未对齐或者数据存在反压等原因造成。 |
毫秒(ms) |
|
lastCheckpointSize |
最近一个Checkpoint的大小。 |
最近一次实际上传的Checkpoint大小,可以在Checkpoint有瓶颈时协助分析Checkpoint性能。 |
Bytes |
状态
latency状态指标需要设置后才可以使用,因此您需要在更多Flink配置中设置state.backend.latency-track.keyed-state-enabled: true,启用latency状态指标后,可能会对作业运行时的性能造成一定影响。
|
指标 |
含义 |
详情 |
单位 |
版本限制 |
|
State Clear Latency |
单次状态清理延迟最大值。 |
查看State清理的性能。 |
纳秒(ns) |
实时计算引擎VVR 4.0.0及以上版本。 |
|
Value State Latency |
单次Value State访问延迟的最大值。 |
查看Value State访问的性能。 |
纳秒(ns) |
|
|
Aggregating State Latency |
单次Aggregating State访问延迟的最大值。 |
查看Aggregating State访问的性能。 |
纳秒(ns) |
|
|
Reducing State Latency |
单次Reducing State访问延迟的最大值。 |
查看Reducing State访问的性能。 |
纳秒(ns) |
|
|
Map State Latency |
单次Map State访问延迟的最大值。 |
查看Map State访问的性能。 |
纳秒(ns) |
|
|
List State Latency |
单次List State访问延迟的最大值。 |
查看List State访问的性能。 |
纳秒(ns) |
|
|
Sorted Map State Latency |
单次Sorted Map State访问延迟的最大值。 |
查看Sorted Map State访问的性能。 |
纳秒(ns) |
|
|
State Size |
状态数据的大小。 |
通过观测该指标,您可以:
|
Bytes |
实时计算引擎VVR 4.0.12及以上版本。 |
|
State File Size |
状态数据文件的大小。 |
通过观测该指标,您可以:
|
Bytes |
实时计算引擎VVR 4.0.13及以上版本。 |
IO
|
指标 |
含义 |
详情 |
单位 |
支持的连接器 |
|
numBytesIn |
输入字节总数。 |
查看上游吞吐的输入情况,协助您观察作业流量表现。 |
Bytes |
|
|
numBytesInPerSecond |
每秒输入字节总数。 |
查看上游流速的输入情况,协助您观察作业流量表现。 |
Bytes/秒 |
|
|
numBytesOut |
输出字节总数。 |
查看上游吞吐的输出情况,协助您观察作业流量表现。 |
Bytes |
|
|
numBytesOutPerSecond |
每秒输出字节总数。 |
查看上游吞吐输出情况,协助您观察作业流量表现。 |
Bytes/秒 |
|
|
Task numRecords I/O |
每个Subtask收到和输出的总数据量。 |
根据该指标判断作业是否存在I/O瓶颈。 |
条 |
|
|
Task numRecords I/O PerSecond |
每个Subtask每秒收到和输出的总数据量。 |
判断作业是否存在I/O瓶颈并且通过速率判断严重程度。 |
条/秒 |
|
|
currentSendTime |
输出到下游系统的每个Subtask发送最近一条数据的用时。 |
该指标值较小时,说明Subtask输出过慢。 |
毫秒(ms) |
|
水印
|
指标 |
含义 |
详情 |
单位 |
支持的连接器 |
|
Task InputWatermark |
每个Task收到最近一条水印的时间。 |
说明TM收到数据的延时情况。 |
无 |
不涉及连接器 |
|
watermarkLag |
Watermark延迟。 |
判断Subtask级别的作业延迟情况。 |
毫秒(ms) |
|
CPU
|
指标 |
含义 |
详情 |
单位 |
|
JM CPU Usage |
单个JM CPU的CPU使用率。 |
该值反映Flink对CPU时间片的占用情况,1个Core的CPU用满了就是100%,4个Core用满了就是400%。如果该值长期大于100%则说明CPU很繁忙。如果负载很高,但CPU使用率却比较低,可能因为频繁的读写操作导致不可中断睡眠状态的进程过多。 说明
仅实时计算引擎VVR 6.0.6及以上版本支持该指标。 |
无 |
|
TM CPU Usage |
单个TM CPU的CPU使用率。 |
该值反映Flink对CPU时间片的占用情况,1个Core的CPU用满了就是100%,4个Core用满了就是400%。如果该值长期大于100%则说明CPU很繁忙。如果负载很高,但CPU使用率却比较低,可能是因为频繁的读写操作导致不可中断睡眠状态的进程过多。 |
无 |
内存
|
指标 |
含义 |
详情 |
单位 |
|
JM Heap Memory |
JM的堆内存。 |
查看JM堆内存的变化。 |
Bytes |
|
JM NonHeap Memory |
JM的非堆内存。 |
查看JM非堆内存的变化。 |
Bytes |
|
TM Heap Memory |
TM的堆内存。 |
查看TM堆内存的变化。 |
Bytes |
|
TM nonHeap Memory |
TM的非堆内存。 |
查看TM非堆内存的变化。 |
Bytes |
|
TM Mem (RSS) |
通过Linux获取整个进程的内存。 |
查看进程内存的变化。 |
Bytes |
JVM
|
指标 |
含义 |
详情 |
单位 |
|
JM Threads |
JM线程数。 |
JM线程数过多会导致占用过大的内存空间,从而降低作业稳定性。 |
个 |
|
TM Threads |
TM线程数。 |
TM线程数过多会导致占用过多内存,从而降低作业稳定性。 |
个 |
|
JM GC Count |
JM GC次数。 |
GC次数过多会导致占用过大内存空间,从而影响作业性能。该指标协助您进行作业诊断,排查作业级别的故障原因。 |
Times |
|
JM GC Time |
每次JM GC时间。 |
长时间GC会导致占用过大内存空间,从而影响作业性能。该指标协助您进行作业诊断,排查作业级别的故障原因。 |
毫秒(ms) |
|
TM GC Count |
TM GC次数。 |
GC次数过多会导致占用过大内存空间,从而影响作业性能。该指标协助您进行作业诊断,排查作业Task级别的故障原因。 |
次数 |
|
TM GC Time |
每次TM GC时间。 |
长时间GC会导致占用过大内存空间,从而影响作业性能。该指标协助您进行作业诊断,排查作业级别的故障原因。 |
毫秒(ms) |
|
JM ClassLoader |
JM所在的JVM在创建后,加载或卸载的类总数。 |
JM所在的JVM创建后,加载类的总数或卸载类的总数过大,会导致占用过大的内存空间,从而影响作业性能。 |
无 |
|
TM ClassLoader |
TM所在的JVM创建后,加载或卸载的类总数。 |
JM所在的JVM创建后加载类的总数或卸载类的总数过大,会导致占用过大内存空间,从而影响作业性能。 |
无 |
连接器 - Mysql
|
指标 |
含义 |
单位 |
应用场景 |
版本限制 |
|
isSnapshotting |
作业是否在处理全量数据阶段(1表示处于该阶段) |
无 |
确定作业处理阶段 |
实时计算引擎VVR 8.0.9及以上版本。 |
|
isBinlogReading |
作业是否在处理增量数据阶段(1表示处于该阶段) |
无 |
确定作业处理阶段 |
|
|
Num of remaining tables |
全量阶段等待处理的表的个数 |
个 |
查看剩余未处理的表数量 |
|
|
Num of snapshotted tables |
全量阶段已经处理的表的个数 |
个 |
查看已经处理的表数量 |
|
|
Num of remaining SnapshotSplits |
全量阶段等待处理的分片的个数 |
个 |
查看已经处理的分片数 |
|
|
Num of processed SnapshotSplits |
全量阶段已经处理的分片的个数 |
个 |
查看未处理的分片数 |
|
|
currentFetchEventTimeLag |
数据从产生到从数据库读取出来之间的延迟 |
ms |
查看从数据库读取binlog的延迟 |
|
|
currentReadTimestampMs |
当前读取到的最新数据的时间戳 |
ms |
查看读取到最新数据时间 |
|
|
numRecordsIn |
已经读取的数据条数 |
条 |
查看已经处理的全部数据量 |
|
|
numSnapshotRecords |
全量阶段已经处理的数据条数 |
条 |
查看全量阶段已处理的数据量 |
|
|
numRecordsInPerTable |
每个表已经读取的数据条数 |
条 |
查看每个表已经处理的全部数据量 |
|
|
numSnapshotRecordsPerTable |
每个表全量阶段已经处理的数据条数 |
条 |
查看每个表全量阶段已处理的数据量 |
连接器 - Kafka
|
指标 |
含义 |
单位 |
应用场景 |
版本限制 |
|
commitsSucceeded |
位点提交成功的次数 |
次 |
判断位点提交是否成功 |
实时计算引擎VVR 8.0.9及以上版本。 |
|
commitsFailed |
位点提交失败的次数 |
次 |
判断位点提交是否成功 |
|
|
Fetch Rate |
拉取数据的频率 |
次/秒 |
判断数据拉取的延迟和速度 |
|
|
Fetch Latency Avg |
拉取数据操作的延迟 |
毫秒 |
判断数据拉取的延迟和速度 |
|
|
Fetch Size Avg |
每次拉取的平均字节数 |
字节 |
判断数据拉取的延迟和速度 |
|
|
Avg Records In Per-Request |
每次拉取的平均消息数 |
条 |
判断数据拉取的延迟和速度 |
|
|
currentSendTime |
发送上一条记录的时间 |
无 |
判断消费进度 |
|
|
batchSizeAvg |
每个批次的平均字节数 |
Bytes |
判断数据写入延迟和速度 |
|
|
requestLatencyAvg |
请求的平均延迟 |
ms |
判断数据写入延迟和速度 |
|
|
requestsInFlight |
正在进行的请求数 |
无 |
判断数据写入延迟和速度 |
|
|
recordsPerRequestAvg |
每次请求的平均消息数 |
条 |
判断数据写入延迟和速度 |
|
|
recordSizeAvg |
消息的平均字节数 |
Bytes |
判断数据写入延迟和速度 |
连接器 - Paimon
|
指标 |
含义 |
单位 |
应用场景 |
版本限制 |
|
Number of Writers |
Writer实例数量 |
个 |
当前有几个分桶正在写入。若数量过大,可能会影响写入效率,增加内存消耗。分析分桶数或分区键设置是否合理。 |
实时计算引擎VVR 8.0.9及以上版本。 |
|
Max Compaction Thread Busy |
小文件合并线程的最大繁忙程度 |
比例 |
当前正在写入的各个分桶中,最近一分钟内,小文件合并线程最多有多少时间在活动。可以反映小文件合并的压力 |
|
|
Average Compaction Thread Busy |
小文件合并线程平均繁忙程度 |
比例 |
当前正在写入的各个分桶中,最近一分钟内,小文件合并线程最多有多少时间在活动。可以反映小文件合并的压力 |
|
|
Max Number of Level 0 Files |
最大Level 0 文件数量 |
个 |
当前正在写入的各个分桶中,level 0文件(小文件)最多有几个。仅对主键表有意义,可以反映小文件合并的效率能否跟上写入效率 |
|
|
Average Number of Level 0 Files |
平均Level 0 文件数量 |
个 |
当前正在写入的各个分桶中,level 0文件(小文件)平均有几个。仅对主键表有意义,可以反映小文件合并的效率能否跟上写入效率 |
|
|
Last Commit Duration |
上次Commit耗时 |
毫秒 |
若时间太长,应检查是否有过多的分桶正在同时写入。 |
|
|
Number of Partitions Last Committed |
上次Commit中写入的分区数量 |
个 |
若数量过大,可能会影响写入效率,增加内存消耗。分析分桶数或分区键设置是否合理。 |
|
|
Number of Buckets Last Committed |
上次Commit中写入的分桶数量 |
个 |
若数量过大,可能会影响写入效率,增加内存消耗。分析分桶数或分区键设置是否合理。 |
|
|
Used Write Buffer |
已使用的Write Buffer的内存大小 |
字节 |
所有task manager的writer节点已使用的buffer大小。该buffer将占用Java堆内存,若设置过大可能会导致OOM。 |
|
|
Total Write Buffer |
分配给Write Buffer的总内存大小 |
字节 |
所有task manager的writer节点设置的uffer大小。该buffer将占用Java堆内存,若设置过大可能会导致OOM,。 |
数据摄入
|
指标 |
含义 |
单位 |
应用场景 |
版本限制 |
|
isSnapshotting |
作业是否在处理全量数据阶段(1表示处于该阶段) |
无 |
确定作业处理阶段 |
实时计算引擎VVR 8.0.9及以上版本。 |
|
isBinlogReading |
作业是否在处理增量数据阶段(1表示处于该阶段) |
无 |
确定作业处理阶段 |
|
|
Num of remaining tables |
全量阶段等待处理的表的个数 |
个 |
查看剩余未处理的表数量 |
|
|
Num of snapshotted tables |
全量阶段已经处理的表的个数 |
个 |
查看已经处理的表数量 |
|
|
Num of remaining SnapshotSplits |
全量阶段等待处理的分片的个数 |
个 |
查看已经处理的分片数 |
|
|
Num of processed SnapshotSplits |
全量阶段已经处理的分片的个数 |
个 |
查看未处理的分片数 |
|
|
currentFetchEventTimeLag |
数据从产生到从数据库读取出来之间的延迟 |
ms |
查看从数据库读取binlog的延迟 |
|
|
currentReadTimestampMs |
当前读取到的最新数据的时间戳 |
ms |
查看读取到最新数据的时间 |
|
|
numRecordsIn |
已经读取的数据条数 |
条 |
查看已经处理的全部数据量 |
|
|
numRecordsInPerTable |
每个表已经读取的数据条数 |
条 |
查看每个表已经处理的全部数据量 |
|
|
numSnapshotRecords |
全量阶段已经处理的数据条数 |
条 |
查看全量阶段已处理的数据量 |
|
|
numSnapshotRecordsPerTable |
每个表全量阶段已经处理的数据条数 |
条 |
查看每个表全量阶段已处理的数据量 |