Amazon Managed Service for Apache Flink で CloudWatch アラームを使用する - Managed Service for Apache Flink
推奨アラームを確認する

Amazon Managed Service for Apache Flink は、以前は Amazon Kinesis Data Analytics for Apache Flink と呼ばれていました。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Managed Service for Apache Flink で CloudWatch アラームを使用する

Amazon CloudWatch メトリクスアラームを使用して、指定した期間にわたって CloudWatch メトリクスを監視します。アラームは、複数の期間にわたる閾値に対するメトリックまたはメートルの値に基づいて、1つまたは複数のアクションを実行します。アクションの例は、Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信することです。

CloudWatch アラームの詳細については、「Amazon CloudWatch アラームの使用」を参照してください。

このセクションには、Managed Service for Apache Flinkアプリケーションをモニタリングするための推薦アラームが含まれています。

この表には推奨されるアラームが説明されており、次のセクションがあります。

  • メトリック表現：しきい値に対してテストするメトリックまたはメトリック式。

  • 統計:メトリックのチェックに使用される統計。たとえば、平均です。

  • しきい値：このアラームを使用するには、期待されるアプリケーションパフォーマンスの上限を定義するしきい値を決定する必要があります。このしきい値は、通常の状態でアプリケーションを監視して決定する必要があります。

  • 説明：このアラームをトリガーする可能性のある原因と、この状態に対して考えられる解決方法。

