推奨アラーム

以下のセクションでは、ベストプラクティスアラームを設定することをお勧めするメトリクスを一覧表示しています。各メトリクスには、ディメンション、アラームの目的、推奨しきい値、しきい値の根拠、期間の長さとデータポイントの数も表示されます。

一部のメトリクスはリストに 2 回表示されることがあります。これは、そのメトリクスのディメンションの組み合わせによって異なるアラームが推奨される場合に発生します。

アラームを発生させるデータポイント数は、アラームが ALARM 状態になるのに必要な違反データポイントの数です。評価期間数 は、アラームの評価時に考慮される期間の数です。この 2 つの数が同じ場合、期間の値がその数だけ連続してしきい値を超えた場合にのみ、アラームは ALARM 状態になります。アラームを発生させるデータポイント数が評価期間数より少ない場合、そのアラームは「N 件中 M 件」のアラームであり、少なくともアラームを発生させるデータポイント数のデータポイントが、任意の評価期間数のデータポイントセット内で違反していると、アラームは ALARM 状態になります。詳細については、「アラームの評価」を参照してください。

Amazon API Gateway

4XXError

ディメンション: ApiName、Stage

アラームの説明: このアラームは、クライアント側エラーの発生率が高いことを検出します。これは、認証パラメータまたはクライアントリクエストパラメータに問題があることを示している可能性があります。また、リソースが削除されたか、存在しないリソースをクライアントがリクエストしている可能性もあります。CloudWatch Logs を有効にして、4XX エラーの原因となっている可能性のあるエラーがないか確認することを検討してください。さらに、詳細な CloudWatch メトリクスを有効にして、リソースやメソッドごとにこのメトリクスを表示し、エラーの原因を絞り込むことを検討してください。また、設定したスロットリング制限を超えたためにエラーが発生することもあります。レスポンスとログで報告されている 429 エラーの発生率が高く予想外の場合は、このガイドに従ってこの問題をトラブルシューティングしてください。

目的: このアラームは、API Gateway リクエストのクライアント側エラーの発生率が高いことを検出できます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 推奨しきい値は、全リクエストの 5% 超が 4XX エラーになっていることを検出します。ただし、リクエストのトラフィックや許容可能なエラー発生率に合わせてしきい値を調整できます。また、履歴データを分析してアプリケーションワークロードの許容エラー発生率を判断し、それに応じてしきい値を調整することもできます。頻繁に発生する 4XX エラーにはアラームが必要です。ただし、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎる可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

5XXError

ディメンション: ApiName、Stage

アラームの説明: このアラームは、サーバー側エラーの発生率が高いことを検出するのに役立ちます。これは、API バックエンド、ネットワーク、または API ゲートウェイとバックエンド API の統合に問題があることを示している可能性があります。このドキュメントは、5xx エラーの原因のトラブルシューティングに役立ちます。

目的: このアラームは、API Gateway リクエストのサーバー側エラーの発生率が高いことを検出できます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 推奨しきい値は、全リクエストの 5% 超が 5XX エラーになっていることを検出します。ただし、リクエストのトラフィックや許容可能なエラー発生率に合わせてしきい値を調整できます。また、履歴データを分析してアプリケーションワークロードの許容エラー発生率を判断し、それに応じてしきい値を調整することもできます。頻繁に発生する 5XX エラーにはアラームが必要です。ただし、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎる可能性があります。

期間: 60

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: GREATER_THAN_THRESHOLD

Count (カウント)

ディメンション: ApiName、Stage

アラームの説明: このアラームは、REST API ステージのトラフィック量が少ないことを検出するのに役立ちます。これは、API を呼び出すアプリケーションに問題があることを示している可能性があります。たとえば、不正なエンドポイントを使用している場合などです。また、API の設定やアクセス許可に問題があり、クライアントがアクセスできないことを示している可能性もあります。

目的: このアラームは、REST API ステージのトラフィック量が予想外に少ないことを検出できます。通常の状態で API が予測可能で一定数のリクエストを受信する場合は、このアラームを作成することをお勧めします。詳細な CloudWatch メトリクスを有効にしていて、メソッドとリソースごとの通常のトラフィック量を予測できる場合は、これに代わるアラームを複数作成して、各リソースとメソッドのトラフィック量の減少をより詳細にモニタリングすることをお勧めします。一定で一貫したトラフィックを想定していない API には、このアラームはお勧めしません。

統計: SampleCount

推奨しきい値: 状況によって異なります。

しきい値の根拠: 履歴データ分析に基づいてしきい値を設定し、API のリクエスト数の予想ベースラインを決定します。しきい値を非常に高い値に設定すると、通常時およびトラフィックが少ないことが予想される時間帯に、アラームの感度が高くなりすぎる可能性があります。逆に、非常に低い値に設定すると、トラフィック量の異常な減少をアラームが見逃してしまう可能性があります。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: LESS_THAN_THRESHOLD

Count (カウント)

ディメンション: ApiName、Stage、Resource、Method

アラームの説明: このアラームは、ステージでの REST API リソースとメソッドのトラフィック量が少ないことを検出するのに役立ちます。これは、API を呼び出すアプリケーションに問題があることを示している可能性があります。例えば、不正なエンドポイントを使用している場合などです。また、API の設定やアクセス許可に問題があり、クライアントがアクセスできないことを示している可能性もあります。

目的: このアラームは、ステージでの REST API リソースとメソッドのトラフィック量が予想外に少ないことを検出できます。通常の状態で API が予測可能で一定数のリクエストを受信する場合は、このアラームを作成することをお勧めします。一定で一貫したトラフィックを想定していない API には、このアラームはお勧めしません。

統計: SampleCount

推奨しきい値: 状況によって異なります。

しきい値の根拠: 履歴データ分析に基づいてしきい値を設定し、API のリクエスト数の予想ベースラインを決定します。しきい値を非常に高い値に設定すると、通常時およびトラフィックが少ないことが予想される時間帯に、アラームの感度が高くなりすぎる可能性があります。逆に、非常に低い値に設定すると、トラフィック量の異常な減少をアラームが見逃してしまう可能性があります。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: LESS_THAN_THRESHOLD

Count (カウント)

ディメンション: ApiId、Stage

アラームの説明: このアラームは、HTTP API ステージのトラフィック量が少ないことを検出するのに役立ちます。これは、API を呼び出すアプリケーションに問題があることを示している可能性があります。例えば、不正なエンドポイントを使用している場合などです。また、API の設定やアクセス許可に問題があり、クライアントがアクセスできないことを示している可能性もあります。

目的: このアラームは、HTTP API ステージのトラフィック量が予想外に少ないことを検出できます。通常の状態で API が予測可能で一定数のリクエストを受信する場合は、このアラームを作成することをお勧めします。詳細な CloudWatch メトリクスを有効にしていて、ルートごとの通常のトラフィック量を予測できる場合は、これに代わるアラームを複数作成して、各ルートのトラフィック量の減少をより詳細にモニタリングすることをお勧めします。一定で一貫したトラフィックを想定していない API には、このアラームはお勧めしません。

統計: SampleCount

推奨しきい値: 状況によって異なります。

しきい値の根拠: 履歴データ分析に基づいてしきい値を設定し、API のリクエスト数の予想ベースラインを決定します。しきい値を非常に高い値に設定すると、通常時およびトラフィックが少ないことが予想される時間帯に、アラームの感度が高くなりすぎる可能性があります。逆に、非常に低い値に設定すると、トラフィック量の異常な減少をアラームが見逃してしまう可能性があります。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: LESS_THAN_THRESHOLD

Count (カウント)

ディメンション: ApiId、Stage、Resource、Method

アラームの説明: このアラームは、ステージ内の HTTP API ルートのトラフィック量が少ないことを検出するのに役立ちます。これは、API を呼び出すアプリケーションに問題があることを示している可能性があります。例えば、不正なエンドポイントを使用している場合などです。また、API の設定やアクセス許可に問題があり、クライアントがアクセスできないことを示している可能性もあります。

目的: このアラームは、ステージ内の HTTP API ルートのトラフィック量が予想外に少ないことを検出できます。通常の状態で API が予測可能で一定数のリクエストを受信する場合は、このアラームを作成することをお勧めします。一定で一貫したトラフィックを想定していない API には、このアラームはお勧めしません。

統計: SampleCount

推奨しきい値: 状況によって異なります。

しきい値の根拠: 履歴データ分析に基づいてしきい値を設定し、API のリクエスト数の予想ベースラインを決定します。しきい値を非常に高い値に設定すると、通常時およびトラフィックが少ないことが予想される時間帯に、アラームの感度が高くなりすぎる可能性があります。逆に、非常に低い値に設定すると、トラフィック量の異常な減少をアラームが見逃してしまう可能性があります。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: LESS_THAN_THRESHOLD

IntegrationLatency

ディメンション: ApiId、Stage

アラームの説明: このアラームは、あるステージの API リクエストの統合レイテンシーが大きいかどうかを検出するのに役立ちます。IntegrationLatency メトリクス値を、Lambda 統合の Duration メトリクスなど、バックエンドの対応するレイテンシーメトリクスと関連付けることができます。これにより、パフォーマンスの問題が原因で API バックエンドがクライアントからのリクエストを処理するのに時間がかかっているのか、それとも初期化やコールドスタートによるその他のオーバーヘッドがあるのかを判断できます。さらに、API の CloudWatch Logs を有効にして、レイテンシーが大きい問題を引き起こしている可能性のあるエラーがないかログを確認することを検討してください。さらに、詳細な CloudWatch メトリクスを有効にして、ルートごとにこのメトリクスを表示することを検討してください。これにより、統合レイテンシーの原因を絞り込むことができます。

目的: このアラームは、ステージ内の API Gateway リクエストの統合レイテンシーが大きいことを検出できます。WebSocket API にはこのアラームをお勧めしますが、HTTP API ではオプションと考えています。これは、レイテンシーメトリクスに関する個別のアラーム推奨事項がすでに設定されているためです。詳細な CloudWatch メトリクスを有効にしていて、ルートごとに統合レイテンシーのパフォーマンス要件が異なる場合は、これに代わるアラームを複数作成して、各ルートの統合レイテンシーをより詳細にモニタリングすることをお勧めします。

統計: p90

推奨しきい値: 2000.0

しきい値の根拠: 推奨しきい値は、すべての API ワークロードに適しているわけではありません。ただし、しきい値の初期値として使用が可能です。その後、ワークロードや許容可能なレイテンシー、パフォーマンス、および API に対する SLA 要件に基づいて異なるしきい値を選択できます。一般的に API のレイテンシーが大きいことを許容できる場合は、しきい値を高く設定してアラームの感度を低くします。一方、API がほぼリアルタイムで応答することが期待される場合は、しきい値を低く設定します。また、履歴データを分析してアプリケーションワークロードのレイテンシーの予想ベースラインを判断し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

IntegrationLatency

ディメンション: ApiId、Stage、Route

アラームの説明: このアラームは、ステージ内のルートに対する WebSocket API リクエストの統合レイテンシーが大きいかどうかを検出するのに役立ちます。IntegrationLatency メトリクス値を、Lambda 統合の Duration メトリクスなど、バックエンドの対応するレイテンシーメトリクスと関連付けることができます。これにより、パフォーマンスの問題が原因で API バックエンドがクライアントからのリクエストを処理するのに時間がかかっているのか、それとも初期化やコールドスタートによるその他のオーバーヘッドがあるのかを判断できます。さらに、API の CloudWatch Logs を有効にして、レイテンシーが大きい問題を引き起こしている可能性のあるエラーがないかログを確認することを検討してください。

目的:このアラームは、ステージ内のルートに対する API Gateway リクエストの統合レイテンシーが大きいことを検出できます。

統計: p90

推奨しきい値: 2000.0

しきい値の根拠: 推奨しきい値は、すべての API ワークロードに適しているわけではありません。ただし、しきい値の初期値として使用が可能です。その後、ワークロードや許容可能なレイテンシー、パフォーマンス、および API に対する SLA 要件に基づいて異なるしきい値を選択できます。一般的に API のレイテンシーが大きいことを許容できる場合は、しきい値を高く設定してアラームの感度を低くできます。一方、API がほぼリアルタイムで応答することが期待される場合は、しきい値を低く設定します。また、履歴データを分析してアプリケーションワークロードのレイテンシーの予想ベースラインを判断し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

レイテンシー

ディメンション: ApiName、Stage

アラームの説明: このアラームは、ステージ内のレイテンシーが大きいことを検出します。IntegrationLatency メトリクス値を調べて API バックエンドのレイテンシーをチェックします。2 つのメトリクスがほぼ一致している場合、API バックエンドがレイテンシー増加の原因となるため、問題がないか調査する必要があります。CloudWatch Logs を有効にして、レイテンシーが大きいことの原因となっている可能性のあるエラーをチェックすることも検討してください。さらに、詳細な CloudWatch メトリクスを有効にして、リソースとメソッドごとにこのメトリクスを表示して、レイテンシーの原因を絞り込むことを検討してください。該当する場合は、「Lambda でのトラブルシューティング」または「エッジ最適化 API エンドポイントのトラブルシューティング」ガイドを参照してください。

目的: このアラームは、ステージ内の API Gateway リクエストのレイテンシーが大きいことを検出できます。詳細な CloudWatch メトリクスを有効にしていて、メソッドとリソースごとにレイテンシーのパフォーマンス要件が異なる場合は、これに代わるアラームを複数作成して、各リソースとメソッドのレイテンシーをより詳細にモニタリングすることをお勧めします。

統計: p90

推奨しきい値: 2500.0

しきい値の根拠: 推奨しきい値は、すべての API ワークロードに適しているわけではありません。ただし、しきい値の初期値として使用が可能です。その後、ワークロードや許容可能なレイテンシー、パフォーマンス、および API に対する SLA 要件に基づいて異なるしきい値を選択できます。一般的に API のレイテンシーが大きいことを許容できる場合は、しきい値を高く設定してアラームの感度を低くできます。一方、API がほぼリアルタイムで応答することが期待される場合は、しきい値を低く設定します。また、履歴データを分析してアプリケーションワークロードの予想ベースラインレイテンシーを判断し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

レイテンシー

ディメンション: ApiName、Stage、Resource、Method

アラームの説明: このアラームは、ステージ内のリソースとメソッドのレイテンシーが大きいことを検出します。IntegrationLatency メトリクス値を調べて API バックエンドのレイテンシーをチェックします。2 つのメトリクスがほぼ一致している場合、API バックエンドがレイテンシー増加の原因となるため、パフォーマンスの問題がないか調査する必要があります。CloudWatch Logs を有効にして、レイテンシーが大きいことの原因となっている可能性のあるエラーがないかをチェックすることも検討してください。該当する場合は、「Lambda でのトラブルシューティング」または「エッジ最適化 API エンドポイントのトラブルシューティング」ガイドを参照することもできます。

目的: このアラームは、ステージ内のリソースとメソッドに対する API Gateway リクエストの統合レイテンシーが大きいことを検出できます。

統計: p90

推奨しきい値: 2500.0

しきい値の根拠: 推奨しきい値は、すべての API ワークロードに適しているわけではありません。ただし、しきい値の初期値として使用が可能です。その後、ワークロードや許容可能なレイテンシー、パフォーマンス、および API に対する SLA 要件に基づいて異なるしきい値を選択できます。一般的に API のレイテンシーが大きいことを許容できる場合は、しきい値を高く設定してアラームの感度を低くできます。一方、API がほぼリアルタイムで応答することが期待される場合は、しきい値を低く設定します。また、履歴データを分析してアプリケーションワークロードのレイテンシーの予想ベースラインを判断し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

レイテンシー

ディメンション: ApiId、Stage

アラームの説明: このアラームは、ステージ内のレイテンシーが大きいことを検出します。IntegrationLatency メトリクス値を調べて API バックエンドのレイテンシーをチェックします。2 つのメトリクスがほぼ一致している場合、API バックエンドがレイテンシー増加の原因となるため、パフォーマンスの問題がないか調査する必要があります。CloudWatch Logs を有効にして、レイテンシーが大きいことの原因となっている可能性のあるエラーがないかをチェックすることも検討してください。さらに、詳細な CloudWatch メトリクスを有効にして、ルートごとにこのメトリクスを表示して、レイテンシーの原因を絞り込むことを検討してください。該当する場合は、「Lambda 統合でのトラブルシューティング」ガイドも参照できます。

目的: このアラームは、ステージ内の API Gateway リクエストのレイテンシーが大きいことを検出できます。詳細な CloudWatch メトリクスを有効にしていて、ルートごとにレイテンシーのパフォーマンス要件が異なる場合は、これに代わるアラームを複数作成して、各ルートのレイテンシーをより詳細にモニタリングすることをお勧めします。

統計: p90

推奨しきい値: 2500.0

しきい値の根拠: 推奨しきい値は、すべての API ワークロードに適しているわけではありません。ただし、しきい値の初期値として使用が可能です。その後、ワークロードや許容可能なレイテンシー、パフォーマンス、および API に対する SLA 要件に基づいて異なるしきい値を選択できます。一般的に API のレイテンシーが大きいことを許容できる場合は、しきい値を高く設定して感度を低くできます。一方、API がほぼリアルタイムで応答することが期待される場合は、しきい値を低く設定します。また、履歴データを分析してアプリケーションワークロードのレイテンシーの予想ベースラインを判断し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

レイテンシー

ディメンション: ApiId、Stage、Resource、Method

アラームの説明: このアラームは、ステージ内のルートのレイテンシーが大きいことを検出します。IntegrationLatency メトリクス値を調べて API バックエンドのレイテンシーをチェックします。2 つのメトリクスがほぼ一致している場合、API バックエンドがレイテンシー増加の原因となるため、パフォーマンスの問題がないか調査する必要があります。CloudWatch Logs を有効にして、レイテンシーが大きいことの原因となっている可能性のあるエラーがないかをチェックすることも検討してください。該当する場合は、「Lambda 統合でのトラブルシューティング」ガイドも参照できます。

