本文为您介绍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（如连接器支持）：
直接反映外部滞留量。数值越高，说明数据在外部系统中的堆积越严重。