Amazon CloudWatch でのアラームの使用 - Amazon CloudWatch

Amazon CloudWatch でのアラームの使用

CloudWatch では、メトリクスアラーム複合アラームの両方を作成できます。

  • 1 つの CloudWatch メトリクスを監視する、または複数の CloudWatch メトリクスに基づく数式の結果を監視するメトリクスアラーム。アラームは、メトリクスや式の値が複数の期間にわたって特定のしきい値を超えた場合に 1 つ以上のアクションを実行します。アクションは、Amazon SNS トピックに通知を送信したり、Amazon EC2 アクションまたは Auto Scaling アクションを実行したり、Systems Manager で OpsItem またはインシデントを作成したりできます。

  • 複合アラームには、作成した他のアラームのアラーム状態を考慮したルール式が含まれます。複合アラームは、ルールのすべての条件が満たされた場合に限り、ALARM 状態になります。複合アラームのルール式で指定されたアラームには、メトリクスアラームやその他の複合アラームを含めることができます。

    複合アラームを使用すると、アラームノイズを低減できます。複数のメトリクスアラームを作成する、複合アラームを作成する、または複合アラームに対してのみアラートを設定することができます。たとえば、複合が ALARM 状態になるのは、基盤となるすべてのメトリクスアラームが ALARM 状態である場合だけです。

    複合アラームは、状態が変更されたときに Amazon SNS 通知を送信できます。また、ALARM 状態になったときに Systems Manager の OptSite またはインシデントを作成できますが、EC2 アクションまたは Auto Scaling アクションを実行することはできません。

CloudWatch ダッシュボードにアラームを追加して視覚的にモニタリングできます。ダッシュボードにある場合、ALARM 状態になると、アラームは赤に変わるため、状態を事前にモニタリングしやすくなります。

アラームは、アラームの状態が変わった場合にのみアクションを呼び出します。例外は、Auto Scaling アクションを持つアラームの場合です。Auto Scaling アクションの場合、アラームは 1 分間に 1 回アクションを呼び出し続け、アラームが新しい状態のままになります。

アラームは、同じアカウントのメトリックスを監視できます。CloudWatch コンソールでクロスアカウント機能を有効にしている場合は、他のAWSアカウントを監視するアラームも作成できます。クロスアカウント複合アラームの作成はサポートされていません。数式を使用するクロスアカウントアラームの作成がサポートされていますが、ANOMALY_DETECTION_BANDINSIGHT_RULE、および SERVICE_QUOTA 関数は、cross=account アラームではサポートされていません。

注記

CloudWatch は、指定したアクションのテストや検証は行いません。また、存在しないアクションの呼び出しから生じる Amazon EC2 Auto Scaling や Amazon SNS のエラーも検出しません。アラームアクションが存在していることを確認してください。

メトリクスアラームの状態

メトリクスアラームには次の状態があります。

  • OK – メトリクスや式は、定義されているしきい値の範囲内です。

  • ALARM – メトリクスまたは式が、定義されているしきい値を超えています。

  • INSUFFICIENT_DATA – アラームが開始直後であるか、メトリクスが利用できないか、メトリクス用のデータが不足しているため、アラームの状態を判定できません。

アラームの評価

アラームを作成するときに、CloudWatch がアラームの状態を変更するタイミングを評価できるように 3 つの設定を指定します。

  • [期間] は、アラームの各データポイントを作成するためにメトリクスや式を評価する期間です。これは秒単位で表されます。期間として 1 分を選択した場合、アラームはメトリクスを 1 分あたり 1 回評価します。

  • [Evaluation Periods (評価期間)] は、アラームの状態を決定するまでに要する最新の期間またはデータポイントの数です。

  • [Datapoints to Alarm (アラームを実行するデータポイント)] は、アラームが ALARM 状態に移るためにしきい値を超過する必要がある評価期間内のデータポイントの数です。しきい値を超えたデータポイントは連続している必要はありませんが、すべてが [評価期間] に相当する直近のデータポイント数に含まれている必要があります。

次の図では、メトリクスアラームのアラームしきい値が 3 単位に設定されています。[Evaluation Periods (評価期間)] と [Datapoints to Alarm (アラームを実行するデータポイント)] はどちらも 3 です。つまり、連続する最新の 3 つの期間内の既存のデータポイントすべてがしきい値を上回わると、アラームは ALARM 状態になります。この図では、第 3 期間から第 5 期間にかけてこれが発生します。第 6 期間で値がしきい値を下回り、評価対象の期間の 1 つが超過していないため、アラームの状態は OK に変化します。第 9 期間中のしきい値に再度超過がありますが、1 つの期間のみです。そのため、アラームの状態は OK のままです。


        アラームのしきい値によるアラームのトリガー

