ストリーミング・アラートの概念

本ブログはこちらのドキュメントをベースにNRQLアラートの動作フローに関する簡単な説明を記述します。NRQLアラートを使いこなしていただく上で、本コンセプトを理解していただくと、より適切なアラートコンディションを設定していただけると思います。

New Relicでは各エンティティから送られたデータが、時々刻々と入ってきます。これらのデータは受信後、ストリーミング・アラートでは、以下のフローで処理されていきます。

1. データのフィルタ
2. データの振り分け・出荷
3. データの集計
4. Incidentの発生

データのフィルタ

WHERE句により記述された条件により、データがフィルタされます。WHERE句の条件にヒットするデータのみが、次のステップへ進みます。なお、filter()関数等の関数内で利用されるWHERE条件は該当しません。

データの振り分け

FACET句が指定されている場合、FACET句で指定された属性の値ごとに異なるストリームに流れていきます。例えば、NRQLクエリーで「FACET attr1, attr2」と2つ指定されており、attr1の値がva1, va2の2通り、attr2の値がvb1, vb2, vb3の3通りのような組み合わせを取る場合、最大で2x3の6パターンに振り分けられ、流れていきます。

出荷

上記のWHERE句/FACET句により振り分けられたデータは、集約用の箱に入ります。集約用の箱はStreaming mthodの設定に応じた条件を満たすと閉じられ、出荷されます。例えばEvent flowの場合、設定条件を満たした未来のタイムスタンプを持つデータが入ると、箱が閉じられ出荷されます。閉じられたあとは、過去のタイムスタンプを持つデータが遅れて来ても、すでに閉じられているため判定の対象とはなりません。各Streaming methodの詳細に関しては、こちらのブログをご参照ください。

ここで注意していただきたいのが、データによっては、時間が前後したtimestampを持つデータが入ってくる可能性があることを考慮する必要があります。特にMobileやBrowser Agentから送られてくるデータはエンドユーザのPCやスマホの設定時刻になり、timestampが大きくずれたデータが流入してくる可能性も高くなり、期待したタイミングよりかなり早いタイミングで出荷されることもあります。

データの判定及びIncidentの作成

出荷されたデータは、集計され、集計結果が評価されます。アラートコンディションに設定されたしきい値の設定を満たした場合、Incidentが作成されます。

重要なポイント

基本的には、WHERE句の条件に該当するデータが入ることにより全体が動作します。そのため、WHERE句で指定した条件に該当するデータがない場合、上記のフローは流れず、通常Incidentは発生しません。

そのため、データがないことによりIncidentを発生させたい場合は、信号喪失の設定を追加してください。

ギャップ埋め

また、ギャップ埋めの設定もあります。ただし、その名の通り、ギャップ埋めなので注意が必要です。基本的にギャップに値が埋められるのは、データがない期間が発生したあと、WHERE句に該当するデータが入ったタイミングです。ギャップが瞬間的に発生するようなケースであれば、特に問題ない場合が多いですが、長期にわたりギャップが発生する場合は、期待したタイミングでIncidentが発生しないなど、多くの人が期待するような挙動とはならないようです。また、ギャップの時間が長すぎる（2時間以上）場合、ギャップとはならないことにも注意が必要です。

以上で、説明は終了です。より安定的なアラートコンディションを作成していただき、ゆっくりと眠れる日々を過ごしてください。