目的:このアラームは、ステージ内のルートに対する API Gateway リクエストのレイテンシーが大きいことを検出するために使用されます。

統計: p90

推奨しきい値: 2500.0

しきい値の根拠: 推奨しきい値は、すべての API ワークロードに適しているわけではありません。ただし、しきい値の初期値として使用が可能です。その後、ワークロードや許容可能なレイテンシー、パフォーマンス、および API に対する SLA 要件に基づいて異なるしきい値を選択できます。一般的に API のレイテンシーが大きいことを許容できる場合は、しきい値を高く設定してアラームの感度を低くできます。一方、API がほぼリアルタイムで応答することが期待される場合は、しきい値を低く設定します。また、履歴データを分析してアプリケーションワークロードのレイテンシーの予想ベースラインを判断し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

4xx

ディメンション: ApiId、Stage

アラームの説明: このアラームは、クライアント側エラーの発生率が高いことを検出します。これは、認証パラメータまたはクライアントリクエストパラメータに問題があることを示している可能性があります。また、ルートが削除されたか、API に存在しないルートをクライアントがリクエストしている可能性もあります。CloudWatch Logs を有効にして、4xx エラーの原因となっている可能性のあるエラーがないか確認することを検討してください。さらに、詳細な CloudWatch メトリクスを有効にして、ルートごとにこのメトリクスを表示して、エラーの原因の絞り込みに役立てることを検討してください。また、設定したスロットリング制限を超えたためにエラーが発生することもあります。レスポンスとログで報告されている 429 エラーの発生率が高く予想外の場合は、このガイドに従ってこの問題をトラブルシューティングしてください。

目的: このアラームは、API Gateway リクエストのクライアント側エラーの発生率が高いことを検出できます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 推奨しきい値は、全リクエストの 5% 超が 4xx エラーになっていることを検出します。ただし、リクエストのトラフィックや許容可能なエラー発生率に合わせてしきい値を調整できます。また、履歴データを分析してアプリケーションワークロードの許容エラー発生率を判断し、それに応じてしきい値を調整することもできます。頻繁に発生する 4xx エラーにはアラームが必要です。ただし、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎる可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

5xx

ディメンション: ApiId、Stage

アラームの説明: このアラームは、サーバー側エラーの発生率が高いことを検出するのに役立ちます。これは、API バックエンド、ネットワーク、または API ゲートウェイとバックエンド API の統合に問題があることを示している可能性があります。このドキュメントは、5xx エラーの原因のトラブルシューティングに役立ちます。

目的: このアラームは、API Gateway リクエストのサーバー側エラーの発生率が高いことを検出できます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 推奨しきい値は、全リクエストの 5% 超が 5xx エラーになっていることを検出します。ただし、リクエストのトラフィックや許容可能なエラー発生率に合わせてしきい値を調整できます。また、履歴データを分析してアプリケーションワークロードの許容エラー発生率を判断し、それに応じてしきい値を調整することもできます。頻繁に発生する 5xx エラーにはアラームが必要です。ただし、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎる可能性があります。

期間: 60

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: GREATER_THAN_THRESHOLD

MessageCount

ディメンション: ApiId、Stage

アラームの説明: このアラームは、WebSocket API ステージのトラフィック量が少ないことを検出するのに役立ちます。これは、クライアントが API を呼び出す際に不正なエンドポイントを使用するなどの問題や、バックエンドがクライアントにメッセージを送信する際の問題を示している可能性があります。また、API の設定やアクセス許可に問題があり、クライアントがアクセスできないことを示している可能性もあります。

目的: このアラームは、WebSocket API ステージのトラフィック量が予想外に少ないことを検出できます。通常の状態で API が予測可能で一定数のメッセージを送受信する場合は、このアラームを作成することをお勧めします。詳細な CloudWatch メトリクスを有効にしていて、ルートごとの通常のトラフィック量を予測できる場合は、これに代わるアラームを複数作成して、各ルートのトラフィック量の減少をより詳細にモニタリングすることをお勧めします。一定で一貫したトラフィックを想定していない API には、このアラームはお勧めしません。

統計: SampleCount

推奨しきい値: 状況によって異なります。

しきい値の根拠: 履歴データ分析に基づいてしきい値を設定し、API のメッセージ数の予想ベースラインを決定します。しきい値を非常に高い値に設定すると、通常時およびトラフィックが少ないことが予想される時間帯に、アラームの感度が高くなりすぎる可能性があります。逆に、非常に低い値に設定すると、トラフィック量の異常な減少をアラームが見逃してしまう可能性があります。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: LESS_THAN_THRESHOLD

MessageCount

ディメンション: ApiId、Stage、Route

アラームの説明: このアラームは、ステージ内の WebSocket API ルートのトラフィック量が少ないことを検出するのに役立ちます。これは、クライアントが API を呼び出す際に不正なエンドポイントを使用するなどの問題や、バックエンドがクライアントにメッセージを送信する際の問題を示している可能性があります。また、API の設定やアクセス許可に問題があり、クライアントがアクセスできないことを示している可能性もあります。

目的: このアラームは、ステージ内の WebSocket API ルートのトラフィック量が予想外に少ないことを検出できます。通常の状態で API が予測可能で一定数のメッセージを送受信する場合は、このアラームを作成することをお勧めします。一定で一貫したトラフィックを想定していない API には、このアラームはお勧めしません。

統計: SampleCount

推奨しきい値: 状況によって異なります。

しきい値の根拠: 履歴データ分析に基づいてしきい値を設定し、API のメッセージ数の予想ベースラインを決定します。しきい値を非常に高い値に設定すると、通常時およびトラフィックが少ないことが予想される時間帯に、アラームの感度が高くなりすぎる可能性があります。逆に、非常に低い値に設定すると、トラフィック量の異常な減少をアラームが見逃してしまう可能性があります。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: LESS_THAN_THRESHOLD

ClientError

ディメンション: ApiId、Stage

アラームの説明: このアラームは、クライアントエラーの発生率が高いことを検出します。これは、認証パラメータまたはメッセージパラメータに問題があることを示している可能性があります。また、ルートが削除されたか、API に存在しないルートをクライアントがリクエストしている可能性もあります。CloudWatch Logs を有効にして、4xx エラーの原因となっている可能性のあるエラーがないか確認することを検討してください。さらに、詳細な CloudWatch メトリクスを有効にして、ルートごとにこのメトリクスを表示して、エラーの原因の絞り込みに役立てることを検討してください。また、設定したスロットリング制限を超えたためにエラーが発生することもあります。レスポンスとログで報告されている 429 エラーの発生率が高く予想外の場合は、このガイドに従ってこの問題をトラブルシューティングしてください。

目的: このアラームは、WebSocket API Gateway メッセージのクライアントエラーの発生率が高いことを検出できます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 推奨しきい値は、全リクエストの 5% 超が 4xx エラーになっていることを検出します。リクエストのトラフィックや許容可能なエラー発生率に合わせてしきい値を調整できます。また、履歴データを分析してアプリケーションワークロードの許容エラー発生率を判断し、それに応じてしきい値を調整することもできます。頻繁に発生する 4xx エラーにはアラームが必要です。ただし、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎる可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

ExecutionError

ディメンション: ApiId、Stage

アラームの説明:このアラームは、実行エラーの発生率が高いことを検出するのに役立ちます。これは、統合、アクセス許可の問題、または統合の呼び出しを正常に実行できないその他の要因 (統合がスロットリングや削除されるなど) による 5xx エラーが原因である可能性があります。API の CloudWatch Logs を有効にし、ログでエラーの種類と原因を確認することを検討してください。さらに、詳細な CloudWatch メトリクスを有効にして、ルートごとにこのメトリクスを表示して、エラーの原因の絞り込みに役立てることを検討してください。このドキュメントも、接続エラーの原因のトラブルシューティングに役立ちます。

目的: このアラームは、WebSocket API Gateway メッセージの実行エラーの発生率が高いことを検出できます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 推奨しきい値は、全リクエストの 5% 超が実行エラーになっていることを検出します。リクエストのトラフィックや許容可能なエラー発生率に合わせてしきい値を調整できます。履歴データを分析してアプリケーションワークロードの許容エラー発生率を判断し、それに応じてしきい値を調整できます。頻繁に発生する実行エラーにはアラームが必要です。ただし、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎる可能性があります。

期間: 60

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: GREATER_THAN_THRESHOLD

Amazon EC2 Auto Scaling

GroupInServiceCapacity

ディメンション: AutoScalingGroupName

アラームの説明: このアラームは、グループ内の容量がワークロードに必要な希望容量を下回ったことを検出するのに役立ちます。トラブルシューティングを行うには、スケーリングアクティビティの起動に障害がないかどうかをチェックし、必要な容量設定が正しいことを確認します。

目的: このアラームは、起動の失敗または中断が原因で 自動スケーリンググループの可用性が低下していることを検出できます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: しきい値は、ワークロードを実行するのに必要な最小容量にするべきです。ほとんどの場合、GroupDesiredCapacity メトリクスと一致するように設定できます。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: LESS_THAN_THRESHOLD

Amazon CloudFront

5xxErrorRate

ディメンション: DistributionId、Region=Global

アラームの説明: このアラームは、オリジンサーバーからの 5xx エラーレスポンスの割合をモニタリングし、CloudFront サービスに問題が発生しているかどうかを検出するのに役立ちます。サーバーの問題点を理解するのに役立つ情報については、「オリジンからのエラーレスポンスのトラブルシューティング」を参照してください。また、詳細なエラーメトリクスを取得するには、追加のメトリクスをオンにしてください。

目的: このアラームは、オリジンサーバーからのリクエストの処理に関する問題、または CloudFront とオリジンサーバー間の通信の問題を検出するために使用されます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、5xx レスポンスの許容度によって大きく異なります。履歴データと傾向を分析し、それに応じてしきい値を設定できます。5xx エラーは一時的な問題が原因で発生する可能性があるため、アラームの感度が高すぎないように、しきい値を 0 より大きい値に設定することをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

OriginLatency

ディメンション: DistributionId、Region=Global

アラームの説明: このアラームは、オリジンサーバーの応答に時間がかかりすぎていないかをモニタリングするのに役立ちます。サーバーの応答に時間がかかりすぎると、タイムアウトになる可能性があります。OriginLatency が一貫して高い場合は、「オリジンサーバーでアプリケーションからの遅延したレスポンスを見つけて修正する」を参照してください。

目的: このアラームは、オリジンサーバーが応答に時間がかかりすぎるという問題を検出するために使用されます。

統計: p90

推奨しきい値: 状況によって異なります。

しきい値の根拠: オリジンレスポンスタイムアウトの約 80% の値を計算し、その結果をしきい値として使用してください。このメトリクスが常にオリジンレスポンスタイムアウト値に近い場合、504 エラーが発生し始める可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

FunctionValidationErrors

ディメンション: DistributionId、FunctionName、Region=Global

アラームの説明: このアラームは、CloudFront 関数からの検証エラーをモニタリングし、解決するための措置を講じるのに役立ちます。CloudWatch 関数ログを分析し、関数コードを調べて問題の根本原因を見つけて解決します。CloudFront Functions のよくある設定ミスを理解するには、「エッジ関数に対する制限」を参照してください。

目的: このアラームは、CloudFront 関数からの検証エラーを検出するために使用されます。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: 0 より大きい値は検証エラーを示します。検証エラーがあると CloudFront 関数が CloudFront に引き渡されるときに問題が発生していることになるため、しきい値を 0 に設定することをお勧めします。例えば、CloudFront はリクエストを処理するために HTTP ホストヘッダーを必要とします。ユーザーは CloudFront 関数コード内のホストヘッダーを削除できてしまいます。しかし、CloudFront がレスポンスを受け取り、ホストヘッダーが見つからない場合、CloudFront は検証エラーをスローします。

期間: 60

アラームを発生させるデータポイント数: 2

評価期間数: 2

比較演算子: GREATER_THAN_THRESHOLD

FunctionExecutionErrors

ディメンション: DistributionId、FunctionName、Region=Global

アラームの説明: このアラームは、CloudFront 関数からの実行エラーをモニタリングし、解決するための措置を講じるのに役立ちます。CloudWatch 関数ログを分析し、関数コードを調べて問題の根本原因を見つけて解決します。

目的: このアラームは、CloudFront 関数からの実行エラーを検出するために使用されます。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: 実行エラーは実行時に発生するコードに問題があることを示しているため、しきい値を 0 に設定することをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

FunctionThrottles

ディメンション: DistributionId、FunctionName、Region=Global

アラームの説明: このアラームは、CloudFront 関数がスロットリングされているかどうかをモニタリングするのに役立ちます。関数がスロットリングされている場合は、実行に時間がかかりすぎていることを意味します。関数のスロットリングを避けるには、関数コードの最適化を検討してください。

目的: このアラームは、スムーズなカスタマーエクスペリエンスのために、CloudFront 関数がスロットリングされていることを検出し、問題に対応して解決できます。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: 関数のスロットリングをより早く解決できるように、しきい値を 0 に設定することをおすすめします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Amazon Cognito

SignUpThrottles

ディメンション: UserPool、UserPoolClient

アラームの説明: このアラームは、スロットリングされたリクエストの数をモニタリングします。ユーザーが定常的にスロットリングされている場合は、サービスクォータの引き上げをリクエストして制限を引き上げる必要があります。クォータの引き上げをリクエストする方法については、「Amazon Cognito のクォータ」を参照してください。事前にアクションを実行するには、クォータの使用状況を追跡することを検討してください。

目的: このアラームは、サインアップリクエストのスロットリングの発生をモニタリングするのに役立ちます。これにより、サインアップでのネガティブな体験の増加を抑えるためのアクションをいつ取るべきかがわかります。リクエストのスロットリングが続くことは、ユーザーがサインアップでネガティブな体験をするということです。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: 適切にプロビジョニングされたユーザープールでは、複数のデータポイントにまたがるスロットリングは発生しないはずです。そのため、予想されるワークロードの通常のしきい値はゼロでなければなりません。バーストが頻繁に発生する不規則なワークロードの場合は、履歴データを分析してアプリケーションのワークロードの許容可能なスロットリングを決定し、それに応じてしきい値を調整できます。スロットリングされたリクエストは、アプリケーションへの影響を最小限に抑えるために再試行する必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

SignInThrottles

ディメンション: UserPool、UserPoolClient

アラームの説明: このアラームは、スロットリングされたユーザー認証リクエストの数をモニタリングします。ユーザーが定常的にスロットリングされている場合は、サービスクォータの引き上げをリクエストして制限を引き上げることが必要な場合があります。クォータの引き上げをリクエストする方法については、「Amazon Cognito のクォータ」を参照してください。事前にアクションを実行するには、クォータの使用状況を追跡することを検討してください。

目的: このアラームは、サインインリクエストのスロットリングの発生をモニタリングするのに役立ちます。これにより、サインインでのネガティブな体験の増加を抑えるためのアクションをいつ取るべきかがわかります。リクエストのスロットリングが続くことは、ユーザー認証で嫌な体験をするということです。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: 適切にプロビジョニングされたユーザープールでは、複数のデータポイントにまたがるスロットリングは発生しないはずです。そのため、予想されるワークロードの通常のしきい値はゼロでなければなりません。バーストが頻繁に発生する不規則なワークロードの場合は、履歴データを分析してアプリケーションのワークロードの許容可能なスロットリングを決定し、それに応じてしきい値を調整できます。スロットリングされたリクエストは、アプリケーションへの影響を最小限に抑えるために再試行する必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

TokenRefreshThrottles

ディメンション: UserPool、UserPoolClient

アラームの説明: しきい値は、リクエストのトラフィックに合わせて設定できるほか、トークン更新リクエストの許容可能なスロットリングに合わせて設定することもできます。スロットリングは、リクエストが多すぎる場合にシステムを保護するために使用されます。ただし、通常のトラフィックに対するプロビジョニングが不足していないかどうかもモニタリングすることが重要です。履歴データを分析してアプリケーションのワークロードの許容可能なスロットリングを確認し、アラームのしきい値が許容可能なスロットリングレベルよりも高くなるように調整できます。スロットリングされたリクエストは一時的なものなので、アプリケーション/サービス側で再試行する必要があります。そのため、しきい値が非常に低いと、アラームが敏感になる可能性があります。

目的: このアラームは、トークン更新リクエストのスロットリングの発生をモニタリングするのに役立ちます。これにより、問題が発生する可能性を軽減するためのアクションをいつ取るべきかがわかり、スムーズなユーザーエクスペリエンスと認証システムの健全性と信頼性を確保できます。リクエストのスロットリングが続くことは、ユーザー認証で嫌な体験をするということです。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: しきい値は、リクエストのトラフィックやトークン更新リクエストの許容可能なスロットリングに合わせて設定/調整することもできます。スロットリングは、リクエストが多すぎる場合にシステムを保護するためのものですが、通常のトラフィックに対するプロビジョニングが不足していないかをモニタリングし、影響の原因となっているかどうかを確認することが重要です。履歴データを分析してアプリケーションのワークロードの許容可能なスロットリングを確認し、しきい値が許容可能なスロットリングレベルよりも高くなるように調整することもできます。スロットリングされたリクエストは一時的なものなので、アプリケーション/サービス側で再試行する必要があります。そのため、しきい値が非常に低いと、アラームが敏感になる可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

FederationThrottles

ディメンション: UserPool、UserPoolClient、IdentityProvider

