New Relicアラートデータポイント評価の基礎 - Window DurationとAggregation Methodの理解 ​

New Relicでアラート設定を行う際、多くの方が「しきい値を設定すればアラートが動作する」と考えがちです。しかし実際には、アラート条件がどのようにデータポイントを評価し、どのタイミングでインシデントを判定するかという仕組みを理解することが、効果的な監視の実現には不可欠です。Window Duration（集約期間）やAggregation Method（集約方法）といった設定を適切に行うことで、誤検知を減らし、真に重要な問題を確実に検出できるアラートシステムを構築できます。この記事では、New Relicアラートの根幹をなすデータ評価の仕組みについて、初心者から中級者の方に向けて詳しく解説します。

データポイント評価の基本概念 ​

New Relicアラートは、アプリケーションやインフラストラクチャから継続的に送られてくるテレメトリデータ（メトリクス、イベント、ログなど）を監視し、設定した条件に基づいてインシデントを生成します。このプロセスは単純な「値がしきい値を超えたら通知する」という仕組みではなく、より洗練された評価サイクルで動作しています。

アラート評価の基本的な流れとして、まずデータポイントがNew Relicに到着すると、設定されたWindow Duration（集約期間）に基づいてデータがグループ化されます。例えば、Window Durationを3分に設定した場合、3分間のデータポイントが1つの集約単位として扱われます。次に、この集約されたデータに対して、平均値や合計値などの統計処理が適用されます。そして、この集約値がアラート条件のしきい値と比較され、条件に一致した場合にインシデントが作成されるという流れになります。

データポイントとメトリクスの関係について理解しておくことも重要です。データポイントは個々の測定値であり、例えば「13時01分のCPU使用率は75%」といった単一の観測結果を指します。一方、メトリクスはこれらのデータポイントの集合体であり、時系列で追跡される測定項目全体を表します。アラート条件は、個々のデータポイントではなく、集約されたメトリクス値に基づいて評価されます。

この評価サイクルは秒単位で継続的に実行されており、リアルタイムに近い応答性を実現しています。ただし、この「継続的な評価」は、設定によって大きく動作が変わるため、Window DurationやAggregation Methodの理解が重要になってきます。

Window Duration（集約期間）の理解 ​

Window Durationは、New Relicがデータを分析のためにどの時間単位でグループ化するかを定義する設定です。この設定がアラートの精度と応答性に大きな影響を与えます。

Window Durationとは ​

Window Durationは、アラート評価の時間枠を決定する基本パラメータです。例えば、Window Durationを5分に設定すると、New Relicは5分間に収集されたすべてのデータポイントを1つのグループとして扱い、その期間の平均値や合計値を計算します。この集約値がしきい値と比較され、アラート判定が行われます。

この設定が重要な理由は、データの性質によって適切な集約期間が異なるためです。Window Durationが短すぎると、一時的なスパイクやノイズに反応して誤検知が増えてしまいます。逆に長すぎると、問題の検出が遅れてしまい、ユーザーへの影響が大きくなってしまう可能性があります。

データ頻度に応じた設定 ​

高頻度データの場合、つまり1分ごとに複数のデータポイントが送信されるようなメトリクス（例：Webアプリケーションのページビュー数やレスポンスタイム）では、比較的短いWindow Durationが適しています。例えば、1分ごとにページビューのメトリクスが送信される場合、Window Durationを1～3分に設定することで、リアルタイムに近い検知が可能になります。このような設定では、問題が発生してから数分以内にアラートが発火するため、迅速な対応が可能です。

一方、低頻度データの場合、例えば1時間ごとに実行されるバッチジョブや、日次で実行される処理の監視では、データの特性に合わせて長いWindow Durationを設定する必要があります。日次バッチジョブの場合、Window Durationを1440分（24時間）に設定することで、1日のサイクル全体を1つの評価単位として扱うことができます。

推奨設定値の考え方として、基本的にはデータの送信間隔の1～3倍程度をWindow Durationとして設定するのが良いでしょう。ただし、メトリクスの変動の性質によって調整が必要です。変動が激しいメトリクスでは、ノイズを平滑化するために長めのWindow Durationを設定し、安定したメトリクスでは短めの設定で素早く検知することが推奨されます。

設定例の比較表 ​

以下の表は、データタイプ別の推奨Window Duration設定をまとめたものです。

この表を参考に、監視対象のデータ特性に応じて適切なWindow Durationを選択してください。

Aggregation Method（集約方法）の詳細 ​

Aggregation Method（Streaming Methodとも呼ばれます）は、New Relicがデータポイントをどのように集約し、アラート評価を行うかを決定する重要な設定です。主に3つの方法があり、それぞれ異なる特性とユースケースがあります。