メトリクス式 統計) Threshold 説明
downtime > 0 [Average] (平均) 0 ダウンタイムが 0 より大きい場合は、アプリケーションが失敗したことを示します。値が0より大きい場合、アプリケーションはデータを処理していません。すべてのアプリケーションに推奨されます。Downtime メトリクスは、停止期間を測定します。ダウンタイムが 0 より大きい場合は、アプリケーションが失敗したことを示します。トラブルシューティングについては、「」を参照してくださいアプリケーションを再起動中。
RATE (numberOfFailedCheckpoints) > 0 [Average] (平均) 0 このメトリクスは、アプリケーションが起動してから失敗したチェックポイントの数をカウントします。アプリケーションによっては、チェックポイントが失敗することがあっても許容できる場合があります。ただし、チェックポイントが定期的に失敗する場合は、アプリケーションが異常である可能性が高く、注意深く見ることが必要です。絶対値ではなく勾配でアラームを発するように RATE（numberOfFailedチェックポイント) をモニタリングすることをお勧めします。すべてのアプリケーションに推奨されます。このメトリクスを使用して、アプリケーションのヘルスとチェックポイントの進行状況をモニタリングします。アプリケーションは、状態データが正常であればチェックポイントに保存します。アプリケーションが入力データの処理を進めていない場合、タイムアウトによりチェックポイントが失敗する可能性があります。トラブルシューティングについては、「」を参照してくださいチェックポイントがタイムアウトしています。。
Operator.numRecordsOutPerSecond < しきい値 [Average] (平均) 通常の状態でアプリケーションから出力されるレコードの最小数。 すべてのアプリケーションに推奨されます。このしきい値を下回ると、アプリケーションが入力データに対して予想される進行を行っていない可能性があります。トラブルシューティングについては、「」を参照してくださいスループットが遅すぎる。
records_lag_max|millisbehindLatest > しきい値 最大値 通常の状態における最大予想レイテンシー。 アプリケーションが Kinesis または Kafka から消費している場合、これらのメトリクスは、アプリケーションが遅れているかどうかを示し、現在の負荷に追いつくためにスケーリングする必要があります。これは、あらゆる種類のアプリケーションで追跡しやすい汎用的な指標です。しかし、これはリアクティブスケーリング、つまりアプリケーションがすでに遅れている場合にのみ使用できます。すべてのアプリケーションに推奨されます。Kafka ソースには records_lag_maxメトリクスを使用し、Kinesis ストリームソースmillisbehindLatestには を使用します。このしきい値を超えると、アプリケーションが入力データに対して予想される進行を行っていない可能性があります。トラブルシューティングについては、「」を参照してくださいスループットが遅すぎる。
lastCheckpointDuration > しきい値 最大値 通常の条件下で予想されるチェックポイントの最大期間。 状態に保存されるデータの量とチェックポイントにかかる時間を監視します。チェックポイントが増えたり、時間がかかったりしても、アプリケーションはチェックポイント処理に時間を費やし続けて、実際の処理のサイクルは少なくなります。場合によっては、チェックポイントが増えすぎたり、時間がかかりすぎて失敗したりすることがあります。絶対値を監視することに加えて、顧客はRATE(lastCheckpointSize)とRATE(lastCheckpointDuration)による変化率の監視を検討する必要もあります。がlastCheckpointDuration継続的に増加する場合、このしきい値を超えると、アプリケーションが入力データに対して予期された進行を行っていないか、バックプレッシャーなどのアプリケーションの状態に問題がある可能性があります。トラブルシューティングについては、「」を参照してください州の無限の成長。
lastCheckpointSize > しきい値 最大値 通常の条件下で予想されるチェックポイントの最大サイズ。 状態に保存されるデータの量とチェックポイントにかかる時間を監視します。チェックポイントが増えたり、時間がかかったりしても、アプリケーションはチェックポイント処理に時間を費やし続けて、実際の処理のサイクルは少なくなります。場合によっては、チェックポイントが増えすぎたり、時間がかかりすぎて失敗したりすることがあります。絶対値を監視することに加えて、顧客はRATE(lastCheckpointSize)とRATE(lastCheckpointDuration)による変化率の監視を検討する必要もあります。がlastCheckpointSize継続的に増加する場合、このしきい値を超えると、アプリケーションが状態データを蓄積している可能性があります。状態データが大きすぎると、チェックポイントからの復旧時にアプリケーションがメモリ不足になったり、チェックポイントからの復旧に時間がかかりすぎる可能性があります。トラブルシューティングについては、「」を参照してください州の無限の成長。
heapMemoryUtilization > しきい値 最大値 これにより、アプリケーションの全体的なリソース使用率がわかり、アプリケーションが I/O バインドされていない限り、プロアクティブスケーリングに使用できます。通常の条件下で予想される最大heapMemoryUtilizationサイズ。推奨値は 90% です。 このメトリクスを使用して、アプリケーション全体のタスクマネージャーの最大メモリ使用率をモニタリングできます。アプリケーションがこのしきい値に達した場合は、より多くのリソースをプロビジョニングする必要があります。これを行うには、自動スケーリングを有効にするか、アプリケーションの並列処理を増やします。リソースの増加の詳細については、「」を参照してくださいアプリケーションのスケーリングを実装する。
cpuUtilization > しきい値 最大値 これにより、アプリケーションの全体的なリソース使用率がわかり、アプリケーションが I/O バインドされていない限り、プロアクティブスケーリングに使用できます。通常の条件下で予想される最大cpuUtilizationサイズで、推奨値は 80% です。 このメトリクスを使用して、アプリケーション全体のタスクマネージャーの最大CPU使用率をモニタリングできます。アプリケーションがこのしきい値に達した場合は、より多くのリソースをプロビジョニングする必要があります。これを行うには、自動スケーリングを有効にするか、アプリケーションの並列処理を増やします。リソースの増加の詳細については、「」を参照してくださいアプリケーションのスケーリングを実装する。
threadsCount > しきい値 最大値 通常の状態における最大想定threadsCountサイズ。 このメトリクスを使用して、アプリケーション全体のタスクマネージャーのスレッドリークを監視できます。このメトリクスがこのしきい値に達した場合は、アプリケーションコードで、スレッドが閉じられていないかどうかを確認してください。
(oldGarbageCollectionTime * 100)/60_000 over 1 min period') > しきい値 最大値 予想される最大oldGarbageCollectionTime期間。一般的なガベージコレクション時間が指定されたしきい値の 60% になるようにしきい値を設定することをお勧めしますが、アプリケーションの正しいしきい値は異なります。 このメトリクスが継続的に増加している場合は、アプリケーション全体のタスクマネージャーにメモリリークがあることを示している可能性があります。
RATE(oldGarbageCollectionCount) > しきい値 最大値 oldGarbageCollectionCount 通常の条件下で予想される最大値。アプリケーションの正しいしきい値は異なります。 このメトリクスが継続的に増加している場合は、アプリケーション全体のタスクマネージャーにメモリリークがあることを示している可能性があります。
Operator.currentOutputWatermark - Operator.currentInputWatermark > しきい値 最小値 通常の条件下で予想されるウォーターマークの最小増分。アプリケーションの正しいしきい値は異なります。 このメトリクスが継続的に増加している場合は、アプリケーションがますます古いイベントを処理しているか、アップストリームサブタスクがますます長い時間ウォーターマークを送信していないことを示している可能性があります。