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

この機械翻訳は参考用に提供されます。

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

問題を作成する

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

アラートは、システムに問題が発生したときにタイムリーに通知を送信します。見る必要がないとわかっている通知がある場合もあります。 ミューティング ルール を使用して、注意を払う必要のないメッセージが殺到するのを防ぐことができます。

不要な通知に共通する要素を見つけたら、他の通知を通過させながら、それらの要素を特に対象とするミュート ルールを定義できます。 通知がミュートされていても、 は依然としてそれらの事件に関するデータを収集しています。 ミュート ルールはアラート プロセスに干渉せず、通知が送信される直前の時点で適用されます。

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

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

ミュート ルールを作成、有効化、無効化、および管理できます。one.newrelic.com > All capabilities > Alerts & AI > Muting rulesに移動します。ミュート ルールはいつでも有効または無効にできます。クリック 各ルールの行にある アイコンをクリックして、ルールを編集および削除します。

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

  • アクティブ:ミューティングが有効でアクティブです。
  • スケジュール済み:ミューティングは有効になっていますが、まだアクティブではありません(将来のスケジュールがあります)。
  • 終了:ミューティングは有効になっていますが、アクティブではなくなりました(将来のスケジュールはありません)。
  • 非アクティブ:ミューティングが無効になっています。

one.newrelic.com > All capabilities > Alerts & AI > Muting rules: 複雑なミューティング ルールを作成して、小規模または大規模な不要な通知のセットをターゲットにすることができます。

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

ヒント

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

ミューティング ルールを作成するには、 one.newrelic.com > All capabilities > Alerts & AI > Muting rules に移動し、 + Add a rule [+ ルールの追加 を]クリックします。ミュート ルールの名前と説明 (オプション) を入力し、ルールを適用するアカウントを選択します。

次に、インシデント フィルターを構築します。インシデント イベント属性のサブセットを使用できます。属性、 演算子、および値を選択します。これらは属性です: accountIdconditionIdconditionNameconditionTypeentity.guidnrqlQuerypolicyId 、 、 policyNameproductrunbookUrl nrqlEventType conditionRunbookUrl)、 tags.<NAME> 、および targetName)。値は、アラート ポリシー ID や条件名などのインシデント属性の 1 つと比較されます。さらにフィルターを含める場合は、 Add another condition [別の条件を追加] をクリックします。

one.newrelic.com > All capabilities > Alerts & AI > Muting rules: 複雑なミューティング ルールを作成して、小規模または大規模な不要な通知のセットをターゲットにすることができます。

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

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

これを行うには、開始時刻または終了時刻、あるいはその両方を選択します。オプションで、ミューティングルールを1日継続するように設定できます。

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

one.newrelic.com > All capabilities > Alerts & AI > Muting rules: ミューティング ルールをスケジュールするための柔軟で強力なオプション。

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

重要

Repeat day of the week チェックボックスは、 Starts および Ends の 日付フィールドよりも優先されます。 開始日を設定し、曜日も選択した場合、ミューティング ルールは開始日の後の最初の日に適用されます。

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

NerdGraphを使用してミューティングルールを管理する

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

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

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

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

ミューティングルール

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

id

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

name必須

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

description

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

accountId

ミューティング ルールのアカウント ID。ミューティング ルールは、1 つのアカウントで発生したインシデントにのみ影響します。複数のアカウントでインシデントをミュートするには、アカウントごとに個別にミュート ルールを作成する必要があります。

createdAt

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

createdBy

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

updatedAt

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

updatedBy

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

enabled

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

condition

対象とするインシデントを定義する個々の式のセット。ミューティング ルールの条件には次のものが含まれます。

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

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

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

    • attribute: インシデント内の単一の属性。インシデント イベント属性のリストについては、ここを参照してください。
    • operator: 選択したインシデント属性を条件の値と比較するために使用される比較関数。サブ条件演算子のリストについては、こちらを参照してください。
    • values: 選択したインシデント属性と比較する文字列値の配列。ミューティング ルールが条件を評価するとき、必要に応じて、値が文字列から強制的に変換されます。INなど、複数の値に対する比較をサポートする演算子を使用する場合、最大 500 個の値を使用できます。

schedule

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

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

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

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

ミューティング ルールは 、インシデント イベントの属性と一致する一連の条件を使用します。ミュート ルールは次の方法を示します。

  1. インシデントが作成された後、問題が開かれる前に個々のインシデントを識別します。
  2. デフォルトの条件をオーバーライドして、「ミュート」する必要があることを示します。

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

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

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

ミューティング動作

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

もしも

それから

イベント: 問題がアクティブ化されました

ミュートされ ていない インシデントが原因で問題がアクティブ化された

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

ミュートされ インシデントが原因で問題がアクティブ化された

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

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

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

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

  • 完全にミュート(FULLY_MUTED) :問題の未解決のインシデントがすべてミュートされています(デフォルト値)。
  • 部分的にミュート(PARTIALLY_MUTED) :少なくとも1つの未解決のインシデントがミュートされ、1つの未解決のインシデントがミュートされていない問題。
  • ミュートされていません(NOT_MUTED):未解決のミュートされたインシデントがない問題。

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

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

オープンまたはクローズ済みの問題を表示すると、インシデントと問題は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:注意:このオペレーターの条件により、アカウントのすべてのインシデントがミュートされます。

ミューティングの例

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

Copyright © 2024 New Relic株式会社。

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