Streaming Method: Event timer の動作について

前段: 集計ウィンドウについて

アラートコンディションの設定では Window Duration として、時間を設定する項目があります。 これは 集計ウィンドウの時間幅を決める項目となります。

New Relic のアラート評価は、個別のデータではなく、一定期間内 (集計期間) に受信した対象データの集計値を 閾値の評価に利用します。

ここで行われる 集計 はアラートクエリの SELECT 句 で設定した内容となります。

SELECT 句の例

• SELECT average(cpuPercent) .. であれば cpuPercent の平均を算出
• SELECT max(duration) .. であれば duration の最大値を算出
• SELECT count(*) .. であれば 任意のカラムを持つデータの個数をカウント など

また、対象データ は、アラートクエリの FROM 句、WHERE 句、FACET 句に合致するデータが対象データとなります。 (一部の Metrics データでは SELECT 句の指定項目が対象データに利用される場合がございます。)

• FROM SystemSample WHERE hostname = ‘web1’ であれば、SystemSample データで hostname が web1 であるデータが対象データです

• FROM Transaction FACET appName WHERE page = ‘index.php’ であれば Transaction データで page が index.php であるデータが各 appName ごとの対象データとなります (appName が異なる場合は、異なるアラートシグナルに分類されます。対象データも各 appName ごとに分離して扱われます)

• FROM Log であれば、Log データが対象データとなります。この場合、期間内に受信したすべてのログデータが対象データとなります

例えば、Window Duration が 10分でアラートクエリが下記であった場合、

SELECT average(duration) FROM Transaction WHERE appName = ‘hoge’

10分ごとに区切られた時間枠で hoge アプリの平均応答時間が算出されます (※ データ受信がなかった場合、SELECT 句の集計処理は行われません)。

前段: データが集計されるタイミング

「データはいつ集計されるのか」を制御するのが Streaming method です。

ここでは各メソッドの概要のみを記載します。

Event flow 後続データを受信したタイミングで集計が行われます。より正確には「集計ウィンドウの終了時刻 + 遅延 (delay)」以降のタイムス>タンプを持つ後続データを受信したタイミングです。後続データを 65分以内に受信しなかった場合、未集計データは破棄されます。そのため、定期的にデータを受信し続けている場合に適しています。

Event timer 対象データ受信後に一定時間が経過した（タイマーが 0 になった）タイミングで集計が行われます。後続データが存在する場合にそれらも集計に含めるため、タイマーという猶予期間が設けられています。単一のデータ受信でも集計が行われるため、ログやエラーなど不定期なイベントの検知に適しています。

Cadence ウィンドウが終了したタイミングで集計が行われます。より正確には、ウィンドウ終了後に設定した delay 時間の経過を待ってから集計されます。データの到着ではなく「実時間」を元に集計タイミングが決まります。遅延傾向にばらつきがある場合、delay 時間を最も遅いデータに合わせる必要があるため、通知までに時間がかかる場合があります。

前段: タイムスタンプと到着時刻

データには timestamp (タイムスタンプ) カラムが存在し、値を取得した時間または送信された時刻が記録されています。

{
  “timestamp”: 1764558180 # 時刻のエポックタイム (2025-12-01 12:03:00 (JST))
  “value”: 50
}

データに付属するタイムスタンプは必ずしも NewRelic 側の受信時刻と等しいとは限りません。

• ネットワークなどの問題で送受信プロセスで遅延が発生した場合
• 送信側の時計がずれていた場合
• API ポーリングなどで、1時間に1度まとめてデータを取得する仕組みである場合
• ジョブ系のデータでジョブの開始時刻がタイムスタンプと設定されている場合

など、仕組み上の関係で必然的に時刻がずれる場合もあります。
データを受信する New Relic 側ではいずれの場合でも遅延として扱われます。

Window Duration が 5分 (Sliding by なし) であった場合、集計ウィンドウは 下記のように固定された時間枠で 5分ごとに作成されます。
(Window Duration は 30秒~6時間で設定可能です)

• 12:00 - 12:05 ウィンドウ
• 12:05 - 12:10 ウィンドウ
• 12:10 - 12:15 ウィンドウ

下記のようなデータを受信した場合、どのウィンドウに所属するかを考えてみます。

• パターン1: 12:04:30 のタイムスタンプを持つデータが 12:04:36 に到着した
• パターン2: 12:04:55 のタイムスタンプを持つデータが 12:05:01 に到着した
• パターン3: 12:10:05 のタイムスタンプを持つデータが 12:09:58 に到着した

データがどのウィンドウに所属するかは、データのタイムスタンプで決まります。

