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 のボトルネック (バックプレッシャーやシステムフリーズなど): まず、ボトルネックの根本原因 (ダウンストリームの問題の処理など) を解決します。次に、最新のチェックポイントからジョブを再起動します。

ダウンストリームデータ出力なしの検出

概要/シンクの秒間出力レコード数

5 期間連続で ≤ 0

P1

1. データがシンクオペレーターに到達するかどうかを確認します。

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

• 遅延データのドロップ: ウォーターマークとウィンドウの構成をチェックして、データが遅延のためにドロップされたかどうかを確認します。

2. シンクが外部システムに書き込めるかどうかを確認します。

• 接続レベル: シンクの接続プールは満杯ですか？ネットワーク接続は正常ですか？

• ターゲットシステムレベル: ダウンストリームのデータベースまたはサービスに、ロックされたテーブル、不十分なディスク領域、書き込みスロットリング、またはその他の例外はありませんか？

3. 一時的にデュアルライトモードにスペックダウンし、データをバックアップストレージに書き込みます。

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

CPU/単一 TaskManager の CPU 使用率

10 期間連続で ≥ 85%

P2

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

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

• データスキュー: ホットスポットキーが単一キーに対して過剰な量のデータを引き起こし、単一タスクの過負荷につながっていないか確認します。

• リソース不足: 現在の並列処理の次数と TaskManager リソースはデータトラフィックと一致していますか？深刻なバックプレッシャーはありますか？

• 頻繁な GC: ログまたは JVM メトリックを使用して、メモリプレッシャーが頻繁なフル GC を引き起こし、大量の CPU を消費していないか確認します。

2. ボトルネックオペレーターの並列処理の次数を増やすか、TaskManager により多くの CPU コアを割り当てます。

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

TaskManager の使用済みヒープメモリ

10 期間連続で ≥ 90%

P2

1. GC ログをチェックして問題を特定します。

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

• 容量不足: ヒープメモリ使用量が長時間高いままで、頻繁にフル GC がトリガーされ、パフォーマンスの低下を引き起こします。

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

2. 特定の原因に基づいて調整を行います: ヒープサイズを増やすか、並列処理の次数を増やしてスロットあたりのデータ量を減らします。