アラームの説明: このアラームは、スロットリングされた ID フェデレーションリクエストの数をモニタリングします。定常的にスロットリングがある場合は、サービスクォータの引き上げをリクエストして制限を引き上げる必要があることを示している可能性があります。クォータの引き上げをリクエストする方法については、「Amazon Cognito のクォータ」を参照してください。

目的: このアラームは、ID フェデレーションリクエストのスロットリングの発生をモニタリングするのに役立ちます。これにより、パフォーマンスのボトルネックや設定ミスに事前に対応し、ユーザーに認証がスムーズだと感じてもらうことができます。リクエストのスロットリングが続くことは、ユーザー認証で嫌な体験をするということです。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: しきい値は、リクエストのトラフィックに合わせて設定できるほか、ID フェデレーションリクエストの許容可能なスロットリングに合わせて設定することもできます。スロットリングは、リクエストが多すぎる場合にシステムを保護するために使用されます。ただし、通常のトラフィックに対するプロビジョニングが不足していないかどうかもモニタリングすることが重要です。履歴データを分析してアプリケーションワークロードの許容可能なスロットリングを確認し、しきい値を許容可能なスロットリングレベルを超える値に設定できます。スロットリングされたリクエストは一時的なものなので、アプリケーション/サービス側で再試行する必要があります。そのため、しきい値が非常に低いと、アラームが敏感になる可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Amazon DynamoDB

AccountProvisionedReadCapacityUtilization

ディメンション: なし

アラームの説明: このアラームは、アカウントの読み取り容量がプロビジョニングされた制限に達したかどうかを検出します。このような場合は、読み取り容量使用量のアカウントクォータを引き上げることができます。Service Quotas を使用して、読み取り容量ユニットの現在のクォータを表示し、引き上げをリクエストできます。

目的: このアラームは、アカウントの読み込み容量使用率がプロビジョニングされた読み取り容量使用率に近づいているかどうかを検出できます。使用率が上限に達すると、DynamoDB は読み取りリクエストのスロットリングを開始します。

統計: Maximum

推奨しきい値: 80.0

しきい値の根拠: スロットリングを回避するために、しきい値を 80% に設定して、容量が満杯になる前にアクション (アカウント制限の引き上げなど) を実行できるようにします。

期間: 300

アラームを発生させるデータポイント数: 2

評価期間数: 2

比較演算子: GREATER_THAN_THRESHOLD

AccountProvisionedWriteCapacityUtilization

ディメンション: なし

アラームの説明: このアラームは、アカウントの書き込み容量がプロビジョニングされた制限に達したかどうかを検出します。このような場合は、書き込み容量使用量のアカウントクォータを引き上げることができます。Service Quotas を使用して、書き込み容量ユニットの現在のクォータを表示し、引き上げをリクエストできます。

目的: このアラームは、アカウントの書き込み容量使用率がプロビジョニングされた書き込み容量使用率に近づいているかどうかを検出できます。使用率が上限に達すると、DynamoDB は書き込みリクエストのスロットリングを開始します。

統計: Maximum

推奨しきい値: 80.0

しきい値の根拠: スロットリングを回避するために、しきい値を 80% に設定して、容量が満杯になる前にアクション (アカウント制限の引き上げなど) を実行できるようにします。

期間: 300

アラームを発生させるデータポイント数: 2

評価期間数: 2

比較演算子: GREATER_THAN_THRESHOLD

AgeOfOldestUnreplicatedRecord

ディメンション: TableName、DelegatedOperation

アラームの説明: このアラームは、Kinesis データストリームへのレプリケーションの遅延を検出します。通常のオペレーションでは、AgeOfOldestUnreplicatedRecord は数ミリ秒にしかならないはずです。この数字は、顧客が管理する設定での選択が原因でレプリケーションを試行しても成功しなかった回数に基づいて増加します。顧客が管理する設定がレプリケーションの試行が失敗する原因になる例として、Kinesis データストリーム容量のプロビジョニングが不足していたために過剰なスロットリングにつながった場合や、Kinesis データストリームのアクセスポリシーを手動で更新したために DynamoDB がデータストリームにデータを追加できなくなった場合が挙げられます。このメトリクスを可能な限り低く保つために、Kinesis データストリーム容量を適切にプロビジョニングし、DynamoDB のアクセス許可が変更されていないことを確認する必要があります。

目的: このアラームは、レプリケーション試行の失敗と、その結果生じる Kinesis データストリームへのレプリケーションの遅延をモニタリングできます。

統計: Maximum

推奨しきい値: 状況によって異なります。

しきい値の根拠: 希望するレプリケーション遅延に従って、しきい値をミリ秒単位で設定してください。この値は、ワークロードの要件と期待されるパフォーマンスによって異なります。

期間: 300

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: GREATER_THAN_THRESHOLD

FailedToReplicateRecordCount

ディメンション: TableName、DelegatedOperation

アラームの説明: このアラームは、DynamoDB が Kinesis データストリームにレプリケートできなかったレコードの数を検出します。34 KB を超える特定の項目はサイズが拡張されて、Kinesis Data Streams の項目サイズ制限 1MB を超えるデータレコードが変更される場合があります。このサイズの拡張は、34 KB を超えるこれらの項目に多数のブール値や空の属性値が含まれる場合に発生します。ブール値と空の属性値は、DynamoDB に 1 バイトで格納されますが、Kinesis Data Streams レプリケーションで標準 JSON を使用してシリアル化すると、最大 5 バイトまで拡張されます。DynamoDB は、このような変更レコードを Kinesis データストリームにレプリケートできません。DynamoDB は、これらの変更データレコードをスキップし、後続のレコードを自動的にレプリケートします。

目的: このアラームは、Kinesis Data Streams のアイテムサイズ制限のために DynamoDB が Kinesis データストリームにレプリケートできなかったレコードの数をモニタリングできます。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: DynamoDB がレプリケートできなかったレコードをすべて検出するには、しきい値を 0 に設定します。

期間: 60

アラームを発生させるデータポイント数: 1

評価期間数: 1

比較演算子: GREATER_THAN_THRESHOLD

ReadThrottleEvents

ディメンション: TableName

アラームの説明: このアラームは、DynamoDB テーブルに対してスロットリングされている読み取りリクエストの数が多いかどうかを検出します。問題のトラブルシューティングについては、「Amazon DynamoDB でのスロットリングの問題のトラブルシューティング」を参照してください。

目的: このアラームは、DynamoDB テーブルへの読み取りリクエストの持続的なスロットリングを検出できます。読み取りリクエストのスロットリングが続くと、ワークロードの読み取りオペレーションに悪影響を及ぼし、システム全体の効率を低下させる可能性があります。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: スロットリングの許容レベルを考慮して、DynamoDB テーブルの予想読み取りトラフィックに応じてしきい値を設定します。プロビジョニングが不十分なために一貫したスロットリングが行われていないかどうかをモニタリングすることが重要です。履歴データを分析してアプリケーションのワークロードの許容可能なスロットリングレベルを確認し、しきい値が通常のスロットリングレベルよりも高くなるように調整することもできます。スロットリングされたリクエストは一時的なものなので、アプリケーション側またはサービス側で再試行する必要があります。そのため、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎて、望ましくない状態遷移が発生する可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

ReadThrottleEvents

ディメンション: TableName、GlobalSecondaryIndexName

アラームの説明: このアラームは、DynamoDB テーブルのグローバルセカンダリインデックスに対してスロットリングされている読み取りリクエストの数が多いかどうかを検出します。問題のトラブルシューティングについては、「Amazon DynamoDB でのスロットリングの問題のトラブルシューティング」を参照してください。

目的: このアラームは、DynamoDB テーブルのグローバルセカンダリインデックスへの読み取りリクエストの持続的なスロットリングを検出できます。読み取りリクエストのスロットリングが続くと、ワークロードの読み取りオペレーションに悪影響を及ぼし、システム全体の効率を低下させる可能性があります。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: スロットリングの許容レベルを考慮して、DynamoDB テーブルの予想読み取りトラフィックに応じてしきい値を設定します。プロビジョニングが不十分なために一貫したスロットリングが行われていないかどうかをモニタリングすることが重要です。履歴データを分析してアプリケーションのワークロードの許容可能なスロットリングレベルを確認し、しきい値が通常の許容可能なスロットリングレベルよりも高くなるように調整することもできます。スロットリングされたリクエストは一時的なものなので、アプリケーション側またはサービス側で再試行する必要があります。そのため、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎて、望ましくない状態遷移が発生する可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

ReplicationLatency

ディメンション: TableName、ReceivingRegion

アラームの説明: このアラームは、グローバルテーブルのリージョン内のレプリカがソースリージョンより遅れているかどうかを検出します。レイテンシーは、AWS リージョンのパフォーマンスが低下し、そのリージョンにレプリカテーブルが含まれる場合は増加することがあります。この場合、アプリケーションの読み込みおよび書き込みアクティビティを別の AWS リージョンに一時的にリダイレクトすることができます。グローバルテーブルの 2017.11.29 (レガシー) を使用している場合は、書き込み容量ユニット (WCU) が各レプリカテーブルについて同一であることを確認してください。また、「キャパシティを管理するためのベストプラクティスと要件」の推奨事項に必ず従ってください。

目的: このアラームは、あるリージョンのレプリカテーブルで別のリージョンからの変更のレプリケーションに遅延が発生しているかどうかを検出できます。これにより、使用しているレプリカが他のレプリカと異なる可能性があります。各 AWS リージョンのレプリケーションレイテンシーを把握し、そのレプリケーションレイテンシーが継続的に増加する場合はアラートを出すと便利です。テーブルのレプリケーションはグローバルテーブルにのみ適用されます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、ユースケースによって大きく異なります。通常、レプリケーションのレイテンシーが 3 分を超える場合は調査が必要です。レプリケーション遅延の重大性と要件を確認し、過去の傾向を分析し、それに応じてしきい値を選択します。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

SuccessfulRequestLatency

ディメンション: TableName、Operation

アラームの説明: このアラームは、DynamoDB テーブルオペレーション (アラームの Operation ディメンション値で示されます) のレイテンシーが大きいことを検出します。Amazon DynamoDB のレイテンシー問題のトラブルシューティングについては、このトラブルシューティングドキュメントを参照してください。

目的: このアラームは、DynamoDB テーブルオペレーションのレイテンシーが大きいことを検出できます。オペレーションのレイテンシーが大きくなると、システム全体の効率に悪影響を及ぼす可能性があります。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: DynamoDB では、GetItem や PutItem などのシングルトンオペレーションのレイテンシーは平均 1 桁のミリ秒です。ただし、ワークロードに関係するオペレーションの種類やテーブルについてのレイテンシーの許容範囲に基づいてしきい値を設定できます。このメトリクスの履歴データを分析してテーブルオペレーションの通常のレイテンシーを調べ、しきい値を、オペレーションの重大な遅延を表す数値に設定できます。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_THRESHOLD

SystemErrors

ディメンション: TableName

アラームの説明: このアラームは、DynamoDB テーブルリクエストのシステムエラーが継続的に多数発生していることを検出します。引き続き 5xx エラーが表示される場合は、AWS サービスヘルスダッシュボードを開いて、サービスの運用上の問題がないか確認してください。このアラームを使用すると、DynamoDB からの内部サービスの問題が長期にわたって発生した場合に通知を受け取ることができ、クライアントアプリケーションが直面している問題と関連付けるのに役立ちます。詳細については、「DynamoDB でのエラー処理」を参照してください。

目的: このアラームは、DynamoDB テーブルリクエストの持続的なシステムエラーを検出できます。システムエラーは、DynamoDB の内部サービスエラーを示し、クライアントが抱えている問題と関連付けるのに役立ちます。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: システムエラーの許容レベルを考慮して、予想されるトラフィックに応じてしきい値を設定します。また、履歴データを分析してアプリケーションワークロードの許容可能なエラー数を見つけ、それに応じてしきい値を調整することもできます。システムエラーは一時的なものなので、アプリケーション/サービス側で再試行する必要があります。そのため、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎて、望ましくない状態遷移が発生する可能性があります。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

ThrottledPutRecordCount

ディメンション: TableName、DelegatedOperation

アラームの説明: このアラームは、変更データキャプチャの Kinesis へのレプリケーションの際に Kinesis データストリームによってスロットリングされるレコードを検出します。このスロットリングは、Kinesis データストリームの容量が不十分であるために発生します。過剰で定期的なスロットリングが発生した場合は、テーブルで観測された書き込みスループットに比例して Kinesis ストリーミングシャードの数を増やす必要があります。Kinesis Data Streams のサイズ決定の詳細については、「Kinesis Data Streams の初期サイズの決定」を参照してください。

目的: このアラームは、Kinesis データストリームの容量が不足しているために、Kinesis データストリームによってスロットリングされたレコードの数をモニタリングできます。

統計: Maximum

推奨しきい値: 状況によって異なります。

しきい値の根拠: 例外的な使用率のピークではスロットリングが発生する可能性がありますが、スロットリングされるレコードを可能な限り少なくしてレプリケーションのレイテンシーを抑える必要があります (DynamoDB は、スロットリングされたレコードの Kinesis データストリームへの送信を再試行します)。しきい値には、過剰なスロットリングが定常的に発生していることを把握するのに役立つ数値を設定します。また、このメトリクスの履歴データを分析して、アプリケーションワークロードの許容可能なスロットリング率を調べることもできます。しきい値は、ユースケースに基づいてアプリケーションで許容可能な値に調整します。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_THRESHOLD

UserErrors

ディメンション: なし

アラームの説明: このアラームは、DynamoDB テーブルリクエストのユーザーエラーが継続的に多数発生していることを検出します。問題が発生している期間中にクライアントアプリケーションログをチェックして、リクエストが無効である理由を確認できます。HTTP ステータスコード 400 をチェックして発生しているエラーの種類を確認し、それに応じてアクションを実行できます。有効なリクエストを作成するには、アプリケーションロジックを修正しなければならない場合があります。

目的: このアラームは、DynamoDB テーブルリクエストの持続的なユーザーエラーを検出できます。リクエストされたオペレーションのユーザーエラーは、クライアントが無効なリクエストを生成していて失敗していることを意味します。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: クライアント側のエラーを検出するには、しきい値をゼロに設定します。一方、エラーの数が非常に少ない場合にはアラームがトリガーされないようにしたい場合は、この値をゼロより大きく設定することもできます。ユースケースとリクエストのトラフィックに基づいて決定します。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_THRESHOLD

WriteThrottleEvents

ディメンション: TableName

アラームの説明: このアラームは、DynamoDB テーブルに対してスロットリングされている書き込みリクエストの数が多いかどうかを検出します。問題のトラブルシューティングについては、「Amazon DynamoDB でのスロットリングの問題のトラブルシューティング」を参照してください。

目的: このアラームは、DynamoDB テーブルへの書き込みリクエストの持続的なスロットリングを検出できます。書き込みリクエストのスロットリングが続くと、ワークロードの書き込みオペレーションに悪影響を及ぼし、システム全体の効率を低下させる可能性があります。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: スロットリングの許容レベルを考慮して、DynamoDB テーブルの予想書き込みトラフィックに応じてしきい値を設定します。プロビジョニングが不十分なために一貫したスロットリングが行われていないかどうかをモニタリングすることが重要です。履歴データを分析してアプリケーションのワークロードの許容可能なスロットリングレベルを確認し、しきい値が通常の許容可能なスロットリングレベルよりも高い値に調整することもできます。スロットリングされたリクエストは一時的なものなので、アプリケーション/サービス側で再試行する必要があります。そのため、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎて、望ましくない状態遷移が発生する可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

WriteThrottleEvents

ディメンション: TableName、GlobalSecondaryIndexName

アラームの説明: このアラームは、DynamoDB テーブルのグローバルセカンダリインデックスに対してスロットリングされている書き込みリクエストの数が多いかどうかを検出します。問題のトラブルシューティングについては、「Amazon DynamoDB でのスロットリングの問題のトラブルシューティング」を参照してください。

目的: このアラームは、DynamoDB テーブルのグローバルセカンダリインデックスへの書き込みリクエストの持続的なスロットリングを検出できます。書き込みリクエストのスロットリングが続くと、ワークロードの書き込みオペレーションに悪影響を及ぼし、システム全体の効率を低下させる可能性があります。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: スロットリングの許容レベルを考慮して、DynamoDB テーブルの予想書き込みトラフィックに応じてしきい値を設定します。プロビジョニングが不十分なために一貫したスロットリングが行われていないかどうかをモニタリングすることが重要です。履歴データを分析してアプリケーションのワークロードの許容可能なスロットリングレベルを確認し、しきい値が通常の許容可能なスロットリングレベルよりも高い値に調整することもできます。スロットリングされたリクエストは一時的なものなので、アプリケーション/サービス側で再試行する必要があります。そのため、値を非常に低く設定すると、アラームの感度が高くなりすぎて、望ましくない状態遷移が発生する可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Amazon EBS

VolumeStalledIOCheck

ディメンション: VolumeId、InstanceId

アラームの説明: このアラームは、Amazon EBS ボリュームの IO パフォーマンスをモニタリングするのに役立ちます。このチェックは、Amazon EBS ボリュームの基盤となるストレージサブシステムのハードウェアまたはソフトウェアの問題、Amazon EC2 インスタンスからの Amazon EBS ボリュームの到達可能性に影響する物理ホストのハードウェアの問題など、Amazon EBS インフラストラクチャの根本的な問題を検出するほか、インスタンスと Amazon EBS ボリューム間の接続の問題も検出できます。Stalled IO Check が失敗した場合は、AWS が問題を解決するまで待つか、影響を受けたボリュームの置き換えやボリュームがアタッチされているインスタンスの停止および再起動などのアクションを実行することができます。ほとんどの場合、このメトリクスが失敗すると、Amazon EBS は数分以内にボリュームを自動的に診断して復元します。

