本記事では New Relic のアラートを抑止する機能である Muting Rules の設定方法と動作について記載します。
製品ドキュメント の補足として、意図通りのアラート設定を行うまたはトラブルシューティングのヒントとして頂ければ幸いです。
通知抑制 (Muting Rules) の概要
Alerts > Muting Rules にて、ミューティングルールを設定することにより、合致したアラート通知を抑制することができます。
本ミュート機能は、Workflow 通知 を抑止するという機能で、インシデントや Issue は作成されます。
アラート通知までの流れ
ミューティングルールの動作仕様の前に、アラート通知までの流れをおさらいます。
- アラートコンディションの対象データを受信し、Streaming Method のタイミングでシグナル値が集計される
- (アラートコンディションの) 閾値評価が行われ、閾値違反の場合はインシデントが作成される
(Open 中のインシデントが存在する場合は、継続中と判断されるため何も起こりません) - 作成されたインシデントは、新規 Issue または既存の Issue にまとめられる
- Issue のイベントに応じて、Workflow 通知が発報される
新規 Issue の場合は、Issue アクティベート (Activated)、
既存 Issue の場合は、Issue への インシデント追加イベント (other updates) が発生します
また、既存 Issue への追加の際にプライオリティが変化する場合は Priority Changed 通知が発生します - ユーザー操作にて Issue への 承認操作が行われると Acknowledged による通知が発生します
- 閾値の回復判定や時間経過などで、インシデントがクローズした場合
すべてのインシデントがクローズされる場合は、Issue クローズ (Closed)、
Issue はクローズされない場合 (Open 中インシデントが残る場合) は、インシデントクローズ (other updates) が発生します
また、IssueTtl やユーザーのクローズ操作で Issue がクローズした場合は Issue クローズ (Closed) 通知が発生します
Workflow 通知は Issue イベントをトリガーとして行われます。
ミューティングルールの設定
ミューティングルールは UI の Alerts > Muting Rules または NerdGraph API などから設定することができます。
設定項目は、ミュート対象のインシデント (Violation filter) と日時情報 (Schedule) です。
Violation filter 設定では、ポリシーやコンディションまたはエンティティやタグなどの情報を設定し、条件に合致したインシデントが対象となります。
Schedule 設定では、開始/終了の時刻や繰り返しの有無 (日次、週次、月次) を選択することができます。
該当ルールが開始時刻になると、ルールはアクティブとなり、終了時刻をすぎると Ended となります。
繰り返しのありの場合で非アクティブな場合は Scheduled と表示されます。
ここで重要なことは対象がインシデントであるという点です。
インシデントのミュート属性
インシデントが作成されたタイミングで、条件に合致するミューティングルールがあるかどうかのチェックが行われます。
合致するミューティングルールが存在する場合、そのインシデントのミュート属性 (muted) が true に設定されます。
合わせて合致するミューティングルール情報 (ルール Id とルール名) がインシデントの属性に追加されます。
複数のミューティングルールに該当する場合でも、いずれかのルール情報が紐づきます。
また、インシデントのミュート属性の値は、該当ミューティングルールが非アクティブに遷移した場合 (終了した場合) でも変更はされません。
インシデントのミュート属性は NrAiIncident をクエリすることで確認できます。
SELECT muted, mutingRuleId, mutingRuleName, * FROM NrAiIncident WHERE conditionId = xxx
また、UI の Issue ページから Incident payload でも表示することができます。 (Incident payload ではミュートの場合は、mutingRuleId, mutingRuleName 属性が記載されます。ミュートではない場合は表示されません。)
Issue のミューティングステート
次に Issue の ミュート状態についてです。
Issue に所属するインシデントのミュート属性によって、下記の 3つの状態をとります。
- 所属する全ての Open インシデントが ミュートな場合、Issue は Fully muted となります
- ミュートな Open インシデントとミュートな Open インシデント混在する場合、Issue は Partially muted となります
- 所属する全ての Open インシデントが 非ミュートな場合、Issue は Not muted となります
Issue のミューティングステートは、UI の Issue ページの Issue payload にて、mutingState にて確認することができ インシデントが 追加される またはクローズイベントによって、値は変化します。
また、NrAiIssue イベントをクエリすることでも確認できます。
SELECT event, muted, * FROM NrAiIssue WHERE issueId = xxx
NrAiIssue の場合は、Issue にインシデントの追加/クローズが発生してもイベントとしては記録されないため create, activate, acknowledge, close が発生したタイミングでの状態が確認できるだけとなります。
Workflow における issue ミュート動作設定
各 workflow で issue のミューティングステートに対する動作を設定することができます。
Workflow > Additional settings より下記の 3つの動作から選択します。
- issue のミュートステートが Fully muted の場合、通知を抑止する (デフォルト)
この場合、Not muted または Partially muted の場合は通知されます - issue のミュートステートが Fully muted または Partially muted の場合、通知を抑止する
この場合、Not muted の場合は通知されます - issue のミュートステートに関係なく通知を行う
本ブログ執筆時点 (2024/09) では、下記のように動作するため注意が必要です。
Issue のミュートステートは インシデントの Open/Close によって変化するが、
Workflow の通知が抑止設定は、 issue がアクティベートした際の ミュートステートで固定され、インシデントの Open/Close の変化は受けません。
つまり、issue が作成され 、アクティベートされたときに、Not muted な issue であった場合、
その後、ミュートなインシデントが その issue に追加されて (partially muted な issue に遷移した) としても、
workflow は アクティベート時の ミュートステートで動作するため、Not muted な issue と判定されます。
ミュート終了後の動作
Muting Rule が有効な時間帯に作成された インシデントおよび Issue は、workflow の抑止設定動作に従って、通知が抑止されます。
該当の Muting Rule が終了した場合でもインシデントおよび Issue の内部的なミュート属性は変化しないため、Issue がクローズされるまでは、引き続き、通知が抑止されます。
従って、メンテナンス等が終了するタイミングで、継続中の Issue が存在する場合は、状況の確認などを実施いただき
復旧対応または、手動での Issue のクローズを実施ください。
Muting Rules を利用しないアラートの抑止方法
アラートコンディションや Workflow は 有効/無効 を切り替えることができるので、アラート抑止開始時に無効化、抑止終了時に有効化 するという方法でもアラートの抑止は可能です。
Muting Rules とのおおまかな違いは、下記となります。
- インシデント単位ではなく、コンディションや workflow 単位でのアラート抑止となる点
- アラートコンディションを無効化する場合は、インシデントも作成されなくなるという点
有効/無効の変更操作は UI での手動操作 や NerdGraph API にて操作可能です。
時間指定で実行するようなツールにてスクリプトやコマンドを登録いただければ自動での切り替えも可能です。
また、アラートコンディションの 有効/無効 を行う場合は、対象のシグナルに対して、リセットが発生するので
継続中のインシデントがある場合は、インシデントはクローズとなります。
また、長時間の Window Duration (WD) を設定されているような場合は、未出荷データの破棄やウィンドウの開始時刻に関して注意が必要です。
例えば WD が 6時間の場合で
12:05 (UTC) に有効化された場合は 12:00 - 18:00 時間帯のウィンドウはすでに始まってしまっているので、この期間のデータは対象外となり
次の 18:00 - 24:00 の評価から開始されることになります。
上記は極端に長い場合の例ですが、
WD や評価期間が数分の場合は、コンディションの有効/無効化運用で問題はないかと思います。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
