Synthetic Monitor (外形監視) の失敗時にアラート通知を行いたいという場合のアラートコンディションの設定例をご紹介します。
本ブログでは NRQL 型アラートコンディションで SyntheticCheck の result が FAILED であることをチェックするコンディションを前提とします。
所要時間 (duration) や 証明書の期日などのアラート設定につきましては、基本的に同様の考え方となりますので、項目などは変えて調整ください。
また、記載内容は、個人的な見解に基づくものとなりますので、設定差や状況によっては期待通りのアラーティングを実現できない場合がございます。
アラート設定ではコンディションの設定および (可能であれば Synthetic Monitor で FAILED となるに調整いただき) 発報テストを実施いただけると安全かと思います。
アラートコンディションを設定するための Synthetic Monitor に関する基本知識
モニタータイプ:
Synthetic Monitor には下記の 7種類のモニタータイプがあります。
- Ping
- Certificate Check
- Broken Links
- Simple browser
- Scripted browser
- Scripted API
- Step Monitor
各モニターでは、http 応答、指定文字列を含むか、証明書期日などでモニタージョブの結果 (result: SUCCESS か FAILED か) の判定基準が異なります。
モニターの実行周期:
1分、5分、10分、15分、30分、1時間、6時間、12時間、1日 から選択できます。
モニターの実行周期は、前回のモニター実行から正確に N分後に実行されるわけではなく、数十秒 (あるいは数分単位で) ずれる場合があります。周期が 5分であれば、おおよ 5分おきに 1時間に 12回実行される、というイメージでいましょう。
1日に 1度実行される場合で 9時ごろに実行したいなどの時刻指定設定はできません。
(MonitorDowntime などと組み合わせて実行いただくことになります)
ロケーション:
モニタージョブの実行箇所として、NewRelic が保守しているパブリックロケーションとユーザーが作成・保守しているプライベートロケーションを選択いただけます。
パブリックロケーションは世界各地のロケーション (ブログ執筆時点では 19箇所) から選択可能、
プライベートロケーションでは、"Share this location" オプションが有効なロケーションは、同一組織の別アカウントのモニタージョブの場合でも選択いただけます。
ロケーションは、各モニターごとに複数のロケーションを選択いただけます。パブリックロケーションとプライベートロケーションを混ぜて選択いただくことも可能です。
実行周期が 1分で、"Tokyo, JP" ロケーションと "Singapore, SG" ロケーションの 2ロケーションでの実行を選択した場合、各ロケーションから 1分周期でモニタージョブ (アクセス) が行われることになります。
(それぞれのロケーションで1分周期で実行されます。)
Browser, Device Emulation
Simple Browser, Step Monitor, Scripted Browser タイプでは、実行ブラウザー (Chrome, Firefox) および エミュレーションデバイスを選択することができます
ブラウザとして Chrome、デバイスとして Desktop, Mobile landscape を選択した場合、
(Chrome, Desktop), (Chrome, Mobile landscape) の 2つのジョブが実行されることになります。
実行周期が 1分で、 2ロケーションを選択し、ブラウザとして Chrome と Firefox、デバイスとして Desktop を選択した場合、4ジョブが 1分周期で実行されることになります。
ジョブの実行結果 (SyntheticCheck, SyntheticRequest):
モニタージョブの実行結果は、UI 各モニター (Overview, Results, Resouces, Diagnose) より確認いただけます、Result で個別のジョブの詳細を確認いただけます。
NRQL で確認する場合は、SyntheticCheck または SyntheticRequest イベントをクエリして確認いただけます。
SyntheticCheck は 1回のモニタージョブの結果が記録されます。result 項目にジョブの成功 (SUCCESS)、失敗 (FAILED) や duration (最初の HTTP リクエスから最後の HTTP リクエストの終了まで) など、ジョブの全体に関する情報が記録されます。また、timestamp はジョブの開始時刻となります。
一方、SyntheticRequest は、ジョブ内での個々の HTTP リクエストの結果 (各 URL の responseCode や duration など) が記録されます。
UI の Results に表示される Script Log や Browser Log (Step Monitor や Scripted Browser/API モニター) は NRQL クエリイベントからは取得いただけませんので、UI からアクセスいただく必要がございます。
3ストライク制
Synthetic Monitor では、3ストライク制が設けられており、
失敗判定 (result = FAILED) は 3回のモニタージョブがいずれも失敗となった場合に、記録される仕組みとなっています。
前回の判定が正常の場合に、モニタージョブが失敗 (アクセス結果が FAILED) となった場合は再度モニタージョブが行われます、そうして、3回連続でアクセス結果が失敗だった場合は SyntheticCheck に FAILED と記録されます。
3ストライクにおけるモニタージョブの再アクセスはリトライ扱いとなるため、ポーリングスケジュールにはよりません、通常は数秒のうちに行われます。
また、SyntheticCheck には 3度目の失敗時の情報のみが記録されます。
また、前ポーリング時のモニター結果が FAILED と判定されている場合、以降では 1度の失敗で FAILED と判定されることになります。(前回が FAILED だった場合は、3ストライクは行われず、1度の失敗判定で FAILED と判定されます)
Syntheticモニターの概要 > 追加機能 > 「3回ストライク」で失敗
Ping モニターでサイト応答がなくタイムアウトとなってしまうような場合、初回の FAILED の判定時は、3度アクセスがタイムアウトとなったあとに SyntheticCheck にジョブ結果が記録されることになり、1分間隔で実行されているモニターの場合は、タイムアウトのアクセス分だけ未実行のように見えてしまう場合があります。
アラートコンディション設定時に注意する点
ストリーミングメソッドが Event flow の場合
Event flow は、後続データを受信したタイミングで集計処理が行われます (より正確には 集計期間終了後 + delay 時間以降のタイムスタンプをもつ後続データした場合に集計処理されます)。
そのため Synthetic Monitor の実行周期が 15分後などの場合は、次のデータを受信したタイミング (15分後に) で、ようやく集計処理が行われることになります (※ Window Duartion に依ります)。
また、65分以上データ受信間隔があくと未集計データが破棄されるため、Synthetic Monitor の実行周期が 1時間以上の場合、Event flow は使用しない方が良いかと思います。
多く場合、アラートはなるべく早く検出されたいと思いますので、実行周期が短い場合でも (5分以上であれば) Event flow にはあまりメリットはないように思います。
ストリーミングメソッドが Event timer の場合
Event timer の場合は単一のデータでも集計されますが、閾値が 2以上の場合 (集計期間で 2回 以上 FAILED だったら) というような場合は、注意が必要です。
Event timer ではタイマーのカウントダウンの終了後に集計処理が行われるため、集計期間 (Window Duration) よりもタイマーの方が短い場合、集計期間の終了前に集計処理が行われてしまう場合があります。
集計処理の完了後に受信したデータは集計には含まれないため、すべてのデータを集計に含める必要がある場合は、タイマーは 集計期間以上にする必要があります。
(ブログ執筆時点) ではタイマーは最長 20分であるため、Synthetic Monitor の実行周期が 30分以上の場合 (で、かつ、すべてのデータを集計対象とされたい場合) は、Event timer は適しません。
また、Synthetic Monitor の実行周期が 15分などの場合で、アラートの集計期間を 15分、Event timer でタイマーを 15分とした場合で、集計期間の終了直前でデータを受信した場合、タイマーはそこから 15分をカウントするため、15分後に集計が行われます。
このような場合は Cadence を利用する方がいいように思います。
閾値が for at least (連続で) を使用している場合
Synthetic Monitor の実行周期が 1分で、アラートの集計期間を 1分、閾値を result > 0 for at least 5分 (5回連続で、失敗した場合違反とする) というような設定の場合は注意が必要です。
Synthetic Monitor の実行周期は、正確に 1分ではなくおおよそ 1分での実行となります。一方、アラートの集計期間は 12:00-12:01, 12:01-12:02 という具合に (1分の) 期間ごとで行われます。
Synthetic Monitor が 12:00:55 の次が 12:02:01 など数秒ずれて実行された場合、アラートとしては 12:01-12:02 の期間データは存在しないことになります。
そして、for at least (連続で閾値を満たした場合) が使用されている場合、データが存在しない期間は条件を満たしていないため、Synthetic Monitor が 5回連続で失敗していたとしてもアラートでは違反と判定されないことになります。
ref. https://newrelic.com/jp/blog/observability/alert-zeronull
このような場合は Gap filling strategy: last known value を使用して対応いただくのがよいかと思います。
アラートコンディション設定例
パターン 1: 一度でも Synthetics が失敗 (result = FAILED) になった場合は違反 (閾値による回復判定なし) という場合
"一度でも失敗" という場合は Event timer の利用が最も早く検知できるので 閾値で at least once in (一度でも) を利用した設定が良いと思います。
アラートクエリでは WHERE 句に result = 'FAILED' (または result != 'SUCCESS') と設定することで、失敗判定となったモニタージョブのみを対象データとして指定します。
この場合は、閾値による回復判定ができないたので、アラートイベントを自動クローズさせたい場合は 信号損失閾値 (Close all current open alert events) で、FAILED データを受信しなくなったらクローズするという設定をすることも可能です。
- アラートクエリ
SELECT count(*) FROM SyntheticCheck
FACET monitorName
WHERE result != 'SUCCESS' AND monitorName in ('モニター1'[, 'モニター2', ..])
- Window Duration: 1分 (または 30秒)
- Streaming Method: Event timer (タイマー 5秒)
- 静的閾値: result > 0 at least once in 1分
- 信号損失閾値 (任意)
- 閾値期間: 任意期間 (目安: 2N または 3N分 くらい) (N分 は Synthetic Monitor の実行周期)
- アクション: Close all current open alert events (データを受信しなくなった場合にアラートイベントをクローズする)
Synthetic Monitor の実行周期 (N分) がいくつであっても、1度でも FAILED が発生した場合に検知したいという場合、アラートコンディションの 集計期間 (Window Duration) は 1分で問題ありません。
アラートクエリの FACET 句や WHERE 句の monitorName の指定は、モニターが区別できれば、monitorId でも entityGuid でも可能です。monitorName がわかりやすいかと思いますので、monitorName としています。
パターン 2: 一度でも モニター が失敗 (result = FAILED) になった場合は違反、正常 (result = SUCCESS) となったら回復と判定させたい、という場合
パターン 1 と同様に "一度でも失敗" なので 閾値で at least once in (一度でも) を利用します。
Event timer (タイマー5秒) でもいいですが、Synthetic Monitor の実行周期が 1分の場合は、実行のずれで 1分間に 2度実行されるという場合も起こり得るため
この点を考慮すると 1分周期の場合は Event timer (タイマー1分) または Cadence を利用するのがよいように思います。
この場合は閾値で回復判定をするので、filter() 関数を利用し、FACET 句では モニターの識別に location や browser など、同一モニターの中のどのジョブかを区別できる項目を追加します。
- アラートクエリ
SELECT filter(count(*), where result != 'SUCCESS') FROM SyntheticCheck
FACET monitorName, location[, browser, deviceType, deviceOrientation]
WHERE monitorName in ('モニター1'[, 'モニター2', ..])
- Window Duration: 1分
- Streaming Method: Event timer (タイマー 1分)
- 静的閾値: result > 0 at least once in 1分
Simple brower, Step Monitor, Scripted Browser 以外の場合はブラウザ、エミュレーションデバイスの選択はないため、
browser, deviceType, deviceOrientation を FACET 項目に指定する必要がありません。
filter() 関数を使用して SUCCESS でない (FAILED) ジョブ数を抽出しています。
各ジョブ (ロケーション、ブラウザ、エミュレーションデバイス) ごとにシグナルが評価され、FAILED が 1度でも発生した場合は閾値違反となり、
その後、SUCCESS となった場合は、シグナル値は 0 が返るため、回復と判定されます。
パターン 3: 1分周期実行のモニターが 5回連続で失敗 (result = FAILED) になった場合は違反、5回連続で正常 (result = SUCCESS) となったら回復と判定させたい、という場合
M回連続で失敗という場合は、閾値で for at least (連続) を使用します。
また、1分周期実行の場合は 実行ずれで、実行されない 1分間 が発生してしまう可能性があるので、Gap filling strategy を使用して補間します。
- アラートクエリ
SELECT filter(count(*), where result != 'SUCCESS') FROM SyntheticCheck
FACET monitorName, location[, browser, deviceType, deviceOrientation]
WHERE monitorName in ('モニター1'[, 'モニター2', ..])
- Window Duration: 1分
- Streaming Method: Event timer (タイマー 1分)
- 静的閾値: result > 0 for at least 5分
- Gap filling strategy: last known value
(Simple brower, Step Monitor, Scripted Browser 以外の場合はブラウザ、エミュレーションデバイスの選択はないため、browser, deviceType, deviceOrientation を FACET 項目に指定する必要がありません。)
パターン 4: 5分周期、2ロケーション実行の Ping モニターで 5分間で ロケーションの区別なしで 2回以上で失敗 (result = FAILED) になった場合は違反、2未満で回復と判定させたい、という場合
"5分間で2回以上" と 閾値が 2以上の値なので、Cadence を使用するのが良いと思います。
Cadence は、集計期間終了後 + delay 時間後に集計が行われるという方式となります。
SyntheticCheck の timestamp は ジョブの開始時刻が利用されます、パブリックロケーションでの各モニターのタイムアウトは 180秒であるため、Cadence の delay は 180秒程度を設定します。
また、アラートコンディションの集計期間は 5分ごとに期間が割かれるため、Slide by を利用して、どの 5分間でも 2以上であれば違反、という設定を実現させます。
- アラートクエリ
SELECT filter(count(*), where result != 'SUCCESS') FROM SyntheticCheck
FACET monitorName
WHERE monitorName in ('モニター1'[, 'モニター2', ..])
- Window Duration: 5分 Slide by 1分 (または 30秒)
- Streaming Method: Cadence (delay 3分)
- 静的閾値: result >= 2 at least once in 1分
ロケーションの区別なしで、モニターの成功失敗をカウントするという条件であるため、FACET 句に location は含めません。
パターン 5: 5分周期、1ロケーション実行の Ping モニターで 15分間で 2回以上で失敗 (result = FAILED) になった場合は違反、2回未満となったら回復と判定させたい、という場合
パターン 4 と同型と考えていただき、アラートの集計期間 15分 (slide by 利用) で 閾値 2以上 の場合で違反と判定させると設定する場合は下記のように設定します。
- アラートクエリ
SELECT filter(count(*), where result != 'SUCCESS') FROM SyntheticCheck
FACET monitorName
WHERE monitorName in ('モニター1'[, 'モニター2', ..])
- Window Duration: 15分 Slide by 1分 (または 30秒)
- Streaming Method: Cadence (delay 3分)
- 静的閾値: result >= 2 at least once in 1分
または、少し考え方を変え、
SyntheticCheck の結果を 1分ごとに分けてカウントし、失敗 (FAILED) となったジョブを含む "時間 (分)" を数えるという方法でも良いかと思います。
この場合はネストクエリ用いて下記のようにクエリで表現します。
SELECT filter(count(*), where failed_count > 0) FROM (
SELECT filter(count(*), where result != 'SUCCESS') as 'failed_count' FROM SyntheticCheck
FACET monitorName, toDateTime(timestamp, 'yyyy-MM-dd HH:mm', timezone: 'UTC') as 'YmdHi'
WHERE monitorName in ('モニター1'[, 'モニター2', ..])
) FACET monitorName
パターン 6: 5分周期、3ロケーション実行の Ping モニターで 3ロケーション以上で失敗だった場合に違反
この場合は、失敗ジョブの location のユニーク数を取得するクエリでいいように思います。
- アラートクエリ
SELECT filter(uniqueCount(location), where result != 'SUCCESS') FROM SyntheticCheck
FACET monitorName
WHERE monitorName in ('モニター1'[, 'モニター2', ..])
- Window Duration: 5分 Slide by 1分 (または 30秒)
- Streaming Method: Cadence (delay 3分)
- 静的閾値: result >= 3 at least once in 1分
パターン 5 の 2つ目に紹介したクエリと同様に考えて
ネストクエリで location を指定し、ロケーションごとの失敗数を収集するというクエリでも良いさそうです。
SELECT filter(count(*), where failed_count > 0) FROM (
SELECT filter(count(*), where result != 'SUCCESS') as 'failed_count' FROM SyntheticCheck
FACET monitorName, location
WHERE monitorName in ('モニター1'[, 'モニター2', ..])
) FACET monitorName
おわりに
本ブログでは Synthetic Monitor 動作特徴とそのアラートコンディションの設定例をいくつかご紹介いたしました。
アラートコンディション設定の際にご参照ください。
また、アラートのウィンドウの考え方や Streaming Method, 閾値設定などにつきましては、鳴らない、止まらない、遅延する……New Relicアラートの疑問を公式ブログで解消する逆引き集 などのブログやドキュメントご参照ください。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
