ミューティングルール：通知を抑制します

アラートは、システムに問題が発生した場合にタイムリーに通知を送信します。 場合によっては、一部の既知の通知を表示したくないことがあります。 muting rulesを使用すると、注意を払う必要のないメッセージが大量に届くのを防ぐことができます。

不要な通知に共通する要素を見つけたら、それらの要素を具体的にミュートし、他の通知を通過させるルールを定義できます。 通知がミュートされている場合でも、 アラートそれらのインシデントに関するデータを収集し続けます。 ミュート ルールはアラート プロセスに干渉せず、通知が送信される直前に適用されます。

ミューティングルールを作成する

ミュート ルールを作成するには、次の手順に従います。

1. one.newrelic.com > All capabilities > Alertsに移動し、左側のナビゲーション ペインでMuting rulesをクリックします。

2. + Add a ruleをクリックします。

3. ミュート ルールの名前と説明 (オプション) を入力し、ルールを適用するアカウントを選択します。

4. インシデント フィルターを構築します。 インシデント イベント属性のサブセットを使用できます。 属性、演算子、および値を選択します。 属性は次のとおりです: accountId 、 conditionId 、 conditionName 、 conditionType 、 entity.guid 、 nrqlEventType 、 nrqlQuery 、 policyId 、 policyName 、 product 、 runbookUrl ( conditionRunbookUrlとして)、 tags.<NAME> 、およびtargetName )。 値は、アラート ポリシー ID や条件名などのインシデント プロパティの 1 つと比較されます。

5. さらにフィルターを追加する場合は、 Add another conditionをクリックします。

ミューティングルールを管理する

ミューティング ルールの条件は、ミューティングの対象となるインシデントを定義する属性、演算子、および値で構成される個々の式のセットです。

ミュート ルールを作成、有効化、無効化、管理するには、次の手順に従います。

1. one.newrelic.com > All capabilities > Alertsに移動し、左側のナビゲーション ペインでMuting rulesをクリックします。

2. Enabled列からいつでもミュート ルールを有効または無効にできます。 各ルールは、 各ルールの行にアイコンが表示されます。

ルールには、次のいずれかのステータスがあります。

• Active: ミュートが有効になってアクティブになっています。
• Scheduled: ミュートは有効ですが、まだアクティブではありません (将来のスケジュールがあります)。
• Ended: ミュートは有効ですが、アクティブではありません (今後のスケジュールはありません)。
• Inactive: ミュートは無効です。

ミュートルールの通知オプション

ミュート ルールがアクティブで、インシデントが開かれると、ユーザーは通知を受信しません。 以下の 2 つの設定を使用して、ミュート ルールが非アクティブな場合の通知の動作を構成できます。

• Notify: ミュートルールの期間が終了した後にインシデントが継続している場合は、通知されます。 これは、既存のミュートされたインシデントを閉じることで機能します。また、閾値がまだ違反されている場合、新しいインシデントが非ミュート状態で開き、通知がトリガーされます。 このデフォルト設定を維持することをお勧めします。

• Suppress notification: ミュートルール期間が終了した後にインシデントが継続している場合は、通知されません。 これは、ミュート ルール ウィンドウの終了タイムスタンプを過ぎても、既存のミュートされたインシデントを開いたままにしておくことによって機能します。

ミューティングルールをスケジュールする

必要に応じて、ミューティングルールをスケジュールできます。

これを行うには、開始時刻と終了時刻を選択します。 オプションで、ミュート ルールを 1 日中有効に設定することもできます。

ミューティングルールスケジュールのタイムゾーンを選択することもできます。デフォルトは、ユーザー設定で選択されたタイムゾーンです。

ミューティングルールを毎日、毎週、または毎月繰り返すようにスケジュールできます。毎週繰り返すようにスケジュールされているミューティングルールには、繰り返す曜日を選択するオプションが含まれています。日が選択されていない場合、毎週の繰り返しは、デフォルトで、ミューティングルールの開始がスケジュールされている曜日に繰り返されます。

特定の日付または特定の発生回数を選択して、再発をいつ終了するかを指定することもできます。

ミュートされたインシデントと問題を表示する

オープンまたはクローズ済みの問題を表示すると、インシデントと問題はMutedとしてマークされます。次のセクションでは、これらのミュートされたインシデントと問題の一部と、それらを見つけることができる場所を示します。

ミュートされた重大インシデントの問題

インシデントのリスト (一部はミュートされています)

インシデントや問題は、 Muted列のアイコン:

を使用してファセット結果をミュートする tags.

ファセット クエリの結果をミュートするには、tags.FACETED_ATTRIBUTE 属性を使用します。ここで、FACETED_ATTRIBUTE はNRQL FACET クエリを実行した属性を表します。 たとえば、NRQL アラート条件のクエリにFACET hostが含まれている場合、 tags.hostを使用してそのFACET属性をターゲットにすることができます。

NRQL条件クエリは、複数のファセット属性を受け入れることができます。集約されたイベントまたはメトリック時系列の属性からフィルタリングできるようにする場合は、それらの属性をNRQLクエリFACET句に追加する必要があります。例： FACET host, region, cluster 。

tags.の使用例については、ミューティングルールの作成を参照してください。

サブ条件演算子

これらは、ミュート ルールを追加するときに属性を比較するために使用できる論理演算子です。ミューティング ルールを初めて使用する場合は、これらの 例を参照してください。

