すべてのプロダクト
Search

このプロダクト

    Realtime Compute for Apache Flink:アラートの設定とテンプレート

    ドキュメントセンター

    Realtime Compute for Apache Flink:アラートの設定とテンプレート

    最終更新日:Aug 07, 2026

    このドキュメントでは、Realtime Compute for Apache Flink の主要なアラートメトリック、推奨されるアラート設定、および運用例を紹介します。これにより、システムパフォーマンスのモニタリングと問題診断を効果的に行えます。

    前提条件

    Configure monitoring and alerting を参照し、ワークスペースのモニタリングサービスに適した設定方法を選択します。

    説明

    ARMS では、use a custom PromQL statement to create an alert rule を行う場合にのみ、複数メトリックをモニタリングできます。より簡単に設定する場合は、CloudMonitor でアラートを設定できます。

    推奨アラートルール

    シナリオ

    メトリック／イベント名

    ルール設定

    重大度

    対応

    ジョブの失敗

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

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

    P0

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

    2. 再起動ポリシーが原因なのか、JobManager／TaskManager の例外が原因なのかを判断します。

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

    フェイルオーバーの急増

    Overview / NumOfRestart

    1 期間連続で 1 以上

    P0

    1. 根本原因を特定します。

    • フェイルオーバー、JobManager、TaskManager のログを分析し、エラーの詳細を確認します。

    • 無視：発生頻度が低く、自動復旧できるマシン障害。

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

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

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

    NumOfCheckpoints (5 分集計)

    1 期間連続で 0 以下

    P0

    1. System checkpoints を参照し、チェックポイント失敗の根本原因をトラブルシューティングします。

    2. 問題を特定して解決します。

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

    • リソースのスケーリング (例：バックプレッシャー)：dynamic scaling を使用して、バックプレッシャーが発生しているオペレーターにリソースを追加します。

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

    高レイテンシ (データ流入あり)

    Overview / CurrentEmitEventTimeLag && NumOfRecordsInFromSourcePerSecond

    最大レイテンシ ≥ 300,000 ms

    入力レコード数 > 0

    5 期間連続

    P1

    1. Monitor metrics を参照し、レイテンシの原因を特定します。

    • データ：イベント時刻の順序が入れ替わっていますか。

    • トラフィック：上流トラフィックの急増、または下流システムからのバックプレッシャーはありますか。

    • 内部：コネクターの WITH オプションを調整するか、ボトルネックとなっているオペレーターをスケールアップします。

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

    上流データフローの中断

    Overview / NumOfRecordsInFromSourcePerSecond &&

    SourceIdleTime

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

    最大アイドル時間 > 60,000 ms

    5 期間連続

    P1

    1. taskmanager.log、フレームグラフ、および上流サービスのメトリックを確認し、問題が 上流データなし、スロットリング、または例外 によるものか、あるいは スレッドスタックの停止 によるものかを確認します。

    • コネクターの問題：コネクターのパラメーター (例：タイムアウト、同時実行数) を最適化するか、TaskManager リソースを追加します。

    • 上流サービスの問題：上流サービスの担当者に通知して、問題を解決してもらいます。

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

    データ出力なし

    Overview / NumOfRecordsOutToSinkPerSecond

    5 期間連続で 0 以下

    P1

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

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

    • 遅延データのドロップ：遅延データとして破棄されていないか、ウォーターマークとウィンドウの設定を確認します。

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

    • 接続レベル：シンクの接続プールが枯渇していませんか。ネットワーク接続は安定していますか。

    • 宛先システムレベル：下流のデータベースまたはサービスで、テーブルロック、ディスク容量不足、書き込みのスロットリング、その他のエラーが発生していないか確認します。

    3. 一時的なフォールバックとして、バックアップストレージシステムへの二重書き込みを実装します。

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

    CPU / TMCPUUsage

    10 期間連続で 85% 以上

    P2

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

    • ビジネスロジック：複雑な計算、JSON パース、または非効率なユーザー定義関数 (UDF)。

    • データスキュー：ホットキーにより、1 つのタスクに大量のデータが集中して過負荷になっている。

    • リソース不足：現在の並列度と TaskManager リソースはデータトラフィックに見合っていますか。深刻なバックプレッシャーは発生していませんか。

    • 頻繁な GC：ログまたは JVM メトリックを使用して、メモリ圧迫により頻繁に Full GC が発生し、CPU を大きく消費していないか確認します。

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

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

    TMHeapMemoryUsed

    10 期間連続で 90% 以上

    P2

    1. GC ログを分析して問題を特定します。

    • メモリリーク：Flink UI またはモニタリングダッシュボードで、GC 後にヒープメモリがベースラインに戻らず、ベースラインが継続的に上昇していないか確認します。

    • 容量不足：ヒープメモリ使用率が恒常的に高い場合、頻繁な Full GC が発生してパフォーマンスが低下する可能性があります。

    • 突発的な OOM：特定のレコードまたはデータバッチの処理によりメモリが瞬時に枯渇し、OutOfMemoryError に直結していないか確認します。

    2. ヒープサイズまたは並列度を増やし、スロットあたりのデータ量を削減します。

    ジョブの可用性

    ジョブ失敗アラート

    コンソール (ARMS)

    1. Realtime Compute for Apache Flink コンソールにログインし、対象のワークスペースの[操作]列にある[コンソール]をクリックします。

    2. 左側のナビゲーションペインで、[運用保守] > [デプロイメント] を選択します。対象のジョブの名前をクリックします。

    3. [アラーム] タブをクリックします。

    [Add Alert Rule] をクリックします。[Create Rule] パネルでアラートを設定します。[Rule] では名前と説明を入力し、[Metric] として [Job Failed] を選択し、[Effective Period] と [Mute For] の間隔を設定します。[Notification Method] では希望する方法と 連絡先グループ を選択します。連絡先を管理するには、[Manage Contact] リンクをクリックします。

    CloudMonitor

    1. CloudMonitor コンソール にログインします。

    2. 左側のナビゲーションペインで、[イベントセンター] > [イベントサブスクリプション]を選択します。

    3. [サブスクリプションポリシー]タブで、[サブスクリプションポリシーの作成]をクリックします。

    4. [サブスクリプションポリシーの作成] ページで、パラメーターを設定します。詳細については、「イベントサブスクリプションの管理 (推奨)」をご参照ください。

    [Subscribe to Events] ステップで、[Type] を [System Event] に設定します。[Scope] セクションで、[Product] に Realtime Compute for Apache Flink を選択し、[Event Name] に [Job Failed] を選択します。[Level] と application group は All のままにできます。

    ジョブの安定性

    JobManager の頻繁な再起動

    • メトリック： NumOfRestart

    • ルール： 1 分以内にジョブが再起動した場合にアラートを発報します。

    • 推奨設定：

      • NumOfRestart

        値が 1 以上

      • 期間：1 分

      • 通知：電話 + SMS + Email + Webhook (Critical)

    チェックポイント成功率

    • メトリック： NumOfCheckpoints

    • ルール：5 分以内に成功したチェックポイントが発生しない場合にアラートを発報します。

    • 推奨設定：

      • NumOfCheckpoints

      • 値が 0 以下

      • 期間：5 分

      • 通知：電話 + SMS + Email + Webhook (Critical)

    データの適時性

    レイテンシ SLA

    • メトリック：

      • CurrentEmitEventTimeLag

      • NumOfRecordsInFromSourcePerSecond

    • ルール：データが取り込まれており、ビジネスレイテンシが 5 分を超える場合にアラートを発報します。しきい値とアラートレベルは、ビジネス要件に応じて調整できます。

    • 推奨設定：

      • CurrentEmitEventTimeLag

        最大値が 300,000 以上

      • NumOfRecordsInFromSourcePerSecond

        値が 0 より大きい

      • 期間：5 分

    上流データフローの中断

    • メトリック：

      • NumOfRecordsInFromSourcePerSecond

      • SourceIdleTime

    • ルール：データ入力が停止し、ソースのアイドル状態が 1 分を超える場合にアラートを発報します。しきい値とアラートレベルは、ビジネス要件に応じて調整できます。

    • 推奨設定：

      • NumOfRecordsInFromSourcePerSecond

        値が 0 以下

      • SourceIdleTime

        最大値が 60,000 を超える

      • 期間：5 分

    データ出力なし

    • メトリック： NumOfRecordsOutToSinkPerSecond

    • ルール：5 分を超えてデータが送信されない場合にアラートを発報します。しきい値とアラートレベルは、ビジネス要件に応じて調整できます。

    • 推奨設定：

      • NumOfRecordsOutToSinkPerSecond

        値が 0 以下

      • 期間：5 分

    リソースパフォーマンスのボトルネック

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

    • メトリック： TMCPUUsage

    • ルール：CPU 使用率が 10 分を超えて 85% を上回る場合にアラートを発報します。

    • 推奨設定：

      • TMCPUUsage

        最大値が 85 以上

      • 期間：10 分

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

    • メトリック： TMHeapMemoryUsed

    • ルール：ヒープメモリ使用率が 10 分を超えて 90% を上回る場合にアラートを発報します。

    • 推奨設定：

      • TMHeapMemoryUsed

        最大値がしきい値 (90%) 以上

        このしきい値は、[デプロイメント] > [ログ] ページで確認できます。 例えば、合計メモリが 413 MB の場合、しきい値を 372 MB (413 MB の 90%) に設定できます。

      • 期間：10 分