[Evaluation Periods (評価期間)] と [Datapoints to Alarm (アラームを実行するデータポイント)] に異なる値を設定する場合、「N 個中 M 個」のアラームを設定することになります。[Datapoints to Alarm (アラームを実行するデータポイント)] が (「M」)、[Evaluation Periods (評価期間)] が (「N」) です。評価間隔は、データポイント数を期間で乗算した値です。たとえば、1 分の期間を持つ 5 個のデータポイントのうち 4 個を設定した場合、評価間隔は 5 分です。10 分の期間を持つ 3 個のデータポイントのうち 3 個を設定した場合、評価間隔は 30 分です。

注記

アラームの作成後すぐにデータポイントが欠落し、アラームの作成前にメトリクスが CloudWatch に報告されている場合、CloudWatch はアラームを評価する際にアラーム作成前の直近のデータポイントを取得します。

アラームアクション

OK、ALARM、および INSUFFICENT_DATA の状態の間で状態が変わったときに、アラームが実行するアクションを指定できます。アラームアクションの最も一般的なタイプは、Amazon Simple Notification Service トピックにメッセージを送信して 1 人または複数のユーザーに通知することです。Amazon SNS の詳細については、「Amazon SNS とは」を参照してください。

EC2 メトリクスに基づくアラームは、EC2 インスタンスの停止、終了、再起動、復旧などの EC2 アクションを実行することもできます。詳細については、「EC2 インスタンスを停止、終了、再起動、または回復するためのアラームを作成する」を参照してください。

アラームは、Auto Scaling グループをスケールするアクションを実行することもできます。詳細については、「Amazon EC2 Auto Scaling のステップおよびシンプルスケーリングポリシー」を参照してください。

Systems Manager Ops Center で OpsItems を作成したり、AWS Systems Manager Incident Manager でインシデントを作成したりするアラームを設定することもできます。これらのアクションは、アラームが ALARM 状態になったときにだけ実行されます。詳細については、「アラームから OpsItems を作成するように CloudWatch を設定する」および「インシデントの作成」を参照してください。

CloudWatch アラームの欠落データの処理の設定

場合によっては、メトリクスの予想されるすべてのデータポイントが CloudWatch にレポートされないことがあります。たとえば、接続が失われた場合、サーバーがダウンした場合、メトリクスがデータを断続的にのみ報告する設計になっている場合などに、これが発生する可能性があります。

CloudWatch では、アラームを評価する際の欠落データポイントの処理方法を指定できます。これにより、モニタリング対象のデータのタイプに適した場合にのみ ALARM 状態になるように、アラームを設定できます。欠落データが問題を示すものではない場合の誤検出を避けることができます。

各アラームが常に 3 つの状態のいずれかであるように、CloudWatch にレポートされるデータポイントはそれぞれ、次の 3 つのカテゴリのいずれかの状態に該当します。

  • Not breaching (しきい値内)

  • Breaching (しきい値を超過)

  • Missing (見つからない)

アラームごとに、CloudWatch が欠落データポイントを次のいずれかとして処理するように指定できます。

  • notBreaching – 欠落データポイントは「良好」とされ、しきい値内として扱われます。

  • breaching – 欠落データポイントは「不良」とされ、しきい値超過として扱われます。

  • ignore – 現在のアラーム状態が維持されます。

  • missing – アラーム評価範囲内のすべてのデータポイントがない場合、アラームは INSUFFICIENT_DATA に移行します。

最適な選択は、メトリクスの種類によって異なります。インスタンスの CPUUtilization など、継続的にデータを報告するメトリクスの場合、欠落データポイントは問題の発生を示している可能性があるため、breaching として処理します。ただし、Amazon DynamoDB の ThrottledRequests など、エラー発生時のみデータポイントを生成するメトリクスの場合は、notBreaching として欠落データを処理します。デフォルトの動作は missing です。

アラームに最適なオプションを選択することで、アラームが、不要で誤解を招く状態に変更されることを防ぐだけでなく、システムの状態をさらに正確に表すことができます。

データが欠落した場合のアラーム状態の評価方法

