Realtime Compute for Apache Flink:モニタリングとログに関するよくある質問

ワークスペースで使用されているモニタリングサービスタイプの確認方法

モニタリングサービスタイプはワークスペースの作成時に選択され、後から変更することはできません。ご利用のワークスペースがどのタイプを使用しているかを確認するには、[オペレーションセンター] > [ジョブ O&M] に移動し、ジョブ名をクリックします。[アラート設定] タブが表示される場合、ワークスペースは Application Real-Time Monitoring Service (ARMS) の一部である従量課金の Prometheus Service を使用しています。タブが表示されない場合、ワークスペースは無料の Cloud Monitor サービスを使用しています。各サービスタイプの設定手順については、「ジョブのモニタリングとアラート」をご参照ください。

Cloud Monitor アラートと ARMS の比較における制限事項

Cloud Monitor は ARMS と比較して、3 つの制限事項があります：

• クエリ分析構文がサポートされていません。

• サブタスク粒度の曲線が利用できません。複数のソースとサブタスクがあるシナリオでは、これによりクラスタリング後のレイテンシー問題を迅速に特定することが困難になります。

• ユーザーコード内のカスタムイベントトラッキングからのメトリックを表示できないため、トラブルシューティングが複雑になる可能性があります。

アラート連絡先の設定または追加方法

Cloud Monitor または ARMS コンソールのアラートを使用する場合、対応するコンソールで連絡先を追加または設定します。詳細については、「モニタリングとアラートの設定」をご参照ください。

ご利用のワークスペースが ARMS を使用しており、Realtime Compute for Apache Flink 開発コンソールで直接単一ジョブのメトリックまたはジョブ失敗アラートを設定する場合、以下の手順に従ってアラート連絡先を追加または設定します。

1. アラート設定ページにアクセスします。

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

   2. [オペレーションセンター] > [ジョブ運用保守] ページで、対象のジョブ名をクリックします。

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

2. [アラートルール] タブで、[アラートルールの追加] > [カスタムルール] を選択し、ルール作成パネルを開きます。

3. アラート連絡先を設定または追加します。

   • 追加： [通知の受信者] パラメーターの横にある [通知の受信者管理] をクリックして、連絡先、DingTalk ロボットなどを追加します。DingTalk ロボット、Webhook、Lark ロボットのアラート設定については、アラートガイドの「よくある質問」セクションをご参照ください。連絡先を追加した後、アラートに電話を使用する場合は、受信者の電話番号が検証済みであることを確認してください。そうでない場合、アラートは配信されません。[連絡先] タブの対象連絡先の [電話] 列に [未検証] ラベルが表示されている場合は、ラベルをクリックして検証を完了してください。

   • 設定： [通知の受信者] パラメーターで、目的のアラート連絡先を選択します。連絡先がリストにない場合は、上記の手順に従って追加してください。

自動的に有効化された Prometheus Service の無効化方法

ワークスペースの作成時に従量課金の Prometheus Service を選択した場合、ARMS は自動的に有効になります。使用を停止するには、Prometheus コンソールから Prometheus インスタンスをアンインストールします。

重要

ワークスペースの Prometheus インスタンスをアンインストールすると、そのワークスペースのモニタリングデータ収集が停止し、ジョブのモニタリングデータ曲線が失われます。ジョブが異常になった場合、異常の初期時刻を特定したり、モニタリングアラートを受信したりできなくなります。注意して進めてください。

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

2. 左側のナビゲーションウィンドウで、[インスタンスリスト] をクリックします。

3. [タグラベル] ドロップダウンリストから、対象のワークスペースの ID または名前を選択します。

4. [インスタンスタイプ] が [Prometheus for Flink Serverless] に設定されているインスタンスを見つけ、[操作] 列の [アンインストール] をクリックします。

5. ダイアログボックスで、[確認] をクリックします。

アラートをトリガーしたジョブの特定方法

アラートイベントには JobID と Deployment ID の両方が含まれています。JobID はジョブのフェールオーバー後に変更されるため、Deployment ID を使用してエラーを報告した特定のジョブを識別します。

Deployment ID は、次のいずれかの場所で表示できます：

