アラート条件は、インシデント がいつ作成されるかを定義する中心的な要素です。これは、意味のあるアラートを作成するための重要な開始点として機能します。アラート条件には、通知を受ける前に満たされたパラメーターまたは閾値が含まれます。過剰なアラートを軽減したり、新しい動作や異常な動作が発生したときにチームに通知したりできます。
Alert conditions list ページは、すべてのアラート条件のユニバーサルハブです。
新しいアラート条件を作成する アラート条件は、継続的に実行されるクエリで、特定の一連のイベントを定義された閾値と比較して測定し、指定された時間枠内に閾値に達するとインシデント を開始します。
この例では、Alert condition details ページを使用して新しいアラート条件を手動で作成する方法を示します。アラート条件を作成する方法は多数あります。アラート条件は以下から作成できます。
次のアラートビルダーのいずれかを使用することもできます。
Write your own query
を使用してアラートをゼロから作成する
Use guided mode
ガイド付きモードを除くすべての方法で、アラート条件を作成するプロセスは、以下の手順で説明するものとまったく 同じになります。
信号の動作を設定する この例では、チームがeコマースサイトのWebPortal
アプリケーションを管理していると想定します。遅延の問題について警告を受け取りたいと考えています。
新しいアラート条件を作成するには:
高度な信号設定を微調整する 信号を定義したら、Run をクリックします。チャートが表示され、設定したパラメーターが表示されます。
この例では、チャートにはWebPortal
アプリケーションの平均pageviews
が表示されます。Next をクリックして、アラート条件の設定を開始します。
この例では、WebPortal
アプリケーション内のpageviews
の異常なアクティビティを監視するために作成した条件に合わせて、これらの高度な信号設定をカスタマイズします。
ウィンドウ期間 ウィンドウ期間は、New Relicがアラート条件での分析のためにデータをグループ化する方法を定義します。適切な設定の選択は、データの頻度と希望する詳細レベルによって異なります。
High-frequency data (for example, pageviews every minute)
:変動や傾向をリアルタイムで把握できるように、データ頻度(この場合は1分)に一致するようにウィンドウ期間を設定します
Low-frequency data (for example, hourly signals)
:パターンや異常を明らかにするのに十分なデータをキャプチャするウィンドウ期間を選択します(たとえば、1時間ごとの信号の場合は60分)
ニーズと経験に応じて、ウィンドウ期間をカスタマイズできます。アラート条件の作成に慣れてきたら、開始時や実験時にはデフォルトを使用することをお勧めします。
スライディングウィンドウ集計を使用する 従来の集計方法では、データがまばらに存在したり、間隔の間に大きな変動が見られるデータを処理する場合には不十分である場合があります。スライディングウィンドウ集計を使用してそのようなデータを分析し、タイムリーなアラートを効果的にトリガーする方法を以下に示します。
Smooth out the noise :まず、大きな集計ウィンドウを作成します。この時間枠(たとえば、5分)はバッファとして機能し、データに固有の「ノイズ」や変動性を平滑化します。これは、単独の急上昇や急降下によってトリガーされる誤ったアラートを防ぐのに役立ちます。
Avoid lag with a sliding window 大きなウィンドウはデータ分析に役立ちますが、閾値をチェックする前に間隔全体が経過するまで待機すると、アラート通知が大幅に遅れる可能性があります。スライディングウィンドウを小さくすることをお勧めします(たとえば、1分)。このスライディングウィンドウを、より大きな集計ウィンドウ内でデータをスキャンする移動フレームとして想像してください。フレームが小さい間隔で進むたびに、集計値(平均など)が計算されます。
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の異常検知は、時間の経過とともにデータを動的に分析し、進化するシステム動作を反映するように閾値を調整します。
異常検知の設定:
上限と下限の選択:
予想よりも高い偏差と低い偏差がある場合に警告を受け取るには、上限と下限を選択します。 異常に高い値のみに焦点を当てるには、「上限のみ」を選択します。 優先順位の割り当て:
潜在的な問題に迅速に対処できるように、最初のアラートの優先度レベルをクリティカルに設定します。 優先レベルの詳細については、アラート条件のドキュメントを参照してください。 違反基準の定義:
デフォルト設定から開始:クエリが予測値から5分間以上標準偏差3だけ逸脱する値を返した場合、インシデントをオープンします。 特定のアプリケーションおよびアラート要件に合わせて、必要に応じてこれらの設定をカスタマイズします。 優先レベルの詳細については、アラート条件に関するドキュメント をご覧ください。
異常の閾値とモデルの動作について詳しくは、異常に関するドキュメント をご覧ください。
静的閾値 異常閾値とは異なり、静的閾値はデータセット全体を参照せず、システムの履歴に基づいて異常な動作を判断します。代わりに、you set ユーザーが設定した基準とは異なる動作をする場合には、システムが静的閾値に従ってインシデントを開きます。
異常閾値と静的閾値の両方の優先レベルを設定する必要があります。詳細については、上のセクションを参照してください。
損失信号閾値(オプション) 損失信号閾値は、損失信号が失われたとみなす前に待機する時間を決定します。その時間内に信号が返されない場合は、新しいインシデントを開くか、関連するインシデントを閉じるかを選択できます。システムの予想される動作とデータ収集頻度に応じて、閾値を設定します。たとえば、pageviews
の信号消失が遅延の問題を示している可能性がある場合は、適切な閾値を設定し、ボックスをオンにして新しい信号消失インシデントを開きます。
アラート条件の詳細を追加する プロセスのこの時点で、条件が完全に定義され、必要なときにインシデントがオープンされるようにするすべてのルールが設定されました。上記の設定に基づいて、設定した閾値に違反するシステム内の動作をアラート条件が認識すると、インシデントが作成されます。ここで必要なのは、この条件に名前を付けてポリシーに添付することだけです。
ポリシーはインシデントの分類システムです。ポリシーを作成すると、受信したすべてのインシデントを整理するツールが作成されます。ポリシーをworkflows ワークフローに接続すると、このすべての受信情報の送信先、送信頻度、送信先を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フィールドにURLを入力できます。
既存のアラート条件を編集または改善する 既に作成したアラート条件を編集する場合は、次の操作を行うことができます。
one.newrelic.com > All capabilities >
Alerts
に移動します。
左側のナビゲーションで
Alert Conditions
を選択します。
編集するアラート条件をクリックします。
これでAlert conditions details ページが表示されます。このページには、条件の作成時に設定したすべての要素が含まれています。各セクションの右上にある鉛筆をクリックすると、アラート条件の特定の項目を編集できます。
信号履歴 Signal history の下に、アラート条件の作成に使用したNRQLクエリの最新の結果が表示されます。この例では、設定した特定の期間におけるWebPortal
アプリの平均pageviews
が表示されます。
NRQLクエリで構築されたすべてのアラート条件について、Signal history に折れ線グラフとして表示されます。
Syntheticモニターで構築されたアラート条件は少し異なります。これは、Syntheticモニターを使用すると、複数の場所からアプリケーションにpingを実行できるため、モニターが実行されるたびに肯定的な結果または否定的な結果が生成される可能性があるためです。このデータは表でのみ表示できます。
トラブルシューティング 履歴チャートに空の信号が表示された場合は、次のいずれかを検討してください。
Review the condition's settings
:すべての要素が正しく設定されていることを再確認します。
Inspect NRQL queries
:クエリが有効なメトリクスまたはイベントをターゲットにしており、データを返していることを確認します。
Examine entity configuration
:エンティティが信号を送信するように正しく設定されていることを確認します。
Consult New Relic documentation
:特定の問題については、関連するガイドを参照してください。
次のステップ