3つのStreaming Method ​

Event Flowは最も推奨される方法で、頻繁かつ安定したデータフローに最適化されています。この方法では、データポイントが到着するたびに継続的にストリーム処理が行われ、Window Duration内のデータが随時集約されます。Webアプリケーションのメトリクスや、継続的に稼働しているサービスの監視に適しています。New Relicの公式推奨設定であり、特別な理由がない限りこの方法を選択するのが良いでしょう。

Event Timerは特定のケースで有効な方法です。この方法では、一定期間内に特定の数のイベントが到着することを前提として動作します。定期的なバッチ処理や、予測可能なスケジュールで実行されるジョブの監視に適しています。例えば、毎日深夜2時に実行されるバックアップジョブや、1時間ごとのレポート生成処理などが該当します。Event Timerを使用することで、低頻度のデータに対しても適切なタイミングでアラート評価が行われます。

Cadenceは一定間隔での評価を行う方法です。この方法では、設定された時間間隔ごとにデータを評価します。データの到着タイミングに関係なく、定期的にアラート条件をチェックしたい場合に使用されます。

選択基準のフローチャート ​

以下のフローチャートは、適切なAggregation Methodを選択するための判断基準を示しています。

基本的には、データが継続的に流れている場合はEvent Flowを選択し、特定のスケジュールで動作するジョブやバッチ処理の場合はEvent Timerを検討するという判断になります。

Sliding Window Aggregationの実践 ​

Sliding Window Aggregationは、データの変動が激しい環境でノイズを削減しつつ、検知の遅延を最小化する高度な手法です。従来の固定ウィンドウ方式では、ウィンドウの境界でデータが急激に変化する問題がありましたが、スライディングウィンドウではこの問題を解決できます。

仕組みと利点 ​

Sliding Window Aggregationの仕組みは、大きな集約ウィンドウと小さなスライディングウィンドウを組み合わせることで、ノイズの平滑化と迅速な検知を両立させます。

まず、大きな集約ウィンドウ（例えば5分）を設定することで、データの変動やノイズを平滑化します。このウィンドウ内のデータ全体を使って統計処理を行うため、一時的なスパイクや異常値の影響を軽減できます。

次に、小さなスライディングウィンドウ（例えば1分）を設定します。このスライディングウィンドウは、大きな集約ウィンドウ内を移動しながら、1分ごとに評価を行います。つまり、5分間のデータを使って計算を行いながら、1分ごとに新しい評価結果を得ることができます。

この仕組みにより、5分間のデータで平滑化しながらも、1分ごとに最新の状態を評価できるため、問題の検出が遅れることがありません。

具体的な動作例として、Webアプリケーションのレスポンスタイム監視を考えてみましょう。通常のトラフィックでは200ms程度のレスポンスタイムですが、一時的に500msのスパイクが発生することがあります。固定の1分ウィンドウでは、このスパイクでアラートが発火してしまう可能性がありますが、5分のスライディングウィンドウを使用すると、5分間の平均値で評価されるため、一時的なスパイクは平滑化され、本当に問題がある場合のみアラートが発火します。

設定方法 ​

Sliding Window Aggregationを設定する際の具体的な手順は以下の通りです。

まず、大きな集約ウィンドウを設定します。アラート条件の作成画面で、Window Durationを5分（または適切な値）に設定します。この期間がデータの平滑化に使用されます。

次に、スライディングウィンドウのステップ幅を設定します。「Slide by」または「Sliding window」オプションで、1分（または適切な値）を設定します。これにより、1分ごとに5分間のデータを使った評価が行われます。

最後に、しきい値を設定します。このしきい値は、スライディングウィンドウで計算された集約値（平均値など）に対して適用されます。例えば、「5分間の平均レスポンスタイムが3秒を超えた状態が3回連続（3分間）続いたらアラート」といった設定が可能です。

注意点とコスト ​

Sliding Window Aggregationは非常に有用な機能ですが、いくつかの注意点があります。

最も重要なのはコストの問題です。New RelicのAdvancedまたはCore Compute価格プランを使用している場合、スライディングウィンドウ集約を利用すると追加のCCU（Compute Capacity Unit）料金が発生する可能性があります。この機能はデータ分析能力を向上させますが、他の方法と比較してコストが増加する可能性があるため、使用前に価格への影響を確認することが推奨されます。

使用の判断基準として、データの変動が激しく誤検知が多い場合や、リアルタイム性と精度の両立が必要な場合にSliding Window Aggregationの導入を検討してください。一方、データが安定しているメトリクスや、コストを最小化したい場合は、通常のWindow Duration設定で十分です。