• Realtime Compute for Apache Flink 開発コンソールで、[デプロイメント詳細] タブの [基本設定] セクションで Deployment ID を見つけます。

  

• ジョブの URL 内。

  

Flink ジョブの再起動に対するモニタリングとアラートの設定方法

Realtime Compute for Apache Flink 開発コンソールは Flink メトリックに基づいてアラートルールを設定します。そのため、ジョブのフェールオーバー後、メトリック曲線は表示されず、アラートもトリガーされません。ジョブの再起動時にアラートを出すには、ARMS で flink_jobmanager_job_numRestarts メトリックの瞬間的な増加率に基づいてカスタムルールを設定します。これにより、ジョブマネージャー (JM) のフェールオーバーイベントに対してアラートを発行できます。

1. Realtime Compute for Apache Flink 管理コンソールにログインします。

2. 対象のワークスペースの [操作] 列で、[その他] > [モニタリングメトリック設定] をクリックして ARMS コンソールを開きます。

3. [アラートルール] ページで、[Prometheus アラートルールの作成] をクリックします。

4. [検出タイプ] を [カスタム PromQL] に設定し、アラート対象のインスタンスを選択します。

5. カスタムの Prometheus クエリ言語 (PromQL) 式を入力します。例：

   irate(flink_jobmanager_job_numRestarts{jobId=~"$jobId",deploymentId=~"$deploymentId"}[1m])>0

   この式は、過去 1 分間の flink_jobmanager_job_numRestarts メトリックをクエリし、瞬間的な変化率が 0 より大きい場合にアラートをトリガーします。

6. [完了] をクリックします。

単一クラスのログレベルパラメーターの設定方法

クラスごとのログレベルパラメーターは、[その他の設定] ではなく、[ログレベル] で設定します。たとえば、Kafka コネクタのログレベルを設定するには、[ログレベル] に次のパラメーターを追加します：

• log4j.logger.org.apache.kafka.clients.consumer=trace (ソーステーブルの場合)

• log4j.logger.org.apache.kafka.clients.producer=trace (結果テーブルの場合)

GC ログパラメーターの有効化方法

[オペレーションセンター] > [ジョブ O&M] ページで、対象のジョブ名をクリックします。[デプロイメント詳細] タブの [パラメーター設定] で、[その他の設定] に以下の構成を追加して保存し、適用します。

env.java.opts: >-
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/flink/log/gc.log
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=2 -XX:GCLogFileSize=50M

SLS のログ設定後にジョブの起動が失敗する

ジョブのログを Simple Log Service (SLS) に出力するように設定した後、ジョブが Job startup failed. Please retry. というメッセージと以下のエラーで失敗します：

Unknown ApiException {exceptionType=com.ververica.platform.appmanager.controller.domain.TemplatesRenderException, exceptionMessage=Failed to render {userConfiguredLoggers={}, jobId=3fd090ea-81fc-4983-ace1-0e0e7b******, rootLoggerLogLevel=INFO, clusterName=f7dba7ec27****, deploymentId=41529785-ab12-405b-82a8-1b1d73******, namespace=flinktest-default, priorityClassName=flink-p5, deploymentName=test}}
029999 202312121531-8SHEUBJUJU

このエラーは、ログ設定中に namespace や deploymentId などの Twig テンプレート変数が誤って変更された場合に発生します。

これを修正するには、「ジョブログ出力の設定」に従ってログ設定を再構成してください。ログ設定テンプレート内の Twig 変数は変更しないでください。

過去の Flink 運用ログの表示、検索、分析方法

Realtime Compute for Apache Flink は、過去の運用ログにアクセスするための 2 つの方法を提供します。

• 開発コンソール内： [デプロイメント詳細] タブでは、[ログアーカイブ] 機能がデフォルトで有効になっており、保持期間は 7 日間です。最新 5 MB の運用ログが保持されます。必要に応じて [ログアーカイブ保持期間] を調整してください。

  

• 外部ストレージ内： ジョブがログを Object Storage Service (OSS)、SLS、または Kafka に送信するように設定し、出力するログレベルを設定します。詳細については、「ジョブログ出力の設定」をご参照ください。