目的: このアラームは、Amazon EBS ボリュームのステータスを検出して、これらのボリュームに障害が発生し、I/O 操作を完了できないタイミングを判断できます。

統計: Maximum

推奨しきい値: 1.0

しきい値の根拠: ステータスチェックが不合格になると、このメトリクスの値は 1 になります。しきい値は、ステータスチェックが不合格になるたびにアラームが ALARM 状態になるように設定されます。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Amazon EC2

CPUUtilization

ディメンション: InstanceId

アラームの説明: このアラームは EC2 インスタンスの CPU 使用率をモニタリングするのに役立ちます。アプリケーションによっては、使用率が定常的に高いことが普通かもしれません。しかし、パフォーマンスが低下し、アプリケーションがディスク I/O、メモリ、ネットワークリソースの制約を受けていない場合、CPU が上限に達しているということは、リソースのボトルネックやアプリケーションのパフォーマンス上の問題を示している可能性があります。CPU 使用率が高い場合は、CPU 集約度の高いインスタンスへのアップグレードが必要であることを示している可能性があります。詳細モニタリングが有効になっている場合は、この期間を 300 秒から 60 秒に変更できます。詳細については、「インスタンスの詳細モニタリングを有効または無効にする」を参照してください。

目的: このアラームは CPU 使用率が高いことを検出するために使用されます。

統計: Average

推奨しきい値: 80.0

しきい値の根拠: 通常、CPU 使用率のしきい値は 70～80% に設定できます。ただし、許容できるパフォーマンスレベルとワークロード特性に基づいてこの値を調整できます。システムによっては、CPU 使用率が定常的に高いことが正常で問題がない場合もあれば、懸念される事態の原因となる場合もあります。CPU 使用率の履歴データを分析して使用状況を特定し、システムにとって許容できる CPU 使用率を確認し、それに応じてしきい値を設定します。

期間: 300

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: GREATER_THAN_THRESHOLD

StatusCheckFailed

ディメンション: InstanceId

アラームの説明: このアラームは、システムステータスチェックとインスタンスステータスチェックの両方のモニタリングに役立ちます。いずれかのタイプのステータスチェックが不合格の場合、このアラームは ALARM 状態になります。

目的: このアラームは、システムステータスチェックエラーとインスタンスステータスチェックエラーの両方を含む、インスタンスの根本的な問題を検出するために使用されます。

統計: Maximum

推奨しきい値: 1.0

しきい値の根拠: ステータスチェックが不合格になると、このメトリクスの値は 1 になります。しきい値は、ステータスチェックが不合格になるたびにアラームが ALARM 状態になるように設定されます。

期間: 300

アラームを発生させるデータポイント数: 2

評価期間数: 2

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

StatusCheckFailed_AttachedEBS

ディメンション: InstanceId

アラームの説明: このアラームは、インスタンスにアタッチされている Amazon EBS ボリュームに到達可能かどうか、および I/O 操作を完了できるかどうかをモニタリングするのに役立ちます。このステータスチェックでは、コンピューティングまたは Amazon EBS インフラストラクチャに関する次のような根本的な問題が検出されます。

• Amazon EBS ボリュームの基盤となるストレージサブシステムのハードウェアまたはソフトウェアの問題

• Amazon EBS ボリュームの到達可能性に影響する、物理ホスト上のハードウェアの問題

• インスタンスと Amazon EBS ボリューム間の接続に関する問題

アタッチ済みの EBS ステータスチェックが失敗した場合は、Amazon が問題を解決するまで待つか、影響を受けたボリュームの置き換えやインスタンスの停止および再起動などのアクションを取ることができます。

目的: このアラームは、インスタンスにアタッチされた到達不能な Amazon EBS ボリュームを検出するために使用されます。これにより、I/O 操作が失敗する可能性があります。

統計: Maximum

推奨しきい値: 1.0

しきい値の根拠: ステータスチェックが不合格になると、このメトリクスの値は 1 になります。しきい値は、ステータスチェックが不合格になるたびにアラームが ALARM 状態になるように設定されます。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Amazon ElastiCache

CPUUtilization

ディメンション: CacheClusterId、CacheNodeId

アラームの説明: このアラームは、データベースエンジンプロセスやインスタンスで実行されている他のプロセスを含む、ElastiCache インスタンス全体の CPU 使用率のモニタリングに役立ちます。AWSElastiCache は、Memcached と Redis の 2 つのエンジンタイプをサポートしています。Memcached ノードの CPU 使用率が高くなったら、インスタンスタイプをスケールアップするか、新しいキャッシュノードを追加することを検討する必要があります。Redis の場合、主なワークロードが読み取りリクエストによるものである場合は、キャッシュクラスターにリードレプリカをさらに追加することを検討する必要があります。主なワークロードが書き込みリクエストによるものである場合、クラスターモードで実行している場合はシャードを追加してワークロードをより多くのプライマリノードに分散することを検討し、Redis を非クラスターモードで実行している場合はインスタンスタイプをスケールアップすることを検討する必要があります。

目的: このアラームは ElastiCache ホストの CPU 使用率が高いことを検出するために使用されます。エンジン以外のプロセスを含め、インスタンス全体の CPU 使用率を幅広く把握できると便利です。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: アプリケーションの CPU 使用率の限界レベルを反映するパーセンテージにしきい値を設定します。Memcached の場合、エンジンは最大 num_threads の個数のコアを使用できます。Redis の場合、エンジンは主にシングルスレッドですが、可能な場合は I/O を高速化するために追加のコアを使用する場合があり、ほとんどの場合、しきい値は使用可能な CPU の約 90% に設定できます。Redis はシングルスレットであるため、実際のしきい値はノードの総容量の割合として計算します。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

CurrConnections

ディメンション: CacheClusterId、CacheNodeId

アラームの説明: このアラームは接続数が多いことを検出します。これは、負荷が高いか、パフォーマンスに問題があることを示している可能性があります。CurrConnections が絶えず増加すると、使用可能な 65,000 の接続を使い果たす可能性があります。アプリケーション側で接続が不適切に閉じられ、サーバー側で確立されたままになっている可能性があります。接続プールまたはアイドル接続タイムアウトを使用してクラスターへの接続数を制限することを検討してください。また、Redis の場合は、クラスターの tcp-keepalive をチューニングして、使用できなくなった可能性のあるピアを検出して終了することを検討してください。

目的: このアラームは、ElastiCache クラスターのパフォーマンスと安定性に影響を与える可能性のある接続数が多い状況を特定するのに役立ちます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、クラスターの接続の許容範囲によって大きく異なります。ElastiCache クラスターの容量と予想されるワークロードを確認し、通常使用中の接続数の履歴を分析してベースラインを確立し、それに応じてしきい値を選択します。各ノードは最大 65,000 しか同時に接続をサポートできないことに注意してください。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_THRESHOLD

DatabaseMemoryUsagePercentage

ディメンション: CacheClusterId

アラームの説明: このアラームは、クラスターのメモリ使用率をモニタリングするのに役立ちます。DatabaseMemoryUsagePercentage が 100% に達すると、Redis maxmemory ポリシーがトリガーされ、選択したポリシーに基づいてエビクションが行われることがあります。キャッシュ内のオブジェクトでエビクションポリシーに一致するものがない場合、書き込みオペレーションは失敗します。一部のワークロードはエビクションを想定していたり、エビクションに依存していたりしますが、エビクションがない場合は、クラスターのメモリ容量を増やす必要があります。プライマリノードを追加してクラスターをスケールアウトすることも、より大きなノードタイプを使用してクラスターをスケールアップすることもできます。詳細については、「ElastiCache for Redis クラスターのスケーリング」を参照してください。

目的: このアラームは、クラスターのメモリ使用率が高いことを検出し、クラスターへの書き込み時に障害が発生するのを防ぐために使用されます。アプリケーションでエビクションが発生しないことが予想される場合、クラスターをスケールアップする必要があるタイミングがわかると便利です。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: アプリケーションのメモリ要件と ElastiCache クラスターのメモリ容量に応じて、クラスターのメモリ使用量の限界レベルを反映するパーセンテージにしきい値を設定する必要があります。メモリ使用量の履歴データを参照して、許容可能なメモリ使用量のしきい値を求めることができます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

EngineCPUUtilization

ディメンション: CacheClusterId

アラームの説明: このアラームは ElastiCache インスタンス内の Redis エンジンスレッドの CPU 使用率をモニタリングするのに役立ちます。エンジン CPU 使用率が高くなる一般的な理由としては、長時間実行されるコマンドで高い CPU 使用率が消費されること、多数のリクエスト、短期間での新しいクライアント接続リクエストの増加、キャッシュに新しいデータを保持するための十分なメモリがない場合のエビクションの多さなどが挙げられます。ノードを追加するか、インスタンスタイプをスケールアップして ElastiCache for Redis クラスターのスケーリングをすることを検討してください。

目的: このアラームは Redis エンジンスレッドの CPU 使用率が高いことを検出するために使用されます。データベースエンジン自体の CPU 使用率をモニタリングしたい場合に便利です。

統計: Average

推奨しきい値: 90.0

しきい値の根拠: アプリケーションのエンジン CPU 使用率の限界レベルを反映するパーセンテージにしきい値を設定します。アプリケーションと想定されるワークロードを使用してクラスターのベンチマークを行い、EngineCPUUtilization を基準となるパフォーマンスと相関させ、それに応じてしきい値を設定できます。ほとんどの場合、しきい値は使用可能な CPU の約 90% に設定できます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

ReplicationLag

ディメンション: CacheClusterId

アラームの説明: このアラームは、ElastiCache クラスターのレプリケーションの健全性をモニタリングするのに役立ちます。レプリケーションの遅延が大きいということは、プライマリノードまたはレプリカがレプリケーションのペースに追いついていないということです。書き込みアクティビティが多すぎる場合は、プライマリノードを追加してクラスターをスケールアウトするか、より大きなノードタイプを使用してクラスターをスケールアップすることを検討してください。詳細については、「ElastiCache for Redis クラスターのスケーリング」を参照してください。リードレプリカが読み取りリクエストの量によって過負荷になっている場合は、リードレプリカをさらに追加することを検討してください。

目的: このアラームは、プライマリノードでのデータ更新とレプリカノードへの同期の間の遅延を検出するために使用されます。リードレプリカクラスターノードのデータ整合性を確保するのに役立ちます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: アプリケーションの要件とレプリケーション遅延の潜在的な影響に応じてしきい値を設定してください。許容できるレプリケーション遅延については、アプリケーションの予想書き込み速度とネットワークの状態を考慮する必要があります。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

Amazon EC2 (AWS/ElasticGPUs)

GPUConnectivityCheckFailed

ディメンション: InstanceId、EGPUId

アラームの説明: このアラームは、インスタンスと Elastic Graphics アクセラレータ間の接続障害を検出するのに役立ちます。Elastic Graphics は、インスタンスネットワークを使用してリモートでアタッチされたグラフィックカードに OpenGL コマンドを送信します。また、Elastic Graphics アクセラレータで OpenGL アプリケーションを実行しているデスクトップは通常、リモートアクセステクノロジーを使用してアクセスされます。OpenGL レンダリングに関連するパフォーマンスの問題とデスクトップのリモートアクセステクノロジーを区別することは重要です。この問題の詳細については、「アプリケーションのパフォーマンス問題の調査」を参照してください。

目的: このアラームは、インスタンスから Elastic Graphics アクセラレータへの接続の問題を検出するために使用されます。

統計: Maximum

推奨しきい値: 0.0

しきい値の根拠: しきい値が 1 の場合は、接続に障害が発生したことを示します。

期間: 300

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: GREATER_THAN_THRESHOLD

GPUHealthCheckFailed

ディメンション: InstanceId、EGPUId

アラームの説明: このアラームは、Elastic Graphics アクセラレータのステータスに異常があることを知るのに役立ちます。アクセラレータが正常でない場合は、「異常状態の問題の解決」のトラブルシューティング手順を参照してください。

目的: このアラームは、Elastic Graphics アクセラレータが正常でないかどうかを検出するために使用されます。

統計: Maximum

推奨しきい値: 0.0

しきい値の根拠: しきい値が 1 の場合、ステータスチェックが不合格であることを示します。

期間: 300

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: GREATER_THAN_THRESHOLD

Amazon ECS

CPUReservation

ディメンション: ClusterName

アラームの説明: このアラームは、ECS クラスターの CPU 予約率が高いことを検出するのに役立ちます。CPU 予約率が高い場合は、そのタスク用に登録されている CPU がクラスターに不足している可能性があります。トラブルシューティングのために、容量を追加したり、クラスターをスケールしたり、自動スケーリングを設定したりできます。

目的: このアラームは、クラスター上のタスクによって予約されている CPU ユニットの総数が、クラスターに登録されている CPU ユニットの総数に達しようとしているかどうかを検出するために使用されます。これにより、クラスターをいつスケールアップすべきかがわかります。クラスターの CPU ユニットの合計に達すると、タスクの CPU が不足する可能性があります。EC2 キャパシティプロバイダーのマネージドスケーリングをオンにしている場合、またはキャパシティプロバイダーに Fargate を関連付けている場合、このアラームはお勧めしません。

統計: Average

推奨しきい値: 90.0

しきい値の根拠: CPU 予約のしきい値を 90% に設定します。ただし、クラスターの特性に基づいて、それより低い値を選択できます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

CPUUtilization

ディメンション: ClusterName、ServiceName

アラームの説明: このアラームは、ECS サービスの CPU 使用率が高いことを検出するのに役立ちます。ECS のデプロイが進行中でない場合、CPU 使用率が上限に達していると、リソースのボトルネックやアプリケーションのパフォーマンス問題を示している可能性があります。トラブルシューティングのために、CPU 上限を増やすことができます。

目的: このアラームは ECS サービスの CPU 使用率が高いことを検出するために使用されます。CPU 使用率が定常的に高い場合は、リソースのボトルネックやアプリケーションのパフォーマンス問題を示している可能性があります。

統計: Average

推奨しきい値: 90.0

しきい値の根拠: CPU 使用率のサービスメトリクスは 100% の使用率を超える可能性があります。ただし、他のサービスに影響が出ないように、サービスメトリクスの CPU 使用率をモニタリングすることをお勧めします。しきい値は約 90～95% に設定します。他のサービスで今後問題が発生しないように、実際の使用状況を反映するようにタスク定義を更新することをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

MemoryReservation

ディメンション: ClusterName

アラームの説明: このアラームは、ECS クラスターのメモリ予約率が高いことを検出するのに役立ちます。メモリ予約率が高い場合は、クラスターのリソースボトルネックを示している可能性があります。トラブルシューティングを行うには、サービスタスクのパフォーマンスを分析して、タスクのメモリ使用率を最適化できるかどうかを確認します。また、より多くのメモリを登録したり、自動スケーリングを設定したりできます。

目的: このアラームは、クラスター上のタスクによって予約されているメモリユニットの合計が、クラスターに登録されているメモリユニットの合計に達しようとしているかどうかを検出するために使用されます。これにより、クラスターをいつスケールアップすべきかがわかります。クラスターの合計メモリユニット数に達すると、クラスターは新しいタスクを起動できなくなる可能性があります。EC2 キャパシティプロバイダーのマネージドスケーリングをオンにしている場合、またはキャパシティプロバイダーに Fargate を関連付けている場合、このアラームはお勧めしません。

統計: Average

推奨しきい値: 90.0

しきい値の根拠: メモリ予約のしきい値を 90% に設定します。これは、クラスターの特性に基づいて、それより低い値に調整できます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

HTTPCode_Target_5XX_Count

ディメンション: ClusterName、ServiceName

アラームの説明: このアラームは、ECS サービスのサーバー側エラー数が多いことを検出するのに役立ちます。これは、サーバーがリクエストを処理できない原因となるエラーがあることを示している可能性があります。トラブルシューティングを行うには、アプリケーションログを確認してください。

目的: このアラームは、ECS サービスのサーバー側エラー数が多いことを検出するために使用されます。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: 平均トラフィックの約 5% の値を計算し、この値をしきい値の初期値として使用します。平均トラフィックは、RequestCount メトリクスを使用して求めることができます。また、履歴データを分析してアプリケーションワークロードの許容エラー発生率を判断し、それに応じてしきい値を調整することもできます。頻繁に発生する 5XX エラーにはアラームが必要です。ただし、しきい値を非常に低く設定すると、アラームの感度が高くなりすぎる可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

TargetResponseTime

ディメンション: ClusterName、ServiceName

アラームの説明: このアラームは、ECS サービスリクエストのターゲット応答時間が長いことを検出するのに役立ちます。これは、サービスがリクエストを時間通りに処理できない原因となる問題があることを示している可能性があります。トラブルシューティングを行うには、CPUUtilization メトリクスをチェックしてサービスの CPU が不足していないかどうかを確認するか、サービスが依存する他のダウンストリームサービスの CPU 使用率をチェックします。

目的: このアラームは、ECS サービスリクエストのターゲット応答時間が長いことを検出するために使用されます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、ユースケースによって大きく異なります。サービスのターゲット応答時間の重要度と要件を確認し、このメトリクスの過去の動作を分析して、適切なしきい値レベルを決定します。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Container Insights を使用する Amazon ECS

EphemeralStorageUtilized

ディメンション: ClusterName、ServiceName

アラームの説明: このアラームは、Fargate クラスターのエフェメラルストレージの使用率が高いことを検出するのに役立ちます。エフェメラルストレージの使用率が常に高い場合は、エフェメラルストレージの使用状況を確認して、エフェメラルストレージを増やすことができます。