パターン 1 の場合、タイムスタンプ は 12:04:30 であるため、12:00 - 12:05 ウィンドウ所属のデータとなります。
パターン 2 の場合、タイムスタンプ は 12:04:55 であるため、12:00 - 12:05 ウィンドウ所属のデータとなります。受信時刻は 12:05 を超えていますが、データの所属はタイムスタンプに依存します。ただし、対象ウィンドウがすでに集計されている場合はアラートデータとしては受け付けられません。
パターン 3 の場合、タイムスタンプ は 12:10:05 であるため、12:10 - 12:15 ウィンドウ所属のデータとなります。受信時刻はタイムスタンプよりも前ですが、データの所属はタイムスタンプに依存します。タイムスタンプが未来のデータの場合でも受信しますが、受信上の制限 (24時間以内) とアラートの制限 (500ウィンドウ以内) がそれぞれあります。

Event timer の一般的な説明

Event timer では Timer (タイマー) を設定します。(2025/12 時点では) タイマーは 5秒 ~ 20分の範囲で設定可能です。

対象データを受信すると、タイマーのカウントダウンが開始されます。
タイマーのカウントダウンが 0 になる前に、後続データを受信した場合、タイマーのカウントはリセットされ、再度、カウントダウンが開始されます。
タイマーが 0 になったタイミングで、集計が行われます。

Event timer に関する疑問 1 (データを受信し続けた場合の挙動)

タイマーのリセットは、「同一ウィンドウ」に所属するデータを受信したときのみ行われます。
対象データを受信し続けた場合であってもデータのタイムスタンプが進んでいれば、異なるウィンドウのデータに移行することになります。対象データを受信しなくなったウィンドウではタイマーはリセットされなくなるため、カウントは 0 になり、集計処理が行われます。

Window Duration (WD) が 5分で、Event timer (タイマー1分) の場合で 以下時刻 (hh:mm:ss) のタイムスタンプを持つデータが到着した場合を考えてみます。

• データ1 .. 12:04:10 (遅延なしで到着) .. 12:00-12:05 ウィンドウに所属するデータ
• データ2 .. 12:04:40 (遅延なしで到着) .. 12:00-12:05 ウィンドウに所属するデータ
• データ3 .. 12:05:05 (遅延なしで到着) .. 12:05-12:10 ウィンドウに所属するデータ

データ1 の到着で、12:00-12:05 ウィンドウのタイマーのカウントダウン (1分) が開始されます。
カウントダウンが 0 になる前に データ 2 が到着しますので、12:04:40 にタイマーはリセットされ、再度 1分のカウントダウンが開始されます。

その後、14:05:05 にデータ3 が到着しますが、これは 12:05-12:10 ウィンドウに所属するデータとなるので 12:00-12:05 ウィンドウのタイマーはリセットされません。
したがって、12:00-12:05 ウィンドウは 12:05:40 にカウントダウンが 0 になり、12:00-12:05 ウィンドウの集計処理がそのタイミングで行われます。

一方で、12:05-12:10 のウィンドウもカウントダウンが進み 1分後の 12:06:05 に 0 となり、12:05-12:10 のウィンドウの集計処理がそのタイミングで行われます。

上記のようにタイマーのカウントダウンは基本的にはウィンドウごとで独立して動作します。
データの送受信遅延など受信順が逆転した場合、より前の時刻のウィンドウのタイマーが作動している場合 (カウントダウンされている場合) は、カウントが 0 になっても集計されず、より前の時間のウィンドウのカウントダウンが終了したタイミングで、集計処理が行われます。 (なるべく timestamp 順に閾値超過を行うため)

Event timer に関する疑問 2 (Window Duration よりもタイマーが短い場合の挙動)

下記のようなログ監視のアラートコンディション (エラーを含むメッセージを受信したら閾値違反) を例にします。

SELECT count(*) FROM Log WHERE message like ‘%error%’
Window Duration が 1時間
Event timer タイマー5分
閾値が result > 0 for at least 1時間 (= WindowDuration 1つ分)

以下の時刻 (hh:mm:ss) のタイムスタンプを持つ対象データを受信した場合を考えてみます。

• データ1 .. 13:01:10 (遅延なし) .. 13:00-14:00 ウィンドウに所属するデータ
• データ2 .. 13:30:20 (遅延なし) .. 13:00-14:00 ウィンドウに所属するデータ
  • この場合、集計されず破棄されます
• データ3 .. 13:31:30 (遅延なし) .. 13:00-14:00 ウィンドウに所属するデータ
  • この場合、集計されず破棄されます
• データ4 .. 12:45:40 (1時間遅延 (13:45:40) で到着) .. 12:00-13:00 ウィンドウに所属するデータ
  • この場合、集計されず破棄されます
• データ5 .. 14:10:50 (遅延なし) .. 14:00-15:00 ウィンドウに所属するデータ

