アラート条件は、インシデントがいつ作成されるかを定義する中心的な要素です。これは、意味のあるアラートを作成するための重要な開始点として機能します。アラート条件には、通知を受ける前に満たされたパラメーターまたは閾値が含まれます。過剰なアラートを軽減したり、新しい動作や異常な動作が発生したときにチームに通知したりできます。
Alert conditions list [アラート条件リスト]ページは、すべてのアラート条件のユニバーサルハブです。
新しいアラート条件を作成する
アラート条件は、継続的に実行されるクエリで、特定の一連のイベントを定義された閾値と比較して測定し、指定された時間枠内に閾値に達するとインシデントを開始します。
この例では、Alert condition details [アラート条件の詳細]ページを使用して新しいアラート条件を手動で作成する方法を示します。ただし、アラート条件を作成する方法は多数あります。アラート条件は以下から作成できます。
次のアラートビルダーのいずれかを使用することもできます。
- Write your own query [独自のクエリを作成]を使用してアラートを最初から作成する
- ガイド付きモードを使用する
ガイド付きモードを除くすべての方法で、アラート条件を作成するプロセスは、以下の手順で説明するものとまったく同じになります。
信号の動作を設定する
この例では、チームがeコマースサイトのWebPortal
アプリケーションを管理していると想定します。遅延の問題について警告を受け取りたいと考えています。
新しいアラート条件を作成するには:
one.newrelic.com > All capabilities > Alerts & AIの順に移動します。
左側のナビゲーションでAlert Conditionsを選択します。
次に、New alert conditionを選択します。
Write your own queryを選択します。
NRQLクエリを使用して、アラート条件でアラートの基礎として使用する信号を定義できます。この例では、次のクエリを使用します。
WHERE appName = 'WebPortal'
アラート条件にこのクエリを使用すると、New RelicにWebPortal
アプリケーションからの平均pageviews
が通知されます。pageviews
を監視すると、アプリケーション内のレイテンシの問題を見つけるのに役立ちます。
New Relicのクエリ言語であるNRQLの使用方法の詳細については、NRQLドキュメントを参照してください。
高度な信号設定を微調整する
信号を定義したら、Runをクリックします。チャートが表示され、設定したパラメーターが表示されます。
この例では、チャートにはWebPortal
アプリケーションの平均pageviews
が表示されます。Nextをクリックして、アラート条件の設定を開始します。
この例では、WebPortal
アプリケーション内のpageviews
の異常なアクティビティを監視するために作成した条件に合わせて、これらの高度な信号設定をカスタマイズします。
ウィンドウ期間は、New Relicがアラート条件での分析のためにデータをグループ化する方法を定義します。適切な設定の選択は、データの頻度と希望する詳細レベルによって異なります。
高頻度データ(たとえば、1分ごとのページビュー):変動や傾向をリアルタイムで把握できるように、データ頻度(この場合は1分)に一致するようにウィンドウ期間を設定します
低頻度データ(時間ごとの信号など):パターンや異常を明らかにするのに十分なデータをキャプチャするウィンドウ期間を選択します(たとえば、時間ごとの信号の場合は60分)
ニーズと経験に応じて、ウィンドウ期間をカスタマイズできます。アラート条件の作成に慣れてきたら、開始時や実験時にはデフォルトを使用することをお勧めします。
従来の集計方法では、データがまばらに存在したり、間隔の間に大きな変動が見られるデータを処理する場合には不十分である場合があります。スライディングウィンドウ集計を使用してそのようなデータを分析し、タイムリーなアラートを効果的にトリガーする方法を以下に示します。
ノイズを平滑化する:まず、大きな集計ウィンドウを作成します。この時間枠(たとえば、5分)はバッファとして機能し、データに固有の「ノイズ」や変動性を平滑化します。これは、単独の急上昇や急降下によってトリガーされる誤ったアラートを防ぐのに役立ちます
スライディングウィンドウでラグを回避する:大きなウィンドウはデータ分析に役立ちますが、閾値をチェックする前に間隔全体が経過するまで待機すると、アラート通知が大幅に遅れる可能性があります。スライディングウィンドウを小さくすることをお勧めします(たとえば、1分)。このスライディングウィンドウを、より大きな集計ウィンドウ内でデータをスキャンする移動フレームとして想像してください。フレームが小さい間隔で進むたびに、集計値(平均など)が計算されます
閾値の期間を設定する:より小さいスライディングウィンドウのコンテキスト内で、アラートの閾値を定義できるようになりました。これにより、現在のフレームの集計値が目的の範囲から大幅に逸脱した場合でも、より大きなウィンドウの平滑化効果を犠牲にすることなく、アラートを迅速にトリガーできます
スライディングウィンドウ集計について詳しくは、このNRQLチュートリアルをご覧ください。
一般に、event flow [イベントフロー]ストリーミング方式を使用することをお勧めします。これは、システムに頻繁かつ安定的に入ってくるデータに最適です。特定のケースでは、event timer [イベントタイマー]を選択したほうがよい場合もありますが、最初のアラートでは、デフォルトのevent flow [イベントフロー]を推奨します。この短いビデオをご覧になることをお勧めします(約5分31秒)、どのストリーミング方法を選択すべきかがわかります。
アラート条件の遅延機能は、一貫性のないデータ収集から生じる潜在的な問題を防ぎます。これはバッファとして機能し、アラートをトリガーする前にデータが到着して処理されるまでの時間を確保します。これにより、誤検知を防止し、より正確なインシデントの作成が保証されます。
使い方:
適切な遅延設定は、受信データの一貫性を評価することによって決定されます。
一貫したデータ:データポイントが1分以内にタイムスタンプとともに定期的に到着する場合は、遅延設定を低くしても問題ありません
一貫性のないデータ:過去や未来の数分間にわたるタイムスタンプを持つデータポイントが到着した場合、不整合に対応するために遅延設定を大きくする必要があります
バッファの作成:
選択した遅延設定により、アラート条件が定義された閾値に対してデータを評価するまでの待機時間が導入されます
このバッファにより、データの不一致を解決するまでの時間が確保され、誤解を招くアラートが発生する可能性が軽減されます
WebPortal
アプリケーションのレイテンシの問題をチームに通知するためのアラート条件を作成しています。この例では、アプリケーションは一貫してNew Relicデータを送信します。アプリケーションからNew Relicに信号が継続的に送信されており、信号に予期されるギャップがないため、ギャップ埋め戦略を選択する必要はありません。
ギャップ埋め戦略は、データ収集が断続的または不完全である可能性があるシナリオに対処します。これらは、欠落しているデータポイントを推定値で置き換える方法を提供し、データストリームにギャップがある場合でもアラート条件が効果的に機能することを保証します。
ギャップ埋めをオフのままにする場合:
一貫したデータフロー:WebPortalアプリケーションの場合のように、アプリケーションが予想されるギャップなしで一貫してNew Relicにデータを送信する場合、通常はギャップ埋めは不要です。このような場合、ギャップ埋め戦略を [なし] に設定したままにすることが、多くの場合最も適切なアプローチです
主な考慮事項:
一般的な使用例:ギャップ埋めの一般的な使用法は、データを受信していないウィンドウに値0を挿入することです
異常閾値:ギャップ充填値は、異常閾値を使用する場合、最後に観測された値からの標準偏差の数として解釈されます。たとえば、ギャップを値0で埋めると、最後に確認された値が複製され、実質的には変化がないと想定されます
ギャップ埋め戦略の詳細については、損失信号に関するドキュメントをご覧ください。
アラート条件の閾値を設定する
アラート条件がコンテナの場合、閾値は各アラート条件が従う必要があるルールです。データがシステムにストリーミングされると、アラート条件によってこれらのルールに該当するインシデントが検索されます。アラート条件で、設定したすべての条件を満たしたデータがシステムから検出されると、インシデントが作成されます。インシデントは、システムに何か問題があることを示しているため、確認する必要があります。
異常閾値は、特定の数値よりも予想されるパターンから逸脱する場合に最適です。これを使用すると、事前定義された制限を設定することなく、異常なアクティビティを監視できます。New Relicの異常検知は、時間の経過とともにデータを動的に分析し、進化するシステム動作を反映するように閾値を調整します。
異常検知の設定:
上限と下限の選択:
- 予想よりも高い偏差と低い偏差がある場合に警告を受け取るには、上限と下限を選択します。
- 異常に高い値のみに焦点を当てるには、「上限のみ」を選択します。
優先順位の割り当て:
- 潜在的な問題に迅速に対処できるように、最初のアラートの優先度レベルをクリティカルに設定します。
- 優先レベルの詳細については、アラート条件のドキュメントを参照してください。
違反基準の定義:
- デフォルト設定から開始:クエリが予測値から5分間以上標準偏差3だけ逸脱する値を返した場合、インシデントをオープンします。
- 特定のアプリケーションおよびアラート要件に合わせて、必要に応じてこれらの設定をカスタマイズします。
優先レベルの詳細については、アラート条件に関するドキュメントをご覧ください。
異常の閾値とモデルの動作について詳しくは、異常に関するドキュメントをご覧ください。
異常閾値とは異なり、静的閾値はデータセット全体を調べず、システムの履歴に基づいて異常な動作を判断します。代わりに、システムが設定した基準と異なる動作をする場合には、静的閾値によってインシデントが発生します。
異常閾値と静的閾値の両方の優先レベルを設定する必要があります。詳細については、上のセクションを参照してください。
損失信号閾値は、損失信号が失われたとみなす前に待機する時間を決定します。その時間内に信号が返されない場合は、新しいインシデントを開くか、関連するインシデントを閉じるかを選択できます。システムの予想される動作とデータ収集頻度に応じて、閾値を設定します。たとえば、pageviews
の信号消失が遅延の問題を示している可能性がある場合は、適切な閾値を設定し、ボックスをオンにして新しい信号消失インシデントを開きます。
アラート条件の詳細を追加する
プロセスのこの時点で、条件が完全に定義され、必要なときにインシデントがオープンされるようにするすべてのルールが設定されました。上記の設定に基づいて、設定した閾値に違反するシステム内の動作をアラート条件が認識すると、インシデントが作成されます。ここで必要なのは、この条件に名前を付けてポリシーに添付することだけです。
ポリシーはインシデントの分類システムです。ポリシーを作成すると、受信したすべてのインシデントを整理するツールが作成されます。ポリシーをワークフローに接続して、このすべての受信情報の送信先、送信頻度、送信先をNew Relicに指示できます。
アラート条件にわかりやすい名前を付けることが重要です。この条件にpageviewsという名前を付けてから、まったく別のアプリケーション用に別の条件を作成し、その条件にpageviewsというラベルを付けたとします。問題が発生すると、どの状態がどのアプリケーションのものであるかを区別できなくなります。したがって、条件には必ず具体的で一意の名前を付けてください。この場合、この条件にpageviews: WebPortal Appという名前を付けます。
アラート条件に接続するポリシーが既にある場合は、既存のポリシーを選択します。
ポリシーの作成について詳しくは、 こちらをご覧ください。
アラート戦略では応答性と疲労のバランスを取ることが重要であり、WebPortal
アプリケーションのpageview
モニタリングに関する重要な考慮事項を示しました。ポリシーのオプションを見てみましょう。
ポリシーごとに1つのイシュー(デフォルト):
- 長所:ノイズを軽減し、即時のアクションを保証します
- 短所:異なる条件によって引き起こされた場合でも、すべてのインシデントが 1 つのイシューにグループ化されます。複数のページビューの問題には理想的ではありません
条件ごとに1つのイシュー:
- 長所:条件ごとに個別のイシューを作成するため、特定の遅延問題を分離して対処するのに最適です
- 短所:より多くのアラートが生成され、疲労を引き起こす可能性があります
あらゆるインシデントに共通するイシュー:
- 長所:外部システムに詳細な情報を提供しますが、過負荷になる可能性があるため、内部利用には最適ではありません
- 短所:これは最もノイズの多いオプションであり、より広範なトレンドを追跡し、効果的に優先順位を付けることが困難です
ポリシーの作成について詳しくは、 こちらをご覧ください。
対象の信号が条件の閾値で示された期間にわたって非違反状態に戻ると、インシデントは自動的に終了します。この待ち時間を回復期間と呼びます。
たとえば、違反行為が「少なくとも 5 分間に1回、pageviews
が300未満」である場合、 pageviews
が5分間連続して300以上になると、インシデントは自動的に終了します。
インシデントが自動的に終了すると、次のようになります。
終了タイムスタンプは回復期間の開始時点に遡ります
評価はリセットされ、前のインシデントが終了したときから再開されます
すべての条件には、長時間続くインシデントを自動的に強制終了する、インシデントの時間制限が設定されています。
New Relicでは自動的にデフォルトで3日間が設定されるため、最初のアラートにはデフォルト設定を使用することをお勧めします。
信号がデータを返さない場合に未解決のインシデントを閉じるもう 1 つの方法は、loss of signal
閾値を設定することです。詳細については、上記の損失信号閾値のセクションを参照してください。
WebPortal
アプリケーションにレイテンシの問題があるかどうかを知らせるアラート条件を作成しているため、開発者がこのインシデントについて通知されたときに必要な情報をすべて入手できるようにする必要があります。インシデントが作成されたときに、ワークフローを使用してチームのSlackチャネルに通知します。
カスタムインシデントの説明について詳しくは、ドキュメントをご覧ください。
ランブックにリンクする場合は、ランブックURLフィールドにURLを入力できます。
既存のアラート条件を編集または改善する
既に作成したアラート条件を編集する場合は、次の操作を行うことができます。
- one.newrelic.com > All capabilities > Alerts & AIの順に移動します。
- 左側のナビゲーションでAlert Conditionsを選択します。
- 編集するアラート条件をクリックします。
そこから、Alert conditions detailsページが表示されます。このページには、条件の作成時に設定したすべての要素が含まれています。各セクションの右上にある鉛筆をクリックすると、アラート条件の特定の側面を編集できます。
信号履歴
Signal history [信号履歴]で、アラート条件の作成に使用したNRQLクエリの最新の結果を確認できます。この例では、設定した特定の期間における、WebPortal
アプリの平均pageviews
が表示されます。
NRQLクエリで構築されたすべてのアラート条件について、Signal history [シグナル履歴]が折れ線グラフで表示されます。
Syntheticモニターで構築されたアラート条件は少し異なります。これは、Syntheticモニターを使用すると、複数の場所からアプリケーションにpingを実行できるため、モニターが実行されるたびに肯定的な結果または否定的な結果が生成される可能性があるためです。このデータは表でのみ表示できます。
トラブルシューティング
履歴チャートに空の信号が表示された場合は、次のいずれかを検討してください。
- 条件の設定を確認する:すべての要素が正しく設定されていることを再確認します
- NRQLクエリを検査する:クエリが有効なメトリクスまたはイベントをターゲットにしており、データを返していることを確認します
- エンティティ設定を検査する:エンティティが信号を送信するように正しく設定されていることを確認します
- New Relicのドキュメントを参照する:特定の問題については、関連するガイドを参照してください
次のステップ