Amazon Managed Service for Apache Flink は、以前は Amazon Kinesis Data Analytics for Apache Flink と呼ばれていました。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Managed Service for Apache Flink でのモニタリング
実稼働環境でストリーミング アプリケーションを実行する場合は、アプリケーションを継続的かつ無期限に実行するように設定します。Flink アプリケーションだけでなく、すべてのコンポーネントのモニターと適切なアラームを実装することが重要です。そうでなければ、新たな問題を早期に見逃してしまい、運用上の事件が完全に解明され、軽減することがはるかに難しくなってしまうと気付くリスクがあります。一般的に監視すべき事項は次のとおりです。
ソースはデータを取り込んでいますか。
データはソース(ソースの観点から)から読み込まれていますか。
Flinkアプリケーションはデータを受信していますか?
Flinkアプリケーションは対応できるのか、それとも遅れていますか。
Flinkアプリケーションは(アプリケーションの観点から)データをシンクに永続化していますか?
シンクはデータを受信していますか?
その場合は、Flinkアプリケーションについてより具体的なメトリクスを検討する必要があります。このCloudWatch ダッシュボード
records_lag_max および millisbehindLatest – アプリケーションが Kinesis または Kafka から消費している場合、これらのメトリクスは、アプリケーションが遅れているかどうかを示し、現在の負荷に追いつくためにスケーリングする必要があります。これは、あらゆる種類のアプリケーションで追跡しやすい汎用的な指標です。しかし、これはリアクティブスケーリング、つまりアプリケーションがすでに遅れている場合にのみ使用できます。
cpuUtilization および heapMemoryUtilization- これらのメトリクスは、アプリケーションの全体的なリソース使用率を適切に示し、アプリケーションが I/O バインドされていない限り、プロアクティブスケーリングに使用できます。
ダウンタイム — ダウンタイムがゼロより大きい場合は、アプリケーションに障害が発生したことを示します。値が0より大きい場合、アプリケーションはデータを処理していません。
lastCheckpointSize および lastCheckpointDuration- これらのメトリクスは、 状態で保存されるデータの量と、チェックポイントにかかる時間を監視します。チェックポイントが増えたり、時間がかかったりしても、アプリケーションはチェックポイント処理に時間を費やし続けて、実際の処理のサイクルは少なくなります。場合によっては、チェックポイントが増えすぎたり、時間がかかりすぎて失敗したりすることがあります。絶対値を監視することに加えて、顧客は
RATE(lastCheckpointSize)
とRATE(lastCheckpointDuration)
による変化率の監視を検討する必要もあります。numberOfFailedチェックポイント — このメトリクスは、アプリケーションが起動してから失敗したチェックポイントの数をカウントします。アプリケーションによっては、チェックポイントが失敗することがあっても許容できる場合があります。ただし、チェックポイントが定期的に失敗する場合は、アプリケーションが異常である可能性が高く、注意深く見ることが必要です。絶対値ではなく勾配でアラームを出すようにモニタリング
RATE(numberOfFailedCheckpoints)
をお勧めします。