動作イメージ図 ​

以下の図は、Sliding Window Aggregationの動作フローを示しています。

この図からわかるように、データは継続的に蓄積され、1分ごとに5分間のデータを使った評価が行われます。これにより、平滑化と迅速な検知の両立が実現されています。

Gap Filling Strategy（データ欠損への対処） ​

実際の運用環境では、ネットワークの問題やエージェントの再起動など、さまざまな理由でデータポイントが一時的に欠損することがあります。Gap Filling Strategyは、このようなデータの欠損をどのように扱うかを定義する機能です。

Gap Fillingとは ​

データ欠損が発生する理由はいくつかあります。ネットワークの一時的な切断、監視対象サーバーの短時間の再起動、エージェントのアップデート、データ送信処理の遅延などが主な原因です。これらの理由により、本来1分ごとに送信されるべきデータポイントが送信されない期間が発生することがあります。

Gap Fillingの役割は、このような欠損期間に対して、どのような値を仮定してアラート評価を行うかを決定することです。適切なGap Filling戦略を選択することで、一時的なデータ欠損による誤検知を防ぎつつ、本当に問題がある場合は確実に検出できます。

戦略の選択 ​

None（何もしない）は、データが常に安定して送信される環境で推奨される設定です。データ欠損が発生した場合、その期間はアラート評価がスキップされます。Webアプリケーションのように、常にトラフィックがあり、継続的にデータが送信される環境では、この設定が最も適切です。

値0で埋めるは、最も一般的に使用されるGap Filling戦略です。データが欠損した期間に値0を挿入して評価を行います。例えば、エラー率の監視で使用すると、データが欠損した期間は「エラーが発生していない」と仮定して評価されます。この戦略は、欠損期間が問題ないと仮定できる場合に有効です。

カスタム値では、特定の値を指定してデータ欠損を埋めることができます。例えば、通常時の平均値や、ビジネス要件に基づいた特定の値を使用します。この戦略は、特殊な監視要件がある場合に使用されますが、一般的なケースでは使用頻度は低いです。

Anomaly Thresholdでの注意点 ​

Anomaly Threshold（異常検知しきい値）を使用している場合、Gap Fillingの値の解釈が通常と異なります。Gap Fillingで設定した値は、最後に観測された値からの標準偏差として解釈されます。

例えば、Gap Fillingで値0を設定した場合、欠損期間は「最後に観測された値と同じ」という意味になります。つまり、変化がないと仮定して評価が行われます。Anomaly Threshold使用時は、この動作を理解した上で適切なGap Filling値を選択する必要があります。

適切な値の選択基準として、通常のStatic Threshold使用時は、問題がない状態を表す値（多くの場合は0）を選択します。Anomaly Threshold使用時は、前回値を保持する意味で0を選択するか、または明示的に異常を検出したい場合は極端な値を設定します。

Delay設定の最適化 ​

Delay設定は、データ到着の不整合やタイムスタンプのゆらぎから保護するためのバッファ機能です。適切なDelay設定により、誤検知を防ぎつつ、真の問題を確実に検出できます。

Delayの役割 ​

データはリアルタイムで送信されますが、実際にはネットワーク遅延やエージェントの処理時間により、データポイントのタイムスタンプと実際の到着時刻にはずれが生じます。また、分散システムでは、異なるサーバーから送信されるデータのタイムスタンプが数分ずれることもあります。

Delay設定は、これらの不整合を吸収するための待機時間を定義します。アラート評価を行う前に指定した時間だけ待機することで、遅れて到着するデータポイントも含めて評価できます。これにより、データの不完全性による誤検知を防止できます。

誤検知の防止という観点では、Delay設定がないとデータが不完全な状態でアラート評価が行われ、本来問題がないのにアラートが発火してしまう可能性があります。適切なDelayを設定することで、すべてのデータが揃った状態で評価が行われ、より正確なアラート判定が可能になります。

設定基準 ​

一貫したデータの場合、つまりデータポイントが常に1分以内のタイムスタンプで到着する環境では、低いDelay設定（30秒～1分）で十分です。Webアプリケーションのメトリクスや、クラウド環境の安定したインフラメトリクスがこれに該当します。

不一貫なデータの場合、データポイントのタイムスタンプが数分の範囲でばらつく環境では、高いDelay設定（3～5分）が必要です。オンプレミス環境で複数のデータセンターからデータを収集する場合や、ネットワークが不安定な環境がこれに該当します。

