# Incident Detection and Response における CloudWatch アラームのユースケースの例
Incident Detection and Response で Amazon CloudWatch アラームを使用する方法の例については、次のユースケースを参照してください。以下の例では、AWS のさまざまなサービスにわたって主要なメトリクスとしきい値をモニタリングするように CloudWatch アラームを設定し、アプリケーションやワークロードの可用性とパフォーマンスに影響を与える可能性がある潜在的な問題を特定して対応できるようにする方法を示します。
## ユースケース A の例: Application Load Balancer
ワークロードへの潜在的な影響を通知する次の CloudWatch アラームを作成できます。これを行うには、正常な接続が特定のしきい値を下回ったときにアラームを発するメトリクス数式を作成します。使用可能な CloudWatch メトリクスについては、「[CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)」を参照してください。
**メトリクス:**`HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`
**名前空間:** AWS/ApplicationELB
**ComparisonOperator (しきい値):** x 未満 (x = お客様のしきい値)。
**期間:** 60 秒
**DatapointsToAlarm:** 3 個中 3 個
**欠落データの処理:** 欠落データを[しきい値を超過](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)として処理します。
**統計: **Sum
次の図は、ユースケース A のフローを示しています。
![\[Application Load Balancer のユースケース例\]](http://docs.aws.amazon.com/ja_jp/IDR/latest/userguide/images/UseCaseAALB.png)
## ユースケース B の例: Amazon API Gateway
ワークロードへの潜在的な影響を通知する次の CloudWatch アラームを作成できます。これを行うには、API Gateway でレイテンシーが高いか、4XX エラーの数が平均して多い場合に、アラームを発する複合メトリクスを作成します。使用可能なメトリクスについては、「[Amazon API Gateway のディメンションとメトリクス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)」を参照してください。
**メトリクス:**`compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`
**名前空間:** AWS/API Gateway
**ComparisonOperator (しきい値):** x または y より大きい (x または y = お客様のしきい値)。
**期間:** 60 秒
**DatapointsToAlarm:** 1 個中 1 個
**欠落データの処理:** 欠落データを[しきい値内](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)として処理します。
**統計:**
次の図は、ユースケース B のフローを示しています。
![\[API Gateway のユースケース例\]](http://docs.aws.amazon.com/ja_jp/IDR/latest/userguide/images/UseCaseBAPIGW.png)
## ユースケース C の例: Amazon Route 53
Route 53 のヘルスチェックを作成すると、リソースをモニタリングできます。ヘルスチェックでは、CloudWatch を使用して未加工データを収集し、読み取り可能なほぼリアルタイムのメトリクスに加工します。ワークロードへの潜在的な影響を通知する次の CloudWatch アラームを作成できます。CloudWatch メトリクスを使用して、確立されたしきい値を超えたときにトリガーするアラームを作成できます。利用可能な CloudWatch メトリクスについては、「[Route 53 ヘルスチェックの CloudWatch メトリクス](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics)」を参照してください。
**メトリクス:**`R53-HC-Success`
**名前空間:** AWS/Route 53
**HealthCheckStatus のしきい値:** HealthCheckStatus が 3 分以内に 3 個のデータポイントで x 未満 (x = お客様のしきい値)
**期間:** 1 分
**DatapointsToAlarm:** 3 個中 3 個
**欠落データの処理:** 欠落データを[しきい値を超過](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)として処理します。
**統計: **Minimum
次の図は、ユースケース C のフローを示しています。
![\[Route 53 のユースケース例\]](http://docs.aws.amazon.com/ja_jp/IDR/latest/userguide/images/UseCaseCR53.png)
## ユースケース D の例: カスタムアプリケーションでワークロードをモニタリングする
このシナリオでは、時間をかけて適切なヘルスチェックを定義することが重要です。アプリケーションのポートが開いていることのみを検証する場合、アプリケーションが動作していることは検証しません。さらに、アプリケーションのホームページを呼び出すことは、アプリケーションが動作しているかどうかを判断する正しい方法とは限りません。例えば、アプリケーションがデータベースと Amazon Simple Storage Service (Amazon S3) の両方に依存している場合、ヘルスチェックではすべての要素を検証する必要があります。そのための 1 つの方法は、**/monitor** などのモニタリングウェブページを作成することです。モニタリングウェブページは、データベースを呼び出して、データを接続および取得できることを確認します。さらに、モニタリングウェブページは Amazon S3 を呼び出します。次に、ロードバランサーのヘルスチェックを **/monitor** ページに指定します。
次の図は、ユースケース D のフローを示しています。
![\[カスタムアプリケーションでのモニタリングを示すユースケース例\]](http://docs.aws.amazon.com/ja_jp/IDR/latest/userguide/images/CustomAlarm.png)