Realtime Compute for Apache Flink:推奨モニタリング設定

シナリオ

複合メトリック/イベント名

ルール設定

レベル

対処

ジョブ失敗アラート

ジョブステータスイベント

= FAILED (イベントアラート)

P0

1. 再起動ポリシーが誤って設定されていないか確認します。デフォルト設定の使用を推奨します。

2. 原因が再起動ポリシーによるものか、JobManager または TaskManager の異常によるものかを特定します。

3. 最新のスナップショットまたは成功したチェックポイントからジョブを復元します。

フェイルオーバー サージ

概要/ジョブの 1 分あたりのエラー回復数

1 期間連続で ≥ 1

P0

1. 問題を特定します。

• フェールオーバー、JobManager、および TaskManager のログを分析して根本原因を特定します。

• 無視：まれに発生し、自動回復可能なマシンの障害。

• 修正：コードのバグ、リソースのボトルネック、または設定エラー。

2. 最新のスナップショットまたは成功したチェックポイントからジョブを復元します。

連続したチェックポイントの失敗

成功したチェックポイント数 (5 分間の累積)

1 期間連続で ≤ 0

P0

1. 詳細については、「システムチェックポイント」をご参照のうえ、失敗の根本原因をトラブルシューティングしてください。

2. 問題を特定します。

• パラメーターの問題 (タイムアウトなど)：チェックポイントの設定を調整します。

• リソースのスケーリング (バックプレッシャーなど)：動的スケーリングを使用して、バックプレッシャーが発生している演算子にリソースを追加します。

3. 設定を動的に更新するか、最新の成功したチェックポイントからジョブを復元します。

高いビジネスレイテンシー (データあり)

概要/ビジネスレイテンシー && ソースからの毎秒の入力レコード数

最大レイテンシー ≥ 180000

入力レコード ≥ 0

3 期間連続

P1

1. 詳細については、「メトリックの説明」をご参照のうえ、レイテンシーの原因を調査してください。

• データプレーン：イベント時間が順不同になっていませんか？

• トラフィックレベル：上流のトラフィック急増や下流のバックプレッシャーがあるかどうかを示します。

2. 原因に基づいて対処します。

• 内部：コネクタの WITH パラメーターを調整し、ボトルネックとなっている演算子をスケールアウトします。

• 外部：速度制限ポリシーの調整や接続数の増加など、外部サービスの設定を最適化します。

上流データストリームの中断検出

概要/ソースからの毎秒の入力レコード数 &&

ソースの生データタイムスタンプ

入力レコード ≤ 0 (ビジネスに依存)

最大アイドル時間 ≥ 60000

5 期間連続

P1

1. taskmanager.log、フレームグラフ、および上流サービスのメトリックを確認し、問題が上流データなし、速度制限、エラー、または停止したスレッドスタックであるかを確認します。

2. 原因に基づいて対処します。

• コネクタの問題：タイムアウトや並列度などのコネクタパラメーターを最適化するか、TaskManager リソースを追加します。

• 上流/下流サービスの問題：上流のビジネスオーナーに通知して問題に対処してもらいます。

• Flink 内部のボトルネック (バックプレッシャーやシステムフリーズなど)：まず、下流の問題など、ボトルネックの根本原因を解決します。その後、最新のチェックポイントからジョブを再起動します。

下流へのデータ出力がないことの検出

概要/sink への毎秒の出力レコード数

5 期間連続で ≤ 0

P1

1. データが sink 演算子に到達しているか確認します。

• ビジネスロジックによるフィルタリング：ログやメトリックを使用して、すべての入力データが条件を満たさなかったためにフィルタリングされたかどうかを確認します。

• 遅延データの破棄：Watermark とウィンドウ設定を確認し、データが遅延のために破棄されたかどうかを確認します。

2. sink が外部システムに書き込めるか確認します。

• 接続レイヤー：sink の接続プールは満杯ですか？ネットワーク接続性は正常ですか？

• ターゲットシステムレイヤー：下流のデータベースやサービスに、ロックされたテーブル、ディスク容量不足、書き込みの速度制限、またはその他のエラーはありませんか？

3. 一時的な対策として、バックアップストレージシステムへのデュアルライトを有効にしてください。

CPU パフォーマンスボトルネック

CPU/単一 TM の CPU 使用率

10 期間連続で ≥ 85%

P2

1. フレームグラフまたは Flink UI を使用して、ホットスポット演算子を特定します。

• ビジネスロジック：複雑な計算、JSON 解析、または非効率なユーザー定義関数 (UDF) がないか確認します。

• データスキュー：ホットスポットキーが原因で、過剰なデータ量により単一のタスクに過負荷がかかっていないか確認します。

• リソース不足：現在の並列度と TM リソースでデータトラフィックを処理できますか？深刻なバックプレッシャーはありますか？

• 頻繁な GC：ログまたは JVM メトリックを使用して、メモリプレッシャーが原因で頻繁なフル GC が発生し、大量の CPU を消費していないか確認します。

2. ボトルネックとなっている演算子の並列度を上げるか、TaskManager により多くの CPU コアを割り当てます。

メモリパフォーマンスボトルネック

TM のヒープメモリ使用量

10 期間連続で ≥ 90%

P2

1. GC ログを確認して問題を特定します。

• メモリリーク：Flink UI またはモニタリングを使用して、GC 後にヒープメモリが通常のベースラインに戻らず、ベースラインが上昇し続けていないか観察します。

• 容量不足：ヒープメモリの使用率が一貫して高く、頻繁にフル GC をトリガーしてパフォーマンスを低下させています。

• 突然の OOM：特定のレコードまたはデータのバッチを処理する際にメモリが即座に満杯になり、直接 OutOfMemoryError を引き起こします。

2. 原因に基づいて対処します：ヒープサイズを増やすか、並列度を上げてスロットあたりのデータ量を減らします。