アラート条件

ウィンドウ期間は、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だけ逸脱する値を返した場合、インシデントをオープンします。
   • 特定のアプリケーションおよびアラート要件に合わせて、必要に応じてこれらの設定をカスタマイズします。

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

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

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

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

損失信号閾値は、損失信号が失われたとみなす前に待機する時間を決定します。その時間内に信号が返されない場合は、新しいインシデントを開くか、関連するインシデントを閉じるかを選択できます。システムの予想される動作とデータ収集頻度に応じて、閾値を設定します。たとえば、ウェブサイトでトラフィックの完全な損失やスループットが発生した場合、それに対応するNew Relicに送信されるテレメトリーデータも停止します。この信号損失を監視することで、このような停止の早期警告システムとして機能します。

条件の命名のベストプラクティスとして、重要な情報がひと目でわかる構造化された形式があります。条件名には次の要素を含めます。

• 優先度：アラートの重大度または緊急度を、P1、P2、P3のように示します。

• 信号：高平均レイテンシや低スループットなど、監視するメトリクスや条件を指定します。

• エンティティ：WebPortalアプリやデータベースサーバーなど、影響を受けるシステム、アプリケーションやコンポーネントを識別します。

  この構造に従うと、適切な条件名の例は「P2 | High Avg Latency | WebPortal App」になります。

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

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

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

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

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

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

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

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

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

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

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

たとえば、レイテンシを測定していて、違反行為が「WebPortalアプリケーションでページ読み込みのdurationが3秒以上増加したこと」である場合、インシデントはdurationが5分間連続して3秒未満になると自動的に終了します。

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

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

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

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

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

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

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

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

タイトルテンプレートの使用はオプションですが、推奨されます。アラート条件は、監視したい一連の閾値を定義します。これらの閾値のいずれかに違反があった場合、インシデントが作成されます。意味のあるタイトルテンプレートを使用することで、問題を正確に特定し、稼働停止の解決を迅速化できます。

タイトルテンプレートの詳細については、ドキュメントをご覧ください。

調査、トリアージ、修復手順を詳述した運用ランブックは、このフィールドにリンクされることがよくあります。