それぞれのコンピューターで作業する2人の人

本ブログでは、NRQL 型のアラート設定で利用するシグナル消失の動作についてご紹介します。
シグナル消失の閾値を設定する場合としない場合の動作差、シグナル消失イベント発生およびその回復判定のタイミングや発生時のウィンドウデータの扱いなど少し細かな点について記載します。

また、ドキュメントや UI での表示において、Lost Signal、 Loss of Signal、シグナル喪失、信号損失など複数の表記がありますが、本ブログではシグナル消失と記載します。

 

シグナル消失の概要と設定

NRQL 型アラートのデータ受信が途絶えたことを検出したい場合、データ受信の停止時間 (待機時間) を設定することで、シグナル消失として検出することができます。

設定された待機時間にわたって、NRQL条件に一致するデータを受信しなかった場合、シグナル消失イベントが発生します。
シグナル消失の設定は、アラートコンディションの Set thresholds にて、”Add lost signal threshold” を追加することで設定します。
項目は待機時間と消失イベントが発生した際のアクションを設定することができます。

  • 待機時間 (シグナル消失の閾値) : データ (シグナル) が失われたとみなすまでの時間
    • 例 5分, 15分。設定上 30秒~48時間で設定可能です
  • シグナル消失発生時のアクション: 下記の 2つのアクションを設定することができます (両方設定する、片方設定する、両方設定しない が可能です)
    • Close all current open incident: 同シグナルに関連するオープン状態のインシデントをすべてクローズします
    • Open new “lost signal” incident: データが送信されなくなったことを示すインシデントを新たに作成します
      また、シグナル消失インシデントの 重大度は Critical となります

Alerts&AI > Alert Conditions > (select condition of NRQL type) > Set thresholds

Event Flow とシグナル消失の利用例

ストリーミングメソッドの Event Flow は、インフラエージェントからのデータのように一定の間隔でデータを受信し続ける場合に最適な方法です。
データ受信が滞った際は、シグナル消失設定で Open new “lost signal” incident アクションを設定することで、シグナル消失を検出し、通知することができます。

 

Event Timer とシグナル消失の利用例

一方で、Event Timer は、到着順序や発生間隔に一貫性のないデータを評価するのに最適な方法で、ログ検知などに利用されます。
定期的にデータを受信しないことが前提となっている場合も多いため、シグナル消失設定とは合わせて利用しないように思えますが、Close all current open incident アクションを活用し、回復判定に利用方法があります。

例えば、エラーが発生されるとインシデントが発生するコンディションで、シグナル消失を Close all current open incident アクションで設定した場合、
エラーが一定時間出力されないとシグナル消失となり、Close アクションで発生していたインシデントをクローズすることができます。
いわば、事象の収束時の回復判定を自動で行うという利用方法です。検知がない = 正常、と判定できる場合などに活用いただけます。

 

シグナル消失の発生タイミング

最後のデータポイントが New Relic に受信した時間を起点に待機時間までのカウントダウンが開始されるという仕組みで検出されます。
カウントがゼロになる前にデータを受信した場合カウントはリセットされます。リセットされずに待機時間を経過するとシグナル消失イベントが発生します (※ Event Timer とは異なる仕組みです)。
カウントダウンの起点はデータのタイムスタンプではなく、データがプラットフォームに到着する時間に基づいています。

Tips

一度も対象のデータを受信したことがないアラートコンディション (シグナル) の場合、シグナル消失は発生するでしょうか?
=> いいえ、発生しません。
上述のとおりデータを受信するとカウントダウンが開始されます。該当データを一度も受信したことがない場合、カウントダウンが開始されません。

回復タイミングについて

シグナル消失の発生タイミングは、データの受信が起点であるため、データが受信すると回復すると思ってしまいがちですが、実際はシグナルとして出荷されたタイミングが回復タイミングとなります。

Tips

Event Flow の出荷タイミングは、遅延時間以降でデータを受信したタイミングとなります。Window Duration 期間が長い場合などはシグナル消失中にデータ受信が再開しても、すぐには出荷されないので、回復タイミングがデータ受信時刻からずれるということがあります。また、1度だけデータを受信したという場合は、出荷されないので回復判定はされません。

シグナル消失イベントで起こること

シグナル消失設定として待機時間のみを設定した場合 (Open/Close アクションを設定しなかった場合) と設定をしなかった場合は、一見動作の違いがないように思いますが、シグナル消失イベントが発生すると、未出荷のウィンドウはすべて破棄されます。また、最後に受信したデータポイントの到着より前の開始時間のウィンドウはデータ集約されなくなります。

Tips

Event Flow の利用で、Window Duration + 遅延時間よりも短い時間をシグナル消失の待機時間として設定した場合、ウィンドウデータは破棄され続けてしまうか?
=> データが待機時間までに受信しているならば、シグナル消失イベントは発生しないので問題ありません。
10分おきにデータが送信されるような場合に、シグナル消失を 5分で設定してしまうと、問題があります。

Tips

Event Flow の利用で、データ受信間隔よりも短い時間をシグナル消失の待機時間として設定した場合、ウィンドウデータは破棄され続けてしまうか?
=> 破棄され続けてしまいます。データは受信できていても次のデータが受信する前にシグナル消失イベントは発生してしまうため、ウィンドウデータは破棄されてしまいます。
30秒おきにデータが送信されるような場合で Window Duration 10分、シグナル消失を 5分と設定しても、シグナル消失は発生しませんので問題はありません。

 

シグナル消失の待機時間がデータの収集間隔 (の最大値) よりも短くならないかという点に注意を払う必要があります。

Event Flow の出荷待ち時間の上限

 

シグナル消失とは直接的には関係ありませんがが、Event Flow 利用の場合、データポイントの間隔が 65分以上の場合は動作しません。

[ストリーミング・アラート:重要な用語と概念 > イベントの流れ > 注意]
https://docs.newrelic.com/jp/docs/alerts-applied-intelligence/new-relic-alerts/advanced-alerts/understand-technical-concepts/streaming-alerts-key-terms-concepts/

Event Flow では、シグナル消失を設定していない場合でも 65分以上データ受信がないと未出荷のウィンドウはデータを破棄します。
Event Flow の出荷タイミングは、自身の ウィンドウ終了時刻+遅延時間以降でのデータ受信をしたタイミングとなりますが、この時間制限によってデータ収集の停止後に数時間または数日ぶりにデータ収集が再開された場合、収集停止前のウィンドウデータが出荷されるということは起こりません。