目的: このアラームは、Fargate クラスターのエフェメラルストレージ使用率が高いことを検出するために使用されます。エフェメラルストレージの使用率が高い状態が続くと、ディスクがいっぱいになり、コンテナに障害が発生する可能性があります。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: しきい値をエフェメラルストレージサイズの約 90% に設定します。この値は、Fargate クラスターの許容可能なエフェメラルストレージ使用率に基づいて調整できます。一部のシステムでは、エフェメラルストレージの使用率が常に高いことが正常である場合もあれば、コンテナの障害につながる場合もあります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

RunningTaskCount

ディメンション: ClusterName、ServiceName

アラームの説明: このアラームは、ECS サービスの実行中のタスク数が少ないことを検出するのに役立ちます。実行中のタスク数が少なすぎる場合は、アプリケーションがサービスの負荷を処理できず、パフォーマンスの問題が発生する可能性があります。実行中のタスクがない場合は、Amazon ECS サービスが利用できないか、デプロイに問題がある可能性があります。

目的: このアラームは、実行中のタスクの数が少なすぎるかどうかを検出するために使用されます。実行中のタスク数が常に少ない場合は、ECS サービスのデプロイやパフォーマンスに問題がある可能性があります。

統計: Average

推奨しきい値: 0.0

しきい値の根拠: ECS サービスの実行中の最小タスク数に基づいてしきい値を調整できます。実行中のタスク数が 0 の場合、Amazon ECS サービスは利用できません。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: LESS_THAN_OR_EQUAL_TO_THRESHOLD

instance_filesystem_utilization

ディメンション: InstanceId、ContainerInstanceId、ClusterName

アラームの説明: このアラームは、ECS クラスターのファイルシステムの使用率が高いことを検出するのに役立ちます。ファイルシステムの使用率が常に高い場合は、ディスク使用量を確認してください。

目的: このアラームは、Amazon ECS クラスターのファイルシステムの使用率が高いことを検出するために使用されます。ファイルシステムの使用率が常に高い場合は、リソースのボトルネックやアプリケーションのパフォーマンスの問題が発生している可能性があり、新しいタスクを実行できなくなる可能性があります。

統計: Average

推奨しきい値: 90.0

しきい値の根拠: ファイルシステム使用率のしきい値は約 90～95% に設定できます。この値は、Amazon ECS クラスターの許容可能なファイルシステム容量レベルに基づいて調整できます。一部のシステムでは、ファイルシステムの使用率が常に高いことが正常で問題がない場合もあれば、他のシステムでは、懸念される事態の原因となり、パフォーマンスの問題が発生して、新しいタスクを実行できなくなる場合もあります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Amazon EFS

PercentIOLimit

ディメンション: FileSystemId

アラームの説明: このアラームは、ワークロードがファイルシステムで利用可能な I/O 制限内に収まるようにするのに役立ちます。メトリクスが定常的に I/O 上限に達している場合は、モードとして Max I/O を使用するファイルシステムにアプリケーションを移動することを検討してください。トラブルシューティングのため、ファイルシステムに接続しているクライアントと、ファイルシステムをスロットリングしているクライアントのアプリケーションを確認します。

目的: このアラームは、ファイルシステムが汎用パフォーマンスモードの I/O 制限にどれだけ近づいているかを検出するのに使用されます。I/O の割合が定常的に高いということは、I/O 要求に対してファイルシステムを十分にスケールできないことを示している可能性があり、ファイルシステムを使用するアプリケーションにとってファイルシステムがリソースのボトルネックになる可能性があります。

統計: Average

推奨しきい値: 100.0

しきい値の根拠: ファイルシステムが I/O の上限に達すると、読み取りリクエストや書き込みリクエストへの応答が遅くなる可能性があります。そのため、ファイルシステムを使用するアプリケーションに影響を与えないように、メトリクスをモニタリングすることをお勧めします。しきい値は 100% 程度に設定できます。ただし、この値はファイルシステムの特性に基づいてそれより低い値に調整できます。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

BurstCreditBalance

ディメンション: FileSystemId

アラームの説明: このアラームは、ファイルシステムの使用に対するバーストクレジットバランスがあることを確認するのに役立ちます。使用可能なバーストクレジットがない場合、スループットが低下するため、ファイルシステムへのアプリケーションのアクセスが制限されます。メトリクスが定常的に 0 に低下する場合は、スループットモードをエラスティックスループットモードまたはプロビジョンドスループットモードに変更することを検討してください。

目的: このアラームは、ファイルシステムのバーストクレジットバランスが少ないことを検出するために使用されます。バーストクレジットバランスが定常的に低いことは、スループットの低下と I/O レイテンシーの増加を示している可能性があります。

統計: Average

推奨しきい値: 0.0

しきい値の根拠: ファイルシステムがバーストクレジットを使い果たすと、ベースラインスループットレートが低くても、EFS はすべてのファイルシステムに対して 1 MiBps の従量制スループットを提供し続けます。ただし、ファイルシステムがアプリケーションのリソースボトルネックになるのを避けるため、バーストクレジットバランスが低いかどうかメトリクスをモニタリングすることをお勧めします。しきい値は 0 バイト程度に設定できます。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: LESS_THAN_OR_EQUAL_TO_THRESHOLD

Container Insights を使用する Amazon EKS

node_cpu_utilization

ディメンション: ClusterName

アラームの説明: このアラームは、EKS クラスターのワーカーノードの CPU 使用率が高いことを検出するのに役立ちます。使用率が定常的に高い場合は、ワーカーノードを CPU の大きいインスタンスに置き換えるか、システムを水平的にスケールする必要があることを示している可能性があります。

目的: このアラームは、EKS クラスター内のワーカーノードの CPU 使用率をモニタリングして、システムパフォーマンスが低下しないようにするのに役立ちます。

統計: Maximum

推奨しきい値: 80.0

しきい値の根拠: システムに影響が出始める前に問題をデバッグするのに十分な時間を確保するために、しきい値を 80% 以下に設定することをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

node_filesystem_utilization

ディメンション: ClusterName

アラームの説明: このアラームは、EKS クラスターのワーカーノードでファイルシステムの使用率が高いことを検出するのに役立ちます。使用率が定常的に高い場合は、ワーカーノードを更新してディスクボリュームを大きくするか、水平的にスケールする必要があることを示している可能性があります。

目的: このアラームは、EKS クラスター内のワーカーノードのファイルシステムの使用率をモニタリングするのに役立ちます。使用率が 100% に達すると、アプリケーション障害、ディスク I/O のボトルネック、ポッドエビクション、またはノードの完全無応答が発生する可能性があります。

統計: Maximum

推奨しきい値: 状況によって異なります。

しきい値の根拠: 十分なディスク負荷がかかっている (つまり、ディスクがいっぱいになっている) 場合、ノードは正常ではないとマークされ、ポッドはノードからエビクションされます。利用可能なファイルシステムが kubelet に設定されたエビクションのしきい値を下回ると、ディスク負荷がかかっているノード上のポッドはエビクションされます。アラームのしきい値を設定して、ノードがクラスターからエビクションされる前に対応する時間が十分にあるようにします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

node_memory_utilization

ディメンション: ClusterName

アラームの説明: このアラームは、EKS クラスターのワーカーノードのメモリ使用率が高いことを検出するのに役立ちます。使用率が定常的に高い場合は、ポッドレプリカの数をスケールするか、アプリケーションを最適化する必要があることを示している可能性があります。

目的: このアラームは、EKS クラスター内のワーカーノードのメモリ使用率をモニタリングして、システムパフォーマンスが低下しないようにするのに役立ちます。

統計: Maximum

推奨しきい値: 80.0

しきい値の根拠: システムに影響が出始める前に問題をデバッグするのに十分な時間を確保するために、しきい値を 80% 以下に設定することをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

pod_cpu_utilization_over_pod_limit

ディメンション: ClusterName、Namespace、Service

アラームの説明: このアラームは、EKS クラスターのポッドの CPU 使用率が高いことを検出するのに役立ちます。使用率が定常的に高い場合は、影響を受けるポッドの CPU 上限を増やす必要があることを示している可能性があります。

目的: このアラームは、EKS クラスター内の Kubernetes Service に属するポッドの CPU 使用率をモニタリングするのに役立ちます。これにより、サービスのポッドが CPU を予想より多く消費しているかどうかをすばやく特定できます。

統計: Maximum

推奨しきい値: 80.0

しきい値の根拠: システムに影響が出始める前に問題をデバッグするのに十分な時間を確保するために、しきい値を 80% 以下に設定することをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

pod_memory_utilization_over_pod_limit

ディメンション: ClusterName、Namespace、Service

アラームの説明: このアラームは、EKS クラスターのポッドのメモリ使用率が高いことを検出するのに役立ちます。使用率が定常的に高い場合は、影響を受けるポッドのメモリ上限を増やす必要があることを示している可能性があります。

目的: このアラームは、EKS クラスター内のポッドのメモリ使用率をモニタリングして、システムパフォーマンスが低下しないようにするのに役立ちます。

統計: Maximum

推奨しきい値: 80.0

しきい値の根拠: システムに影響が出始める前に問題をデバッグするのに十分な時間を確保するために、しきい値を 80% 以下に設定することをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Amazon Kinesis Data Streams

GetRecords.IteratorAgeMilliseconds

ディメンション: StreamName

アラームの説明: このアラームは、イテレータの最大存続期間が長すぎるかどうかを検出できます。リアルタイムデータ処理アプリケーションでは、遅延の許容度に従ってデータ保持を設定します。通常は数分以内です。履歴データを処理するアプリケーションでは、このメトリクスを使用してキャッチアップ速度をモニタリングします。問題のトラブルシューティングを行う間、データ損失を防ぐ手っ取り早い解決策は、保存期間を長くすることです。また、コンシューマーアプリケーションのレコードを処理するワーカーの数を増やすこともできます。イテレータの存続期間がしだいに増加する一般的な原因は、物理リソースの不足またはストリームスループットの上昇に応じてレコード処理ロジックがスケールされていないことです。詳細については、リンクを参照してください。

目的: このアラームは、ストリーム内のデータが、保存期間が長すぎるかレコード処理が遅すぎるために期限切れになるかどうかを検出するために使用されます。ストリームの保持期間が 100% に達した後のデータ損失を防ぐのに役立ちます。

統計: Maximum

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、ストリームの保持期間とレコードの処理遅延の許容度に大きく依存します。要件を確認して過去の傾向を分析し、しきい値を重大な処理遅延を表すミリ秒単位の数値に設定します。イテレータの存続期間が保持期間 (デフォルトで 24 時間、最大で 365 日まで設定可能) の 50% を経過すると、レコードの有効期限切れによるデータ損失のリスクがあります。メトリクスをモニタリングして、どのシャードもこの制限に接近したことがないことを確認できます。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

GetRecords.Success

ディメンション: StreamName

アラームの説明: このメトリクスは、コンシューマーがストリームからデータを正常に読み取るたびに増加します。GetRecords は、例外をスローすると、データを何も返しません。最もよくある例外は ProvisionedThroughputExceededException です。ストリームのリクエストレートが高すぎることや、利用可能なスループットが既に一定の秒数供給されてしまったことが原因です。リクエストの頻度またはサイズを少なくします。詳細については、「Amazon Kinesis Data Streams デベロッパーガイド」の「制限」と、「AWS でのエラー再試行とエクスポネンシャルバックオフ」を参照してください。

目的: このアラームは、コンシューマーによるストリームからのレコードの取得が失敗したかどうかを検出できます。このメトリクスにアラームを設定することで、エラー率の上昇や取得の成功率の低下など、データ消費に関する問題を事前に検出できます。これにより、潜在的な問題を解決し、円滑なデータ処理パイプラインを維持するためのアクションをタイムリーに実行できます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: ストリームからレコードを取得することの重要性に応じて、失敗したレコードに対するアプリケーションの許容度に基づいてしきい値を設定します。しきい値は、その許容度に対応する成功オペレーションの割合にする必要があります。GetRecords の過去のメトリクスデータを許容可能な失敗率のリファレンスとして使用できます。また、失敗したレコードは再試行できるため、しきい値を設定する際には再試行も考慮する必要があります。これにより、一時的なスパイクによって不要なアラートがトリガーされるのを防ぐことができます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: LESS_THAN_THRESHOLD

PutRecord.Success

ディメンション: StreamName

アラームの説明: このアラームは、失敗した PutRecord オペレーションの数がしきい値を超えたことを検出します。データプロデューサーのログを調べて、失敗の根本原因を見つけます。最もよくある理由は、ProvisionedThroughputExceededException の原因となったシャードのプロビジョニングされたスループットが不十分であることです。これは、ストリームのリクエストレートが高すぎるか、シャードに取り込もうとしたスループットが高すぎることが原因です。リクエストの頻度またはサイズを少なくします。詳細については、「制限」と「AWS でのエラーの再試行とエクスポネンシャルバックオフ」を参照してください。

目的: このアラームは、ストリームへのレコードの取り込みが失敗しているかどうかを検出できます。ストリームにデータを書き込む際の問題を特定するのに役立ちます。このメトリクスにアラームを設定することで、エラー率の上昇や公開に成功したレコードの減少など、ストリームにデータを公開する際にプロデューサーが抱える問題を事前に検出できます。これにより、潜在的な問題に対処し、信頼性の高いデータインジェストプロセスを維持するためのアクションをタイムリーに実行できます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: サービスへのデータインジェストと処理の重要性に応じて、失敗したレコードに対するアプリケーションの許容度に基づいてしきい値を設定します。しきい値は、その許容度に対応する成功オペレーションの割合にする必要があります。PutRecord の過去のメトリクスデータを許容可能な失敗率のリファレンスとして使用できます。また、失敗したレコードは再試行できるため、しきい値を設定する際には再試行も考慮する必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: LESS_THAN_THRESHOLD

PutRecords.FailedRecords

ディメンション: StreamName

アラームの説明: このアラームは、失敗した PutRecords の数がしきい値を超えたことを検出します。Kinesis Data Streams は、各 PutRecords リクエストのすべてのレコードを処理しようとしますが、1 つのレコードに失敗が発生しても後続のレコードの処理は停止しません。これらの失敗の主な理由は、ストリームまたは個々のシャードのスループットを超えていることです。よくある原因としては、レコードがストリームに不均等に届く原因となるトラフィックスパイクやネットワーク遅延があります。正常に処理されなかったレコードを検出し、それ以降の呼び出しで再試行する必要があります。詳細については、「PutRecords を使用するときのエラーの処理」を参照してください。

目的: このアラームは、バッチオペレーションを使用してストリームにレコードを追加する際に定常的に発生するエラーを検出できます。このメトリクスにアラームを設定することで、失敗したレコードの増加を事前に検出できるため、根本的な問題に対処するためのアクションをタイムリーに実行し、円滑で信頼性の高いデータインジェストプロセスを確保できます。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: 失敗したレコードに対するアプリケーションの許容度を反映して、失敗したレコード数のしきい値を設定します。過去のデータを許容可能な失敗の値のリファレンスとして使用できます。また、失敗したレコードは後続の PutRecords 呼び出しで再試行できるため、しきい値を設定する際には再試行も考慮する必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

ReadProvisionedThroughputExceeded

ディメンション: StreamName

アラームの説明: このアラームは、読み取りスループットキャパシティのスロットリングの原因となったレコードの数を追跡します。定常的にスロットリングされていることがわかった場合は、ストリームにシャードを追加して、プロビジョニングされた読み取りスループットを増やすことを検討してください。ストリーム上で実行されているコンシューマーアプリケーションが複数あり、それらが GetRecords 制限を共有している場合は、Enhanced Fan-Out を使用して新しいコンシューマーアプリケーションを登録することをお勧めします。シャードを追加してもスロットリングの数が減らない場合は、他のシャードよりも多くの読み取りを受けている「ホット」シャードがある可能性があります。拡張モニタリングを有効にし、「ホット」シャードを見つけて分割します。

目的: このアラームは、コンシューマーがプロビジョニングされた読み取りスループット (所有するシャードの数によって決まる) を超えたときに、コンシューマーがスロットリングされているかどうかを検出できます。その場合、ストリームからの読み取りはできず、ストリームはバックアップを開始する可能性があります。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: 通常、スロットリングされたリクエストは再試行できるため、しきい値を 0 に設定するとアラームの感度が高くなりすぎます。ただし、定常的なスロットリングは、ストリームからの読み取りに影響する可能性があるため、アラームをトリガーする必要があります。アプリケーションのスロットリングされたリクエストに応じた割合にしきい値を設定し、設定を再試行します。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

SubscribeToShardEvent.MillisBehindLatest

ディメンション: StreamName、ConsumerName

アラームの説明: このアラームは、アプリケーションのレコード処理の遅延がしきい値を超えたことを検出します。ダウンストリームのアプリケーションで API オペレーションが失敗するなどの一時的な問題により、メトリクスが突然増加する可能性があります。定常的に発生しているかどうかを調査する必要があります。よくある原因は、物理リソースの不足や、レコード処理ロジックがストリームスループットの増加に伴ってスケールしなかったために、コンシューマーがレコードを十分な速度で処理していないことです。クリティカルパス内の呼び出しをブロックすることが、レコード処理の速度低下の原因となることがよくあります。シャードの数を増やして並列処理を増やすことができます。また、需要のピーク時には、基盤となる処理ノードに十分な物理リソースがあることを確認する必要もあります。

目的: このアラームは、ストリームのシャードイベントへのサブスクリプションの遅延を検出できます。これは処理遅延を示しており、コンシューマーアプリケーションのパフォーマンスやストリーム全体の健全性に関する潜在的な問題を特定するのに役立ちます。処理遅延が顕著になった場合は、ボトルネックやコンシューマーアプリケーションの非効率性を調査して対処し、リアルタイムのデータ処理を確保し、データバックログを最小限に抑える必要があります。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、アプリケーションで許容できる遅延によって大きく異なります。アプリケーションの要件を確認して過去の傾向を分析し、それに応じてしきい値を選択します。SubscribeToShard 呼び出しが成功すると、コンシューマーは持続的接続を介して最大 5 分間の SubscribeToShardEvent イベントの受信を開始します。その後、レコードを引き続き受信したい場合は、SubscribeToShard を再度呼び出してサブスクリプションを更新する必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

