アラート条件を正しく設定するための詳細ガイド

本記事では、New RelicのAlerts & AI 機能のうち、事前定義された条件に基づく異常検出の根幹となるアラート条件（Alert Condition）についてドリルダウンし、お問い合わせ頂くことが多い設定箇所について説明します。ドキュメントと合わせて、アラート条件をどのように設定すべきかに迷った際に、参考として頂ければ幸いです。

また、本ブログで以前公開した、New Relicのアラート機能のトラブルシューティングに関する記事でも、アラートシステムの全体像と、問題の切り分け方法について説明しています。本記事とあわせて、アラート通知で想定と異なる挙動があった場合のトラブルシューティングにお役立てください。

アラートに関連するコンポーネント

以前の記事のおさらいですが、New Relicのアラートシステムは以下のようなコンポーネントで構成されています。

アラート条件（Alert Condition）に定義した条件違反が検出されると、Incidentが作成されます。このときIncidentは、Alert Policyの設定にしたがってグルーピングされ、Issueとなります。IssueがWorkflowをトリガーして、実際にユーザーへの通知が行われます。本記事では、アラート条件違反を検出する前段にあたる集計のプロセスについて深堀りします。

アラート条件の集計とシグナル

アラート条件の集計結果は、内部的にシグナルと呼ばれるデータセットとして記録されます。シグナルの値と、アラート条件の閾値が比較評価され、条件を満たす場合にはIncidentが作成されます。なお、FACETで複数対象を監視している場合、それぞれ別個のシグナルが生成されます。

個々のシグナルにはIDが割り当てられており、NrAiSignal と呼ばれるデータをクエリすることで、特定シグナルの集計結果の時系列や、集計対象になったデータポイントの数といった詳細を確認することができます。通常あまり意識する必要はないかと思いますが、アラートに関して想定と異なる挙動が見られる場合の調査に有効です。NrAiSignal のクエリ時には通常と同様にWHERE句でシグナルIDを指定すると、調査がスムーズです。Incidentにはそれぞれ、判定の元となったシグナルの情報が記録されており、Incident payloadからそのシグナルIDを確認できます。

ストリーミングアラートの処理特性

NRQLアラート条件のWHERE句に該当するデータが、New Relicのアラートパイプラインに到着すると、該当データの集計が開始されます。アラート状態を判定するのに十分な数の評価対象データが揃うまでの集計保留期間を集計ウインドウ（Aggregation window）と呼びます。集計ウインドウが閉じられると、集計結果がシグナルに記録され、閾値と照合してアラートの判定が行われます。

一連の集計処理は、リアルタイムに発生するストリーミングデータに対して行われます。大まかに表現すると、New Relicが収集したデータをデータベースへ格納する処理と同時並行して、アラートパイプラインでの処理も開始される形となります。普段ダッシュボード等で観測されているような、データベースに蓄積された過去のデータを参照する仕組みとは異なり、直近のリアルタイムなデータに基づいて処理が行われる点にご留意ください。

集計ウインドウ

データを集約する単位が集計ウインドウ（Aggregation window）です。アラート条件ごとに、この集計ウインドウの期間を Window Duration として設定します。プレビューにおいて、チャート上にプロットされる個々の点がシグナルで、点と点の間隔が集計ウインドウにあたります。

デフォルトでは、集計ウインドウは重なり合うことはありませんが、Sliding windowsオプションを有効にすると、集計ウインドウを重ね合わせる形でより細かな集計が可能です。

集計方法の選択

データの発生元や収集方法によって大小は異なりますが、メトリックが発生してからNew Relicのアラートパイプラインに到達するまでには遅延が生じる点に考慮が必要です。単純なタイムラグだけでなく、一定周期でバッチとしてメトリクスが送信されるケースもあります。

いずれの場合でも精度の高い集計結果が得られるように、New Relicでは、集計ウインドウ内のデータが一通り到着したと判定する方法、つまり集計ウインドウを閉じる判定ロジックを複数用意しています。

データの性質に合わせて集計方法（Aggregation method）を選択する必要がありますが、基本的にはテレメトリーデータのタイムスタンプと、New Relicのアラートパイプラインに実際にデータが到着するタイミングの乖離に着目します。

データが一定間隔で確実に到着し、タイムラグが少ない場合には、Event Flowを選択します。

ログメッセージなど、エラー時にのみ発生するようなデータ、またはバッチ処理で取得するメトリクスのように、データのタイムスタンプと集計時点との間にタイムラグがある場合には、Event Timerが適しています。

本記事では上記2種類の集計方法について説明します。詳細はドキュメントにも記載がありますので、あわせて参照してください。

Event Flowの特徴

