Realtime Compute for Apache Flink:モニタリングとログに関する FAQ

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

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

ARMS と比較した CloudMonitor アラートの制限

CloudMonitor には、ARMS と比較して 3 つの制限があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自動的に有効化された 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 開発コンソールの [デプロイ詳細] タブで、[基本設定] セクションにあるデプロイメント ID を見つけます。

  

• ジョブの URL で確認します。

  

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

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

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

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

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

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

5. カスタム Prometheus Query Language (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 つしかなく、ソースに出力のみがあり、シンクに入力のみがある場合に発生します。このトポロジーでは、Flink はトポロジーグラフにデータ量を表示しません。

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

pipeline.operator-chaining: 'false'

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

DataStream ジョブに遅延がないにもかかわらず、出力グラフに遅延が表示される問題への対処

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

Flink 組み込みコネクタの依存関係に切り替えてください。正しいバージョンは Maven Repository で確認できます。

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 コネクタの既知の動作であり、データ処理の正確性には影響しません。メトリクスの急上昇の大きさがジョブのアイドル時間と一致するかどうかを確認してください。ジョブが履歴データの消費を完了し、リアルタイムデータに追いつくと、メトリクスは正常なレベルに戻ります。