WriteProvisionedThroughputExceeded

ディメンション: StreamName

アラームの説明: このアラームは、書き込みスループットキャパシティのスロットリングの原因となったレコード数がしきい値に達したことを検出します。プロデューサーがプロビジョニングされた書き込みスループット (所有しているシャードの数によって決まる) を超えると、プロデューサーはスロットリングされ、ストリームにレコードを追加できなくなります。定常的なスロットリングに対処するには、ストリームにシャードを追加することを検討する必要があります。これにより、プロビジョニングされた書き込みスループットが増加し、その後のスロットリングが防止されます。レコードを取り込む際には、パーティションキーの選択も考慮する必要があります。ランダムパーティションキーは、可能な限りストリームのシャード全体にレコードを均等に分散させるため、推奨されます。

目的: このアラームは、ストリームまたはシャードのスロットリングが原因で、プロデューサーがレコードの書き込みを拒否されているかどうかを検出できます。ストリームがプロビジョンドモードの場合、このアラームを設定すると、データストリームが制限に達したときに事前にアクションを実行できるため、データ損失を防ぎ、円滑なデータ処理を維持するために、プロビジョニングされた容量を最適化したり、適切なスケーリングアクションを実行したりできます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: 通常、スロットリングされたリクエストは再試行できるため、しきい値を 0 に設定するとアラームの感度が高くなりすぎます。ただし、定常的なスロットリングは、ストリームへの書き込みに影響する可能性があるため、アラームのしきい値を設定してこれを検出する必要があります。アプリケーションのスロットリングされたリクエストに応じた割合にしきい値を設定し、設定を再試行します。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Lambda

ClaimedAccountConcurrency

ディメンション: なし

アラームの説明: このアラームは、Lambda 関数の同時実行数がアカウントのリージョンレベルの同時実行制限に近づいているかどうかをモニタリングするのに役立ちます。同時実行数の上限に達すると、関数はスロットリングされ始めます。以下のアクションを実行して、スロットリングを回避できます。

1. このリージョンで同時実行数の増加をリクエストします。

2. 未使用の予約された同時実行またはプロビジョニングされた同時実行を特定して減らします。

3. 関数内のパフォーマンスの問題を特定して処理速度を向上させ、スループットを向上させます。

4. 関数のバッチサイズを増やして、各関数呼び出しでより多くのメッセージが処理されるようにします。

目的: このアラームは、Lambda 関数の同時実行数がアカウントのリージョンレベルの同時実行クォータに近づいているかどうかを事前に検出し、ユーザーがそれに対応できるようにします。ClaimedAccountConcurrency がアカウントのリージョンレベルの同時実行クォータに達すると、関数はスロットリングされます。リザーブド同時実行 (RC) またはプロビジョニングされた同時実行 (PC) を使用している場合、このアラームにより、ConcurrentExecutions のアラームよりも同時実行の使用率をより詳細に把握できます。

統計: Maximum

推奨しきい値: 状況によって異なります。

しきい値の根拠: リージョン内のアカウントに設定されている同時実行クォータの約 90% の値を計算し、その結果をしきい値として使用してください。デフォルトで、アカウントの同時実行クォータは 1 つのリージョン内のすべての関数全体で 1,000 です。ただし、Service Quotas ダッシュボードでアカウントのクォータを確認する必要があります。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_THRESHOLD

エラー

ディメンション: FunctionName

アラームの説明: このアラームは、エラー数が多いことを検出します。エラーには、コードによってスローされた例外と、Lambda ランタイムによってスローされた例外が含まれます。関数に関連するログを確認して問題を診断できます。

目的: このアラームは、関数呼び出しで発生したエラーの数が多いことを検出するのに役立ちます。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: しきい値を 0 より大きい数値に設定します。正確な値は、アプリケーションのエラー許容度によって異なります。関数が処理する呼び出しの重要度を把握してください。アプリケーションによっては、どのようなエラーも許容できない場合もあれば、ある程度の誤差を許容できるアプリケーションもあります。

期間: 60

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: GREATER_THAN_THRESHOLD

Throttles

ディメンション: FunctionName

アラームの説明: このアラームは、スロットリングされた呼び出しリクエストが多いことを検出します。スロットリングは、スケールアップに同時実行が利用できない場合に発生します。この問題を解決するには、いくつかのアプローチがあります。1) このリージョンの AWS サポートに同時実行数の増加をリクエストします。2) 関数内のパフォーマンスの問題を特定して処理速度を向上させ、それによってスループットを向上させます。3) 関数のバッチサイズを増やして、関数が呼び出されるたびにより多くのメッセージが処理されるようにします。

目的: このアラームは、Lambda 関数に対するスロットリングされた呼び出しリクエストの数が多いことを検出するのに役立ちます。スロットリングが原因でリクエストが常に拒否されているのかを知ることや、定常的なスロットリングを回避するために Lambda 関数のパフォーマンスを改善したり同時実行容量を増したりする必要があるのかを知ることが重要です。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: しきい値を 0 より大きい数値に設定します。しきい値の正確な値は、アプリケーションの許容度によって異なる場合があります。アプリケーションの用途と関数のスケーリング要件に従ってしきい値を設定します。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

duration

ディメンション: FunctionName

アラームの説明: このアラームは、Lambda 関数によるイベントの処理時間が長いことを検出します。処理時間が長くなるのは、関数の実行時間が長くなるような関数コードの変更や、関数の依存関係の時間が長くなることが原因の可能性があります。

目的: このアラームは、Lambda 関数の実行時間が長いことを検出できます。実行時間が長いということは、関数の呼び出しに時間がかかることを示し、Lambda が処理するイベントの数が多い場合は、呼び出しの同時実行容量にも影響する可能性があります。Lambda 関数の実行時間が常に予想よりも長くなっているかどうかを知ることは重要です。

統計: p90

推奨しきい値: 状況によって異なります。

しきい値の根拠: 経過時間のしきい値は、アプリケーションとワークロード、およびパフォーマンス要件によって異なります。高性能が要件の場合は、しきい値を短く設定して、その関数が想定どおりかどうかを確認します。また、経過時間メトリクスの履歴データを分析して、かかった時間が関数の想定パフォーマンスと一致するかどうかを確認し、しきい値を過去の平均よりも長い時間に設定することもできます。しきい値は、設定した関数タイムアウトよりも短く設定してください。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

ConcurrentExecutions

ディメンション: FunctionName

アラームの説明: このアラームは、関数の同時実行数がアカウントのリージョンレベルの同時実行制限に近づいているかどうかをモニタリングするのに役立ちます。同時実行数の上限に達すると、関数はスロットリングされ始めます。以下のアクションを実行して、スロットリングを回避できます。

1. このリージョンで同時実行数の増加をリクエストします。

2. 関数内のパフォーマンスの問題を特定して処理速度を向上させ、スループットを向上させます。

3. 関数のバッチサイズを増やして、各関数呼び出しでより多くのメッセージが処理されるようにします。

予約された同時実行数とプロビジョニングされた同時実行数の使用率をより明確に把握するには、代わりに新しいメトリクス ClaimedAccountConcurrency にアラームを設定します。

目的: このアラームは、関数の同時実行数がアカウントのリージョンレベルの同時実行クォータに近づいているかどうかを事前に検出し、ユーザーが対応できるようにします。アカウントのリージョンレベルの同時実行クォータに達すると、関数はスロットリングされます。

統計: Maximum

推奨しきい値: 状況によって異なります。

しきい値の根拠: リージョンのアカウントに設定されている同時実行クォータの約 90% にしきい値を設定します。デフォルトで、アカウントの同時実行クォータは 1 つのリージョン内のすべての関数全体で 1,000 です。ただし、AWS サポートに連絡すれば増やすことができるため、アカウントのクォータを確認することに意味はあります。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_THRESHOLD

Lambda Insights

以下の Lambda Insights メトリクスにベストプラクティスアラームを設定することをお勧めします。

memory_utilization

ディメンション: function_name

アラームの説明: このアラームは、Lambda 関数のメモリ使用率が設定された上限に近づいているかどうかを検出するために使用されます。トラブルシューティングのためにできる試行として、1) コードを最適化します。2) メモリ要件を正確に見積もって、メモリ割り当てのサイズを適切に設定します。同じことについては、「Lambda Power Tuning」を参照することもできます。3) 接続プーリングを使用します。RDS データベースの接続プーリングについては、「Amazon RDS Proxy を Lambda で使用する」を参照してください。4) また、呼び出しと呼び出しの間に大量のデータをメモリに保存しないように関数を設計することも検討できます。

目的: このアラームは、Lambda 関数のメモリ使用率が設定された上限に近づいているかどうかを検出するために使用されます。

統計: Average

推奨しきい値: 90.0

しきい値の根拠: しきい値を 90% に設定して、メモリ使用率が割り当てられたメモリの 90% を超えるとアラートが表示されるようにします。ワークロードのメモリ使用率が気になる場合は、この値をそれより低い値に調整できます。このメトリクスの履歴データを確認して、それに応じてしきい値を設定することもできます。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_THRESHOLD

Amazon VPC (AWS/NATGateway)

ErrorPortAllocation

ディメンション: NatGatewayId

アラームの説明: このアラームは、NAT ゲートウェイが新しい接続へのポートの割り当てができないことを検出するのに役立ちます。この問題を解決するには、「NAT Gateway でのポートアロケーションエラーを解決する」を参照してください。

目的: このアラームは、NAT ゲートウェイがソースポートの割り当てができなかったかどうかを検出するために使用されます。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: ErrorPortAllocation の値がゼロより大きい場合、多くの接続を集めている単一の送信先に NAT ゲートウェイを介して開かれている同時接続が多すぎるということです。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

PacketsDropCount

ディメンション: NatGatewayId

アラームの説明: このアラームは、NAT ゲートウェイによってパケットがドロップされたことを検出するのに役立ちます。これは NAT ゲートウェイの問題が原因で発生する可能性があるため、AWS サービスヘルスダッシュボードで、リージョンの AWS NAT ゲートウェイのステータスを確認してください。これにより、NAT ゲートウェイを使用するトラフィックに関連するネットワークの問題を関連付けることができます。

目的: このアラームは、パケットが NAT ゲートウェイによってドロップされているかどうかを検出するために使用されます。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: NAT ゲートウェイの総トラフィックの 0.01% の値を計算し、その結果をしきい値として使用してください。NAT ゲートウェイのトラフィックの履歴データを使用してしきい値を決定します。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

AWS プライベートリンク (AWS/PrivateLinkEndpoints)

PacketsDropped

ディメンション: VPC Id、VPC Endpoint Id、Endpoint Type、Subnet Id、Service Name

アラームの説明: このアラームは、エンドポイントがドロップしたパケット数をモニタリングすることで、エンドポイントまたはエンドポイントサービスに異常があるかどうかを検出するのに役立ちます。8500 バイトを超えるパケットは VPC エンドポイントに到達したときにドロップされることに注意してください。トラブルシューティングについては、「インターフェイス VPC エンドポイントとエンドポイントサービス間の接続の問題」を参照してください。

目的: このアラームは、エンドポイントやエンドポイントサービスに異常があるかどうかを検出するのに使用されます。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: ユースケースに応じてしきい値を設定します。エンドポイントまたはエンドポイントサービスの異常状態を把握したい場合は、データが大幅に失われる前に問題を解決できるよう、しきい値を低く設定する必要があります。履歴データを使用して、ドロップされるパケット数の許容範囲を把握し、それに応じてしきい値を設定できます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

AWS プライベートリンク (AWS/PrivateLinkServices)

RstPacketsSent

ディメンション: Service Id、Load Balancer Arn、Az

アラームの説明: このアラームは、エンドポイントに送信されたリセットパケットの数に基づいて、エンドポイントサービスの異常なターゲットを検出するのに役立ちます。サービスのコンシューマーとの接続エラーをデバッグする際に、サービスが RstPacketsSent メトリクスによって接続をリセットしているのか、それともネットワークパス上で何か他の障害が発生しているのかを検証できます。

目的: このアラームは、エンドポイントサービスの異常なターゲットを検出するのに使用されます。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: しきい値はユースケースによって異なります。ユースケースでターゲットの異常を許容できる場合は、しきい値を高く設定できます。ユースケースで異常なターゲットを許容できない場合は、しきい値を非常に低く設定できます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Amazon RDS

CPUUtilization

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、常に高い CPU 使用率をモニタリングするのに役立ちます。CPU 使用率は、アイドル状態でない時間を測定します。拡張モニタリングまたは Performance Insights を使用して、MariaDB、MySQL、Oracle、および PostgreSQL の CPU 時間 (guest、irq、wait、nice など) を最も多く消費している待機時間を確認することを検討してください。次に、CPU を最も多く消費しているクエリを評価します。ワークロードを調整できない場合は、より大きな DB インスタンスクラスへの移行を検討してください。

目的: このアラームは、常に高い CPU 使用率を検出して、非常に長い応答時間やタイムアウトを防ぐために使用されます。CPU 使用率がマイクロバーストしていることを確認したい場合は、アラームの評価時間を短く設定できます。

統計: Average

推奨しきい値: 90.0

しきい値の根拠: CPU 使用率がランダムに増加してもデータベースのパフォーマンスは低下しないかもしれませんが、CPU 使用率が高い状態が続くと、今後のデータベースリクエストが妨げられる可能性があります。データベース全体のワークロードによっては、RDS/Aurora インスタンスの CPU 使用率が高いと、全体的なパフォーマンスが低下する可能性があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

DatabaseConnections

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは多数の接続を検出します。既存の接続を確認し、「スリープ」状態の接続や不適切に閉じられた接続を終了します。接続プールを使用して新しい接続の数を制限することを検討してください。または、DB インスタンスのサイズを増やしてメモリの多いクラスを使用するため、「max_connections」のデフォルト値を高くするか、現在のクラスがワークロードをサポートできる場合は、現在のクラスの RDS、Aurora MySQL、および PostgreSQL で「max_connections」値を増やします。

目的: このアラームは、DB 接続の最大数に達したときに接続が拒否されないようにするために使用されます。DB インスタンスクラスを頻繁に変更する場合は、メモリとデフォルトの最大接続数が変わるため、このアラームはお勧めしません。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: 許可される接続数は、DB インスタンスクラスのサイズと、プロセス/接続に関連するデータベースエンジン固有のパラメータによって異なります。データベースの最大接続数の 90～95% の値を計算し、その結果をしきい値として使用する必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

EBSByteBalance%

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、残っているスループットクレジットの割合が低いことを監視するのに役立ちます。トラブルシューティングについては、「RDS のレイテンシー問題」を参照してください。

目的: このアラームは、バーストバケットに残っているスループットクレジットの割合が低いことを検出するために使用されます。バイトバランスの割合が低いと、スループットボトルネックの問題が発生する可能性があります。このアラームは、Aurora PostgreSQL インスタンスにはお勧めしません。

統計: Average

推奨しきい値: 10.0

しきい値の根拠: スループットクレジット残高が 10% を下回ると不十分と見なされるため、状況に応じてしきい値を設定する必要があります。アプリケーションがワークロードのスループットの低下を許容できる場合は、より低いしきい値を設定することもできます。

期間: 60

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: LESS_THAN_THRESHOLD

EBSIOBalance%

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、残っている IOPS クレジットの割合が低いことを監視するのに役立ちます。レイテンシー問題のトラブルシューティングについては、「RDS のレイテンシー問題」を参照してください。

目的: このアラームは、バーストバケットに残っている I/O クレジットの割合が低いことを検出するために使用されます。IOPS バランスの割合が低いと、IOPS ボトルネックの問題が発生する可能性があります。このアラームは、Aurora インスタンスにはお勧めしません。

統計: Average

推奨しきい値: 10.0

しきい値の根拠: IOPS クレジット残高が 10% を下回ると不十分と見なされるため、状況に応じてしきい値を設定できます。アプリケーションがワークロードの IOPS の低下を許容できる場合は、より低いしきい値を設定することもできます。

期間: 60

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: LESS_THAN_THRESHOLD

FreeableMemory

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、データベース接続が急増している場合や、インスタンスのメモリプレッシャーが高くなっている場合など、解放可能なメモリが不足していることを監視するのに役立ちます。FreeableMemory に加えて SwapUsage の CloudWatch メトリクスを監視して、メモリプレッシャーを確認します。インスタンスメモリの消費量が頻繁に高くなりすぎている場合は、ワークロードの見直し、またはインスタンスクラスのアップグレードが必要であることを表します。Aurora リーダー DB インスタンスの場合は、クラスターにリーダー DB インスタンスを追加することを検討してください。Aurora のトラブルシューティングの詳細については、「解放可能なメモリの問題」を参照してください。

目的: このアラームは、メモリが不足して接続が拒否されるのを防ぐのに役立ちます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: ワークロードとインスタンスクラスによっては、適切なしきい値が異なる場合があります。理想的には、使用可能なメモリが長時間にわたって合計メモリの 25% を下回らないようにする必要があります。Aurora の場合、メトリクスが 0 に近づくと DB インスタンスが可能な限りスケールアップしたことを意味するため、しきい値を 5% 近くに設定できます。このメトリクスの過去の動作を分析して、適切なしきい値レベルを決定できます。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: LESS_THAN_THRESHOLD

