このトピックでは、フルマネージド Flink でサポートされているメトリックについて説明します。
注意事項
Cloud Monitor と Flink コンソールの間のデータ差異
表示ディメンションの違い
Flink コンソールでは、Prometheus Query Language (PromQL) クエリを使用して最大レイテンシーのみを表示します。これは、リアルタイムコンピューティングのシナリオでは、平均レイテンシーがデータスキューや単一パーティションのブロッキングといった重大な問題を隠してしまう可能性があるためです。運用保守 (O&M) にとって価値のある情報は、最大レイテンシーのみが提供します。値のドリフト
Cloud Monitor は、事前集計メカニズムを使用してメトリックを計算します。集計ウィンドウ、サンプリング時間、または計算ロジックの違いにより、Cloud Monitor に表示される最大値は、Flink コンソールに表示されるリアルタイムの値とわずかに異なる場合があります。トラブルシューティングの際は、Flink コンソールのデータを基準としてください。
データレイテンシーとウォーターマークの設定
レイテンシーの計算ロジック
現在のモニタリングメトリックである Emit Delay は、イベント時間に基づいて計算されます。計算式は次のとおりです。遅延 = 現在のシステム時刻 - データペイロード内の論理時間フィールド (例：PriceData.time)
これは、このメトリックがシステムの処理速度ではなく、データの鮮度を反映していることを意味します。データ自体が古い場合や、システムがウォーターマークのアライメントを待つために出力を一時停止した場合、メトリックの値は高くなります。
推奨される調整
シナリオ 1：ビジネスロジックが正確性のためにウォーターマークに強く依存しているが、データソースが古い場合
典型的な状況：
上流のデータ伝送に固有のレイテンシーがある (例：イベントトラッキングレポートが遅い)。
履歴データをバックフィルしており、前日のデータを処理している。
ビジネスロジックは、順序不同のイベントを処理するためにウォーターマークに依存する必要があり、無効にできない。
症状：モニタリングアラートでは高いレイテンシーが示されているが、Kafka コンシューマーグループにはメッセージの蓄積がなく (ラグ ≈ 0)、CPU 負荷も低い。
推奨事項：
このレイテンシーメトリックを無視する：この場合、データが古いことを反映しているため、高い遅延は通常のビジネス動作です。これはシステム障害を示すものではありません。
モニタリングメトリックを変更する：運用保守エンジニアは、代わりに Kafka コンシューマーラグ (メッセージの蓄積) をモニタリングする必要があります。蓄積が継続的に増加しない限り、システムの処理能力は正常であり、介入は不要です。
シナリオ 2：リアルタイムパフォーマンスが優先され、軽微な順序不同のイベントやデータ損失が許容できる場合
典型的な状況：
ダッシュボードやリアルタイムリスク管理において、データがウォーターマークを待っているため出力が遅い。
ビジネスでは、「データ内のタイムスタンプ」よりも「データがいつ受信されたか」が重要視される。
症状：データストリームはリアルタイムであるが、ウォーターマークに大きな許容ウィンドウ (例：10 秒の遅延を許可) が設定されているため、データ出力が 10 秒遅延する。
推奨事項：
ウォーターマークを削除または無効にする：計算を処理時間に切り替えるか、ウォーターマークの待機しきい値を 0 に設定できます。
期待される結果：レイテンシーメトリックは即座に低下し、物理的な処理時間に近づきます。データはアライメントを待つことなく、到着次第処理および出力されます。
典型的なシナリオにおけるメトリックの特性
メトリックはコンポーネントの現在の状態を反映するだけであり、問題の根本原因を特定するには不十分です。包括的な診断のためには、常に Flink UI のバックプレッシャー検出機能やその他の補助ツールを使用する必要があります。
1. オペレーターのバックプレッシャー
症状：下流の処理能力が不足しているため、ソースの送信レートが低下します。
検出方法：Flink UI のバックプレッシャーモニタリングパネルを使用します。
メトリックの特性：
sourceIdleTime が定期的に増加します。
currentFetchEventTimeLag と currentEmitEventTimeLag が継続的に増加します。
極端なケース：オペレーターが完全にスタックした場合、sourceIdleTime は継続的に増加します。
2. ソースのパフォーマンスボトルネック
症状：ソースの読み取り速度が限界に達しているが、データ処理の要求を満たせていません。
検出方法：ジョブでバックプレッシャーが検出されません。
メトリックの特性：
sourceIdleTime が非常に低い値で推移しており、これはソースがフル稼働していることを示します。
currentFetchEventTimeLag と currentEmitEventTimeLag の値が類似しており、かつ高い値を示します。
3. データスキューまたは空のパーティション
症状：データが上流の Kafka パーティション間で不均等に分散しているか、空のパーティションが存在します。
検出方法：さまざまなソース間のメトリックの違いを観察します。
メトリックの特性：
特定のソースの sourceIdleTime が他のソースよりも著しく高く、これはその並列度がアイドル状態であることを示します。
4. データレイテンシー分析
症状：ジョブ全体のレイテンシーが高く、ボトルネックがソース内にあるのか、外部システムにあるのかを特定する必要があります。
検出方法：アイドル時間、ラグの差、メッセージの蓄積の組み合わせを分析します。
メトリックの特性：
高い sourceIdleTime：
これはソースがアイドル状態であることを示します。通常、Flink の処理が遅いのではなく、外部システムのデータ出力レートが低いことを意味します。ラグの差の分析：
currentEmitEventTimeLag と currentFetchEventTimeLag の差 (データがソースオペレーター内に滞在する時間) を比較します。差が小さい (2 つのメトリックが近い)：プル能力が不足しています。ボトルネックは、ネットワーク I/O 帯域幅またはソースの並列度の不足にあります。
差が大きい：処理能力が不足しています。ボトルネックは、非効率なデータ解析または下流のバックプレッシャーによる制限です。
pendingRecords (コネクタがサポートしている場合)：
このメトリックは、外部に保持されているデータ量を直接反映します。値が高いほど、外部システムでのデータ蓄積が深刻であることを示します。