Event Flowで重要となるのは、後続データの到着をトリガーとして、集計ウインドウが閉じられる点です。
毎分01秒ちょうどにデータが到着し、Window Durationが5分、Delayが2分の場合を例とします。12:00:00 から 12:04:59 まで5分間の集計ウインドウ内で、最新のデータのタイムスタンプは 12:04:01 になります。そこから2分後、12:06:01 以降のタイムスタンプを持つデータが到着すると、12:00:00 から 12:04:59 までの集計ウインドウが閉じ、集計と判定が行われます。

ここで、NRQLアラート条件の文脈におけるデータの到着は、NRQLクエリのWHERE句に該当するデータの発生を意味する点に留意してください。
例えば、WHERE result = 'FAILED' のように、NRQLクエリ側で集計フィルターにあたる条件を定義しているケースについて考えます。このケースでは、あるチェック結果のうち、result = 'FAILED' に該当するデータのみが有効な後続データとなります。一定サイクルで報告されるデータがいずれも result = 'SUCCESS' であった場合、WHERE句には該当しないためアラートパイプライン上での処理はされません。

集計ウインドウが閉じてアラート条件の判定が行われるのは、次に result = 'FAILED' に 該当するデータが到着した時点になるため、アラートの発生が想定より大きく遅延する可能性が考えられます。このような場合には、次に説明するEvent Timerに変更することを検討してください。

 Event Timerの特徴

Event Timerでは、集計ウインドウ内のデータが最後に到着した時点からカウントダウンを開始し、0 になると集計ウインドウが終了し判定が行われます。
Window Durationが1分で、Timerが3分の場合を例とします。12:00 から 12:01 の間のタイムスタンプを持つデータが到着すると、集計ウインドウがオープンし、3分間のカウントダウンを開始します。カウントが0になる前に、12:00 から 12:01 の間のタイムスタンプを持つデータが到着するとカウントはリセットされ、その時点から再び3分のカウントダウンが開始されます。こうしてカウントが0になると、集計ウインドウが閉じ、判定が開始されます。

Timerには、Window Durationと同じか、より長い時間を指定します。データが揃う前に集計ウインドウが閉じてしまい、想定と異なる判定結果となる可能性があるためです。

後続のデータが到着するまで判定が保留されるEvent Flowと異なり、Event Timerはランダムに発生するログやメトリクスに対するアラート条件の設定に適しています。

Event Timerはデータのタイムスタンプと処理される時間にラグがある場合に有効ですが、アラート発生タイミングにも同様にラグが生じる点に留意してください。
例えば 12:00 から 12:01 までのメトリクスが 12:10 に到着するケースでは、12:10 を起点としてタイマーのカウントが始まります。ここでタイマーが3分の場合、12:01 に発生したアラートの通知が 12:13 頃になることが考えられます。

典型的な例としては、AWS CloudWatchメトリクスをAPIポーリングで取得している場合が挙げられます。CloudWatch側でメトリクスが記録されるタイミングと、New RelicがAPIをポーリングするタイミングのレースコンディションで、データのタイムスタンプと実際に処理される時間にタイムラグが発生することがあります。こちらはAWS上のメトリクス取得方法を、APIポーリングから、リアルタイム性の高い Metric Streams に切り替えることで大幅な緩和が期待できます。

アラート状態と復旧状態の判定

集計ウインドウが閉じてクエリ結果が得られると、アラート条件の閾値と評価期間に照合して判定を行います。閾値を超過しており、かつ同一のIncidentが存在しなければ、新たにIncidentを作成します。

判定の結果、閾値に指定した評価期間にわたって、アラート条件に違反していない状態が継続すると、復旧状態(recover state)とみなされ、そのアラート条件から発生したIncidentが自動的にクローズされます。

自動復旧の判定は、アラート条件のWHERE句に該当するデータが継続して発生しており、クエリの結果として正常な状態であると判断できることが前提となります。
アラート状態の時のみ値が得られて、正常時にはクエリ結果が存在しないようなアラート条件では、この復旧判定は使用できません。代わりに、Loss of signalの設定による自動クローズが有効です。

判定タイミングに関して注意が必要なのは、後からNRQLクエリを実行した結果と、アラート条件の判定時とで、結果に差異が生じる場合がある点です。
状況は様々ですが、すでに閉じた過去の集計ウインドウ内のタイムスタンプを持つデータが、遅れて届くケースがあります。そのような場合、遅れて届いたデータはクエリ結果のチャート上には反映されますが、すでに集計ウインドウは閉じられているため、アラート状態や復旧状態を判定する要素にはなりません。
チャートのプレビューやクエリ結果と、実際のIncidentのステータスが一致しない場合には、こちらに該当している可能性が高いです。