FreeLocalStorage

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、空き容量が少ないローカルストレージを監視するのに役立ちます。Aurora PostgreSQL 互換エディションは、ローカルストレージを使用してエラーログと一時ファイルを保存します。Aurora MySQL は、エラーログ、全般ログ、スロークエリログ、監査ログ、および InnoDB 以外の一時テーブルを保存するのにローカルストレージを使用します。これらのローカルストレージボリュームは、Amazon EBS Store によってバックアップされ、より大きな DB インスタンスクラスを使用することで拡張できます。トラブルシューティングについては、Aurora「PostgreSQL 互換」と「MySQL 互換」を参照してください。

目的: このアラームは、Aurora Serverless v2 以降を使用していない場合に、Aurora DB インスタンスがローカルストレージの制限にどれだけ近づいているかを検出するために使用されます。一時テーブルやログファイルなどの非永続的データをローカルストレージに保存すると、ローカルストレージが容量に達する可能性があります。このアラームは、DB インスタンスがローカルストレージを使い果たしたときに発生する容量不足エラーを防ぐことができます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: ボリュームの使用速度と傾向に基づいて使用可能なストレージ量の約 10%～20% を計算し、その結果をしきい値として使用して、ボリュームが制限に達する前に事前に措置を講じる必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: LESS_THAN_THRESHOLD

FreeStorageSpace

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、使用可能なストレージ容量が少ないことを監視します。ストレージ容量の制限に頻繁に近づく場合は、データベースストレージをスケールアップすることを検討してください。アプリケーションからのリクエストの予期しない増加に対応するために、いくらかのバッファを含めてください。または、RDS ストレージ自動スケーリングを有効にすることを検討してください。さらに、未使用または古いデータやログを削除して、空き容量を増やすことを検討してください。詳細については、「RDS ストレージ不足に関するドキュメント」と「PostgreSQL ストレージ問題に関するドキュメント」を参照してください。

目的: このアラームは、ストレージがいっぱいになる問題を防ぐのに役立ちます。これにより、データベースインスタンスがストレージを使い果たしたときに発生するダウンタイムを防ぐことができます。ストレージ自動スケーリングが有効になっている場合や、データベースインスタンスのストレージ容量を頻繁に変更する場合は、このアラームを使用することはお勧めしません。

統計: Minimum

推奨しきい値: 状況によって異なります。

しきい値の根拠: しきい値は、現在割り当てられているストレージ容量によって異なります。通常は、割り当てられているストレージ容量の 10 パーセントの値を計算し、その結果をしきい値として使用する必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: LESS_THAN_THRESHOLD

MaximumUsedTransactionIDs

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、PostgreSQL のトランザクション ID のラップアラウンドを防ぐのに役立ちます。この問題を調査して解決するには、このブログのトラブルシューティング手順を参照してください。このブログを参照して、autovacuum の概念、一般的な問題、ベストプラクティスについてさらに理解を深めることもできます。

目的: このアラームは、PostgreSQL のトランザクション ID のラップアラウンドを防ぐのに役立ちます。

統計: Average

推奨しきい値: 1.0E9

しきい値の根拠: このしきい値を 10 億に設定すると、問題を調査する時間を確保できます。autovacuum_freeze_max_age のデフォルト値は 2 億です。最も古いトランザクションの存続時間が 10 億の場合、autovacuum がこのしきい値を目標の 2 億トランザクション ID 以下に維持することに問題があります。

期間: 60

アラームを発生させるデータポイント数: 1

評価期間数: 1

比較演算子: GREATER_THAN_THRESHOLD

ReadLatency

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、大きな読み取りレイテンシーを監視するのに役立ちます。ストレージレイテンシーが大きい場合は、ワークロードがリソースの制限を超えていることが原因です。インスタンスと割り当てられたストレージ構成を基準にして I/O 使用率を確認できます。「IOPS ボトルネックによる Amazon EBS ボリュームのレイテンシーのトラブルシューティング」を参照してください。Aurora では、I/O 最適化ストレージ構成のインスタンスクラスに切り替えることができます。ガイダンスについては、「Planning I/O in Aurora」を参照してください。

目的: このアラームは、大きい読み取りレイテンシーを検出するために使用されます。データベースディスクは通常、読み取り/書き込みレイテンシーは小さいですが、レイテンシーが大きいオペレーションを引き起こすような問題が発生する可能性があります。

統計: p90

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、ユースケースによって大きく異なります。20 ミリ秒を超える読み取りレイテンシーは、調査の対象となる可能性があります。また、アプリケーションの読み取りオペレーションのレイテンシーが大きくなる可能性がある場合は、しきい値を高く設定することもできます。読み取りレイテンシーの重要度と要件を確認し、このメトリクスの過去の動作を分析して、適切なしきい値レベルを決定します。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

ReplicaLag

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、レプリカがプライマリインスタンスより遅れている秒数を把握するのに役立ちます。ソースデータベースインスタンスでユーザートランザクションが発生していない場合、PostgreSQL リードレプリカで最長 5 分のレプリケーションの遅延が報告されます。ReplicaLag メトリクスが 0 に達すると、レプリカはプライマリ DB インスタンスに追いついています。ReplicaLag メトリクスにより -1 が返された場合、レプリケーションは現在アクティブではありません。RDS PostgreSQL に関するガイダンスについては、「レプリケーションのベストプラクティス」を、ReplicaLag のトラブルシューティングと関連するエラーについては、「ReplicaLag のトラブルシューティング」を参照してください。

目的: このアラームは、プライマリインスタンスに障害が発生した場合に生じる可能性のあるデータ損失を反映するレプリカラグを検出できます。レプリカがプライマリよりも大幅に遅れ、プライマリに障害が発生した場合、レプリカでは、プライマリインスタンスにあったデータが失われます。

統計: Maximum

推奨しきい値: 60.0

しきい値の根拠: 通常、許容できる遅延はアプリケーションによって異なります。60 秒を超えないことをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: GREATER_THAN_THRESHOLD

WriteLatency

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、大きな書き込みレイテンシーを監視するのに役立ちます。ストレージレイテンシーが大きい場合は、ワークロードがリソースの制限を超えていることが原因です。インスタンスと割り当てられたストレージ構成を基準にして I/O 使用率を確認できます。「IOPS ボトルネックによる Amazon EBS ボリュームのレイテンシーのトラブルシューティング」を参照してください。Aurora では、I/O 最適化ストレージ構成のインスタンスクラスに切り替えることができます。ガイダンスについては、「Planning I/O in Aurora」を参照してください。

目的: このアラームは、大きい書き込みレイテンシーを検出するために使用されます。データベースディスクは通常、読み取り/書き込みレイテンシーは小さいですが、レイテンシーが大きいオペレーションを引き起こすような問題が発生する可能性があります。これを監視することで、ディスクレイテンシーが予想どおりに小さくなることが保証されます。

統計: p90

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、ユースケースによって大きく異なります。20 ミリ秒を超える書き込みレイテンシーは、調査の対象となる可能性があります。また、アプリケーションの書き込みオペレーションのレイテンシーが大きくなる可能性がある場合は、しきい値を高く設定することもできます。書き込みレイテンシーの重要度と要件を確認し、このメトリクスの過去の動作を分析して、適切なしきい値レベルを決定します。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

DBLoad

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、高い DB ロードを監視するのに役立ちます。プロセスの数が vCPU の数を超えると、プロセスはキューイングを開始します。キューイングが増加すると、パフォーマンスに影響します。DB ロードが最大 vCPU ラインをしばしば超過し、プライマリ待機状態が CPU である場合、CPU が過ロードになっています。この場合、CPUUtilization、DBLoadCPU、およびキューに入っているタスクを Performance Insights/拡張モニタリングで監視することができます。インスタンスへの接続を抑制したり、CPU ロードの高い SQL クエリを調整したり、より大きなインスタンスクラスを検討する必要があります。待機状態の高い一貫したインスタンスは、解決するボトルネックまたはリソースの競合問題がある可能性があることを示します。

目的: このアラームは、DB ロードが高いことを検出するために使用されます。DB ロードが高いと、DB インスタンスにパフォーマンスの問題が発生する可能性があります。このアラームは、サーバーレス DB インスタンスには適用されません。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: 最大 vCPU 値は、DB インスタンスの vCPU (仮想 CPU) のコア数によって決まります。最大 vCPU によって、適切なしきい値が異なる場合があります。理想的には、DB ロードは vCPU ラインを超えないようにしてください。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

AuroraVolumeBytesLeftTotal

ディメンション: DBClusterIdentifier

アラームの説明: このアラームは、残りの合計ボリュームが少ないことを監視するのに役立ちます。残りの合計ボリュームがサイズ制限に達すると、クラスターはスペースがないというエラーを報告します。Aurora ストレージはクラスターボリューム内のデータに合わせて自動的にスケールし、DB エンジンのバージョンに応じて最大 128 TiB または 64 TiB まで拡張されます。不要になったテーブルとデータベースを削除して、ストレージを削減することを検討してください。詳細については、「ストレージのスケーリング」を参照してください。

目的: このアラームは、Aurora クラスターがボリュームサイズの制限にどれだけ近づいているかを検出するために使用されます。このアラームは、クラスターの容量が不足したときに発生する容量不足エラーを防ぐことができます。このアラームは、Aurora MySQL にのみお勧めします。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: ボリューム使用量の増加速度と傾向に基づいて実際のサイズ制限の 10%～20% を計算し、その結果をしきい値として使用して、ボリュームが制限に達する前に事前に措置を講じる必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: LESS_THAN_THRESHOLD

AuroraBinlogReplicaLag

ディメンション: DBClusterIdentifier、Role=WRITER

アラームの説明: このアラームは、Aurora ライターインスタンスのレプリケーションのエラー状態を監視するのに役立ちます。詳細については、「AWS リージョン間での Aurora MySQL DB クラスターのレプリケート」を参照してください。トラブルシューティングについては、「Aurora MySQL レプリケーションの問題」を参照してください。

目的: このアラームは、ライターインスタンスがエラー状態にあり、ソースを複製できないかどうかを検出するために使用されます。このアラームは、Aurora MySQL にのみお勧めします。

統計: Average

推奨しきい値: -1.0

しきい値の根拠: レプリカがエラー状態にある場合、Aurora MySQL はこの値を公開するため、しきい値として -1 を使用することをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 2

評価期間数: 2

比較演算子: LESS_THAN_OR_EQUAL_TO_THRESHOLD

BlockedTransactions

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、Aurora DB インスタンスでブロックされたトランザクション数が多いことを監視するのに役立ちます。ブロックされたトランザクションは、ロールバックまたはコミットのいずれかで終了することがあります。高い同時実行性、トランザクションのアイドル状態、または実行時間の長いトランザクションにより、トランザクションがブロックされる可能性があります。トラブルシューティングについては、「Aurora MySQL」に関するドキュメントを参照してください。

目的: このアラームは、トランザクションのロールバックやパフォーマンスの低下を防ぐために、Aurora DB インスタンスでブロックされたトランザクションの数が多いことを検出するために使用されます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: ActiveTransactions メトリクスを使用してインスタンスの全トランザクションの 5% を計算し、その結果をしきい値として使用する必要があります。また、ブロックされたトランザクションの重要度と要件を確認し、このメトリクスの過去の動作を分析して、適切なしきい値を決定することもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

BufferCacheHitRatio

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、Aurora クラスターのキャッシュヒット率が常に低いことを監視するのに役立ちます。ヒット率が低い場合、この DB インスタンスのクエリが、頻繁にディスクに書き込まれていることを示します。トラブルシューティングについては、ワークロードを調査して、この動作の原因となっているクエリを確認し、「DB インスタンスの RAM の推奨事項」に関するドキュメントを参照してください。

目的: このアラームは、Aurora インスタンスのパフォーマンスが持続的に低下するのを防ぐために、キャッシュヒット率が常に低いことを検出するために使用されます。

統計: Average

推奨しきい値: 80.0

しきい値の根拠: バッファキャッシュヒット率のしきい値を 80% に設定できます。ただし、許容できるパフォーマンスレベルとワークロード特性に基づいてこの値を調整できます。

期間: 60

アラームを発生させるデータポイント数: 10

評価期間数: 10

比較演算子: LESS_THAN_THRESHOLD

EngineUptime

ディメンション: DBClusterIdentifier、Role=WRITER

アラームの説明: このアラームは、ライター DB インスタンスのダウンタイムが短いことを監視するのに役立ちます。ライター DB インスタンスは、再起動、メンテナンス、アップグレード、またはフェイルオーバーによりダウンする可能性があります。クラスター内のフェイルオーバーによってアップタイムが 0 になり、クラスターに 1 つ以上の Aurora レプリカがある場合は、障害イベント中に 1 つの Aurora レプリカがプライマリライターインスタンスに昇格されます。DB クラスターの可用性を高めるために、複数のアベイラビリティーゾーン内で 1 つ以上の Aurora レプリカを作成することを検討してください。詳細については、「Aurora のダウンタイムに影響する要因」を参照してください。

目的: このアラームは、Aurora ライター DB インスタンスがダウンタイム状態にあるかどうかを検出するために使用されます。これにより、クラッシュやフェイルオーバーが原因でライターインスタンスに長時間障害が発生するのを防ぐことができます。

統計: Average

推奨しきい値: 0.0

しきい値の根拠: 障害イベントによって短い中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。ただし、サービスの一般的な復元時間は 60 秒未満であり、多くの場合 30 秒未満です。

期間: 60

アラームを発生させるデータポイント数: 2

評価期間数: 2

比較演算子: LESS_THAN_OR_EQUAL_TO_THRESHOLD

RollbackSegmentHistoryListLength

ディメンション: DBInstanceIdentifier

アラームの説明: このアラームは、Aurora インスタンスのロールバックセグメント履歴の長さが一貫して長くなっていることを監視するのに役立ちます。InnoDB 履歴リストの長さが大きくなると、古い行バージョンが多数存在することになり、クエリやデータベースのシャットダウンが遅くなります。詳細とトラブルシューティングについては、「InnoDB 履歴リストの長さが大幅に増加した」に関するドキュメントを参照してください。

目的: このアラームは、ロールバックセグメント履歴の長さが一貫して長くなっていることを検出するために使用されます。これにより、Aurora インスタンスでパフォーマンスが継続的に低下したり、CPU 使用率が高くなったりするのを防ぐことができます。このアラームは、Aurora MySQL にのみお勧めします。

統計: Average

推奨しきい値: 1000000.0

しきい値の根拠: このしきい値を 100 万に設定すると、問題を調査する時間を確保できます。ただし、許容できるパフォーマンスレベルとワークロード特性に基づいてこの値を調整できます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

StorageNetworkThroughput

ディメンション: DBClusterIdentifier、Role=WRITER

アラームの説明: このアラームは、高いストレージネットワークスループットを監視するのに役立ちます。ストレージネットワークスループットが EC2 インスタンスのネットワーク帯域幅の合計を超えると、読み取りと書き込みのレイテンシーが高くなり、パフォーマンスが低下する可能性があります。EC2 インスタンスタイプは、AWS コンソールで確認できます。トラブルシューティングについては、書き込み/読み取りレイテンシーの変化を確認し、このメトリクスでアラームが発生しているかどうかも評価してください。アラームが発生している場合は、アラームがトリガーされた時間帯のワークロードパターンを評価してください。これにより、ワークロードを最適化してネットワークトラフィックの総量を削減できるかどうかを判断できます。これが不可能な場合は、インスタンスのスケーリングを検討する必要があるかもしれません。

目的: このアラームは、ストレージネットワークスループットが高いことを検出するために使用されます。高スループットを検出することで、ネットワークパケットのドロップやパフォーマンスの低下を防ぐことができます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠:EC2 インスタンスタイプの総ネットワーク帯域幅の 80%～90% を計算し、その結果を閾値として使用して、ネットワークパケットが影響を受ける前に事前に措置を講じる必要があります。また、ストレージネットワークスループットの重要度と要件を確認し、このメトリクスの過去の動作を分析して、適切なしきい値を決定することもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Amazon Route 53 Public Data Plane

HealthCheckStatus

ディメンション: HealthCheckId

アラームの説明: このアラームは、ヘルスチェッカーに従って異常のあるエンドポイントを検出するのに役立ちます。異常なステータスになる障害の原因を理解するには、Route 53 ヘルスチェックコンソールの [ヘルスチェッカー] タブを使用して、各リージョンのステータスと、ヘルスチェックで検出した最後の障害を表示します。[ステータス] タブには、エンドポイントが異常と報告された理由も表示されます。トラブルシューティングの手順を参照してください。

目的: このアラームは Route53 ヘルスチェッカーを使用して異常のあるエンドポイントを検出します。

統計: Average

推奨しきい値: 1.0

しきい値の根拠: エンドポイントのステータスは、正常であれば 1 と報告されます。1 未満はすべて異常です。

期間: 60

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: LESS_THAN_THRESHOLD

Amazon S3

4xxErrors

ディメンション: BucketName、FilterId

アラームの説明: このアラームは、クライアントのリクエストに応答して生成されたエラーステータスコード 4xx の総数を報告するのに役立ちます。例えば、エラーコード 403 は IAM ポリシーが正しくないことを示している可能性があり、エラーコード 404 はクライアントアプリケーションの動作が正しくないことを示している可能性があります。一時的に S3 サーバーアクセスログを有効にすると、HTTP ステータスフィールドと Error Code フィールドを使用して問題の原因を特定するのに役立ちます。エラーコードの詳細については、「エラーレスポンス」を参照してください。

目的: このアラームは、通常の 4xx エラー率のベースラインを作成するのに使用されます。これにより、セットアップの問題を示す可能性のある異常を調べることができます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 推奨しきい値は、全リクエストの 5% 超が 4XX エラーになっていることを検出するためのものです。頻繁に発生する 4XX エラーにはアラームが必要です。ただし、しきい値が非常に低いと、アラームの感度が高くなりすぎる可能性があります。また、4XX エラーの許容レベルを考慮して、リクエストの負荷に合わせてしきい値を調整することもできます。また、履歴データを分析してアプリケーションワークロードの許容可能なエラー率を確認し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

