本文為您介紹Flink全託管支援的監控指標詳情。
注意事項
CloudMonitor與Flink控制台資料差異說明
展示維度差異
Flink 控制台通過 PromQL 查詢，僅展示最大延遲。這是因為在Realtime Compute情境中，平均延遲極易掩蓋資料扭曲或單分區阻塞等嚴重問題，僅最大延遲具備營運參考價值。數值偏差
CloudMonitor採用預彙總機制計算指標。由於彙總視窗、採樣時間點或計算邏輯的差異，CloudMonitor顯示的“最大值”可能與 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（如連接器支援）：
直接反映外部滯留量。數值越高，說明資料在外部系統中的堆積越嚴重。