みなさんこんにちは。
マネージドサービス部の福田です。

自身の備忘録用としてもまとめたかったので
記事にしました。

アラートの要素

Alert Policy、Alert Conditionについて

Alert Policy

アラート条件をまとめて管理するための設定になります。
異なる監視内容や通知ルール（通知方法、通知先など）を定義するために使用されます。

Alert Condition

個々のメトリクスやイベントを監視し、特定の条件が満たされた場合に
アラートをトリガーするための設定です。
例えば、特定のメトリクスが一定のしきい値を超えたときにアラートを発するような条件を定義します。

まとめ

Alert Policyはアラート設定をまとめたグループになり、複数のAlert Conditionをポリシー内に設定することができます。
一方、Alert Conditionは具体的な監視ルールを定義し、その条件が満たされるとアラートがトリガーされます。

Incidents、Issueについて

IncidentsとIssue

Alert Conditionの閾値を超過した場合はIncidentが生成されます。
Incident Prederenceの設定によって、Issueを起票する（Incidentをまとめる）粒度を設定します。

Incidentが発生したらアラートではなく、Issueが発生したらアラートと処理される流れになります。

Issueの起票粒度

例. 1つのAlert Policyに2つのAlert Conditionを設定し、その全てがCriticalになった
• フロントエンドのJSエラー率上昇(対象サイトは1つ)
• サーバーサイドのエラー率上昇(対象アプリケーションは3つ)

設定名	Issueの起票粒度	この例で起票されるIssue
By Policy	ポリシー単位	1つ (ポリシー全体で1つ)
By condition	コンデイション単位	2つ (JSエラーで1つ, サーバーサイドエラーで1つ)
By condition and signal	インシデント単位	4つ (JSエラーで1つ, サーバーサイドエラーで3つ)

Workflows、Destinationsについて

Workflows

IssueとDestinationと関連づけて対象のIssueを
どこに通知するのかを紐づけする項目になります。
また対象Issueに情報（NRQLクエリの結果や、Entity情報）を付加することも可能です。

公式ドキュメント：Workflows | New Relic Documentation

Destinations

Issueの通知先を設定する項目になります。
なお、以下を通知先として指定が可能になります。

Atlassian Jira
ServiceNow
Slack
Webhook
メール
AWS EventBridge
PagerDuty
New Relic Mobile Push

公式ドキュメント：Destinations | New Relic Documentation

Alert Conditionの要素

Streaming method（Event flow、Event timer）の違い

Event flowの特徴

後続のウィンドウに最初のデータポイントが到着したときにデータのウィンドウを集約し集計するため、後続データが届かない場合は集計されない
評価タイミングはデータのタイムスタンプに基づき実施
現在のウィンドウの集計をトリガーするために、Delayでタイミングを調整する

Event timerの特徴

イベントタイマーは指定されたウィンドウのデータが到着したときのみ、そのウィンドウのデータを集計
集計ウィンドウにデータポイントが到着すると、そのウィンドウ専用のタイマーがカウントダウンを開始
- それ以上のデータが到着しない場合、そのウィンドウのデータは集約される
- タイマーのカウントダウンが完了する前にさらにデータが到着した場合、タイマーはリセットされ再度カウントダウンが始まる
Event timerの注意点
- タイマーをウィンドウの継続時間と同じかそれ以上にする
  - タイマーがウィンドウの時間より短く、データの流れに一貫性がない場合、誤った通知が行われる可能性がある

Sliding window aggregationについて

概要

データを評価するウィンドウを動すことで、リアルタイムでのデータ集計を実現する機能になります。
短い期間のデータを定期的に集計することで、異常なパフォーマンスの変化や問題を迅速に検知することも可能です。

newrelic.com

使用例：ウェブアプリのレスポンスタイム監視

ウェブアプリケーションでは、ユーザー体験が重要かと思います。
Sliding Window Aggregationを活用することでリアルタイムでのレスポンスタイムの監視が可能になります。

Sliding Windowの設定: 
5分間隔でデータを集計するSliding Windowを設定します。
これにより、直近のデータを含むウィンドウが常にスライドしてデータを集計します。

アラートの設定: 
レスポンスタイムが一定の閾値を超えた場合に
アラートを発生させるアラート条件を設定します。

リアルタイム監視：
リアルタイムでSliding Windowがスライドし、レスポンスタイムが常に更新されます。
もし閾値を超えた場合、すぐにアラートが発生し、問題の迅速な対応が可能となります。

Gap filling strategyについて

概要

データセット内のギャップを埋め、正確な分析と可視化を可能にするための機能になります。
時系列データの評価において、データの欠損が問題となる場合、Gap-filling strategyを適用することで
データの完全性を保ちながら分析や可視化を行うことが可能になります

実際の動作と評価の仕組み

異常なデータが12:00:30に、その後正常なデータが12:05:40に到着した場合
1分の集計間隔で評価を行う場合は以下になります。

・12:00 - 12:01 の期間では、異常値が検出されます。
・12:01 - 12:02 の期間では、評価対象のデータが存在しないため、評価結果はNULLとなります。
・同様に、12:02 - 12:05 の期間も評価対象のデータがないため、評価結果はNULLとなります。
・12:05 - 12:06 の期間では、正常値が検出されます。

Gap-fillingが設定されている場合、NULLと評価された期間（12:01 - 12:05）のデータは後から埋められます。
Gap-fillingに評価されたデータはNrAiSignal内のfillOptionに記録されます。

まとめ

NewRelicのアラート設定する際に出てくる項目を簡単にまとめてみました。
他にも以下のような機能もありますのでアラート設定する時の参考にしていただければと思います。

Evaluation delay：最初のデータを評価するまでの時間の決定（起動が遅いプロセスの監視等に使用できる）
signal lost：Nullデータが到着した場合、インシデントを起票するか、インシデントを閉じるか等の決定

【New Relic】基本的な監視設定項目をまとめてみた。