5xxErrors

ディメンション: BucketName、FilterId

アラームの説明: このアラームは、サーバー側エラー数が多いことを検出するのに役立ちます。これらのエラーは、クライアントがリクエストを行ったが、サーバーが完了できなかったことを示しています。これは、S3 が原因でアプリケーションが直面している問題を関連付けることに役立ちます。エラーを効率的に処理または削減するのに役立つ詳細については、「パフォーマンスを最適化する設計パターン」を参照してください。エラーは S3 の問題が原因である可能性もあります。AWS サービスヘルスダッシュボードで、リージョンの Amazon S3 のステータスを確認してください。

目的: このアラームは、5xx エラーが原因でアプリケーションに問題が発生しているかどうかを検出するのに役立ちます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 全リクエストの 5% 超が 5XXError になっている場合に検出されるように、しきい値を設定することをお勧めします。ただし、リクエストのトラフィックや許容可能なエラー率に合わせてしきい値を調整できます。また、履歴データを分析してアプリケーションワークロードの許容可能なエラー率を確認し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

OperationsFailedReplication

ディメンション: SourceBucket、DestinationBucket、RuleId

アラームの説明: このアラームは、レプリケーションの障害を把握するのに役立ちます。このメトリッスは、S3 CRR または S3 SRR を使用してレプリケートされた新しいオブジェクトのステータスを追跡し、S3 バッチレプリケーションを使用してレプリケートされた既存のオブジェクトも追跡します。詳細については、「レプリケーションのトラブルシューティング」を参照してください。

目的: このアラームは、失敗したレプリケーションオペレーションがあるかどうかを検出するために使用されます。

統計: Maximum

推奨しきい値: 0.0

しきい値の根拠: このメトリクスは、オペレーションが成功した場合は 0 の値を出力し、1 分間レプリケーションオペレーションが実行されなかった場合は何も出力しません。メトリクスが 0 より大きい値を出力した場合は、レプリケーションオペレーションが失敗しています。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

S3ObjectLambda

4xxErrors

ディメンション: AccessPointName、DataSourceARN

アラームの説明: このアラームは、クライアントのリクエストに応答して生成されたエラーステータスコード 4xx の総数を報告するのに役立ちます。一時的に S3 サーバーアクセスログを有効にすると、HTTP ステータスフィールドと Error Code フィールドを使用して問題の原因を特定するのに役立ちます。

目的: このアラームは、通常の 4xx エラー率のベースラインを作成するのに使用されます。これにより、セットアップの問題を示す可能性のある異常を調べることができます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 全リクエストの 5% 超が 4XXError になっている場合に検出されるように、しきい値を設定することをお勧めします。頻繁に発生する 4XX エラーにはアラームが必要です。ただし、しきい値が非常に低いと、アラームの感度が高くなりすぎる可能性があります。また、4XX エラーの許容レベルを考慮して、リクエストの負荷に合わせてしきい値を調整することもできます。また、履歴データを分析してアプリケーションワークロードの許容可能なエラー率を確認し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

5xxErrors

ディメンション: AccessPointName、DataSourceARN

アラームの説明: このアラームは、サーバー側エラー数が多いことを検出するのに役立ちます。これらのエラーは、クライアントがリクエストを行ったが、サーバーが完了できなかったことを示しています。これらのエラーは S3 の問題が原因である可能性があります。AWS サービスヘルスダッシュボードで、リージョンの Amazon S3 のステータスを確認してください。これは、S3 が原因でアプリケーションが直面している問題を関連付けることに役立ちます。これらのエラーを効率的に処理または軽減するのに役立つ情報については、「パフォーマンスを最適化する設計パターン」を参照してください。

目的: このアラームは、5xx エラーが原因でアプリケーションに問題が発生しているかどうかを検出するのに役立ちます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 全リクエストの 5% 超が 5XX エラーになっている場合に検出されるように、しきい値を設定することをお勧めします。ただし、リクエストのトラフィックや許容可能なエラー率に合わせてしきい値を調整できます。また、履歴データを分析してアプリケーションワークロードの許容可能なエラー率を確認し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

LambdaResponse4xx

ディメンション: AccessPointName、DataSourceARN

アラームの説明: このアラームは、S3 Object Lambda への呼び出しの失敗 (500 番台) を検出して診断するのに役立ちます。これらのエラーは、リクエストへのレスポンスを担当する Lambda 関数のエラーまたは設定ミスが原因である可能性があります。Object Lambda アクセスポイントに関連付けられた Lambda 関数の CloudWatch ログストリームを調査すると、S3 Object Lambda からのレスポンスに基づいて問題の原因を特定するのに役立ちます。

目的: このアラームは、WriteGetObjectResponse 呼び出しのクライアントエラー 4xx を検出するために使用されます。

統計: Average

推奨しきい値: 0.05

しきい値の根拠: 全リクエストの 5% 超が 4XXError になっている場合に検出されるように、しきい値を設定することをお勧めします。頻繁に発生する 4XX エラーにはアラームが必要です。ただし、しきい値が非常に低いと、アラームの感度が高くなりすぎる可能性があります。また、4XX エラーの許容レベルを考慮して、リクエストの負荷に合わせてしきい値を調整することもできます。また、履歴データを分析してアプリケーションワークロードの許容可能なエラー率を確認し、それに応じてしきい値を調整することもできます。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_THRESHOLD

Amazon SNS

NumberOfMessagesPublished

ディメンション: TopicName

アラームの説明: このアラームは、公開されている SNS メッセージの数が少なすぎることを検出できます。トラブルシューティングのため、パブリッシャーが送信するトラフィックが減少している理由を確認します。

目的: このアラームは、通知の公開が大幅に低下していることを事前にモニタリングして検出するのに役立ちます。これにより、アプリケーションまたはビジネスプロセスで発生する可能性のある問題を特定できるため、通知のフローを想定どおりに維持するための適切なアクションを実行できます。システムが処理するトラフィックが最小限になると予想される場合は、このアラームを作成する必要があります。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: 公開されるメッセージの数は、アプリケーションで公開されるメッセージの予想数と一致している必要があります。また、履歴データ、傾向、トラフィックを分析して、適切なしきい値を見つけることもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: LESS_THAN_THRESHOLD

NumberOfNotificationsDelivered

ディメンション: TopicName

アラームの説明: このアラームは、配信された SNS メッセージの数が少なすぎることを検出できます。これは、エンドポイントのサブスクリプションが意図せず解除されたことや、SNS イベントが原因でメッセージに遅延が発生したことが原因である可能性があります。

目的: このアラームは、配信されるメッセージ量の減少を検出するのに役立ちます。システムが処理するトラフィックが最小限になると予想される場合は、このアラームを作成する必要があります。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: 配信されるメッセージの数は、メッセージの予想数およびコンシューマーの数と一致している必要があります。また、履歴データ、傾向、トラフィックを分析して、適切なしきい値を見つけることもできます。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: LESS_THAN_THRESHOLD

NumberOfNotificationsFailed

ディメンション: TopicName

アラームの説明: このアラームは、失敗した SNS メッセージの数が多すぎることを検出できます。通知の失敗をトラブルシューティングするには、CloudWatch Logs のログ記録を有効にします。ログを確認すると、失敗しているサブスクライバーと、それらのサブスクライバーが返しているステータスコードを確認するのに役立ちます。

目的: このアラームは、通知の配信に関する問題を事前に発見し、それに対処するための適切なアクションを実行するのに役立ちます。

統計: Sum

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、通知の失敗の影響度によって大きく異なります。エンドユーザーに提供される SLA、耐障害性、通知の重要性を確認し、履歴データを分析し、それに応じてしきい値を選択します。SQS、Lambda、または Firehose サブスクリプションしかないトピックでは、失敗した通知の数は 0 になるはずです。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidAttributes

ディメンション: TopicName

アラームの説明: このアラームは、パブリッシャーまたはサブスクライバーに発生する可能性のある問題をモニタリングして解決するのに役立ちます。パブリッシャーが無効な属性を持つメッセージを公開していないか、サブスクライバーに不適切なフィルターが適用されていないかを確認します。また、CloudWatch Logs を分析して、問題の根本的な原因の発見に役立てることもできます。

目的: このアラームは、公開されたメッセージが有効でないか、サブスクライバーに不適切なフィルターが適用されているかを検出するために使用されます。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: 無効な属性は、ほとんどの場合、パブリッシャーのミスです。正常なシステムでは無効な属性は想定されないため、しきい値を 0 に設定することをおすすめします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidMessageBody

ディメンション: TopicName

アラームの説明: このアラームは、パブリッシャーまたはサブスクライバーに発生する可能性のある問題をモニタリングして解決するのに役立ちます。パブリッシャーが無効なメッセージ本文を含むメッセージを公開していないか、またはサブスクライバーに不適切なフィルターが適用されていないかを確認します。また、CloudWatch Logs を分析して、問題の根本的な原因の発見に役立てることもできます。

目的: このアラームは、公開されたメッセージが有効でないか、サブスクライバーに不適切なフィルターが適用されているかを検出するために使用されます。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: 無効なメッセージ本文は、ほとんどの場合、パブリッシャーのミスです。正常なシステムでは無効なメッセージ本文は想定されないため、しきい値を 0 に設定することをおすすめします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

NumberOfNotificationsRedrivenToDlq

ディメンション: TopicName

アラームの説明: このアラームは、デッドレターキューに移動されたメッセージの数をモニタリングするのに役立ちます。

目的: このアラームは、デッドレターキューに移動されたメッセージを検出するのに使用されます。SNS が SQS、Lambda、または Firehose と連携している場合には、このアラームを作成することをお勧めします。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: どのサブスクライバータイプであっても、正常なシステムでは、メッセージはデッドレターキューに移動されないはずです。根本原因を特定して対処し、データ損失を防ぐためにデッドレターキュー内のメッセージを再処理できるように、メッセージがキューに入った場合は通知を受けることをお勧めします。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

NumberOfNotificationsFailedToRedriveToDlq

ディメンション: TopicName

アラームの説明: このアラームは、デッドレターキューに移動できなかったメッセージをモニタリングするのに役立ちます。デッドレターキューが存在するかどうか、また正しく設定されているかどうかを確認します。また、SNS にデッドレターキューへのアクセス許可があることも確認します。詳細については、「デッドレターキューのドキュメント」を参照してください。

目的: このアラームは、デッドレターキューに移動できなかったメッセージを検出するのに使用されます。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: メッセージをデッドレターキューに移動できないのはほとんどの場合ミスです。しきい値の推奨値は 0 です。つまり、キューが設定されていると、処理に失敗したすべてのメッセージがデッドレターキューに到達できる必要があります。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

SMSMonthToDateSpentUSD

ディメンション: TopicName

アラームの説明: このアラームは、SNS がメッセージを配信するのに十分なクォータがアカウントにあるかどうかをモニタリングするのに役立ちます。クォータに達すると、SNS は SMS メッセージを配信できなくなります。SMS の毎月の使用量クォータの設定、または AWS に対して使用量クォータの引き上げをリクエストする方法については、「SMS メッセージプリファレンスを設定する」を参照してください。

目的: このアラームは、SMS メッセージを正常に配信するのに十分なクォータがアカウントにあるかどうかを検出するために使用されます。

統計: Maximum

推奨しきい値: 状況によって異なります。

しきい値の根拠: アカウントのクォータ (アカウントの使用量上限) に従ってしきい値を設定します。クォータ制限に達しようとしていることを早期に通知するしきい値を設定して、引き上げをリクエストする時間を確保してください。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

SMSSuccessRate

ディメンション: TopicName

アラームの説明: このアラームは、SMS メッセージ配信の失敗率をモニタリングするのに役立ちます。CloudWatch Logs を設定して失敗の性質を把握し、それに基づいてアクションを実行できます。

目的: このアラームは、SMS メッセージ配信の失敗を検出するために使用されます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: SMS メッセージ配信に失敗した場合の許容度に合わせて、アラームのしきい値を設定します。

期間: 60

アラームを発生させるデータポイント数: 5

評価期間数: 5

比較演算子: GREATER_THAN_THRESHOLD

Amazon SQS

ApproximateAgeOfOldestMessage

ディメンション: QueueName

アラームの説明: このアラームは、キュー内の最も古いメッセージの存続期間をモニタリングします。このアラームを使用して、コンシューマーが望ましい速度で SQS メッセージを処理しているかどうかをモニタリングできます。メッセージの存続期間を短縮するために、コンシューマー数またはコンシューマースループットを増やすことを検討してください。このメトリクスを ApproximateNumberOfMessagesVisible と組み合わせて使用すると、キューのバックログの大きさやメッセージの処理速度を判断できます。メッセージが処理前に削除されないようにするには、ポイズンピルの可能性があるメッセージを除外するようにデッドレターキューを設定することを検討してください。

目的: このアラームは、QueueName キュー内の最も古いメッセージの存続期間が長すぎるかどうかを検出するために使用されます。存続期間が長いということは、メッセージが十分に速く処理されていないか、またはキューに残っていて処理できないポイズンピルメッセージがあることを示している可能性があります。

統計: Maximum

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、想定されるメッセージ処理時間によって大きく異なります。履歴データを使用して平均メッセージ処理時間を計算し、キューコンシューマーの SQS メッセージの最大予想処理時間よりも 50% 高く設定します。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesNotVisible

ディメンション: QueueName

アラームの説明: このアラームは、QueueName に関する送信中メッセージが多いことを検出するのに役立ちます。トラブルシューティングのため、メッセージバックログの減少を確認してください。

目的: このアラームは、キューにある処理中のメッセージが多いことを検出するために使用されます。表示可能性がタイムアウトになるまでにコンシューマーがメッセージを削除しない場合、キューがポーリングされると、メッセージはキューに再び表示されます。FIFO キューでは、処理中のメッセージは最大 20,000 存在することが可能です。このクォータに達した場合、SQS はエラーメッセージを返しません。FIFOキューは、最初の 20k メッセージを検索して、使用可能なメッセージグループを判別します。つまり、1 つのメッセージグループにメッセージのバックログがある場合、バックログからそれらのメッセージを正常に使用するまで、後からキューに送信された他のメッセージグループからのメッセージを使用することはできません。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: このアラームの推奨しきい値は、想定される送信中メッセージ数によって大きく異なります。履歴データを使用して、想定される最大送信中メッセージ数を計算し、そのしきい値をこの値よりも 50% 高く設定します。キューのコンシューマーがメッセージを処理していても、キューからメッセージを削除していない場合、この数は突然増加します。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesVisible

ディメンション: QueueName

アラームの説明: このアラームは、メッセージキューのバックログが予想よりも大きくなるのをモニタリングします。これは、コンシューマーが遅すぎるか、コンシューマーの数が足りないことを示しています。このアラームが ALARM 状態になった場合は、コンシューマー数を増やすか、コンシューマーの速度を上げることを検討してください。

目的: このアラームは、アクティブキューのメッセージ数が多すぎて、コンシューマーがメッセージを処理するのが遅いのか、またはメッセージを処理するのに十分なコンシューマーがいないのかを検出するために使用されます。

統計: Average

推奨しきい値: 状況によって異なります。

しきい値の根拠: 表示されるメッセージの数が予想外に多い場合は、コンシューマーがメッセージを想定した速度で処理していないことを示しています。このしきい値を設定するときは、履歴データを考慮する必要があります。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

NumberOfMessagesSent

ディメンション: QueueName

アラームの説明: このアラームは、QueueName に対してプロデューサーからメッセージが送信されていないかどうかを検出するのに役立ちます。トラブルシューティングのため、プロデューサーがメッセージを送信していない理由を確認してください。

目的: このアラームは、プロデューサーがメッセージの送信を停止したことを検出するために使用されます。

統計: Sum

推奨しきい値: 0.0

しきい値の根拠: 送信されるメッセージの数が 0 の場合、プロデューサーはメッセージを一切送信していないことになります。このキューの TPS が低い場合は、それに応じて EvaluationPeriods の数値を増やしてください。

期間: 60

アラームを発生させるデータポイント数: 15

評価期間数: 15

比較演算子: LESS_THAN_OR_EQUAL_TO_THRESHOLD

AWS VPN

TunnelState

ディメンション: VpnId

アラームの説明: このアラームは、1 つまたは複数のトンネルの状態が DOWN になっているかどうかを把握するのに役立ちます。トラブルシューティングについては、「VPN トンネルのトラブルシューティング」を参照してください。

目的: このアラームは、この VPN のトンネルが 1 つでも DOWN 状態にあるかどうかを検出し、影響を受ける VPN をトラブルシューティングできるようにするために使用されます。このアラームは、トンネルが 1 つしか設定されていないネットワークでは常に ALARM 状態になります。

統計: Minimum

推奨しきい値: 1.0

しきい値の根拠: 1 未満の値は、少なくとも 1 つのトンネルが DOWN 状態であることを示します。

期間: 300

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: LESS_THAN_THRESHOLD

TunnelState

ディメンション: TunnelIpAddress

アラームの説明: このアラームは、このトンネルの状態が DOWN になっているかどうかを把握するのに役立ちます。トラブルシューティングについては、「VPN トンネルのトラブルシューティング」を参照してください。

目的: このアラームは、トンネルが DOWN 状態かどうかを検出し、影響を受ける VPN をトラブルシューティングできるようにするために使用されます。このアラームは、トンネルが 1 つしか設定されていないネットワークでは常に ALARM 状態になります。

統計: Minimum

推奨しきい値: 1.0

しきい値の根拠: 1 未満の値は、トンネルが DOWN 状態であることを示します。

期間: 300

アラームを発生させるデータポイント数: 3

評価期間数: 3

比較演算子: LESS_THAN_THRESHOLD