推奨値としては、まずは2分のDelayから開始し、誤検知が多い場合は徐々に増やし、検知が遅すぎる場合は減らすという調整を行うのが実践的です。データの到着パターンをNew Relicのクエリで分析し、95パーセンタイル値を参考にDelay値を決定する方法も有効です。

実践的な設定例 ​

ここでは、実際の監視シナリオに基づいた具体的な設定例を紹介します。これらの例を参考に、自分の環境に合わせて調整してください。

ケーススタディ1: Webアプリケーションのレスポンスタイム監視 ​

ECサイトのWebアプリケーション「WebPortal」のレスポンスタイムを監視する例です。

まず、以下のNRQLクエリでデータを取得します。

SELECT average(duration)
FROM PageView
WHERE appName = 'WebPortal'

このクエリは、WebPortalアプリケーションの平均ページ表示時間を取得します。

設定パラメータは以下の通りです。

• Window Duration 3分 - リアルタイムに近い検知が必要ですが、一時的なスパイクを平滑化するため3分を設定
• Aggregation Method Event Flow - 継続的にトラフィックがある環境なので、Event Flowが最適
• Gap Filling None - 常にトラフィックがあるため、データ欠損はほぼ発生しない想定
• Delay 1分 - データは安定して到着するため、最小限のDelayで十分
• しきい値 Critical 3秒以上が5分継続、Warning 2秒以上が5分継続

この設定により、レスポンスタイムの悪化を素早く検知しつつ、一時的な変動による誤検知を防げます。

ケーススタディ2: 日次バッチジョブの監視 ​

毎日深夜2時に実行されるデータ処理バッチジョブの監視例です。

設定パラメータは以下の通りです。

• Window Duration 1440分（24時間） - バッチジョブは1日に1回実行されるため、24時間のウィンドウを設定
• Aggregation Method Event Timer - 定期的なバッチ処理に最適化された方法
• Gap Filling None（または0） - バッチが実行されない日は問題として検出したいため、Noneまたは0を設定
• Delay 30分 - バッチ処理の完了後にデータが送信されるため、十分なバッファを確保
• しきい値 バッチジョブの実行回数が0回（1日に1回も実行されない場合にアラート）

この設定により、バッチジョブが正常に実行されなかった場合を確実に検出できます。

よくある間違いと対処法 ​

アラート設定でよく見られる間違いと、その対処法を紹介します。

Window Durationが短すぎる場合、一時的なスパイクやノイズに反応して誤検知が頻発します。対処法として、データの変動を分析し、Window Durationを2～3倍に延長してください。また、Sliding Window Aggregationの使用も検討してください。

Window Durationが長すぎる場合、問題の検知が遅れ、ユーザーへの影響が拡大してしまいます。対処法として、Window Durationを短縮するか、Critical/Warningの2段階しきい値を設定して早期警告を受け取れるようにしてください。

Gap Fillingの誤用では、不適切な値を設定すると、データ欠損時に誤ったアラートが発火します。対処法として、まずはGap Fillingを「None」にして動作を確認し、必要な場合のみ適切な値を設定してください。また、Anomaly Threshold使用時は値の解釈が異なることに注意してください。

Delayの設定ミスでは、Delayが短すぎるとデータが不完全な状態で評価され、長すぎると検知が遅れます。対処法として、データ到着パターンをクエリで分析し、95パーセンタイル値を参考に調整してください。また、誤検知と検知遅延のバランスを見ながら段階的に調整することが重要です。

まとめ ​

New Relicアラートの効果的な設定には、Window Duration、Aggregation Method、Sliding Window Aggregation、Gap Filling、Delayといった各種パラメータの理解が不可欠です。これらの設定は、アラートがどのようにデータポイントを評価し、インシデントを判定するかの根幹を成しています。

重要なポイントとして、データの特性（頻度、変動性、安定性）に応じてWindow Durationを適切に設定すること、ほとんどのケースでEvent Flowが推奨されるが、バッチ処理の監視ではEvent Timerが有効であること、Sliding Window Aggregationは強力ですがコストへの影響を考慮すること、Gap FillingとDelayは誤検知防止に重要だが、過度な設定は検知遅延を引き起こすことを覚えておいてください。

次のステップとして、Signal Loss（シグナルロス）の検知設定について学習することをお勧めします。データの送信が停止した場合の検知は、システム全体の健全性監視に不可欠な要素です。また、しきい値の設計とチューニングについても深く理解することで、より精度の高いアラートシステムを構築できます。

関連記事: New Relicアラート概要関連記事: Signal Loss（シグナルロス）検知の実装関連記事: しきい値設計とチューニングの実践