ストリーミングアラートプラットフォームは、New Relicに入ってくるストリームのデータの有無、または シグナル に基づいて違反の有無をチェックします。
NRQL条件 を使用して、通知を受けたい信号のどの部分かを制御することができます。NRQL条件は、 ストリーミングアルゴリズム によって処理されるデータをフィルタリングします。
NRQL 条件でフィルタリングされたデータを集約する方法は 3 つあります。
- イベントフロー(デフォルト)
- イベントタイマー
- ケイデンス
このショートビデオでは、3つの集計方法について説明しています(5分31秒)。
重要な理由
ストリーミングアラートの仕組みを理解することで、NRQLの条件を微調整して、重要なことを通知することができます。
NRQL の WHERE 句の条件に一致するデータのみがアラートされます。プロセスの各ステップの詳細については、 ストリーミングアラートのプロセスと説明 を参照してください。
New Relic にデータが流れ込むと、NRQL の条件によってフィルタリングされます。データが評価される前に、データは NRQL クエリの WHERE
節 で定義された基準を満たさなければなりません。NRQL アラート条件は、データをすぐに評価して違反を探すのではなく、アグリゲーション・ウィンドウと呼ばれる期間にわたってデータを収集します。追加の遅延/タイマーにより、ウィンドウが集約される前に、より遅いデータポイントが到着することができます。
遅延時間/タイマー時間が経過すると、New Relic はデータを 1 つのデータポイントに集約します。その後、アラートはNRQL条件を使用してデータポイントを評価し、違反閾値の基準を満たしているかどうかを判断します。
データポイントがバイオレーションの基準を満たしていても、バイオレーションがトリガーされない場合があります。違反は、データポイントが一定期間にわたって一貫して閾値の基準を満たした場合にのみトリガされます。これが閾値期間です。データポイントがしきい値の継続時間全体にわたって違反している場合は、ポリシー設定に基づいて通知を送信します。
これらの設定可能な遅延により、散発的なデータや欠落したデータに対する警告方法をより細かくコントロールすることができます。
ストリーミングアラートのプロセスと説明
プロセス | 説明 |
---|---|
ストリーミングデータ | すべてのデータがNew Relicに入ってくる。 |
WHERE句 | すべての受信ストリーミングデータをフィルタリングします。このフィルターを通過したデータについてのみ、アラートを監視します。 |
アグリゲーション方法 | 評価される前のデータの収集方法を制御する3つの方法のうちの1つ。 彼らは
|
集計ウィンドウ | この期間内のタイムスタンプを持つデータが集計され、評価されます。 |
スライディングウィンドウ | この機能を有効にすると、アグリゲーションウィンドウが重なり合い、より滑らかなチャートを作成することができます。 スライディングウィンドウの期間を使って、アグリゲーションウィンドウが重なる時間を設定します。 |
遅延/タイマー | アグリゲーションが行われる前に、すべてのデータポイントがアグリゲーションウィンドウに到着していることを確認するための時間的な遅延です。 |
集計されたデータ | アグリゲートウィンドウのデータは、アラート評価のために1つのデータポイントに折りたたまれます。 |
評価 | データポイントはNRQL条件によって評価されます。この条件は、入力される各集約されたデータポイントによってトリガされます。 |
しきい値の継続時間 | 違反が発生するかどうかを判断する特定の継続時間のこと。指定されたNRQL条件がしきい値の持続時間にわたってしきい値の基準を満たす場合、違反が発生します。 データポイントにデータがない場合、カスタム値を挿入してギャップを埋めます。 |
集計方法の選択
お客様のニーズに合わせて、3種類の集計方法を選択することができます。
イベントフロー (デフォルト)は、頻繁に入ってくるデータ、ほとんどが順番に入ってくるデータに最適です。
イベントタイマー は、クラウド統合データや頻度の低いエラーログなど、一括して届く頻度の低いデータに最適です。
Cadence は、私たちのオリジナルで劣った集計方法です。データのタイムスタンプに関係なく、New Relic の内部ウォールクロックで検出された特定の時間間隔のデータを集約します。
集計方法を説明した短い動画(5分35秒)をご紹介します。
イベントの流れ
イベントフローは、後続のウィンドウに最初のデータポイントが到着したときに、データのウィンドウを集約します。カスタムディレイは、現在のウィンドウのアグリゲーションをトリガーするために、どの後続ウィンドウにデータが入り始めるかを定義します。カスタムディレイは、データが到着するまでの時間を延長します。これらの時間はデータのタイムスタンプに基づいており、New Relic のウォールクロックの時間ではありません。
例えば、CPU使用率をウィンドウの持続時間が1分、遅延時間が3分の場合に監視しているとします。
CPU使用率のデータポイントが12:00から12:01の間のタイムスタンプで入ってくると、イベントフローは12:04pmから12:05pmの間のタイムスタンプを持つデータポイントが現れるまで、そのウィンドウを集約しません。イベントフローは、タイムスタンプが12:04pm以降の最初のデータポイントを受信すると、12:00から12:01のデータを送信して集計します。
注意
データポイントが65分以上の間隔で到着することが予想される場合は、後述のイベントタイマー方式をご利用ください。
イベントタイマー
イベントタイマーは、イベントフローと同様に、指定したウィンドウにデータが到着したときのみ、そのウィンドウのデータを集約します。アグリゲーションウィンドウにデータポイントが到着すると、そのウィンドウ専用のタイマーがカウントダウンを開始します。タイマーがカウントダウンする前にデータが到着しなければ、そのウィンドウのデータが集約されます。タイマーのカウントダウンが完了する前にさらにデータポイントが到着した場合、タイマーはリセットされます。
例えば、かなりの頻度で到着するCloudWatchデータを監視しているとします。ウィンドウの時間は1分、タイマーは3分を使用しています。
CloudWatchのデータポイントが12:00~12:01の間のタイムスタンプで入ってくると、タイマーがカウントダウンを開始します。その12:00~12:01のウィンドウにそれ以上のデータポイントが現れなければ、そのウィンドウは3分後に集約されます。
12:00から12:01の間のタイムスタンプを持つ新しいデータポイントが到着すると、タイマーはリセットされます。さらにそのウィンドウのデータポイントが到着するたびにリセットされ続けます。タイマーが0になるまで、ウィンドウはアグリゲーションのために送信されません。
後のデータポイントのタイマーが先のデータポイントよりも先に経過した場合、イベントタイマー法は先のタイマーが経過するのを待ってから後のデータポイントを集計します。
最良の結果を得るためには、タイマーがウィンドウの継続時間と同じかそれ以上であることを確認してください。タイマーがウィンドウ期間より短く、データフローに一貫性がない場合、すべてのデータポイントが到着する前にデータが評価される可能性があります。これにより、誤った通知が行われる可能性があります。
ケイデンス
他の2つの方法のいずれかを使用することをお勧めします。
Cadence は私たちの古いストリーミング集計方法です。この方法では、New Relic のウォールクロックの時間を使用して、データがいつ集約され評価されるかを決定します。この方法では、データポイントが到着したときのタイムスタンプは考慮されません。
ストリーミングアラートツール
ストリーミングアラートは、評価される前のデータの集計方法をコントロールし、誤った通知を減らすための一連のツールを提供します。それらは
- ウインドウ期間
- 遅延/タイマー
- 信号検知の消失
- ギャップ埋め
ヒント
この記事では、これらのツールを概念的なレベルで説明しています。これらのツールの使い方については、 Create NRQL alert conditions で直接説明しています。
ウインドウ期間
信号損失の検出をより効果的にし、不要な通知を減らすために、集約ウィンドウを必要な期間にカスタマイズすることができます。
アグリゲーションウィンドウ は、特定の時間のブロックです。データを評価する前に、データポイントをアグリゲーションウィンドウに集めます。アグリゲーション・ウィンドウが長いと、データを滑らかにすることができます。異常値のデータポイントは、一緒にアグリゲートされるデータポイントが増えるため、評価のために送信されるアグリゲートされたデータポイントへの影響が少なくなるからです。データポイントが到着すると、そのタイムスタンプが使用され、適切な集計ウィンドウに入れられます。
アグリゲーションウィンドウは、 30秒 から 15分 の間で設定できます。デフォルトは 1分 です。
遅延/タイマー
遅延/タイマーの設定は、アグリゲーションウィンドウにデータを集約する前に条件が待機する時間を制御します。
イベントフローとケイデンスメソッドは、ディレイを使用します。イベントタイマーはタイマーを使用します。
遅延のデフォルトは 2分 です。タイマーのデフォルトは 1分 で、最小値は 5秒 です。
信号検知の消失
信号の喪失は、特定の期間にNRQLの条件に合致するデータがない場合に発生します。信号の喪失はさまざまな原因で起こります。NRQL クエリの WHERE
句は、違反がないか評価される前にデータをフィルタリングすることができます。また、サービスやエンティティがオフラインになっていたり、定期的なジョブの実行に失敗し、New Relic にデータが送信されていないことも考えられます。
不必要な通知を避けるために、信号消失の違反が通知されるまでの待ち時間を選択することができます。信号の喪失の検出を使用して違反を開き、信号が失われたときに通知を受けることができます。また、一時的なサービスや、エラーカウントなどの散発的なデータに対しては、信号の喪失を利用して違反をクローズすることもできます。
ギャップ埋め
ギャップフィリングでは、シグナルにデータがないときに使用する値をカスタマイズすることができます。データ・ストリームのギャップを、最後に受信した値や静的な値で埋めることも、何もせずにギャップを残すこともできます。デフォルトは None
です。
ストリーミングデータのギャップは、ネットワークやホストの問題によって引き起こされることがあります。また、信号がまばらであったり、エラーカウントなどの一部の信号では、何か問題が発生したときにしかデータが得られないことがあります。ギャップを既知の値で埋めることで、アラート評価プロセスはそれらのギャップを処理し、信号の損失評価にどのような影響を与えるべきかを判断することができます。
ヒント
アラートシステムは、アクティブに報告された信号のギャップを埋めます。この信号の履歴は、2時間操作が行われないと失われます。ギャップを埋めるために、この非アクティブ期間の後に受信されたデータポイントは新しい信号として扱われます。
シグナルロスとギャップフィリングについては、 このExplorers Hubの記事 を参照してください。