# 複合アラーム
<a name="alarm-combining"></a>

CloudWatch では、複数のアラームを 1 つの複合アラームにまとめて、アプリケーション全体またはリソースグループ全体にわたってまとめて集計されたヘルスインジケーターを作成できます。複合アラームとは、他のアラームの状態をモニタリングして自身の状態を判定するアラームです。ブール論理を使用して、モニタリング対象アラームのステータスを組み合わせるルールを定義します。

複合アラームを使用すると、集約したレベルでのみアクションを実行すればよいので、アラームのノイズを低減できます。例えば、ウェブサーバーに関連するアラームがトリガーされた場合にウェブサーバーチームに通知を送信する複合アラームを作成できます。これらのアラームのいずれかが ALARM 状態になると、複合アラームは ALARM 状態になり、チームに通知を送信します。ウェブサーバーに関連する他のアラームが ALARM 状態になっても、複合アラームは現状を既に通知しているので、チームが新しい通知で過負荷になることはありません。

また、複合アラームを使用して複雑なアラーム条件を作成し、さまざまな条件が満たされた場合にのみアクションを実行することもできます。例えば、CPU アラームとメモリアラームを組み合わせた複合アラームを作成して、CPU アラームとメモリアラームの両方がトリガーされた場合にのみチームに通知することができます。

**複合アラームを使用する**

複合アラームを作成するには、次の 2 つの方法があります。
+ 複合アラームレベルでのみ実行したいアクションを設定し、基礎となるモニタリング対象アラームはアクションなしで作成する
+ 複合アラームレベルでは異なるアクションのセットを設定する。例えば、問題が広範囲に及ぶ場合、複合アラームアクションには別のチームを従事させることができます。

複合アラームでは次のアクションのみを実行できます。
+ Amazon SNS トピックへの通知
+ Lambda 関数を呼び出す
+  Systems Manager Ops Center での OpsItems の作成
+  Systems Manager Incident Manager でのインシデントの作成

**注記**  
複合アラームの基盤となるすべてのアラームは、複合アラームと同じアカウントおよびリージョンに存在する必要があります。ただし、CloudWatch のクロスアカウントオブザーバビリティモニターリングアカウントで複合アラームを設定した場合、基盤となるアラームが、異なるソースアカウントとモニターリングアカウント自体のメトリクスを監視できます。詳細については、「[CloudWatch のクロスアカウントオブザーバビリティ](CloudWatch-Unified-Cross-Account.md)」を参照してください。  
 1 つの複合アラームで 100 の基盤となるアラームを監視でき、1 つのアラームは 150 の複合アラームで監視できます。

**ルール式**

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

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

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

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

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

**アラームの参照**

アラーム名または ARN のいずれかを使用してアラームを参照する場合、ルール構文は、アラーム名または ARN を引用符 (") で囲むかどうかにかかわらず、アラームの参照をサポートできます。
+ 引用符なしで指定した場合、アラーム名や ARN には、スペース、丸括弧、カンマを含めることはできません。
+ 引用符で囲む場合、参照を正しく解釈するために、二重引用符 (") を*含む*アラーム名や ARN では、バックスラッシュエスケープ (\\) 文字を使用して " を囲む必要があります。

**[Syntax]** (構文)

複数のアラームを 1 つの複合アラームに結合するために使用する式の構文は、ブールロジックと関数を使用します。次の表に、ルール式で使用できる演算子と関数を示します。


| 演算子/関数 | 説明 | 
| --- | --- | 
| AND | 論理 AND 演算子。指定されたすべての条件が TRUE の場合、TRUE を返します。 | 
| OR | 論理 OR 演算子。指定された条件の少なくとも 1 つが TRUE の場合、TRUE を返します。 | 
| NOT | 論理 NOT 演算子 指定された条件が FALSE の場合、TRUE を返します。 | 
| AT\_LEAST | 指定されたアラームのうち、少なくともある数または割合のアラームが、要件となっている状態にある場合に TRUE を返す関数。形式: AT\_LEAST(M, STATE\_CONDITION, (alarm1, alarm2, ...alarmN))。M は絶対数または割合 (例: 50%)、STATE\_CONDITION は ALARM、OK、INSUFFICIENT\_DATA、NOT ALARM、NOT OK、または NOT INSUFFICIENT\_DATA です。 | 

括弧を使用して条件をグループ化し、複雑な式で評価の順序を制御できます。

**式の例**

リクエストパラメータ `AlarmRule` は、`AND`、`OR`、`NOT` の論理演算子、および `AT_LEAST` 関数の使用をサポートしています。これにより、複数の関数を 1 つの式に結合することができます。次の式の例は、複合アラームで基盤となるアラームを設定する方法を示しています。
+ `ALARM(CPUUtilizationTooHigh) AND ALARM(DiskReadOpsTooHigh)`

  この式は、`CPUUtilizationTooHigh` および `DiskReadOpsTooHigh` が `ALARM` 状態である場合のみ、複合アラームが `ALARM` 状態になることを指定しています。
+ `AT_LEAST(2, ALARM, (WebServer1CPU, WebServer2CPU, WebServer3CPU, WebServer4CPU))`

  式は、4 つのウェブサーバー CPU アラームのうち少なくとも 2 つが `ALARM` 状態になると、複合アラームが `ALARM` 状態になることを指定します。これにより、すべてまたは 1 つだけをアラーム状態にするのではなく、影響を受けるリソースのしきい値に基づいてアラートをトリガーできます。
+ `AT_LEAST(50%, OK, (DatabaseConnection1, DatabaseConnection2, DatabaseConnection3, DatabaseConnection4))`

  式は、データベース接続アラームの少なくとも 50% が `OK` 状態になると、複合アラームが `ALARM` 状態になることを指定します。パーセンテージを使用すると、モニタリング対象アラームを追加または削除するときにルールを動的に適応させることができます。
+ `ALARM(CPUUtilizationTooHigh) AND NOT ALARM(DeploymentInProgress)`

  この式は、`CPUUtilizationTooHigh` が `ALARM` 状態で、`DeploymentInProgress` が `ALARM` 状態ではない場合、複合アラームが `ALARM` 状態になることを指定しています。これは、デプロイ期間中にアラームのノイズを低減する複合アラームの例です。
+ `AT_LEAST(2, ALARM, (AZ1Health, AZ2Health, AZ3Health)) AND NOT ALARM(MaintenanceWindow)`

  式は、3 つのアベイラビリティーゾーンの健全性アラームのうち少なくとも 2 つが `ALARM` 状態になり、メンテナンスウィンドウアラームが `ALARM` 状態でない場合に、複合アラームが `ALARM` 状態になることを指定します。これにより、AT\_LEAST 関数と他の論理演算子を組み合わせて、より複雑なモニタリングシナリオを実現できます。