• /
  • EnglishEspañolFrançais日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

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

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

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

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

重要

ミュート ルールを作成する前に、 通知を 生成する ポリシー条件を作成する必要があります。

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

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

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

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

  4. 人気イベントフィルターを構築します。 イベントプロパティのサブセットを使用できます。 属性、演算子、および値を選択します。属性は次のとおりです: accountIdconditionIdconditionNameconditionTypeentity.guidnrqlEventTypenrqlQuerypolicyIdpolicyNameproductrunbookUrl (conditionRunbookUrlとして)、 tags.<NAME> 、およびtargetName)。値は、アラート ポリシー ID や条件名などの集約イベント プロパティの 1 つと比較されます。

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

/* <img title="ミュートルール編集画面" alt="ミュートルール編集画面" src="/images/alerts_screenshot-crop_violation-filter.webp"/> <figcaption> <DNT>**[one.newrelic.com > すべての機能](https\://one.newrelic.com/all-capabilities) に移動します> [アラート]**</DNT> に移動し、左側のナビゲーション ペインで <DNT>**ミュート ルール**</DNT> をクリックします。複雑なミュート ルールを作成して、小規模または大規模な一連の不要な通知を対象にすることができます。 </figcaption> */

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

ミューティング ルールの条件は、どの人気イベントをミュートの対象にするかを定義する、プロパティ、演算子、および値で構成される個々の式のセットです。

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

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

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

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

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

/* <img title="ミュートルールの管理" alt="ミュートルールの管理" src="/images/alerts_screenshot-full_muting-rules.webp"/> <figcaption> <DNT>**[one.newrelic.com > すべての機能](https\://one.newrelic.com/all-capabilities) に移動します> アラート > ミューティング ルール**</DNT>: 複雑なミューティング ルールを作成して、小規模または大規模な不要な通知を対象にすることができます。 </figcaption> */

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

ミュートルールが有効で、人気イベントが開かれている場合、ユーザーは通知を受け取りません。 以下の 2 つの設定を使用して、ミュート ルールが非アクティブな場合の通知の動作を構成できます。

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

  • Suppress notification: ミュート ルールの期間が終了した後に進行中のイベントがある場合、通知は届きません。 これは、ミュート ルール ウィンドウの終了タイムスタンプを過ぎても、既存のミュートされた多数イベントを開いたままにすることで機能します。

How to suppress notifications

one.newrelic.com > All capabilities > Alertsに移動し、 + Add a ruleをクリックします。

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

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

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

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

Schedule your muting window

one.newrelic.com > All capabilities > Alertsに移動し、左側のナビゲーション ペインでMuting rulesクリックします。 ミュート ルールをスケジュールするための柔軟で強力なオプションを確認します。

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

重要

Repeat曜日のチェックボックスは、 StartsおよびEnds日付フィールドをオーバーライドします。 開始日を設定し、曜日も選択した場合、ミュート ルールは開始日後の最初の日に適用されます。

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

ミュートされたイベントや問題を表示

オープンまたはクローズ済みの問題を表示すると、まとめイベントと問題はMutedとしてマークされます。 ミュートされたイベントや問題は、次の場所で確認できます。

  • ミュートされた問題を表示するには、 one.newrelic.com > All capabilities > Alertsに移動し、左側のナビゲーション ペインでIssues & Activityをクリックします。ミュートされた問題をクリックすると、ミュートされた重大なアラート イベントの詳細が表示されます。

  • ミュートされたイベントのリストを表示: one.newrelic.com > All capabilities > Alertsに移動し、左側のナビゲーション ペインでIssues & Activityをクリックします。 次に、 alert events tabを選択します。ミュートされたイベントや問題には が付いています。 Muted列のアイコン。

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

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

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

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

サブ条件演算子

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

ヒント

サブ条件演算子の値はすべて、大文字と小文字が区別されます。たとえば、 policyName STARTS_WITH 'PROD'を使用すると、「Prod」で始まるポリシー名は取得されません。

  • 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: この演算子を含む条件により、アカウント上のすべてのイベントがミュートされます。

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

ミュート ルールは、通知を抑制またはミュートするために、デフォルトの集計ライフサイクルの最後に適用されます。 既存のポリシーや条件は無効になりません。たとえば、メンテナンス期間やデプロイメントなどの既知のシステム中断中に通知をミュートすることができます。集中イベントの通知がミュートされていても、システム障害が発生したことは引き続き特定されます。

ミュート ルールは、集計イベントのプロパティに一致する一連の条件を使用します。 ミュート ルールでは次のことが規定されています。

  • 作成後、問題がオープンされる前に、個々の注目イベントを特定します。
  • デフォルトの条件を上書きして、ミュートする必要があることを示します。

現在、頻繁イベントをミュートするということは、通常のアラートイベントのライフサイクルが維持されることを意味します。ただし、ミュートされた人気イベントのみを含む号は通知を送信しません。

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

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

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

もしも

それから

Event: 問題は有効化されています

