アラート条件

ウィンドウ期間は、New Relicがアラート条件での分析のためにデータをグループ化する方法を定義します。適切な設定の選択は、データの頻度と希望する詳細レベルによって異なります。

• High-frequency data (for example, pageviews every minute)

  ：変動や傾向をリアルタイムで把握できるように、データ頻度（この場合は1分）に一致するようにウィンドウ期間を設定します

• Low-frequency data (for example, hourly signals)

  ：パターンや異常を明らかにするのに十分なデータをキャプチャするウィンドウ期間を選択します（たとえば、1時間ごとの信号の場合は60分）

  ニーズと経験に応じて、ウィンドウ期間をカスタマイズできます。アラート条件の作成に慣れてきたら、開始時や実験時にはデフォルトを使用することをお勧めします。

従来の集計方法では、データがまばらに存在したり、間隔の間に大きな変動が見られるデータを処理する場合には不十分である場合があります。スライディングウィンドウ集計を使用してそのようなデータを分析し、タイムリーなアラートを効果的にトリガーする方法を以下に示します。

1. Smooth out the noise：まず、大きな集計ウィンドウを作成します。この時間枠（たとえば、5分）はバッファとして機能し、データに固有の「ノイズ」や変動性を平滑化します。これは、単独の急上昇や急降下によってトリガーされる誤ったアラートを防ぐのに役立ちます。

2. Avoid lag with a sliding window大きなウィンドウはデータ分析に役立ちますが、閾値をチェックする前に間隔全体が経過するまで待機すると、アラート通知が大幅に遅れる可能性があります。スライディングウィンドウを小さくすることをお勧めします（たとえば、1分）。このスライディングウィンドウを、より大きな集計ウィンドウ内でデータをスキャンする移動フレームとして想像してください。フレームが小さい間隔で進むたびに、集計値（平均など）が計算されます。

3. Set your threshold duration：より小さいスライディングウィンドウのコンテキスト内で、アラートの閾値を定義できるようになりました。これにより、現在のフレームの集計値が目的の範囲から大幅に逸脱した場合でも、より大きなウィンドウの平滑化効果を犠牲にすることなく、アラートを迅速にトリガーできます。

   スライディングウィンドウ集計について詳しくは、このNRQLチュートリアルをご覧ください。

一般的には、event flowストリーミングメソッドを使用することをお勧めします。これは、システムに高頻度で安定的に入力されるデータに最適です。event timerを選択する方がよい場合もありますが、最初のアラートにはデフォルトのevent flowをお勧めします。ストリーミングメソッドの選び方を理解するには、こちらの短いビデオ（約5分31秒）を視聴することをお勧めします。

アラート条件の遅延機能は、一貫性のないデータ収集から生じる潜在的な問題を防ぎます。これはバッファとして機能し、アラートをトリガーする前にデータが到着して処理されるまでの時間を確保します。これにより、誤検知を防止し、より正確なインシデントの作成が保証されます。

使い方：

適切な遅延設定は、受信データの一貫性を評価することによって決定されます。

• 一貫したデータ：データポイントが1分以内にタイムスタンプとともに定期的に到着する場合は、遅延設定を低くしても問題ありません

• 一貫性のないデータ：過去や未来の数分間にわたるタイムスタンプを持つデータポイントが到着した場合、不整合に対応するために遅延設定を大きくする必要があります

  バッファの作成：

• 選択した遅延設定により、アラート条件が定義された閾値に対してデータを評価するまでの待機時間が導入されます

• このバッファにより、データの不一致を解決するまでの時間が確保され、誤解を招くアラートが発生する可能性が軽減されます

WebPortalアプリケーションのレイテンシの問題をチームに通知するためのアラート条件を作成しています。この例では、アプリケーションは一貫してNew Relicデータを送信します。アプリケーションからNew Relicに信号が継続的に送信されており、信号に予期されるギャップがないため、ギャップ埋め戦略を選択する必要はありません。

ギャップ埋め戦略は、データ収集が断続的または不完全である可能性があるシナリオに対処します。これらは、欠落しているデータポイントを推定値で置き換える方法を提供し、データストリームにギャップがある場合でもアラート条件が効果的に機能することを保証します。

ギャップ埋めをオフのままにする場合：

• Consistent data flow

  ：WebPortalアプリケーションの場合のように、アプリケーションが予想されるギャップなしで一貫してNew Relicにデータを送信する場合、通常はギャップを埋める必要はありません。このような場合、たいていはギャップ埋め戦略を実行しない設定のままにすることが最適なアプローチとなります。

  主な考慮事項：

• Popular use case：一般的に、ギャップを埋める際には、データを受信していないウィンドウに値0を挿入します。

• Anomaly thresholdsギャップ埋め値は、異常閾値を使用する場合、最後に観測された値からの標準偏差の数値として解釈されます。たとえば、ギャップを値0で埋めると、最後に確認された値が複製され、実質的には変化がないと想定されます。

  ギャップ埋め戦略の詳細については、損失信号に関するドキュメントをご覧ください。

