# Incident Detection and Response でアラームを定義および設定する
AWS は、アプリケーションとその基盤となる AWS インフラストラクチャのパフォーマンスを可視化するため、お客様と協力してメトリクスとアラームを定義します。しきい値を定義および設定する際は、アラームが次の基準に準拠する必要があります。
+ アラームは、モニタリング対象のワークロードに重大な影響 (収益の損失またはパフォーマンスを大幅に低下させるカスタマーエクスペリエンスの低下) があり、オペレーターによる即時の注意が必要な場合にのみ「Alarm」状態になります。
+ また、アラームは、インシデント管理チームを関与させると同時に、または関与させる前に、ワークロード向けに指定したリゾルバーを関与させる必要があります。インシデント管理エンジニアは、緩和プロセスでお客様が指定したリゾルバーと連携しますが、エスカレーションする第一線の応答者としては機能しません。
+ アラームのしきい値は、アラームが発生したときに調査が行われるように、適切なしきい値と期間に設定する必要があります。アラームが「Alarm」状態と「OK」状態の間でフラッピングしている場合、オペレーターの応答と注意を必要とする十分な影響が発生しています。
**アラームのタイプ**:
+ ビジネスへの影響のレベルを示し、単純な障害検出のために関連情報を渡すアラーム。
+ Amazon CloudWatch canary。詳細については、「[Canary と X-Ray のトレース](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html)」および「[X-Ray](https://aws.amazon.com/xray/)」を参照してください。
+ アラームの集計 (依存関係のモニタリング)
次の表に、CloudWatch モニタリングシステムを使用した、アラームの例を示します。
****
| メトリクス名/アラームしきい値 | アラームの ARN またはリソース ID | このアラームが発生した場合 | 関与が認められる場合、プレミアムサポートケースを発行するサービス |
| --- | --- | --- | --- |
| API エラー/ エラー数 >= 10 個のデータポイントで 10 回 | arn:aws:cloudwatch:us-west-2:000000000000:alarm:E2MPmimLambda-Errors | データベース管理者 (DBA) チームにチケットを提出 | Lambda、API Gateway |
| ServiceUnavailable (Http ステータスコード 503) エラー数 >= 5 分間で 10 個のデータポイントで 3 回 (異なるクライアント) | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode503 | サービスチームにチケットを提出 | Lambda、API Gateway |
| ThrottlingException (Http ステータスコード 400) エラー数 >= 5 分間で 10 個のデータポイントで 3 回 (異なるクライアント) | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode400 | サービスチームにチケットを提出 | EC2、Amazon Aurora |
詳細については、以下を参照してください。[AWS Incident Detection and Response のモニタリングとオブザーバビリティ](observe-idr.md)
自動化ツールを使用してアラームをオンボードする場合は、Incident Detection and Response コマンドラインインターフェイス (CLI) がアラームのデプロイとオンボードに役立ちます。詳細については、以下を参照してください。[AWS Incident Detection and Response CLI](idr-cli.md)
**重要なアウトプット:**
+ ワークロードのアラームの定義と設定。
+ オンボーディングアンケートにアラームの詳細を入力します。
**Topics**
+ [CloudWatch アラームの作成](idr-alarms-fit-purpose.md)
+ [CloudFormation テンプレートを使用して CloudWatch アラームを作成する](idr-create-alarms-with-cfn.md)
+ [CloudWatch アラームのユースケースの例](idr-ex-alarm-use-cases.md)
# Incident Detection and Response でビジネスニーズに合った CloudWatch アラームを作成する
Amazon CloudWatch アラームを作成する場合、アラームがビジネスニーズに最も適していることを確認するために実行できるいくつかのステップがあります。
**注記**
AWS のサービス が Incident Detection and Response にオンボードするための推奨される CloudWatch アラームの例については、「[Incident Detection and Response Alarm Best Practices on AWS re:Post](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr)」を参照してください。
## 提案された CloudWatch アラームを確認する
提案されたアラームを確認して、モニタリング対象のワークロードに重大な影響 (収益の損失またはパフォーマンスを大幅に低下させるカスタマーエクスペリエンスの低下) がある場合にのみ「Alarm」状態になることを確認します。例えば、このアラームは、「Alarm」状態になった場合にすぐに対応する必要があるほど重大なものですか?
以下は、エンドユーザーのアプリケーションエクスペリエンスに影響を与えるなど、ビジネスに重大な影響を与える可能性のある推奨メトリクスです。
+ **CloudFront:** 詳細については、「[CloudFront 関数およびエッジ関数のメトリクスの表示](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html)」を参照してください。
+ **Application Load Balancers:** 可能であれば、Application Load Balancer に対して次のアラームを作成することがベストプラクティスです。
+ HTTPCode\$1ELB\$15XX\$1Count
+ HTTPCode\$1Target\$15XX\$1Count
上記のアラームにより、Application Load Balancer の背後にあるターゲットからのレスポンス、または他のリソースの背後にあるターゲットからのレスポンスをモニタリングできます。これにより、5XX エラーの原因を簡単に特定できるようになります。詳細については、「[CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)」を参照してください。
+ **Amazon API Gateway:** Elastic Beanstalk で WebSocket API を使用している場合、次のメトリクスの使用を検討してください。
+ 統合エラー率 (5XX エラーにフィルタリング)
+ 統合のレイテンシー
+ 実行エラー
詳細については、「[CloudWatch メトリクスを使用した WebSocket API の実行のモニタリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html)」を参照してください。
+ **Amazon Route 53:** **EndPointUnhealthyENICount** メトリクスをモニタリングします。このメトリクスは、**[自動復旧]** ステータスの Elastic Network Interface の数です。このステータスは、エンドポイント (**[EndpointId]** で指定) に関連付けられている 1 つ以上の Amazon Virtual Private Cloud ネットワークインターフェイスをリゾルバーが復旧しようとしたことを示します。復旧プロセスでは、エンドポイントは限られた容量で機能します。エンドポイントは、完全に復旧するまで DNS クエリを処理できません。詳細については、「[Monitoring Amazon Route 53 Resolver endpoints with Amazon CloudWatch](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html)」を参照してください。
## アラーム設定を検証する
提案されたアラームがビジネスニーズに合っていることを確認したら、アラームの設定と履歴を検証します。
+ メトリクスの **[しきい値]** を検証して、メトリクスのグラフのトレンドに対する「Alarm」状態を入力します。
+ データポイントのポーリングに使用される **[期間]** を検証します。データポイントを 60 秒でポーリングすると、インシデントの早期検出に役立ちます。
+ **[DatapointToAlarm]** 設定を検証します。ほとんどの場合、これを 3 個中 3 個または 5 個中 5 個に設定するのがベストプラクティスです。インシデントでは、[60 second metrics with 3 out of 3 DatapointToAlarm] に設定すると 3 分後にアラームがトリガーされ、[60 second metrics with 5 out of 5 DatapointToAlarm] に設定すると 5 分後にアラームがトリガーされます。この組み合わせを使用して、ノイズの多いアラームを排除します。
**注記**
上記の推奨事項は、サービスの使用方法によって異なる場合があります。AWS のサービスごとにワークロード内での動作は異なります。また、同じサービスを複数の場所で使用した場合、動作が異なる場合があります。ワークロードがアラームを供給するリソースをどのように使用するか、およびアップストリームとダウンストリームの効果を理解する必要があります。
## アラームが欠落データを処理する方法を検証する
一部のメトリクスソースは、データを CloudWatch に定期的に送信しません。これらのメトリクスについては、欠落データを **[notBreaching]** として扱うことがベストプラクティスです。詳細については、「[CloudWatch アラームの欠落データの処理の設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)」および「[アラーム状態への早期移行の回避](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition)」を参照してください。
例えば、メトリクスでエラー率をモニタリングし、エラーがない場合、メトリクスはデータなし (nil) のデータポイントを報告します。欠落データを **[欠落]** として扱うようにアラームを設定すると、1 つの違反データポイントに続いて 2 つのデータなし (nil) データポイントがあると、メトリクスは「Alarm」状態になります (データポイント 3 個中 3 個)。これは、欠落データの設定が評価期間内の最後の既知のデータポイントを評価するためです。
メトリクスでエラー率をモニタリングする場合、サービスの低下がない限り、データがないのは良いことだと考えることができます。欠落データを **[notBreaching]** として扱うことがベストプラクティスです。これにより、欠落データは「OK」として扱われ、メトリクスが単一のデータポイントで「Alarm」状態になることはありません。
## 各アラームの履歴を確認する
アラームの履歴が、頻繁に「Alarm」状態になるものの、すぐに回復していることを示す場合、アラームが問題になっている可能性があります。ノイズや誤アラームを防ぐために、アラームを調整してください。
## 基盤となるリソースのメトリクスを検証する
メトリクスが、基盤となる有効なリソースを参照し、正しい統計情報を使用していることを確認します。無効なリソース名を確認するようにアラームが設定されている場合、アラームは基盤となるデータを追跡できない可能性があります。これにより、アラームが「Alarm」状態になる場合があります。
## 複合アラームを作成する
Incident Detection and Response オペレーションにオンボーディング用のアラームを多数提供すると、複合アラームを作成するように求められる場合があります。複合アラームにより、オンボードする必要があるアラームの総数を減らすことができます。
# CloudFormation テンプレートを使用して Incident Detection and Response で CloudWatch アラームを作成する
AWS Incident Detection and Response へのオンボーディングを高速化し、アラームの作成に必要な労力を削減するために、AWS は CloudFormation テンプレートを提供しています。テンプレートには、Application Load Balancer、Network Load Balancer、Amazon CloudFront など、一般的にオンボーディングされるサービス用に最適化されたアラーム設定が含まれています。
**CloudFormation テンプレートを使用して CloudWatch アラームを作成する**
1. 提供されたリンクを使用してテンプレートをダウンロードします。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IDR/latest/userguide/idr-create-alarms-with-cfn.html)
1. ダウンロードした JSON ファイルを確認し、組織の運用およびセキュリティのプロセスを満たしていることを確認します。
1. CloudFormation スタックを作成します。
**注記**
次の手順では、標準の CloudFormation スタック作成プロセスを使用します。詳細な手順については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で AWS CloudFormation コンソール を開きます。
1. [**Create stack**] を選択します。
1. **[テンプレートの準備完了]** を選択し、ローカルフォルダからテンプレートファイルをアップロードします。
**[スタックを作成]** 画面の例を次に示します。
![\[[スタックを作成] で、テンプレートファイルをアップロードする例\]](http://docs.aws.amazon.com/ja_jp/IDR/latest/userguide/images/create-cfn-stack1.png)
1. [**次へ**] を選択します。
1. 以下の必須情報を入力します。
+ **[AlarmNameConfig]** と **[AlarmDescriptionConfig]**: アラームの名前と説明を入力します。
+ **[ThresholdConfig]**: アプリケーションの要件を満たすようにしきい値を変更します。
+ **[DistributionIDConfig]**: ディストリビューション ID が、CloudFormation スタックを作成するアカウントの正しいリソースを指していることを確認します。
1. [**次へ**] を選択します。
1. **[PeriodConfig]**、**[EvalutionPeriodConfig]**、**[DatapointsToAlarmConfig]** の各フィールドのデフォルト値を確認します。これらのフィールドにはデフォルト値を使用するのがベストプラクティスです。必要に応じて、アプリケーションの要件に合わせて調整できます。
1. 必要に応じて、タグと SNS 通知情報を入力します。アラームが誤って削除されないように、**[終了の保護]** を有効にするのがベストプラクティスです。[終了の保護] を有効にするには、次の例に示すように、**[アクティブ化]** ラジオボタンを選択します。
![\[[スタックを作成] で、[終了の保護] をアクティブ化する例\]](http://docs.aws.amazon.com/ja_jp/IDR/latest/userguide/images/create-cfn-stack2.png)
1. [**次へ**] を選択します。
1. スタックの設定を確認し、**[スタックを作成]** を選択します。
1. スタックを作成すると、次の例に示すように、Amazon CloudWatch の **[アラーム]** リストにアラームが表示されます。
![\[CloudWatch のアラームリストの例\]](http://docs.aws.amazon.com/ja_jp/IDR/latest/userguide/images/create-cfn-stack3.png)
1. すべてのアラームを正しいアカウントおよび AWS リージョンで作成したら、テクニカルアカウントマネージャー (TAM) に通知します。AWS Incident Detection and Response チームは、新しいアラームのステータスを確認し、オンボーディングを続行します。
# 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)