非静的メソッドからのログが SLS に出力されない問題の解決方法

SLS Logger Appender の実装ロジックにより、非静的メソッドからのログは SLS に出力されません。

この問題を解決するには、標準の静的パターンを使用してロガーを宣言します：

private static final Logger LOG = LoggerFactory.getLogger(xxx.class);

データは正しく書き込まれるが、Flink ジョブのステータス概要にデータが 0 と表示される場合の対処法

これは、ジョブにノードが 1 つしかなく、ソースに出力のみ、sink に入力のみがある場合に発生します。このトポロジーでは、Flink はトポロジーグラフにデータ量を表示しません。

トポロジーグラフでデータトラフィックを表示するには、ソースと sink の演算子を独立した演算子に分割します。[デプロイメント詳細] タブの [パラメーター設定] にある [その他の設定] に次のパラメーターを追加します：

pipeline.operator-chaining: 'false'

[オペレーションセンター] > [ジョブ O&M] に移動し、ジョブ名をクリックしてから、[デプロイメント詳細] タブの [パラメーター設定] にある [その他の設定] を見つけます。

DataStream ジョブに遅延がないにもかかわらず、出力曲線に遅延が表示される場合の対処法

CurrentEmitEventTimeLag と CurrentFetchEventTimeLag メトリックが約 52 年の遅延を示す場合、ジョブは Flink 組み込みコネクタではなく、コミュニティ Kafka コネクタを使用しています。コミュニティコネクタはこれらの曲線のメトリックレポートロジックを実装していないため、値が異常に見えます。

Flink 組み込みコネクタの依存関係に切り替えてください。正しいバージョンは Maven リポジトリ で見つけることができます。

DataStream ジョブのタスクマネージャー (TM) ログで NullPointerException がスローされるが、詳細なスタックトレースがない場合の対処法

JVM は、パフォーマンス最適化として、頻繁にスローされる例外のスタックトレースを省略します。この動作を無効にするには、[デプロイメント詳細] タブの [パラメーター設定] にある [その他の設定] に次のフラグを追加します：

env.java.opts: "-XX:-OmitStackTraceInFastThrow"

[オペレーションセンター] > [ジョブ O&M] に移動し、ジョブ名をクリックしてから、[デプロイメント詳細] タブの [パラメーター設定] にある [その他の設定] を見つけます。

Hologres コネクタを使用したジョブの再起動後、currentFetchEventTimeLag メトリックが異常に高い値を示す

• 現象

  Hologres コネクタを使用する Flink ジョブがチェックポイントから再起動または再開した後、currentFetchEventTimeLag メトリックが一時的に非常に高い値 (数時間、場合によっては数日) に急上昇し、その後徐々に正常に戻ります。

• 原因

  currentFetchEventTimeLag メトリックは System.currentTimeMillis() - record.getBinlogTimestamp() / 1000 として計算されます。このメトリックには次の特徴があります：

  • これは一時的なスナップショット値であり、チェックポイントと共に永続化されません。ジョブの再起動後、初期値の 0 にリセットされます。

  • 実際のデータレコードが消費された場合にのみ更新されます。ハートビートレコードは更新をトリガーしません。

  ジョブの再起動後、Hologres コネクタは最後のチェックポイント位置から binlog の消費を再開します。コンパクション、スキーマ変更、パーティションメンテナンスなどの内部 Hologres 操作により、より古いタイムスタンプを持つ過去の binlog レコードが生成されることがあります。これらの過去のレコードが消費されると、現在のシステム時刻とレコードのタイムスタンプとの間の大きなギャップにより、メトリックが急上昇します。すべての過去のデータが消費され、ジョブがリアルタイムデータに追いつくと、メトリックは正常に戻ります。

• 解決策

  このメトリックの異常は、ジョブの再起動時における Hologres コネクタの既知の動作であり、データ処理の正確性には影響しません。メトリックの急上昇の大きさがジョブのアイドル時間と一致していることを確認してください。ジョブが過去のデータの消費を終え、リアルタイムデータに追いつくと、メトリックは正常なレベルに戻ります。