集計方法の選択

アラート条件には、監視対象に何かが起こった、または起こらなかったことについて通知を受けるタイミングを記述するための、洗練されたツールセットが用意されています。最良の結果を得るためには、データの受信方法に最も適した集計方法を選択してください。

集計方法は、イベントフロー、イベントタイマー、ケイデンスの3つです。概念的な概要に興味のある方は、 ストリーミングアラート、重要な用語と概念に関するドキュメント をご覧ください。

アグリゲーションとは？

アプリケーションやサービスをNew Relicで監視していると、さまざまな方法でデータが届きます。安定して予測可能なデータもあれば、矛盾して散発的に到着するデータもあります。

集計とは、警告システムがデータを集めて、警告や重要な閾値を超えていないかを分析することです。

データは集計ウィンドウにデータポイントとして収集され、1 つの数値に変換されます。データポイントは、NRQL クエリに基づいて、sum、average、min、max などの方法で集約されます。この単一の数値が、条件のしきい値の評価に使用されます。

一度集計されたデータには、それ以上データポイントを追加することはできません。当社のさまざまな集計方法は、データを素早く集計することと、十分なデータポイントが到着するのを待つことのバランスをとるのに役立ちます。

重要な理由

適切な集計方法を用いれば、気になる通知を受け取り、気にならない通知を防ぐことができる可能性が高くなります。

集計方法を決める際に最も重要な質問です。どのくらいの頻度でデータが届くのか？どのくらいの頻度でデータが送られてくるか？

データが頻繁に、かつ一貫して直線的に届く場合は、イベントフローの使用をお勧めします。

データが散発的に、矛盾して、不規則に届く場合には、イベントタイマー集約の使用をお勧めします。

イベントフローを使用する場合

イベントフローでは、データポイントのタイムスタンプに基づいてデータが集約されるため、データポイントが一貫して直線的に到着することが重要です。この集計方法は、データポイントのタイムスタンプが順番に到着しない場合や、短い期間に広いスパンで到着する場合には、うまく機能しません。

イベントフローは、最も一般的なユースケースに適用されるため、デフォルトの集計方法となっています。

イベントフローの仕組み

イベントフローでは、データポイントのタイムスタンプを使用して、アグリゲーションウィンドウを開閉するタイミングを決定します。

例えば、イベントフローで2分のディレイウィンドウを使用している場合、最後に受信したタイムスタンプよりも2分後のタイムスタンプが到着すると、アグリゲーションウィンドウが閉じられます。

12:00pmのタイムスタンプを持つデータポイントが到着します。アグリゲーションウィンドウが開きます。ある時点で、12:03pmのデータポイントが到着します。イベントフローは、12:03のデータポイントを除いてウィンドウを閉じ、その閉じたウィンドウをしきい値に照らして評価します。

イベントフローの集計画面では、その後のタイムスタンプまでデータポイントの収集を続けます。システムを前進させるのは後のタイムスタンプであって、データポイントそのものではありません。イベントフローは、データを集約する前に、遅延設定よりも遅い次のデータポイントが到着するまで、必要なだけ待ちます。

イベントフローは、頻繁に、かつ安定して届くデータに最適です。

イベントフローの使用例

イベントフローの代表的な使用例をご紹介します。

• エージェント データ。

• インフラのエージェントデータ。

• サードパーティから頻繁に信頼性の高いデータが入ってくるもの。

• ほとんどの AWS CloudWatch メトリクスは、AWS メトリクス ストリームから取得されます (ポーリングではありません)。主な例外は、一部の AWS CloudWatch データは (S3 ボリューム データのように) ストリーミングであるかポーリングであるかに関係なく非常にまれであり、その場合はEvent timerを使用することです。

イベントタイマーを使用する場合

イベントのタイマー集計は、データポイントが到着するとカウントダウンするタイマーに基づいて行われます。タイマーは、新しいデータポイントが到着するたびにリセットされます。新しいデータポイントが到着する前にタイマーがカウントダウンされた場合、イベントタイマーはその間に受信したすべてのデータポイントを集約します。

イベントタイマーは、散発的に発生するイベントや、時間的に大きなギャップがあるイベントのアラートに最適です。

イベントタイマーの仕組み

エラーとは、散発的に、予測不可能に、そして多くの場合、大きな時間の隔たりをもって起こる事象の一種です。

例えば、エラーの数を返すクエリで条件を設定したとします。全くエラーが発生しないまま何分も経過した後、1分以内に突然5件のエラーが発生したとします。

この例では、5つのエラーのうち最初のものが到着するまで、イベントタイマーは何もしません。その後、タイマーを開始し、新しいエラーが到着するたびにリセットします。新たなエラーが発生せずにタイマーのカウントダウンが0になった場合、イベントタイマーはデータを集約し、閾値に対して評価します。

イベントタイマーの使用例

ここでは、イベントタイマーの代表的な使用例をご紹介します。

• New Relicの使用データ。
• ポーリングされているクラウドインテグレーションデータ（GCP、Azure、AWSのポーリング方法など）。
• エラーの数など、データが少ない、または頻度の低いデータを配信するクエリ。

ケイデンス

Cadence は、New Relic 独自の集計方法です。データのタイムスタンプに関係なく、New Relic の内部ウォールクロックで検出された特定の時間間隔のデータを集約します。

イベントがクロックスキューの影響を受けやすく、プロデューサーを制御して修正できない場合を除いて、代わりに他の集計方法のいずれかを使用することをお勧めします。たとえば、 PageActionイベントはユーザーのブラウザに組み込まれ、タイムスタンプを割り当てるためにユーザーのデバイスクロックに依存します。タイムスタンプが偏っている単一のイベントは、イベントフローに影響を与える可能性があり、タイマーアラートにさえ影響を与える可能性があります。これは、ウィンドウの集約が早すぎて誤検知が発生する可能性があるためです。

このシナリオ以外では、他の集計方法のいずれかを選択する必要があります。イベント フローは、一貫性のある予測可能なデータ ポイントに最適です。イベント タイマーは、一貫性のない散発的なデータ ポイントに最適です。

アグリゲーションとシグナルの消失

当社の信号消失システムは、これらの集計方法や設定とは別に実行されます。

信号が 10 分間失われたときに新しいインシデントを開始するようにアラート条件を設定すると、信号サービスの損失によりデータ ポイントの到着が監視されます。新しいデータ ポイントが 10 分以内に到着しない場合、信号の損失によりインシデントが発生します。

ギャップフィリングとロスシングルを使うタイミングの詳細については、私たちのフォーラムの投稿を参照してください 。