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