アラームが状態を変更するかどうかを評価するたびに、CloudWatch は [Evaluation Periods (評価期間)] に指定されている数よりも多くのデータポイントを取得しようとします。取得を試みるデータポイントの正確な数は、アラーム期間の長さと、基づいているメトリクスが標準解像度か高解像度かによって異なります。取得を試みるデータポイントのタイムフレームは評価範囲です。

CloudWatch がこれらのデータポイントを取得すると、次の処理が実行されます。

  • 評価範囲内のデータポイントが欠落していない場合、CloudWatch は収集された最新のデータポイントに基づいてアラームを評価します。評価されるデータポイントの数は、アラームの [Evaluation Periods (評価期間) ] と同じです。評価範囲内のよりさかのぼった時点からの余分なデータポイントは必要なく、無視されます。

  • 評価範囲内のデータポイントの一部が欠落しているが、評価範囲から正常に取得された既存のデータポイントの合計数がアラームの [Evaluation Periods (評価期間) ] 以上である場合、CloudWatch は、最新の正常に取得された最新のデータポイントに基づいたアラームの状態を評価します (評価範囲内のよりさかのぼった時点からの必要な追加データポイントを含む)。この場合、欠落データを処理する方法に設定した値は不要であり、無視されます。

  • 評価範囲のデータポイントの一部が欠落しており、取得された既存のデータポイントの数がアラームの [Evaluation Periods (評価期間)] の数を下回る場合、CloudWatch によって、欠落データ部分に欠落データの処理方法に指定された結果が入力され、アラームが評価されます。ただし、評価範囲内のすべての実際のデータポイントが評価に含まれます。CloudWatch は、欠落データポイントの使用を最小限に抑えます。

注記

この動作の特殊なケースは、メトリクスのフローが停止した後の一定期間、CloudWatch アラームが最後のデータポイントのセットを繰り返し再評価する可能性があることです。この再評価により、メトリクスのストリームが停止する直前にアラームの状態が変更されていた場合に、アクションが再実行される可能性があります。この動作を軽減するには、より短い期間を使用します。

次の表は、アラーム評価の動作の例を示しています。最初の表では、[Datapoints to Alarm (アラームを発生させるデータポイント数)] と [Evaluation Periods (評価期間)] はどちらも 3 です。CloudWatch は、直近の 3 個のデータポイントの一部が欠落している場合、アラームを評価する際に直近のデータポイントを 5 個取得します。5 はアラームの評価範囲です。

列 1 は、評価範囲が 5 であるため、最新の 5 つのデータポイントを示しています。これらのデータポイントが、右側が最新のデータポイントになるように表示されます。0 は違反していないデータポイント、X は違反しているデータポイント、- は欠落しているデータポイントを示します。

列 2 は、3 つの必要なデータポイントの欠落数を示します。最新の 5 個のデータポイントが評価されている場合でも、アラーム状態を評価する上で必要なデータポイントは 3 個 ([評価期間] の設定) のみです。列 2 のデータポイントの数は、欠落データの処理方法に関する設定を使用して「入力する」必要があるデータポイント数です。

列 3~6 では、列ヘッダーが欠落データの処理方法を示す値になります。これらの列の行には、欠損データを処理するためのこれらの可能な方法ごとに設定されたアラーム状態が表示されます。

データポイント 埋める必要のあるデータポイントの数 MISSING IGNORE BREACHING NOT BREACHING

0 - X - X

0

OK

OK

OK

OK

- - - - 0

2

OK

OK

OK

OK

- - - - -

3

INSUFFICIENT_DATA

現在の状態を維持

ALARM

OK

0 X X - X

0

ALARM

ALARM

ALARM

ALARM

- - X - -

2

ALARM

Retain current state

ALARM

OK

前の表の 2 行目で、欠落データが超過として処理されても、アラームは OK のままです。既存のデータポイント 1 個が超過しておらず、これが超過として処理される欠落データポイント 2 個とともに評価されるためです。次回このアラームが評価される際にデータがまだ欠落したままであれば ALARM に遷移します。これは、超過していないデータポイントが、評価範囲に含まれなくなるためです。

3 番目の行では、最新の 5 つのデータポイントがすべて欠落しており、欠落したデータの処理方法に関するさまざまな設定がアラームの状態にどのように影響するかを示しています。欠落しているデータポイントが超過していると見なされるとアラームは ALARM 状態になり、超過していないと見なされるとアラームは OK 状態になります。欠落しているデータポイントを無視すると、アラームは欠落しているデータポイントよりも前の現在の状態を保持します。また、欠落しているデータポイントが欠落しているとみなされた場合、アラームには評価を行うのに十分な最近の実際のデータがないため、INSUFFICIENT_DATA に入ります。