• EQUALS: 指定された値がインシデント属性値と等しい場合。
• DOES_NOT_EQUALS: 指定された値がインシデント属性値と等しくない場合。
• IN: 指定された値のリスト (最大 500) にインシデント属性値が存在する場所。
• NOT_IN: 指定された値のリスト (最大 500) にインシデント属性値が存在しない場合。
• CONTAINS: 指定された値文字列がインシデント属性値に存在する場所。
• DOES_NOT_CONTAINS: 指定された値文字列がインシデント属性値に存在しない場所。
• ENDS_WITH: インシデント属性値が指定された値文字列で終わる場所。
• NOT_ENDS_WITH: インシデント属性値が指定された値文字列で終わっていない場所。
• STARTS_WITH: インシデント属性値が指定された値文字列で始まる場所。
• DOES_NOT_STARTS_WITH: インシデント属性値が指定された値文字列で始まっていない場所。
• IS_BLANK: インシデント属性値が空白の場合。null、空文字列など
• IS_NOT_BLANK: インシデント属性値が空白でない場合。null、空文字列など
• IS_ANY: この演算子を含む条件では、アカウントのすべてのインシデントがミュートされます。

ミューティングルールのしくみ

ミュート ルールは、通知を抑制またはミュートするために、デフォルトのアラート ライフサイクルの最後に適用されます。既存のポリシーや条件を無効にすることはありません。たとえば、メンテナンス ウィンドウや展開など、既知のシステム中断中は通知をミュートできます。システム中断インシデントは、それらのインシデントの通知がミュートされていても識別されます。

ミュート ルールは、インシデント イベント内の属性と一致する一連の条件を使用します。 ミュート ルールでは、次のことが規定されています。

• インシデントが作成された後、問題が開かれる前に個々のインシデントを識別します。
• デフォルトの条件を上書きして、ミュートする必要があることを示します。

現在、インシデントをミュートすることは、通常のアラート インシデントのライフサイクルが維持されることを意味します。ただし、ミュートされたインシデントのみを含む問題は通知を送信しません。

ミュート ルールは、問題内で通知をトリガーした最初のイベントによって決定されます。 つまり、最初の通知イベントがミュート状態のためにミュートされた場合、問題の残りの部分もミュートされます。

ミューティング ルールは、特定のインシデントを上書きします。既存のポリシーや条件を無効にすることはありません。これにより、多数のエンティティをカバーするポリシーまたは条件によってカバーされる可能性のある特定のエンティティからのインシデントをミュートできます。これにより、システムのサブセットでメンテナンスを実行しているときに、監視を過度にミュートする必要がなくなります。

次の表は、アラート インシデントのライフサイクルがミュートされたインシデントによってどのように影響を受けるかを示しています。

ワークフローによる動作のミュート

トリガーされたインシデントと問題の比率は 1:1 であるため、インシデントがミュートされている場合、一致する問題も同様にミュートされます。ワークフローは、1 つ以上のインシデントを持つ可能性がある問題によってトリガーされるため、ミュートされたインシデントとミュートされていないインシデントが組み合わされたシナリオが存在する可能性があります。

各問題には、次のいずれかのミューティング状態があります。

• Fully muted (FULLY_MUTED): 問題のオープン インシデントがすべてミュートされます (デフォルト値)。
• Partially muted (PARTIALLY_MUTED): ミュートされているオープン インシデントが少なくとも 1 つと、ミュートされていないオープン インシデントが 1 つある問題。
• Not muted (NOT_MUTED): ミュートされた未解決のインシデントがない問題。

ワークフローの設定方法に関する段階的なガイドについては、以下のサンプル デモをご覧ください (約 .2:17 分):

NerdGraph によるミュート動作

NerdGraphでは、ミューティングルールで次のクエリとミューテーションを使用できます。スキーマの詳細は、 APIExplorerで確認できます。

• actor.account.alerts.mutingRule: ID でミュート ルールを取得します。
• actor.account.alerts.mutingRules：アカウントのミュートルールのリストを取得します。
• alertsMutingRuleCreate：アカウントのミュートルールを作成します。
• alertsMutingRuleUpdate: ID とアカウント ID でミュート ルールを更新します。

このページでは、いくつかのサンプル クエリとミューテーションの例を見つけることができます。

ミューティングルールには、次のフィールドとコンポーネントがあります。

ミューティングの例

NerdGraphへのリクエストの詳細については、 GraphQLチュートリアルを含むNerdGraphのドキュメントを参照してください。

{
  actor {
    account(id: YOUR_ACCOUNT_ID) {
      alerts {
        mutingRules {
          name
          condition {
            operator
            conditions {
              attribute
              operator
              values
            }
          }
        }
      }
    }
  }
}

mutation {
  alertsMutingRuleCreate(
    accountId: YOUR_ACCOUNT_ID
    rule: {
      name: "host-1 mute rule"
      description: "Mute host-1 incidents"
      enabled: true
      condition: {
        operator: AND
        conditions: [
          { attribute: "tags.host", operator: EQUALS, values: ["host-1"] }
        ]
      }
    }
  ) {
    id
  }
}

mutation {
  alertsMutingRuleCreate(
    accountId: YOUR_ACCOUNT_ID
    rule: {
      name: "host-1 and synthetics/mobile mute rule"
      description: "Mute host-1 and synthetics/mobile incidents"
      enabled: true
      condition: {
        operator: OR
        conditions: [
          { attribute: "targetName", operator: EQUALS, values: ["host-1"] }
          {
            attribute: "product"
            operator: IN
            values: ["SYNTHETICS", "MOBILE"]
          }
        ]
      }
    }
  ) {
    id
  }
}

mutation {
  alertsMutingRuleUpdate(
    accountId: YOUR_ACCOUNT_ID
    id: MUTING_RULE_ID
    rule: { name: "updated name", enabled: false }
  ) {
    name
  }
}

mutation {
  alertsMutingRuleDelete(accountId: YOUR_ACCOUNT_ID, id: MUTING_RULE_ID) {
    id
  }
}