複合アラームの作成 - Amazon CloudWatch

複合アラームの作成

複合アラームでは、他のアラームの状態を監視して、それらの状態を判別できます。複合アラームを使用すると、アラームのノイズを低減できます。例えば、特定の条件を満たす場合に、基盤となるメトリクスのアラームが ALARM 状態になる複合アラームを作成できます。また、基盤となるメトリクスアラームがアクションを実行しないように設定することで、それらが ALARM 状態になったときに複合アラームが ALARM 状態になるように設定したり、通知を送信するように設定できます。現在、複合アラームでは次のアクションを実行できます。

  • SNS トピックの通知

  • AWS Systems Manager Ops Center での OpsItems の作成

  • AWS Systems Manager Incident Manager でのインシデントの作成

注記

複合アラームの基盤となるすべてのアラームは、複合アラームと同じ AWS アカウントおよびリージョンにある必要があります。1 つの複合アラームで 100 の基盤となるアラームを監視でき、1 つのアラームは 150 の複合アラームで監視できます。

ルール式

すべての複合アラームには、ルール式が含まれています。ルール式は、複合アラームに監視および状態を判別するアラームを指示するものです。ルール式では、メトリクスアラームと複合アラームを参照できます。ルール式でアラームを参照するときは、アラームが次の 3 つのうちのどの状態になるかを決定する関数をアラームに指定します。

  • アラーム

    ALARM (「alarm-name または alarm-ARN」) は、指定されたアラームが ALARM 状態である場合に TRUE になります。

  • OK

    OK (「alarm-name または alarm-ARN」) は、指定されたアラームが ALARM 状態である場合に TRUE になります。

  • INSUFFICIENT_DATA

    INSUFFICIENT_DATA (「alarm-name または alarm-ARN」) は、指定されたアラームが INSUFFICIENT_DATA 状態である場合に TRUE になります。

注記

TRUE は常に TRUE と評価され、FALSE は常に FALSE と評価されます。

式の例