頻繁イベントがミュートされていないため、問題がアクティブ化されています

この問題に関する通知が送信されます。

ミュートされている大量イベントにより問題がアクティブ化されました

この問題に関する通知は送信されません(ミュートされます)。

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

トリガーされた集中イベントと問題の比率は 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 でミュート ルールを更新します。

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

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

ミューティングルール

フィールドとコンポーネント

accountId

ミュートルールのアカウント ID。ミュート ルールは、単一のアカウントで発生する頻繁なイベントにのみ影響します。 複数のアカウント間で集中イベントをミュートするには、アカウントごとに個別にミュート ルールを作成する必要があります。

actionOnMutingRuleWindowEnded

ミュート ルール ウィンドウの終了時に予想される動作。有効な値はCLOSE_ISSUES_ON_INACTIVEまたはDO_NOTHINGです。CLOSE_ISSUES_ON_INACTIVEが選択されている場合、進行中の問題はすべてクローズされ、イベントが継続する場合は (通知付きで) 再開されます。

condition

どの集中イベントを対象にするかを定義する個々の式のセット。 ミュート ルールの条件には次のものが含まれます。

  • operator:条件のセットを組み合わせる方法を定義するブール演算子ANDまたはOR

  • conditions: まとめイベント内の属性を対象とする個々の式 (サブ条件) のセット。 これらはoperatorに基づいて一緒に評価されます。1 つのミュート ルールには最大 20 個のサブ条件を設定できます。

    サブ条件には次が含まれます。

    • attribute: まとめイベント内の単一のプロパティ。 集中イベントプロパティのリストについては、こちらをご覧ください。

    • operator: 選択した集計イベント プロパティを条件内の値と比較するために使用される比較関数。 サブ条件演算子のリストについては、ここをクリックしてください。

    • values: 選択した集計イベント プロパティと比較する文字列値の配列。 ミュート ルールが条件を評価するときに、必要に応じて、文字列から値が強制変換されます。INなど、複数の値との比較をサポートする演算子を使用する場合は、最大 500 個の値を使用できます。

createdAt

ミューティングルールが作成されたときのタイムスタンプ(UTC)。

createdBy

ミューティングルールを作成した人のユーザーID。

description

これは、ミューティング ルールを説明するオプションのテキスト フィールドです。これは、ミューティング ルールにより多くのコンテキストを提供する便利な方法です。このデータは、管理表示目的でのみ使用されます。

enabled

ミューティング ルールを有効または無効にします (ブール値)。ミューティング ルールを手動で有効または無効にします。

id

ミューティングルールの一意の識別子。

mutingRuleLifecycleEventPublishedAt

ミュート ルール ウィンドウの終了動作が最後に適用された時刻を表す日時スタンプ。

name (必須)

ミューティング ルールのわかりやすい名前のテキスト フィールド。これは、ルールをリストまたは参照するときに使用されます。名前が一意である必要はありませんが、推奨されます。

schedule

MutingRuleがイベントをアクティブにミュートする時間枠。

  • startTime: ミュート ルールがいつ開始されるかを表す日時スタンプ。 これはオフセットなしのローカル ISO 8601 形式です。 例: 2020-07-08T14:30:00
  • endTime: ミュート ルールが終了する日時を表す日時スタンプ。 これは、オフセットのないローカル ISO 8601 形式です。 例: 2020-07-15T14:30:00
  • timeZone: ミューティング ルールのスケジュールに適用されるタイム ゾーン。 例: America/Los_AngelesWikipedia の tz データベース タイム ゾーンのリストを参照してください。
  • repeat: ミューティング ルール スケジュールが繰り返される頻度。 繰り返しがない場合は null を使用します。 オプションはDAILYWEEKLYMONTHLYです。
  • endRepeat: ミュート ルール スケジュールの繰り返しが停止する日時スタンプ。 これは、オフセットのないローカル ISO 8601 形式です。 例: 2020-07-10T15:00:00 。 注: ミュート ルール スケジュールを終了するには、 endRepeatまたはrepeatCountいずれかを使用する必要があります。 両方のフィールドを一緒に指定しないでください。
  • repeatCount: ミューティング ルール スケジュールが繰り返される回数。 これには元のスケジュールが含まれます。 たとえば、 repeatCountが 2 の場合、その繰り返しは 1 回になります。 3 のrepeatCountは 2 回繰り返されます。 注: ミュート ルール スケジュールを終了するには、 repeatCountまたはendRepeatいずれかを使用できます。 両方のフィールドを同時に指定しないでください。
  • weeklyRepeatDays: 繰り返しフィールドがWEEKLYに設定されている場合にミュート ルールを繰り返す曜日。 例: ['MONDAY', 'WEDNESDAY']

updatedAt

ミューティングルールが最後に変更されたときのタイムスタンプ(UTC)。

updatedBy

ミューティングルールを最後に変更した人のユーザーID。

ミューティングの例

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

Copyright © 2026 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.