[Alerts] Evaluation Delay の動作

機能概要

Evaluation Delay は 新規のシグナル (データ) に関して一定期間 (設定した時間の間は) 閾値評価を行わない、つまりインシデントを作成しないようにする、という機能となります。

例えば、Evaluation Delay を 20分と設定した場合、最初の 20分間は閾値を超過しても違反とは判定されず、インシデントは作成されません。

設定

Evaluation Delay はアラートコンディションの Set thresholds ページの設定項目で、デフォルトでは無効化 (利用なし) となっています。

Use evaluation delay トグルを有効化すると、シグナル遅延時間 (閾値評価を行わない期間) を設定できます。

対象シグナル (新規シグナル) について

Evaluation Delay の対象は新規シグナル、または シグナル TTL 後に再出現したシグナルの最初の数分間 (Evaluation Delay で指定された期間) のシグナルです。

新規シグナルの最初の集計からの起算となります (「適用される時刻について」 にて詳細を記載)。 アラートコンディション作成後から起算ではなく、シグナルが作成されてからの起算となります。

また、シグナルの TTL は 24時間であるため、24時間以上シグナルがない状態のあとで、再度データ受信が再開し、シグナル値が集計された場合は、新規と同じように、復帰後の最初の数分間 (Evaluation Delay で指定された期間) のシグナル値に対しては閾値の判定を行わないという動作となります。 (数分の OS 停止では、シグナルのリセットはされません。)

シグナル TTL の他にアラートコンディションの (シグナルの算出や閾値評価に関する項目の) 変更を行った場合、シグナルはリセット (再作成) されます。 コンディションの変更後に受信したデータは新規シグナルとなるため、 Evaluation Delay が適用されます。

「シグナルの評価に関する項目」は、アラートクエリ、WD や閾値などの項目で コンディション名、violationTtl や title template、description などシグナルの算出や閾値評価に関係のない項目の変更では、シグナルはリセットされません。

適用される時刻について

シグナルの集計処理に関しては、ウィンドウの開始時刻 (timestamp)、ウィンドウの終了時刻 (EndTimestamp)、集計処理が完了した時刻 (serverTime) など複数の時刻がありますが Evaluation Delay の開始時刻は、新規シグナルが最初に集計された際のウィンドウの開始時刻が採用されます。

例えば、Window Duartion が 5分の場合、ウィンドウは下記のように 5分ごとの期間が割り当てられます。

• 12:00 - 12:05
• 12:05 - 12:10
• 12:10 - 12:15
• ..

12:01 のタイムスタンプデータを持つデータは 12:00 - 12:05 のウィンドウに所属するデータとなります。新規シグナルの最初に集計されたウィンドウが 12:00 - 12:05 であった場合、 Evaluation Delay の開始時刻は (ウィンドウの開始時刻である) 12:00 となります。

閾値評価において、Evaluation Delay に利用される時刻はシグナル値の timestamp (そのウィンドウの開始時刻) が Evaluation Delay 期間内か否かが判断されます。 シグナル値が算出されたその時の時間 (serverTime) ではありません。

例えば、Evaluation Delay を 20分と設定していた場合、12:15 までのウィンドウの開始時刻のシグナルが対象となります。 個別に記載すると 12:00-12:05, 12:05-12:10, 12:10-12:15, 12:15-12:20のウィンドウは、Evaluation Delay の対象、 ウィンドウの開始時刻が 12:20 以降が対象外となります。

シグナルロストにおいては、検証した結果からの結論ですが、利用される時刻は expirationLastSeenTime (最終データ) が Evaluation Delay 期間内か否かで判断されるようです。 つまり、シグナルロスト前に最後に受信したデータが 12:20 より前であれば、Evaluation Delay の対象。 12:20 よりあとのデータを受信後にシグナルロストした場合は、Evaluation Delay の対象外。

(後述の例を参照ください)

Evaluation Delay の範囲内だったか否かの確認方法

Evaluation Delay 期間の対象である場合、NrAiSignal の resetCause カラムに delayedEvaluation と記載されますので 確認が必要な場合は 下記のような NRQL をクエリすることで確認することができます。

SELECT endTimestamp, signalValue, serverTime, resetCause, signalId, * FROM NrAiSignal WHERE conditionId = コンディションId

アラートクエリで FACET を利用している場合は、tags.${FACET項目} などで区別いただけます。

(後述の例を参照ください)

また、NrAiSignal の項目の説明は下記をご参照ください。 [New Relic data dictionary > NrAiSignal]

例 1 (新規シグナル)

下記のようなアラートコンディションを例に見てみましょう。

• アラートクエリ

SELECT average(cpuPercent) FROM SystemSample FACET entityName

• Window Duration (WD): 5分
• Event flow (delay: 2分)
• Evaluation Delay: 20分
• 閾値: result > 50 for at least 5分

新規のホストにインフラエージェントをインストールし、9:46 ごろよりデータ収集が開始されました、という場合です。 検証のため、30分ほど 閾値を超過するように CPU 使用率を高騰させています。

実際のシグナル値 (NrAiSignal) とインシデントイベントは下記のように記録されました。

例 1. シグナル値 (NrAiSignal)