リクエストパラメータ AlarmRule は、論理演算子 ANDOR、および NOT の使用をサポートしています。これにより、複数の関数を 1 つの式に組み合わせることができます。次の式の例は、複合アラームで基盤となるアラームを設定する方法を示しています。

  • ALARM(CPUUtilizationTooHigh) AND ALARM(DiskReadOpsTooHigh)

    この式は、CPUUtilizationTooHigh および DiskReadOpsTooHighALARM 状態である場合のみ、複合アラームが ALARM 状態になることを指定しています。

  • ALARM(CPUUtilizationTooHigh) AND NOT ALARM(DeploymentInProgress)

    この式は、CPUUtilizationTooHighALARM 状態で、DeploymentInProgressALARM 状態ではない場合、複合アラームが ALARM 状態になることを指定しています。これは、デプロイ期間中にアラームのノイズを低減する複合アラームの例です。

  • (ALARM(CPUUtilizationTooHigh) OR ALARM(DiskReadOpsTooHigh)) AND OK(NetworkOutTooHigh)

    この式は、(ALARM(CPUUtilizationTooHigh) または (DiskReadOpsTooHigh)ALARM 状態で、(NetworkOutTooHigh)OK 状態である場合、複合アラームが ALARM 状態になることを指定しています。これは、ネットワークの問題が発生している間、基盤となるアラームのいずれかが ALARM 状態ではない場合に通知を送信しないことで、アラームのノイズを低減する複合アラームの例です。

複合アラームの作成

複合アラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Alarms] (アラーム) を選択し、[In alarm] (アラーム状態) を選択します。

  3. アラームのリストで、ルール式で参照する既存のアラームの横にあるチェックボックスをオンにしてから、[Create composite alarm] (複合アラームの作成) を選択します。

  4. [Specify composite alarm conditions] (複合アラーム条件を指定) で、新しい複合アラームのルール式を指定します。

    注記

    [Conditions] (条件) ボックスに、アラームのリストから選択したアラームが自動的に表示されます。デフォルトでは、ALARM 関数が各アラームに指定されており、各アラームは論理演算子 OR によって結合されています。

    次のサブステップに従って、ルール式を変更できます。

    1. 各アラームで必要な状態は、ALARM から OK または INSUFFICENT_DATA に変更できます。

    2. ルール式の論理演算子は、OR から AND または NOT に変更できます。また、関数をグループ化するための括弧を追加できます。

    3. ルール式に他のアラームを含めることも、ルール式からアラームを削除することもできます。

    例: 条件付きのルール式

    (ALARM("CPUUtilizationTooHigh") OR ALARM("DiskReadOpsTooHigh")) AND OK("NetworkOutTooHigh")

    このルール式の例では、OK("NetworkOutTooHigh") が OK であると同時に ALARM ("CPUUtilizationTooHigh" or ALARM("DiskReadOpsTooHigh") が ALARM 状態であるとき、複合アラームが ALARM 状態になります。

  5. 完了したら、[次へ] を選択します。

  6. [Configure actions] (アクションの設定) で、次を選択できます。

    [Notification] (通知) から

    • [Select an exisiting SNS topic] (既存の SNS トピックを選択)、[Create a new SNS topic] (新しい SNS トピックを作成)、または [Use a topic ARN] (トピック APN を使用) を選択すると、通知を受け取る SNS トピックを定義できます。

    • [Add notification] (通知の追加) を選択すると、アラームで同じアラーム状態または異なるアラーム状態についての複数の通知を送信できます。

    • [Remove] (削除) を選択すると、アラームによる通知の送信やアクションの実行を停止できます。

    [Systems Manager action] (Systems Manager のアクション) から

    • [Add Systems Manager action] (Systems Manager アクションを追加する) を選択すると、アラームが ALARM 状態になったときに SSM アクションを実行できます。

    Systems Manager のアクションの詳細については、「AWS Systems Manager ユーザーガイド」の「アラームから OpsItems を作成するように CloudWatch を設定する」、「Incident Manager ユーザーガイド」の「Incident creation」(インシデントの作成) を参照してください。SSM Incident Manager アクションを実行するアラームを作成するには、正しいアクセス許可が必要です。詳細については、「Incident Manager ユーザーガイド」の「Identity-based policy examples for AWS Systems Manager Incident Manager」(AWS Systems Manager Incident Manager のアイデンティティベースのポリシーの例) を参照してください。

  7. 完了したら、[次へ] を選択します。

  8. [Add name and description] (名前と説明を追加) で、新しい複合アラームのアラーム名とオプションの説明を入力します。アラーム名には ASCII 文字のみを使用する必要があります。

  9. 完了したら、[次へ] を選択します。

  10. [Preview and create] (プレビューと作成) で情報を確認し、[Create composite alarm] (複合アラームの作成) を選択します。

    注記

    1 つの複合アラームと別の複合アラームが互いに依存する複合アラームのサイクルを作成できます。このシナリオの場合、複合アラームは評価されなくなります。また、複合アラームは互いに依存しているため削除できません。複合アラーム間のサイクルの依存関係を断ち切る最も簡単な方法は、複合アラームのうちの 1 つで、関数 AlarmRuleFalse に変更することです。

複合アラームのアクション抑制

複合アラームのアクション抑制では、アラームをサプレッサーアラームとして定義します。サプレッサーアラームは、複合アラームでアクションが実行されるのを防ぐアラームです。例えば、サポートしているリソースのステータスを表すサプレッサーアラームを指定できます。サポートしているリソースがダウンしている場合、サプレッサーアラームは複合アラームによる通知の送信を妨げます。複合アラームのアクション抑制は、アラームのノイズを低減するのに役立ちます。そのため、アラームの管理に費やす時間を減らし、オペレーションに集中する時間を増やすことができます。

サプレッサーアラームは、複合アラームを設定する際に指定します。すべてのアラームは、サプレッサーアラームとして機能できます。サプレッサーアラームの状態が OK から ALARM に変わると、その複合アラームはアクションを停止します。サプレッサーアラームの状態が ALARM から OK に変わると、その複合アラームはアクションを再開します。

WaitPeriod および ExtensionPeriod

サプレッサーアラームを指定する際は、WaitPeriod および ExtensionPeriod パラメータを設定します。これらのパラメータにより、サプレッサーアラームの状態の変更中に、複合アラームにより予期しないアクションが実行されるのを防ぐことができます。WaitPeriod を使用すると、サプレッサーアラームが OK から ALARM に変わる際に発生する可能性のある遅延を補うことができます。例えば、サプレッサーアラームが 60 秒以内に OK から ALARM に変わる場合、WaitPeriod を 60 秒に設定します。


             WaitPeriod 内のアクション抑制

この図では、複合アラームは t2 で OK から ALARM に変わります。WaitPeriod は t2 で開始され、t8 で終了します。これにより、WaitPeriod が t8 で期限切れになる際、複合アラームのアクションを抑制する前に、t4 でサプレッサーアラームの状態が OK から ALARM に変わる時間を確保できます。

ExtensionPeriod を使用すると、サプレッサーアラームが OK に変わった後、複合アラームが OK に変わる際に発生する可能性のある遅延を補うことができます。例えば、サプレッサーアラームが OK に変わってから 60 秒以内に複合アラームが OK に変わる場合、ExtensionPeriod を 60 秒に設定します。


             ExtensionPeriod 内のアクション抑制

この図では、サプレッサーアラームは t2 で ALARM から OK に変わります。ExtensionPeriod は t2 で開始され、t8 で終了します。これにより、ExtensionPeriod が t8 で期限切れになる前に、複合アラームが ALARM から OK に変わる時間を確保できます。

WaitPeriod および ExtensionPeriod がアクティブになるとき、複合アラームではアクションは実行されません。ExtensionPeriod および WaitPeriod が非アクティブになるとき、複合アラームでは現在の状態に基づいてアクションが実行されます。CloudWatch では 1 分ごとにメトリクスアラームが評価されるため、各パラメータの値は 60 秒に設定することをお勧めします。パラメータは、秒単位で任意の整数に設定できます。

次の例は、WaitPeriod および ExtensionPeriod を使用して、複合アラームで予期しないアクションが実行されるのを防ぐ方法を、より詳細に説明しています。

注記

次の例では、WaitPeriod は 2 つの時間単位、ExtensionPeriod は 3 つの時間単位として設定されています。

例 1: WaitPeriod の後にアクションが抑制されない


            第 1 のアクション抑制の例

この図では、複合アラームの状態が t2 で OK から ALARM に変わっています。WaitPeriod は t2 で開始され t4 で終了するため、複合アラームでアクションが実行されるのを防ぐことができます。t4 で WaitPeriod の期限が切れた後は、サプレッサーアラームがまだ OK 状態であるため、複合アラームでアクションが実行されます。

例 2: WaitPeriod の期限が切れる前にアラームによりアクションが抑制される


            第 2 のアクション抑制の例

この図では、複合アラームの状態が t2 で OK から ALARM に変わっています。WaitPeriod は t2 で開始され、t4 で終了します。これにより、t3 でサプレッサーアラームの状態が OK から ALARM に変わる時間を確保できます。サプレッサーアラームの状態が t3 で OK から ALARM に変わるため、t2 で開始された WaitPeriod は破棄されます。また、サプレッサーアラームにより複合アラームのアクションの実行が停止されます。

例 3: アクションが WaitPeriod により抑制される場合の状態遷移


            第 3 のアクション抑制の例

この図では、複合アラームの状態が t2 で OK から ALARM に変わっています。WaitPeriod は t2 で開始され、t4 で終了します。これにより、サプレッサーアラームの状態が変わる時間を確保できます。複合アラームは t3 でOK に戻るため、t2 で開始された WaitPeriod は破棄されます。新たに t3 で WaitPeriod が開始され、t5 で終了します。t5 で新しい WaitPeriod の期限が切れると、複合アラームによりアクションが実行されます。

例 4: アクションがアラームにより抑制される場合の状態遷移


            第 4 のアクション抑制の例

この図では、複合アラームの状態が t2 で OK から ALARM に変わっています。サプレッサーアラームは既に ALARM の状態です。サプレッサーアラームにより、複合アラームによるアクションの実行が停止されます。

例 5: ExtensionPeriod の後にアクションが抑制されない


            第 5 のアクション抑制の例

この図では、複合アラームの状態が t2 で OK から ALARM に変わっています。WaitPeriod は t2 で開始され、t4 で終了します。これにより、複合アラームのアクションを t6 まで抑制する前に、t3 でサプレッサーアラームの状態が OK から ALARM に変わる時間を確保できます。サプレッサーアラームの状態が t3 で OK から ALARM に変わるため、t2 で開始された WaitPeriod は破棄されます。t6 で、サプレッサーアラームは OK に変わります。ExtensionPeriod は t6 で開始され、t9 で終了します。ExtensionPeriod の期限が切れると、複合アラームによりアクションが実行されます。

例 6: アクションがExtensionPeriod により抑制される場合の状態遷移


            第 6 のアクション抑制の例

この図では、複合アラームの状態が t2 で OK から ALARM に変わっています。WaitPeriod は t2 で開始され、t4 で終了します。これにより、複合アラームのアクションを t6 まで抑制する前に、t3 でサプレッサーアラームの状態が OK から ALARM に変わる時間を確保できます。サプレッサーアラームの状態が t3 で OK から ALARM に変わるため、t2 で開始された WaitPeriod は破棄されます。t6 で、サプレッサーアラームは OK に戻ります。ExtensionPeriod は t6 で開始され、t8 で終了します。t7 で複合アラームが OK に戻ると、ExtensionPeriod は破棄されます。その後 t7 では新しい WaitPeriod が開始され、t9 で終了します。新しい WaitPeriod の期限が切れると、複合アラームでアクションを実行できます。

ヒント

アクションのサプレッサーアラームを置き換えると、アクティブな WaitPeriod または ExtensionPeriod は破棄されます。