Amazon CloudWatch でのアラームの使用
Amazon CloudWatch でメトリクスと複合アラームを作成できます。
-
1 つの CloudWatch メトリクスを監視する、または複数の CloudWatch メトリクスに基づく数式の結果を監視するメトリクスアラーム。アラームは、メトリクスや式の値が複数の期間にわたって特定のしきい値を超えた場合に 1 つ以上のアクションを実行します。アクションでは、Amazon SNS トピックに通知を送信したり、Amazon EC2 アクションまたは Amazon EC2 Auto Scaling アクションを実行できます。また、Systems Manager で OpsItem またはインシデントを作成できます。
複合アラームには、作成した他のアラームのアラーム状態を考慮したルール式が含まれます。複合アラームは、ルールのすべての条件が満たされた場合に限り、ALARM 状態になります。複合アラームのルール式で指定されたアラームには、メトリクスアラームやその他の複合アラームを含めることができます。
複合アラームを使用すると、アラームノイズを低減できます。複数のメトリクスアラームを作成する、複合アラームを作成する、または複合アラームに対してのみアラートを設定することができます。たとえば、複合が ALARM 状態になるのは、基盤となるすべてのメトリクスアラームが ALARM 状態である場合だけです。
複合アラームは、状態が変更されたときに Amazon SNS 通知を送信できます。また、ALARM 状態になったときに Systems Manager の OpsItems またはインシデントを作成できますが、EC2 アクションまたは Auto Scaling アクションを実行することはできません。
注記
AWS アカウントでは、必要な数だけアラームを作成できます。
ダッシュボードにアラームを追加すると、複数のリージョンにまたがる AWS リソースとアプリケーションを監視してアラートを受信できます。ダッシュボードにアラームを追加すると、アラームは、INSUFFICIENT_DATA 状態の場合はグレーに変わり、ALARM 状態の場合は赤に変わります。OK 状態の場合、アラームは色なしで表示されます。
また、CloudWatch コンソールのナビゲーションペインで、最近アクセスしたアラームを [Favorites and recents] (お気に入りと最近のアクセス) オプションからお気に入りに登録できます。[Favorites and recents] (お気に入りと最近のアクセス) オプションには、お気に入りのアラームと最近アクセスしたアラームの列があります。
アラームは、アラームの状態が変わった場合にのみアクションを呼び出します。例外は、Auto Scaling アクションを持つアラームの場合です。Auto Scaling アクションの場合、アラームは 1 分間に 1 回アクションを呼び出し続け、アラームが新しい状態のままになります。
アラームは、同じアカウントのメトリックスを監視できます。CloudWatch コンソールでクロスアカウント機能を有効にしている場合は、他のAWSアカウントを監視するアラームも作成できます。クロスアカウント複合アラームの作成はサポートされていません。数式を使用するクロスアカウントアラームの作成がサポートされていますが、ANOMALY_DETECTION_BAND、INSIGHT_RULE、および SERVICE_QUOTA 関数は、クロスアカウントアラームではサポートされていません。
注記
CloudWatch は、指定したアクションのテストや検証は行いません。また、存在しないアクションの呼び出しから生じる Amazon EC2 Auto Scaling や Amazon SNS のエラーも検出しません。アラームアクションが存在していることを確認してください。
メトリクスアラームの状態
メトリクスアラームには次の状態があります。
-
OK– メトリクスや式は、定義されているしきい値の範囲内です。 -
ALARM– メトリクスまたは式が、定義されているしきい値を超えています。 -
INSUFFICIENT_DATA– アラームが開始直後であるか、メトリクスが利用できないか、メトリクス用のデータが不足しているため、アラームの状態を判定できません。
アラームの評価
アラームを作成するときに、CloudWatch がアラームの状態を変更するタイミングを評価できるように 3 つの設定を指定します。
-
[期間] は、アラームの各データポイントを作成することを目的として、メトリクスや式を評価するために使用する期間です。これは秒単位で表されます。
-
[Evaluation Periods (評価期間)] は、アラームの状態を決定するまでに要する最新の期間またはデータポイントの数です。
-
[Datapoints to Alarm (アラームを実行するデータポイント)] は、アラームが
ALARM状態に移るためにしきい値を超過する必要がある評価期間内のデータポイントの数です。しきい値を超過したデータポイントは連続している必要はありません。しかしすべてが [Evaluation Period] (評価期間) に相当する直近のデータポイント数に含まれている必要があります。
期間が 1 分以上の場合、アラームは 1 分ごとに評価され、評価は [期間] と [評価期間] で定義されている時間枠に基づいて行われます。例えば、[期間] が 5 分 (300 秒) で、[評価期間] が 1 の場合、5 分終了時に、アラームは 1 分～5 分のデータに基づいて評価されます。続いて、6 分終了時に、2 分～6 分のデータに基づいてアラームが評価されます。
アラーム期間が 10 秒または 30 秒の場合、アラームは 10 秒ごとに評価されます。
次の図では、メトリクスアラームのアラームしきい値が 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、および INSUFFICIENT_DATA の状態の間で状態が変わったときに、アラームが実行するアクションを指定できます。
3 つの状態それぞれに移行するほとんどのアクションを設定できます。Auto Scaling アクションを除き、アクションは状態遷移時にのみ発生し、その状態が数時間または数日間続く場合は再実行されません。1 つのアラームに対して複数のアクションが許可されているという事実を利用して、しきい値を超えたときと、しきい値を超えた状態が終了したときに E メールを送信することができます。これにより、スケーリングまたは回復のアクションが予想どおりにトリガーされ、期待どおりに機能していることを確認できます。
以下がアラームアクションとしてサポートされています。
[Amazon Simple Notification Service トピックを使用] して、1 つ以上のサブスクライバーに通知します。サブスクライバーはアプリケーションでも個人でもかまいません。Amazon SNS の詳細については、「Amazon SNS とは」を参照してください。
[Lambda 関数を呼び出す]。これは、アラーム状態の変化に対するカスタムアクションを自動化する最も簡単な方法です。
-
EC2 メトリクスに基づくアラームは、EC2 インスタンスの停止、終了、再起動、復旧などの [EC2 アクションを実行] することもできます。詳細については、「EC2 インスタンスを停止、終了、再起動、または復旧するアラームを作成する」を参照してください。
アラームは、[Auto Scaling グループをスケールする] アクションを実行することもできます。詳細については、「Amazon EC2 Auto Scaling のステップおよびシンプルスケーリングポリシー」を参照してください。
-
アラームは、[Systems Manager Ops Center で OpsItems を作成するか、AWS Systems Manager Incident Manager でインシデントを作成する] ことができます。これらのアクションは、アラームが ALARM 状態になった場合にのみ実行されます。詳細については、「アラームから OpsItems を作成するように CloudWatch を設定する」および「インシデントの作成」を参照してください。
Lambda アラームアクション
CloudWatch アラームは、次の場合を除き、特定の状態変化に対して Lambda 関数の非同期呼び出しを保証します。
関数が存在しない場合。
CloudWatch が Lambda 関数を呼び出す権限がない場合。
CloudWatch が Lambda サービスに到達できない場合、または別の理由でメッセージが拒否された場合、CloudWatch は呼び出しが成功するまで再試行します。Lambda はメッセージをキューに入れ、実行の再試行を処理します。Lambda がエラーを処理する方法など、この実行モデルの詳細については、「AWS Lambda デベロッパーガイド」の「非同期呼び出し」を参照してください。
Lambda 関数は、同じアカウントまたは他の AWS アカウントで呼び出すことができます。
アラームアクションとして Lambda 関数を呼び出すアラームを指定する場合、関数名、関数エイリアス、または関数の特定のバージョンを指定することもできます。
アラームアクションとして Lambda 関数を指定する場合は、関数のリソースポリシーを作成して、CloudWatch サービスプリンシパルによる関数の呼び出しを許可する必要があります。
これを行う 1 つの方法は、次の例のように AWS CLI を使用することです。
aws lambda add-permission \ --function-namemy-function-name\ --statement-id AlarmAction \ --action 'lambda:InvokeFunction' \ --principal lambda.alarms.cloudwatch.amazonaws.com \ --source-account111122223333\ --source-arn arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name
または、次の例のいずれかに似たポリシーを作成し、それを関数に割り当てることもできます。
次の例では、アラームが配置されているアカウントを指定して、そのアカウント (111122223333) のアラームだけが関数を呼び出せるようにします。
{ "Version": "2012-10-17", "Id": "default", "Statement": [{ "Sid": "AlarmAction", "Effect": "Allow", "Principal": { "Service": "lambda.alarms.cloudwatch.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name", "Condition": { "StringEquals": { "AWS:SourceAccount": "111122223333" } } }] }
次の例では対象範囲が狭いため、指定したアカウントの指定したアラームだけが関数を呼び出せるようになっています。
{ "Version": "2012-10-17", "Id": "default", "Statement": [ { "Sid": "AlarmAction", "Effect": "Allow", "Principal": { "Service": "lambda.alarms.cloudwatch.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name", "Condition": { "StringEquals": { "AWS:SourceAccount": "111122223333", "AWS:SourceArn": "arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name" } } }] }
ソースアカウントを指定しないポリシーは、混乱した代理問題に対して脆弱であるため、作成することはお勧めしません。
CloudWatch から Lambda に送信されたイベントオブジェクト
Lambda 関数をアラームアクションとして設定すると、CloudWatch は Lambda 関数を呼び出したときに JSON ペイロードを Lambda 関数に配信します。この JSON ペイロードは、関数のイベントオブジェクトとして機能します。この JSON オブジェクトからデータを抽出して、関数で使用できます。以下は、メトリクスアラームのイベントオブジェクトの例です。
{ 'source': 'aws.cloudwatch', 'alarmArn': 'arn:aws:cloudwatch:us-east-1:444455556666:alarm:lambda-demo-metric-alarm', 'accountId': '444455556666', 'time': '2023-08-04T12:36:15.490+0000', 'region': 'us-east-1', 'alarmData': { 'alarmName': 'lambda-demo-metric-alarm', 'state': { 'value': 'ALARM', 'reason': 'test', 'timestamp': '2023-08-04T12:36:15.490+0000' }, 'previousState': { 'value': 'INSUFFICIENT_DATA', 'reason': 'Insufficient Data: 5 datapoints were unknown.', 'reasonData': '{"version":"1.0","queryDate":"2023-08-04T12:31:29.591+0000","statistic":"Average","period":60,"recentDatapoints":[],"threshold":5.0,"evaluatedDatapoints":[{"timestamp":"2023-08-04T12:30:00.000+0000"},{"timestamp":"2023-08-04T12:29:00.000+0000"},{"timestamp":"2023-08-04T12:28:00.000+0000"},{"timestamp":"2023-08-04T12:27:00.000+0000"},{"timestamp":"2023-08-04T12:26:00.000+0000"}]}', 'timestamp': '2023-08-04T12:31:29.595+0000' }, 'configuration': { 'description': 'Metric Alarm to test Lambda actions', 'metrics': [ { 'id': '1234e046-06f0-a3da-9534-EXAMPLEe4c', 'metricStat': { 'metric': { 'namespace': 'AWS/Logs', 'name': 'CallCount', 'dimensions': { 'InstanceId': 'i-12345678' } }, 'period': 60, 'stat': 'Average', 'unit': 'Percent' }, 'returnData': True } ] } } }
以下は、複合アラームのイベントオブジェクトの例です。
{ 'source': 'aws.cloudwatch', 'alarmArn': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:SuppressionDemo.Main', 'accountId': '111122223333', 'time': '2023-08-04T12:56:46.138+0000', 'region': 'us-east-1', 'alarmData': { 'alarmName': 'CompositeDemo.Main', 'state': { 'value': 'ALARM', 'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC', 'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}', 'timestamp': '2023-08-04T12:56:46.138+0000' }, 'previousState': { 'value': 'ALARM', 'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC', 'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}', 'timestamp': '2023-08-04T12:54:46.138+0000', 'actionsSuppressedBy': 'WaitPeriod', 'actionsSuppressedReason': 'Actions suppressed by WaitPeriod' }, 'configuration': { 'alarmRule': 'ALARM(CompositeDemo.FirstChild) OR ALARM(CompositeDemo.SecondChild)', 'actionsSuppressor': 'CompositeDemo.ActionsSuppressor', 'actionsSuppressorWaitPeriod': 120, 'actionsSuppressorExtensionPeriod': 180 } } }
CloudWatch アラームの欠落データの処理の設定
場合によっては、メトリクスの予想されるすべてのデータポイントが CloudWatch にレポートされないことがあります。たとえば、接続が失われた場合、サーバーがダウンした場合、メトリクスがデータを断続的にのみ報告する設計になっている場合などに、これが発生する可能性があります。
CloudWatch では、アラームを評価する際の欠落データポイントの処理方法を指定できます。これにより、モニターリング対象のデータのタイプに適した場合にのみ ALARM 状態になるように、アラームを設定できます。欠落データが問題を示すものではない場合の誤検出を避けることができます。
各アラームが常に 3 つの状態のいずれかであるように、CloudWatch にレポートされるデータポイントはそれぞれ、次の 3 つのカテゴリのいずれかの状態に該当します。
-
Not breaching (しきい値内)
-
Breaching (しきい値を超過)
-
Missing (見つからない)
アラームごとに、CloudWatch が欠落データポイントを次のいずれかとして処理するように指定できます。
-
notBreaching– 欠落データポイントは「良好」かつしきい値内として扱われます。 -
breaching– 欠落データポイントは「不良」とされ、しきい値超過として扱われます。 -
ignore– 現在のアラーム状態が維持されます。 -
missing– アラーム評価範囲内のすべてのデータポイントがない場合、アラームは INSUFFICIENT_DATA に移行します。
最適な選択は、メトリクスの種類とアラームの目的によって異なります。例えば、継続的にデータをレポートするメトリクスを使用してアプリケーションのロールバックアラームを作成する場合、欠落しているデータポイントは何らかの問題の存在を示している可能性があるため、違反として扱うことが推奨されます。ただし、Amazon DynamoDB の ThrottledRequests など、エラー発生時のみデータポイントを生成するメトリクスの場合は、notBreaching として欠落データを処理します。デフォルトの動作は missing です。
重要
Amazon EC2 メトリクスに設定されたアラームは、メトリクスデータポイントが欠落している場合、一時的に INSUFFICIENT_DATA 状態になることがあります。まれに、Amazon EC2 インスタンスが正常であっても、メトリクスレポートが中断されたときに、これが発生することがあります。アクションの停止、終了、再起動、復旧を行うように設定された Amazon EC2 メトリクスのアラームについては、欠落データを missing として扱い、アラームが ALARM 状態にある場合にのみトリガーされるように、これらのアラームを設定することが推奨されます。
アラームに最適なオプションを選択することで、アラームが、不要で誤解を招く状態に変更されることを防ぐだけでなく、システムの状態をさらに正確に表すことができます。
重要
AWS/DynamoDB 名前空間のメトリクスを評価するアラームでは、アラームで欠落データを扱う方法について他のオプションを選択した場合でも、欠落データは常に無視されます。AWS/DynamoDB メトリクスに欠落データがある場合、そのメトリクスを評価するアラームは現在の状態のままです。
データが欠落した場合のアラーム状態の評価方法
アラームが状態を変更するかどうかを評価するたびに、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 |
|
|
|
|
|
- - - - 0 |
2 |
|
|
|
|
|
- - - - - |
3 |
|
現在の状態を維持 |
|
|
|
0 X X - X |
0 |
|
|
|
|
|
- - X - - |
2 |
|
現在の状態を維持 |
|
|
前の表の 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 |
|
|
|
|
|
0 0 X 0 X |
0 |
|
|
|
|
|
0 - X - - |
1 |
|
|
|
|
|
- - - - 0 |
2 |
|
|
|
|
|
- - - X - |
2 |
|
現在の状態を維持 |
|
|
行 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 状態になります。これは、[Evaluation Periods] (評価期間) 中のデータポイントのうち、利用可能な最も古い超過データポイントが、[Datapoints to Alarm] (アラームへのデータポイント) の値と少なくとも同じように古く、他のすべての最新のデータポイントが超過または欠落している場合にアラームが常に ALARM 状態になるように設計されているためです。この場合、使用可能なデータポイントの総数が M ([Datapoints to Alarm (アラームを実行するデータポイント)]) より少ない場合でも、アラームは ALARM 状態になります。
このアラームロジックは、N 個中 M 個のアラームにも適用されます。評価範囲で最も古い違反データポイントが [アラームを実行するデータポイント] の値と少なくとも同じくらい古く、最近のすべてのデータポイントが違反または欠落している場合、M ([アラームを実行するデータポイント]) の値に関係なくアラームは ALARM 状態になります。
高解像度アラーム
高解像度メトリクスでアラームを設定する場合、10 秒または 30 秒の期間で高解像度アラームを指定するか、60 秒の倍数の期間で通常のアラームを設定できます。高解像度のアラームには高い料金が発生します。高解像度メトリクスの詳細については、「カスタムメトリクスをパブリッシュする」を参照してください。
数式に基づくアラーム
1 つ以上の CloudWatch メトリクスに含む数式の結果に基づいてアラームを設定できます。アラーム用の数式には 10 個までのメトリクスを含めることができます。各メトリクスは同じ期間を使用している必要があります。
数式に基づくアラームの場合、データポイントの欠落を CloudWatch で処理する方法を指定できます。この場合、数式がそのデータポイントの値を返さない場合、そのデータポイントは欠落していると見なされます。
数式に基づくアラームでは Amazon EC2 アクションを実行できません。
メトリクスの数式と構文の詳細については、「CloudWatch メトリクスでの数式の使用」を参照してください。
パーセンタイルベースの CloudWatch アラームおよび少数のデータサンプル
アラームの統計としてパーセンタイルを設定すると、統計評価に使用する十分なデータがない場合の処理を指定することができます。そのまま統計を評価し、任意でアラームの状態を変更するように指定することもできます。また、サンプルサイズが小さい場合は、メトリクスを無視し、統計的に十分なデータが揃うまで評価を保留することもできます。
パーセンタイルが 0.5 以上 1.00 未満の場合、この設定は、評価期間中にデータポイントが 10/(1- パーセンタイル) を下回ると使用されます。たとえば、この設定は、p99 パーセンタイルのアラームのサンプル数が 1000 を下回ると使用されます。パーセンタイルが 0 以上 0.5 未満の場合、この設定は、データポイントが 10/パーセンタイルを下回ると使用されます。
CloudWatch アラームの一般的な機能
次の機能は、すべての CloudWatch アラームに適用されます。
-
作成できるアラームの数に制限はありません。アラームを作成または更新するには、CloudWatch コンソール、PutMetricAlarm API アクション、または AWS CLI の put-metric-alarm コマンドを使用します。
-
アラーム名には UTF-8 文字のみを使用する必要があり、ASCII 制御文字は使用できません。
-
現在設定しているアラームのいずれかまたはすべてを一覧表示したり、特定の状態にあるアラームを一覧表示したりするには、CloudWatch コンソール、DescribeAlarms API アクション、または AWS CLI の describe-alarms コマンドを使用します。
-
アラームを無効または有効にするには、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 は、アラーム履歴を 30 日間保存します。状態変化ごとに固有のタイムスタンプが付きます。まれに、1 つの状態変化に対して複数の通知が履歴に残されることがあります。タイムスタンプによって状態変化を区別できます。
-
[Favorites and recents] (お気に入りと最近のアクセス) オプションでお気に入りのアラームにカーソルを合わせ、その横にある星記号をクリックして、CloudWatch コンソールのナビゲーションペインにお気に入りとして登録できます。
-
アラームの評価期間の数を各評価期間の長さで乗算した値が 1 日を超えることはできません。
注記
特定の状況では、AWS リソースが CloudWatch にメトリクスデータを送信しないことがあります。
例えば、Amazon EBS は、Amazon EC2 インスタンスに追加されていない利用可能なボリュームに関するメトリクスデータを送信しないことがあります。これは、そのボリュームでモニターリングするメトリクスの動作がないためです。このようなメトリクスにアラームを設定すると、状態が INSUFFICIENT_DATA に変わる場合があります。これは、リソースが動作していないことを示すもので、必ずしも問題があることを意味しているわけではありません。各アラームが欠落データを処理する方法を指定できます。詳細については、「CloudWatch アラームの欠落データの処理の設定」を参照してください。