異常閾値は、特定の数値よりも予想されるパターンから逸脱する場合に最適です。これを使用すると、事前定義された制限を設定することなく、異常なアクティビティを監視できます。New Relicの異常検知は、時間の経過とともにデータを動的に分析し、進化するシステム動作を反映するように閾値を調整します。

異常検知の設定：

1. 上限と下限の選択：

   • 予想よりも高い偏差と低い偏差がある場合に警告を受け取るには、上限と下限を選択します。
   • 異常に高い値のみに焦点を当てるには、「上限のみ」を選択します。

2. 優先順位の割り当て：

   • 潜在的な問題に迅速に対処できるように、最初のアラートの優先度レベルをクリティカルに設定します。
   • 優先レベルの詳細については、アラート条件のドキュメントを参照してください。

3. 違反基準の定義：

   • デフォルト設定から開始：クエリが予測値から5分間以上標準偏差3だけ逸脱する値を返した場合、インシデントをオープンします。
   • 特定のアプリケーションおよびアラート要件に合わせて、必要に応じてこれらの設定をカスタマイズします。

   優先レベルの詳細については、アラート条件に関するドキュメントをご覧ください。

   異常の閾値とモデルの動作について詳しくは、異常に関するドキュメントをご覧ください。

異常閾値とは異なり、静的閾値はデータセット全体を参照せず、システムの履歴に基づいて異常な動作を判断します。代わりに、you setユーザーが設定した基準とは異なる動作をする場合には、システムが静的閾値に従ってインシデントを開きます。

異常閾値と静的閾値の両方の優先レベルを設定する必要があります。詳細については、上のセクションを参照してください。

損失信号閾値は、損失信号が失われたとみなす前に待機する時間を決定します。その時間内に信号が返されない場合は、新しいインシデントを開くか、関連するインシデントを閉じるかを選択できます。システムの予想される動作とデータ収集頻度に応じて、閾値を設定します。たとえば、pageviewsの信号消失が遅延の問題を示している可能性がある場合は、適切な閾値を設定し、ボックスをオンにして新しい信号消失インシデントを開きます。

アラート条件にはわかりやすい名前を付けることが重要です。この条件にpageviewsという名前を付けてから、まったく別のアプリケーション用に別の条件を作成し、その条件にも同じくpageviewsというラベルを付けたとします。問題が発生すると、どの状態がどのアプリケーションのものであるかを区別できなくなります。したがって、条件には必ず具体的で一意の名前を付けてください。このケースでは、この条件にpageviews: WebPortal Appという名前を付けます。

アラート条件に接続するポリシーが既にある場合は、既存のポリシーを選択します。

ポリシーの作成について詳しくは、 こちらをご覧ください。

アラート戦略では応答性と疲労のバランスを取ることが重要であり、WebPortalアプリケーションのpageviewモニタリングに関する重要な考慮事項を示しました。ポリシーのオプションを見てみましょう。

1. ポリシーごとに1つのイシュー（デフォルト）：

   • 長所：ノイズを軽減し、即時のアクションを保証します
   • 短所：異なる条件によって引き起こされた場合でも、すべてのインシデントが 1 つのイシューにグループ化されます。複数のページビューの問題には理想的ではありません

2. 条件ごとに1つのイシュー：

   • 長所：条件ごとに個別のイシューを作成するため、特定の遅延問題を分離して対処するのに最適です
   • 短所：より多くのアラートが生成され、疲労を引き起こす可能性があります

3. あらゆるインシデントに共通するイシュー：

   • 長所：外部システムに詳細な情報を提供しますが、過負荷になる可能性があるため、内部利用には最適ではありません
   • 短所：これは最もノイズの多いオプションであり、より広範なトレンドを追跡し、効果的に優先順位を付けることが困難です

   ポリシーの作成について詳しくは、 こちらをご覧ください。

対象の信号が条件の閾値で示された期間にわたって非違反状態に戻ると、インシデントは自動的に終了します。この待ち時間を回復期間と呼びます。

たとえば、違反行為が「少なくとも 5 分間に1回、pageviewsが300未満」である場合、 pageviewsが5分間連続して300以上になると、インシデントは自動的に終了します。

インシデントが自動的に終了すると、次のようになります。

1. 終了タイムスタンプは回復期間の開始時点に遡ります

2. 評価はリセットされ、前のインシデントが終了したときから再開されます

   すべての条件には、長時間続くインシデントを自動的に強制終了する、インシデントの時間制限が設定されています。

   New Relicでは自動的にデフォルトで3日間が設定されるため、最初のアラートにはデフォルト設定を使用することをお勧めします。

   信号がデータを返さない場合に未解決のインシデントを閉じるもう 1 つの方法は、loss of signal閾値を設定することです。詳細については、上記の損失信号閾値のセクションを参照してください。

WebPortalアプリケーションにレイテンシの問題があるかどうかを知らせるアラート条件を作成しているため、開発者がこのインシデントについて通知されたときに必要な情報をすべて入手できるようにする必要があります。インシデントが作成されたときに、ワークフローを使用してチームのSlackチャネルに通知します。

カスタムインシデントの説明について詳しくは、ドキュメントをご覧ください。

ランブックにリンクする場合は、ランブックURLフィールドにURLを入力できます。