# アラームミュートルール
<a name="alarm-mute-rules"></a>

 アラームミュートルールは、事前定義されたタイムウィンドウ内にアラームアクションを自動的にミュートするメカニズムを備えた CloudWatch 機能です。ミュートルールを作成する際には、アクションがミュートされる特定の期間とターゲットアラームを定義します。CloudWatch は、予想される運用イベント中に不要な通知や自動アラームアクションが発生するのを防止しながら、アラーム状態のモニタリングと評価を継続します。

 アラームミュートルールは、アラームアクションが不要または破壊的になるような重要な運用シナリオを管理する際に役立ちます。例えば、計画メンテナンスウィンドウの中で、システムを意図的にオフラインにしている時や想定される問題が発生している時に自動アラームアクションが実行されないようにすることができるため、中断することなくメンテナンスを実行できます。週末や祝日など、営業時間外のオペレーションについては、緊急対応が不要な場合に重要でないアラームアクションをミュートすることで、アラームノイズやオペレーションチームへの不要な通知を減らすことができます。テスト環境でミュートルールを使用すると、リソース使用率やエラー率が高く、すぐに対処する必要のない負荷テストなどのシナリオでアラームアクションを一時的にミュートできます。チームが問題解決に積極的に取り組んでいる時にミュートルールを使用すると、重複するアラームアクションがトリガーされるのを防ぐことができ、冗長なアラーム通知に気を取られることなく解決に集中できます。

## アラームミュートルールの定義
<a name="defining-alarm-mute-rules"></a>

 アラームミュートルールは、**ルール**と**ターゲット**を使用して定義できます。
+  **ルール** - アラームアクションをミュートするタイムウィンドウを定義します。ルールは次の 3 つの属性で構成されます。
  +  **式** – ミュート期間の開始のタイミングと反復方法を定義します。次の 2 種類の式を使用できます。
    +  **cron 式** – 標準的な cron 構文を使用して、反復ミュートウィンドウを作成します。このアプローチは、毎週のシステム更新や毎日のバックアップオペレーションなど、定期的なメンテナンススケジュールに最適です。Cron 式を使用すると、特定の曜日、月、時刻など、複雑な繰り返しパターンを指定できます。

       *cron 式の構文* 

      ```
      ┌───────────── minute (0 - 59)
      │ ┌───────────── hour (0 - 23)
      │ │ ┌───────────── day of the month (1 - 31)
      │ │ │ ┌───────────── month (1 - 12) (or JAN-DEC)
      │ │ │ │ ┌───────────── day of the week (0 - 6) (0 or 7 is Sunday, or MON-SUN)
      │ │ │ │ │
      │ │ │ │ │
      * * * * *
      ```
      +  文字 `*`、`,`、`-` はすべてのフィールドでサポートされます。
      +  英語名は、`month` (JAN-DEC) フィールドと `day of week` (SUN-SAT) フィールドに使用できます。
    +  **at 式** – 1 回限りのミュートウィンドウには at 式を使用します。このアプローチは、既知の時間に 1 回発生する計画的運用イベントに適しています。

      ```
      Syntax: `at(yyyy-MM-ddThh:mm)`
      ```
  +  **期間** – ミュートルールがアクティブ化されてからの持続期間を指定します。期間は、最小 1 分 (PT1M)、最大 15 日 (P15D) の ISO-8601 形式で指定する必要があります。
  +  **タイムゾーン** – 「America/Los\_Angeles」や「Europe/London」などの標準的なタイムゾーン識別子を使用して、式に従ってミュートウィンドウが適用されるタイムゾーンを指定します。
+  **ターゲット** - 定義されたタイムウィンドウ中にアクションがミュートされるアラーム名のリストを指定します。メトリクスアラームと複合アラームの両方をターゲットリストに含めることができます。

 ミュートウィンドウに追加の境界を設けるために、オプションで、開始タイムスタンプと終了タイムスタンプを含めることもできます。開始タイムスタンプは特定の日時より前にミュートルールがアクティブ化されないようにするもので、終了タイムスタンプは指定した日時を超えてルールが適用されないようにするものです。

 プログラムによるアラームミュートルールの作成の詳細については、「[PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html)」を参照してください。

**注記**  
 ターゲットアラームは、ミュートルールの作成時と同じ AWS アカウント と AWS リージョン に存在する必要があります。
 単一のアラームミュートルールにおいて、アラーム名ごとに最大 100 個のアラームをターゲットにすることができます。

 CloudWatch コンソールには、AWS アカウント 内のすべてのミュートルールを一元管理できる専用の「アラームミュートルール」タブが含まれています。ルール名などのミュートルール属性を使用して、特定のミュートルールを検索できます。

## ミュートルールのステータス
<a name="mute-rule-status"></a>

 作成されたアラームミュートルールのステータスは、次の 3 つのいずれかになります。