13:01:10 のタイムスタンプをもつデータ1 は 13:00 - 14:00 ウィンドウに所属するデータで、データ受信時に同ウィンドウのタイマーの 5分のカウントダウンが開始されます。
以降カウントダウンが 0 になるまで、後続のデータがないため、13:06:10 にカウントダウンは 0 になり、集計値 (count(*)) 1 が算出されます。
閾値は 直近の 1つの集計値が 0 よりも大きい場合に違反とする、という設定であるため、閾値違反と判定され、この時間 (13:06) にインシデントおよび Issue が作成されます。

次に データ2, 3 を 13:30 ごろに受信しますが、すでに 13:00 - 14:00 ウィンドウは集計処理が完了しているため、これらのデータはアラートの集計に含まれず破棄されます。(インシデントが作成されているかということではなく、このウィンドウがすでに集計済みであるためです)

13:45:40 にデータ 4 が 1時間遅延で到着します。データ 4 のタイムスタンプは 12:45 であるため 12:00 - 13:00 ウィンドウに属するデータとなります。
12:00 - 13:00 ウィンドウは過去に対象データを受信していないため、まだ集計は行われていませんが、よりあとのウィンドウである 13:00 - 14:00 ウィンドウが集計されてしまっているため、クローズ済みという扱いで、データ 4 も集計には含まれず、破棄されます。
ウィンドウが集計される際に、より後の時間のウィンドウがすでに集計済みであった場合は、該当ウィンドウの集計処理は却下されます。

最後に 14:00 - 15:00 ウィンドウに属するデータ 5 が 14:10:50 に到着します。
同様に 5分後にカウントダウンが 0 になり、集計処理が行われ、集計値が 1 が算出されます。
閾値評価では違反となりますが、データ 1 によるインシデントが Open (継続中) の場合は、新規のインシデントは作成されません。
継続中の障害 (インシデント) で、継続して (後続データでも) 閾値を超過している、という判定となるため、シグナル値 1 が記録されるだけで、特に何も起こりません。

したがって、シグナルの集計処理上では下記のようになると思われます。
また集計処理自体は (経験上) 15~60秒 (おおよそ30秒程度) かかる場合が多いです。

Event timer のアンチパターン (信号損失閾値の期間がタイマーよりも短い場合)

信号損失閾値 (Lost Signal Threshold) を導入する場合は、信号損失閾値の時間が Event timer のタイマーよりも短くならないように設定する必要があります。

例えば、Event timer のタイマーが 5分で、信号損失期間が 3分 であった場合、タイマーが 0 になる前に、信号損失が発生してしまいます。 信号損失が発生した場合、未集計のデータが破棄されますので、アラートデータとして集計されなくなってしまいます。

Event timer 使用で注意が必要なパターン (閾値で 2以上 にしたいときの対処)

10分間に対象のログを 2つ以上受信した場合に通知したい (閾値違反とする) というアラートを設定したい場合を考えてみます。

Window Duration を 10分とした場合、下記のようにウィンドウが割り振られるため

• 12:00 - 12:10
• 12:10 - 12:20
• 12:20 - 12:30
• 12:30 - 12:40

12:08, 12:12 に対象データを受信した場合は、それぞれが異なるウィンドウに属することになってしまいます。

sliding window aggregation (SWA) を利用すると、アラート要件に近づけることができそうです。
例えば、Window Duration を 10分で、SWA を 1分とした場合で、10分のウィンドウが1分ずれて作成されます。
このとき 12:08:01, 12:12:01 に対象データを受信した場合は、ウィンドウの対象データは下記のようになり、12:03-12:13 ~ 12:08-12:18 ウィンドウでは両方のデータを含めることができます。
閾値を result >= 2 at least once in 1分 とすれば 12:03-12:13 ウィンドウが集計されたタイミングで閾値違反となります。

(この場合、9分以内にデータを受信した場合には検知。タイムスタンプによってはポイント間が 9分~10分の場合でも検知できる場合があるという設定になるかと思います。)

上記のような設定において、Event timer を利用する場合の注意点は、タイマーは Window Duration と同じ時間以上にする必要があるという点です。

タイマーを1分などにしていると、1分以内に後続データを受信しないと、後続データの受信前にタイマーが 0 になり、ウィンドウが集計されてしまいます。

現行では Event timer のタイマーは最大 20分であるため、Window duration が 20分より長い場合、Event timer ではすべてのデータを集計できない場合があります。

また、Event timer 利用の場合、上記のようにデータ受信後にタイマー分の時間経過を待つことになってしまうため、インシデント発生まで時間がかかってしまう場合もあるかと思います。
そのような場合は、ウィンドウの終了後に集計が行われる Cadence を利用してみてください。