Realtime Compute for Apache Flink：監控警示推薦配置樣本與模板

情境

組合指標/事件名稱

規則配置

層級

處理動作

作業失敗警示

作業運行狀態事件

= FAILED（事件警示）

P0

①檢查重啟策略是否配置不當（建議使用預設配置）。

②定位是重啟策略導致，還是 JobManager/TaskManager 異常導致。

③從最近的快照/成功的Checkpoint 恢複生產。

Failover 激增

Overview/作業每分鐘錯誤恢複次數

≥ 1 連續 1 個周期

P0

①定位問題

• 通過 Failover 及 JM/TM 日誌，確認失敗根因。

• 忽略：偶發的、可自動回復的機器故障。

• 修複：代碼 Bug、資源瓶頸或配置錯誤。

②從最近的快照/成功的Checkpoint 恢複生產。

Checkpoint連續失敗

Checkpoint 成功次數（5 min 累計）

≤ 0 連續 1 周期

P0

①參閱系統檢查點排查checkpoint失敗根本原因。

②定位問題

• 參數問題（如逾時）：調整checkpoint相關配置。

• 資源擴容（如反壓）：可以進行動態擴縮容，為反壓運算元增加資源。

③動態更新配置或從最近成功的Checkpoint恢複生產。

業務延時高（有資料）

Overview/業務延時 && 每秒Source端輸入記錄數

最大值延時≥180000

輸入記錄數≥0

連續 3 個周期

P1

①參閱監控指標說明排查延遲原因。

• 資料層面：事件時間（EventTime）是否亂序？

• 流量層面：上遊流量是否激增？下遊是否反壓？

②根據具體原因調整

• 內部：調整 Connector WITH 參數，為瓶頸運算元擴容。

• 外部：最佳化外部服務配置（如調整限流策略、增加串連數）。

上遊資料流中斷檢測

Overview/每秒Source端輸入記錄數 &&

源端未處理資料時間

輸入記錄數≤0（業務而定）

最大值未處理時間≥60000

持續 5 個周期

P1

①可查看taskmanager.log、火焰圖、上遊服務指標等。確認問題是上遊無資料/限流/異常，還是線程棧卡死。

②根據具體原因調整

• Connector問題：最佳化 Connector 參數（如逾時、並發）或增加 TaskManager 資源。

• 上下遊服務問題：通知上遊業務方進行處理。

• Flink 內部瓶頸(如反壓或系統卡死)：先解決導致瓶頸的根本原因（如處理下遊問題），然後從最近的 Checkpoint 重啟作業。

下遊資料無輸出檢測

Overview/每秒輸出到Sink端記錄數

≤ 0 連續 5 個周期

P1

①確認資料是否抵達 Sink 運算元

• 商務邏輯過濾：通過日誌或指標，確認是否所有輸入資料都因不滿足條件被過濾。

• 遲到資料丟棄：檢查 Watermark 和視窗配置，確認資料是否因遲到而被丟棄。

②確認 Sink 是否能寫入外部系統

• 串連層面：Sink 串連池是否已打滿？網路連接是否正常？

• 目標系統層面：下遊資料庫/服務是否存在鎖表、磁碟空間不足、寫入限流或其他異常？

③臨時雙寫降級，將資料寫入備用儲存。

CPU效能瓶頸

CPU/ 單個TM 的CPU利用率

≥ 85 % 連續 10 周期

P2

①看火焰圖或Flink UI定位熱點運算元。

• 商務邏輯：是否為複雜的計算、JSON 解析、不合理的自訂函數 (UDF)。

• 資料扭曲：是否存在熱點Key導致某個key的資料量過大，導致單任務過載。

• 資源不足：當前並行度和 TM 資源能否匹配資料流量？是否存在嚴重反壓？

• GC 頻繁：通過日誌或 JVM 指標檢查是否因記憶體壓力導致頻繁 Full GC，消耗大量 CPU。

②適當增加瓶頸運算元的並行度，或為TaskManager分配更多CPU Core。

記憶體效能瓶頸

TM的堆記憶體已使用

≥ 90 % 連續 10 周期

P2

①查看 GC 日誌定位問題。

• 記憶體流失 (Leak)：通過 Flink UI 或監控觀察，堆記憶體在 GC 後無法回落到正常基準，基準持續抬升。

• 容量不足 (Insufficient)：堆記憶體使用量率長期處於高位，頻繁觸發 Full GC，導致效能下降。

• 瞬間 OOM：處理某條或某批資料時，記憶體瞬間佔滿，直接導致 OutOfMemoryError。

②根據具體原因調整：增加Heap或調大並行度降低單槽資料量。