アラートは、システムに問題が発生したときにタイムリーに通知を送信します。見る必要がないとわかっている通知がある場合もあります。 ミューティング ルール を使用して、注意を払う必要のないメッセージが殺到するのを防ぐことができます。
不要な通知に共通する要素を見つけたら、それらの要素を明確に対象とするミュート ルールを定義し、他の通知を通過させることができます。通知がミュートされている場合でも、アラートはそれらのインシデントに関するデータを収集します。ミュート ルールはアラート プロセスに干渉せず、通知が送信される直前に適用されます。
ミューティングルールを管理する
ミューティング ルールの条件は、ミューティングの対象となるインシデントを定義する属性、演算子、および値で構成される個々の式のセットです。
ミューティング ルールを作成、有効化、無効化、および管理できます。 one.newrelic.com > Alerts & AI > Muting rulesに移動します。 ミューティング ルールをいつでも有効または無効にできます。クリック 各ルールの行にある アイコンをクリックして、ルールを編集および削除します。
ルールには、次のいずれかのステータスがあります。
- アクティブ:ミューティングが有効でアクティブです。
- スケジュール済み:ミューティングは有効になっていますが、まだアクティブではありません(将来のスケジュールがあります)。
- 終了:ミューティングは有効になっていますが、アクティブではなくなりました(将来のスケジュールはありません)。
- 非アクティブ:ミューティングが無効になっています。
one.newrelic.com > Alerts & AI > Muting rules : 複雑なミュート ルールを作成して、小規模または大規模な不要な通知セットをターゲットにすることができます。
ミューティングルールを作成する
ミューティング ルールを作成するには、 one.newrelic.com > Alerts & AI > Muting rules に移動し、 + Add a ruleをクリックします。 ミューティング ルールの名前と説明 (オプション) を入力し、ルールを適用するアカウントを選択します。
次に、インシデント フィルターを作成します。 インシデント イベント属性のサブセットを使用できます。 属性、 演算子、および値を選択します。 これらは属性です: accountId
、 conditionId
、 conditionName
、 conditionType
、 entity.guid
、 nrqlQuery
、 policyId
、 、 policyName
、 product
、 runbookUrl
nrqlEventType
conditionRunbookUrl
)、 tags.<NAME>
、およびtargetName
)。値は、アラート ポリシー ID や条件名などのインシデント属性の 1 つと比較されます。さらにフィルターを含める場合は、 [別の条件を追加] をクリックします。
one.newrelic.com > Alerts & AI > Muting rules : 複雑なミュート ルールを作成して、小規模または大規模な不要な通知セットをターゲットにすることができます。
ミューティングルールをスケジュールする
必要に応じて、ミューティングルールをスケジュールできます。
これを行うには、開始時刻または終了時刻、あるいはその両方を選択します。オプションで、ミューティングルールを1日継続するように設定できます。
ミューティングルールスケジュールのタイムゾーンを選択することもできます。デフォルトは、ユーザー設定で選択されたタイムゾーンです。
one.newrelic.com > 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。ミューティング ルールは、1 つのアカウントで発生したインシデントにのみ影響します。複数のアカウントでインシデントをミュートするには、アカウントごとに個別にミュート ルールを作成する必要があります。 |
| ミューティングルールが作成されたときのタイムスタンプ(UTC)。 |
| ミューティングルールを作成した人のユーザーID。 |
| ミューティングルールが最後に変更されたときのタイムスタンプ(UTC)。 |
| ミューティングルールを最後に変更した人のユーザーID。 |
| ミューティング ルールを有効または無効にします (ブール値)。ミューティング ルールを手動で有効または無効にします。 |
| 対象とするインシデントを定義する個々の式のセット。ミューティング ルールの条件には次のものが含まれます。
|
|
|
ミューティングルールのしくみ
ミュート ルールは、通知を抑制またはミュートするために、デフォルトのアラート ライフサイクルの最後に適用されます。既存のポリシーや条件を無効にすることはありません。たとえば、メンテナンス ウィンドウや展開など、既知のシステム中断中は通知をミュートできます。システム中断インシデントは、それらのインシデントの通知がミュートされていても識別されます。
ミューティング ルールは、インシデント イベントの属性と一致する一連の条件を使用します。ミューティング ルールは、次の方法を教えてくれます。
- インシデントが作成された後、問題が開かれる前に個々のインシデントを識別します。
- デフォルトの条件をオーバーライドして、「ミュート」する必要があることを示します。
現在、インシデントをミュートすると、通常のアラート インシデント ライフサイクルが維持されますが、ミュートされたインシデントのみを含む問題は通知を送信しません。
ミューティング ルールは、特定のインシデントを上書きします。既存のポリシーや条件を無効にすることはありません。これにより、多数のエンティティをカバーするポリシーまたは条件によってカバーされる可能性のある特定のエンティティからのインシデントをミュートできます。これにより、システムのサブセットでメンテナンスを実行しているときに、監視を過度にミュートする必要がなくなります。
ミューティング動作
次の表は、アラート インシデントのライフサイクルがミュートされたインシデントによってどのように影響を受けるかを示しています。
もしも | それから | |
---|---|---|
イベント: 問題がアクティブ化されました | ||
ミュートされ ていない インシデントが原因で問題がアクティブ化された | この問題に関する通知が送信されます。 | |
ミュートされ た インシデントが原因で問題がアクティブ化された | この問題に関する通知は送信され ません (ミュート)。 |
ワークフローによる動作のミュート
トリガーされたインシデントと問題の比率は 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のドキュメントを参照してください。