4 行目では、最新の 3 つのデータポイントが超過しており、アラームの [Evaluation Periods (評価期間)] と [Datapoints to Alarm (アラームを実行するデータポイント)] が両方とも 3 に設定されているため、アラーム は ALARM 状態になります。この場合、欠落データポイントは無視され、欠落データの評価方法の設定は必要ありません。これは、評価する実際のデータポイントが 3 つあるためです。

行 5 は、早期アラーム状態と呼ばれる、アラーム評価の特別なケースを表します。詳細については、「アラーム状態への早期移行の回避」を参照してください。

次の表では、[期間] は再び 5 分に設定され、[Datapoints to Alarm (アラームを発生させるデータポイント数)] は 2 のみですが [評価期間] は 3 です。つまり 3 個のうち 2 個、N 個中 M のアラームです。

評価範囲は 5 です。これは、取得される最近のデータポイントの最大数であり、一部のデータポイントが欠落している場合に使用できます。

データポイント 欠落データポイント数 MISSING IGNORE BREACHING NOT BREACHING

0 - X - X

0

ALARM

ALARM

ALARM

ALARM

0 0 X 0 X

0

ALARM

ALARM

ALARM

ALARM

0 - X - -

1

OK

OK

ALARM

OK

- - - - 0

2

OK

OK

ALARM

OK

- - - X -

2

ALARM

現在の状態を維持

ALARM

OK

行 1 と 2 では、最新の 3 つのデータポイントのうちの 2 つが超過しているため、アラームは常に ALARM 状態になります。行 2 では、評価範囲内の最も古い 2 つのデータポイントは不要です。これは、最新の 3 つのデータポイントのいずれも欠落していないためです。したがって、これらの 2 つの古いデータポイントは無視されます。

行 3 と 4 では、アラームは ALARM 状態になります。この場合、欠落データが超過として扱われる場合のみ、最新の 2 つの欠落データポイントは両方とも超過として扱われます。行 4 では、超過として扱われるこれらの 2 つの欠落データポイントは、ALARM 状態をトリガーするのに必要な 2 つの超過データポイントを提供します。

行 5 は、早期アラーム状態と呼ばれる、アラーム評価の特別なケースを表します。詳細については、以下のセクションを参照してください。

アラーム状態への早期移行の回避

CloudWatch アラーム評価には、データが断続的な場合にアラームが早く ALARM 状態になる誤アラームを回避しようとするロジックが含まれています。前のセクションの表の行 5 に示した例は、このロジックを示しています。これらの行および次の例では、[Evaluation Periods (評価期間)] は 3 で、評価範囲は 5 データポイントです。[Datapoints to Alarm (アラームを実行するデータポイント)] は 3 ですが、N 個のうち M の例を除いて、[Datapoints to Alarm (アラームを実行するデータポイント)] は 2 です。

アラームの最新のデータが - - - - X で 、4 つのデータポイントが欠落しており、最新のデータポイントとして超過データポイントがあるとします。次のデータポイントは超過していない可能性があるため、データが - - - - X または - - - X - で、[Datapoints to Alarm (アラームを実行するデータポイント)] が 3 の場合、アラームはすぐに ALARM 状態になりません。このようにして、次のデータポイントが超過しておらず、データが - - - X O または - - X - O になる場合に誤検出が回避されます。

ただし、最後の数個のデータポイントが - - X - - の場合、欠落しているデータポイントが欠落していると見なされても、アラームは ALARM 状態になります。これは、評価期間のデータポイント数の間に利用可能な最も古い超過データポイントが、少なくとも [Datapoints to Alarm (アラームを実行するデータポイント)] の値と同じように古い場合、およびその他すべての最新のデータポイントが超過または欠落している場合に、アラームが常に ALARM 状態になるように設計されているためです。この場合、使用可能なデータポイントの総数が M ([Datapoints to Alarm (アラームを実行するデータポイント)]) より少ない場合でも、アラームは ALARM 状態になります。

このアラームロジックは、N 個のアラームのうち M にも適用されます。評価期間で最も古い違反データポイントが [Datapoints to Alarm (アラームを実行するデータポイント)] の値と同じくらい古く、最近のすべてのデータポイントが違反または欠落している場合、M の値に関係なくアラームは ALARM 状態になります (Datapoints to Alarm (アラームを実行するデータポイント))。