+  **SCHEDULED** – ミュートルールは、設定されたタイムウィンドウ式に従ってその後のある時点でアクティブになります。
+  **ACTIVE** – ミュートルールは、設定されたタイムウィンドウ式に従って現在アクティブであり、ターゲットアラームアクションを積極的にミュートします。
+  **EXPIRED** – ミュートルールはその後、SCHEDULED/ACTIVE になりません。これは、ミュートウィンドウ終了後に 1 回限りのミュートルール、または終了タイムスタンプが設定されてその時間が経過したときに繰り返される反復ミュートルールに対して発生します。

## アラームに対するミュートルールの影響
<a name="effects-of-mute-rules"></a>

 ミュートウィンドウがアクティブである時に、ターゲットアラームの状態が変わってアクションが設定されると、CloudWatch はそれらのアクションの実行をミュートします。ミュートはアラームアクションにのみ適用されます。つまり、アラームは引き続き評価され、状態の変更は CloudWatch コンソールに表示されますが、Amazon Simple Notification Service 通知、Amazon Elastic Compute Cloud Auto Scaling アクション、Amazon EC2 アクションなどの設定されたアクションは実行されません。CloudWatch は、ミュート期間中もアラームの状態を正常に評価し続けます。この情報はアラーム履歴を通じて表示できます。

 ミュートウィンドウが終了すると、ターゲットアラームがアラーム状態 (OK/ALARM/INSUFFICIENT\_DATA) のままである場合、CloudWatch はウィンドウ中にミュートされたアラームアクションを自動的に再トリガーします。これにより、予定のミュート期間が終了すると、進行中の問題に対してアラームアクションが実行され、モニタリングシステムの整合性が維持されます。

**注記**  
 アラームをミュートした場合:   
 ターゲットアラームに関連付けられているすべてのアクションがミュートされる 
 すべてのアラーム状態 (OK、ALARM、INSUFFICIENT\_DATA) に関連付けられたアクションがミュートされる 

## ミュートされたアラームの表示と管理
<a name="viewing-managing-muted-alarms-link"></a>

ミュートされたアラームの表示と管理については、「[ミュートされたアラームの表示と管理](viewing-managing-muted-alarms.md)」を参照してください。

## 一般的なユースケースのスケジュール例
<a name="common-use-cases"></a>

 以下の例は、一般的なユースケース向けにタイムウィンドウ式を設定する方法を示しています。

 **シナリオ 1: スケジュールされたメンテナンスウィンドウ中にアラームアクションをミュートする** – サービスを意図的に利用不可にしている時やパフォーマンス低下モードでサービスが動作している時のシステムやデータベースの更新など、予測可能なスケジュールで発生する定期的なメンテナンスアクティビティ。
+  期間 `PT4H` を含む cron 式 `0 2 * * SUN` - 週次システムメンテナンスのために、毎週日曜日の午前 2 時から午前 6 時までアラームをミュートする。
+  期間 `PT6H` を含む cron 式 `0 1 1 * *` - 月次データベースメンテナンスのために、毎月1日の午前 1 時から午前 7 時までアラームをミュートする。

 **シナリオ 2: 営業時間外に重要でないアラームをミュートする** – 即時対応が不要な週末や休日にアラートによる疲労を軽減する。
+  期間 `P2DT12H` を含む cron 式 `0 18 * * FRI` - 毎週末、金曜日の午後 6 時から月曜日の午前 6 時までアラームをミュートする。

 **シナリオ 3: 毎日のバックアップオペレーション中にパフォーマンスアラームをミュートする** – リソース使用率を一時的に増やし、予測可能な時間帯にパフォーマンス関連のアラームをトリガーする毎日の自動バックアッププロセス。
+  期間 `0 23 * * *` を含む cron 式 `PT2H` - 毎日、ディスク I/O と CPU 使用率を一時的に増やす夜間バックアップオペレーション中に、午後 11 時から午前 1 時までアラームをミュートする。

 **シナリオ 4: アクティブなトラブルシューティングセッション中に重複するアラームをミュートする** – チームが問題の調査や解決に積極的に取り組んでいる間のアラームアクションの一時的なミュート。通知ノイズを防いで問題解決に集中できるようにする。
+  期間 `PT4H` を含む at 式 `at(2024-05-10T14:00)` - アクティブなインシデント対応セッション中に、2024 年 5 月 10 日の午後 2 時から午後 6 時までアラームをミュートする。

 **シナリオ 5: 計画された会社のシャットダウン中にアラームアクションをミュートする** – メンテナンス期間の 1 回限りの延長、またはすべてのシステムが意図的に長期間オフラインにされている状態での会社全体のシャットダウン。
+  期間 `P7D` を含む at 式 `at(2024-12-23T00:00)` - 2024 年 12 月 23 日から 29 日までの間、会社の年次シャットダウン中にアラームをミュートする。