WD が 5分で、Event flow (Delay 2分) であるため、最初のウィンドウ (9:45-9:50) は 9:52 過ぎに締め切られ、シグナルの集計が行われました。

最初のシグナル値が記録されたウィンドウの開始時刻 9:45 がこの時刻が Evaluation Delay の開始時刻です。 また、resetCause には "delayedEvaluation" と記録されています。

次の 9:50 - 9:55 ウィンドウも Evaluation Delay (20分) の範囲内であるため、"delayedEvaluation" と記録されています。 その後 10:05 - 10:10 ウィンドウでは Evaluation Delay (20分) の範囲外となったため、"delayedEvaluation" と記録されなくなりました。

次のインシデントイベントを確認する前に、シグナル値を確認しておきましょう。 閾値は (5分間で) 50 を超えたら違反という設定であるため、Evaluation Delay の設定がない場合は 9:45 - 9:50 の値で閾値違反となるはずです。

例 1. インシデントイベント (NrAiIncident)

インシデントの作成は 10:13 で、degradation time (閾値を超過し始めた時刻) は 10:05 となっています。

予想された通り Evaluation Delay 期間のシグナル値は閾値評価されないため、Evaluation Delay 明けの 10:05 - 10:10 のウィンドウから閾値評価が行われ、インシデントが作成されました。

例 2 (アラートコンディションの変更、信号損失)

次に アラートコンディションを変更した場合に振る舞い、と信号損失の振る舞いを確認します。 具体例 1 のアラートコンディションに信号損失閾値を追加します。

• アラートクエリ

SELECT average(cpuPercent) FROM SystemSample FACET entityName

• Window Duration (WD): 5分
• Event flow (delay: 2分)
• Evaluation Delay: 20分
• 閾値: result > 50 for at least 5分
• 信号損失閾値: 5分 (Open new "lost signal" incident.) (追加)

少し複雑になりますが、アラートコンディションの変更後、10分ほど稼働させ、その後、対象ホストを停止し信号損失を発生させました。

実際のシグナル値 (NrAiSignal) とインシデントイベントは下記のように記録されました。

例 2. シグナル値 (NrAiSignal)

アラートコンディションは 12:17 ごろに変更しました。シグナル評価に関連する項目であるため、次のウィンドウ (12:20 - 12:25) からシグナルID が変わりました。

そして、そのタイミングから再度 resetCause には "delayedEvaluation" が記録されました。 先の記載の通りシグナルID が変更されたため、新規シグナルとみなされ、再度 Evaluation Delay が発生した、と動作しました。

次に青線で強調した信号損失の発生時の挙動に着目してみましょう。

このホストからのデータは 12:27:38 (expirationLastSeenTime) を最後に 5分以上のデータの受信が滞りました。

信号損失閾値を 5分で設定しているため、12:32 に 信号損失 (expiration) イベントが発生しました。

信号損失イベント発生時のアクションとして、Open new "lost signal" incident (信号損失インシデントの作成) が設定されているため、 Evaluation Delay の設定がない場合は このタイミングで 信号損失インシデントが作成されるはずです。

例 2. インシデントイベント (NrAiIncident)

期待通りですが、信号損失インシデントは発生しませんでした。

これは Evaluation Delay 期間内に受信したデータを最後に、信号損失が発生したため Evaluation Delay が適用され (評価が行われない) インシデントの作成が行われませんでした。

いくつかのパターンで検証しましたが、信号損失イベントが発生した時刻ではなく 最後に受信したデータが Evaluation Delay の対象か否かでの判断のようです。 (信号損失インシデントの DegdationTime は expirationLastSeenTime (最後の受信データ時刻)、OpenTime は 信号損失イベントの timestamp (最後の受信データ時刻+信号損失期間) が採用される)

• 最後に受信したデータが Evaluation Delay 期間内で、信号損失イベントが Evaluation Delay 期間内 の場合 => インシデントは作成されない
• 最後に受信したデータが Evaluation Delay 期間内で、信号損失イベントが Evaluation Delay 期間外 の場合 => インシデントは作成されない
• 最後に受信したデータが Evaluation Delay 期間外で、そのデータが所属するウィンドウが Evaluation Delay 期間内 の場合 => インシデントが作成される
• 最後に受信したデータが Evaluation Delay 期間外で、そのデータが所属するウィンドウが Evaluation Delay 期間外 の場合 => インシデントが作成される

注意が必要な例 (最初のシグナルが出荷される前に信号損失が発生した場合)

Event flow の場合は、 (WD 終了後＋Delay 以降のタイムスタンプをもつ) 後続のデータ 受信によってシグナルの集計処理が行われます。 後続のデータ受信しかった場合は、信号損失が発生します。

このような信号損失は新規のシグナルについても同様に発生しますが、過去に一度も出荷されていないシグナルの場合で、上記のようなことが発生すると、 Evaluation Delay の範囲外で、信号損失インシデントが作成されます。

Evaluation Delay の開始タイミングは、集計された新規シグナルのウィンドウの開始時刻が起点であるため、集計されたことがないシグナルが信号損失になると、 起点時間の前であるため、Evaluation Delay の対象外となってしまうようです。 (こちらの動作は今後、修正される可能性があります。)