高解像度アラーム

高解像度メトリクスでアラームを設定する場合、10 秒または 30 秒の期間で高解像度アラームを指定するか、60 秒の倍数の期間で通常のアラームを設定できます。高解像度のアラームには高い料金が発生します。高解像度メトリクスの詳細については、「カスタムメトリクスの発行」を参照してください。

数式に基づくアラーム

1 つ以上の CloudWatch メトリクスに含む数式の結果に基づいてアラームを設定できます。アラーム用の数式には 10 個までのメトリクスを含めることができます。各メトリクスは同じ期間を使用している必要があります。

数式に基づくアラームの場合、アラームの評価対象となるメトリクスのデータポイントの欠落を CloudWatch で処理する方法を指定できます。

数式に基づくアラームでは Amazon EC2 アクションを実行できません。

メトリクスの数式と構文の詳細については、「Metric Math を使用する」を参照してください。

パーセンタイルベースの CloudWatch アラームおよび少数のデータサンプル

アラームの統計としてパーセンタイルを設定すると、統計評価に使用する十分なデータがない場合の処理を指定することができます。そのまま統計を評価し、任意でアラームの状態を変更するように指定することもできます。また、サンプルサイズが小さい場合は、メトリクスを無視し、統計的に十分なデータが揃うまで評価を保留することもできます。

パーセンタイルが 0.5 以上 1.00 未満の場合、この設定は、評価期間中にデータポイントが 10/(1- パーセンタイル) を下回ると使用されます。たとえば、この設定は、p99 パーセンタイルのアラームのサンプル数が 1000 を下回ると使用されます。パーセンタイルが 0 以上 0.5 未満の場合、この設定は、データポイントが 10/パーセンタイルを下回ると使用されます。

CloudWatch アラームの一般的な機能

次の機能は、すべての CloudWatch アラームに適用されます。

  • 作成できるアラームの数に制限はありません。アラームを作成または更新するには、CloudWatch コンソール、PutMetricAlarm API アクション、または AWS CLI の put-metric-alarm コマンドを使用します。

  • アラーム名には ASCII 文字のみを使用する必要があります。

  • 現在設定しているアラームのいずれかまたはすべてを一覧表示したり、特定の状態にあるアラームを一覧表示したりするには、CloudWatch コンソール、DescribeAlarms API アクション、または AWS CLI の describe-alarms コマンドを使用します。

  • アラームを無効または有効にするには、CloudWatch コンソール、DisableAlarmActions および EnableAlarmActions API アクション、または AWS CLI の disable-alarm-actions および enable-alarm-actions コマンドを使用します。

  • アラームの動作をテストするには、SetAlarmState API アクションまたは AWS CLI の set-alarm-state コマンドを使用して、アラームを任意の状態に設定します。この一時的な状態変更が持続するのは、次のアラーム比較が行われるときまでです。

  • カスタムメトリクスを作成する前に、カスタムメトリクスのアラームを作成できます。アラームを有効にするには、メトリクス名前空間およびメトリクス名に加えて、カスタムメトリクスのディメンションをすべてアラームの定義に含める必要があります。これを行うには、PutMetricAlarm API アクションを使用するか、AWS CLI で put-metric-alarm コマンドを使用します。

  • アラームの履歴を表示するには、CloudWatch コンソール、DescribeAlarmHistory API アクション、または AWS CLI の describe-alarm-history コマンドを使用します。CloudWatch は、アラーム履歴を 2 週間保存します。状態変化ごとに固有のタイムスタンプが付きます。まれに、1 つの状態変化に対して複数の通知が履歴に残されることがあります。タイムスタンプによって状態変化を区別できます。

  • アラームの評価期間の数を各評価期間の長さで乗算した値が 1 日を超えることはできません。

注記

特定の状況では、AWS リソースが CloudWatch にメトリクスデータを送信しないことがあります。

例えば、Amazon EBS は、Amazon EC2 インスタンスに追加されていない利用可能なボリュームに関するメトリクスデータを送信しないことがあります。これは、そのボリュームでモニタリングするメトリクスの動作がないためです。このようなメトリクスにアラームを設定すると、状態が INSUFFICIENT_DATA に変わる場合があります。これは、リソースが動作していないことを示すもので、必ずしも問題があることを意味しているわけではありません。各アラームが欠落データを処理する方法を指定できます。詳細については、「CloudWatch アラームの欠落データの処理の設定」を参照してください。