アラート条件は、インシデント がいつ作成されるかを定義する中心的な要素です。これは、意味のあるアラートを作成するための重要な開始点として機能します。アラート条件には、通知を受ける前に満たされたパラメーターまたは閾値が含まれます。過剰なアラートを軽減したり、新しい動作や異常な動作が発生したときにチームに通知したりできます。
新しいアラート条件を作成する アラート条件は、継続的に実行されるクエリで、特定の一連のイベントを定義された閾値と比較して測定し、指定された時間枠内に閾値に達するとインシデント を開始します。
この例では、Alert condition details ページを使用して新しいアラート条件を手動で作成する方法を示します。アラート条件を作成する方法は多数あります。アラート条件は以下から作成できます。
次のアラートビルダーのいずれかを使用することもできます。
Write your own query を使用してアラートをゼロから作成するUse guided mode
ガイド付きモードを除くすべての方法で、アラート条件を作成するプロセスは、以下の手順で説明するものとまったく 同じになります。
信号の動作を設定する この例では、チームがeコマースサイトのWebPortal
アプリケーションを管理していると想定します。遅延の問題について警告を受け取りたいと考えています。
新しいアラート条件を作成するには:
one.newrelic.com > All capabilities > Alerts に移動します。
左側のナビゲーションでAlert Conditions を選択します。
次に、New alert condition を選択します。
Write your own query を選択します。
信号の動作を設定する NRQLクエリを使用して、アラート条件でアラートの基礎として使用する信号を定義できます。この例では、次のクエリを使用します。
WHERE appName = 'WebPortal'
アラート条件にこのクエリを使用すると、WebPortal
アプリケーションの取得したいページ読み込みの平均レイテンシまたは期間がNew Relicに通知されます。レイテンシに関するプロアクティブなアラートは中核的なゴールデンシグナルであり、潜在的な低下に対する早期警告を提供します。
New Relicのクエリ言語であるNRQLの使用方法の詳細については、NRQLドキュメント を参照してください。
高度な信号設定を微調整する 信号を定義したら、Run をクリックします。チャートが表示され、設定したパラメーターが表示されます。
この例では、チャートにはWebPortal
アプリケーションの平均レイテンシが表示されます。Next をクリックして、アラート条件の設定を開始します。
この例では、 WebPortal
アプリケーションのレイテンシを監視するために作成した条件に合わせて、これらの高度な信号設定をカスタマイズします。
ウィンドウ期間 ウィンドウ期間は、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だけ逸脱する値を返した場合、インシデントをオープンします。 特定のアプリケーションおよびアラート要件に合わせて、必要に応じてこれらの設定をカスタマイズします。 優先レベルの詳細については、アラート条件に関するドキュメント をご覧ください。
異常の閾値とモデルの動作について詳しくは、異常に関するドキュメント をご覧ください。
静的閾値 異常閾値とは異なり、静的閾値はデータセット全体を参照せず、システムの履歴に基づいて異常な動作を判断します。代わりに、システムが設定した基準と異なる動作をした場合には必ず、静的閾値がインシデントを開きます。
異常閾値と静的閾値の両方の優先レベルを設定する必要があります。詳細については、上のセクションを参照してください。
損失信号閾値(オプション) 損失信号閾値は、損失信号が失われたとみなす前に待機する時間を決定します。その時間内に信号が返されない場合は、新しいインシデントを開くか、関連するインシデントを閉じるかを選択できます。システムの予想される動作とデータ収集頻度に応じて、閾値を設定します。たとえば、ウェブサイトでトラフィックの完全な損失やスループットが発生した場合、それに対応するNew Relicに送信されるテレメトリーデータも停止します。この信号損失を監視することで、このような停止の早期警告システムとして機能します。
アラート条件の詳細を追加する プロセスのこの時点で、条件が完全に定義され、必要なときにインシデントがオープンされるようにするすべてのルールが設定されました。上記の設定に基づいて、設定した閾値に違反するシステム内の動作をアラート条件が認識すると、インシデントが作成されます。ここで必要なのは、この条件に名前を付けてポリシーに添付することだけです。
ポリシーはインシデントの分類システムです。ポリシーを作成すると、受信したすべてのインシデントを整理するツールが作成されます。ポリシーをworkflows ワークフローに接続すると、このすべての受信情報の送信先、送信頻度、送信先をNew Relicに指示できます。
条件に名前を付ける 条件の命名のベストプラクティスとして、重要な情報がひと目でわかる構造化された形式があります。条件名には次の要素を含めます。
優先度 :アラートの重大度または緊急度を、P1、P2、P3のように示します。
信号 :高平均レイテンシや低スループットなど、監視するメトリクスや条件を指定します。
エンティティ :WebPortalアプリやデータベースサーバーなど、影響を受けるシステム、アプリケーションやコンポーネントを識別します。
この構造に従うと、適切な条件名の例は「P2 | High Avg Latency | WebPortal App
」になります。
既存のポリシーを選択します。 アラート条件に接続するポリシーが既にある場合は、既存のポリシーを選択します。
ポリシーの作成について詳しくは、 こちらを ご覧ください。
新しいポリシーを作成する アラート戦略では応答性と疲労のバランスを取ることが重要であり、WebPortal
アプリケーションのpageview
モニタリングに関する重要な考慮事項を示しました。ポリシーのオプションを見てみましょう。
ポリシーごとに1つのイシュー(デフォルト):
長所:ノイズを軽減し、即時のアクションを保証します 短所:異なる条件によって引き起こされた場合でも、すべてのインシデントが 1 つのイシューにグループ化されます。複数のページビューの問題には理想的ではありません 条件ごとに1つのイシュー:
長所:条件ごとに個別のイシューを作成するため、特定の遅延問題を分離して対処するのに最適です 短所:より多くのアラートが生成され、疲労を引き起こす可能性があります あらゆるインシデントに共通するイシュー:
長所:外部システムに詳細な情報を提供しますが、過負荷になる可能性があるため、内部利用には最適ではありません 短所:これは最もノイズの多いオプションであり、より広範なトレンドを追跡し、効果的に優先順位を付けることが困難です ポリシーの作成について詳しくは、 こちらを ご覧ください。
未解決のインシデントをクローズする 対象の信号が条件の閾値で示された期間にわたって非違反状態に戻ると、インシデントは自動的に終了します。この待ち時間を回復期間と呼びます。
たとえば、レイテンシを測定していて、違反行為が「WebPortal
アプリケーションでページ読み込みのduration
が3秒以上増加したこと」である場合、インシデントはduration
が5分間連続して3秒未満になると自動的に終了します。
インシデントが自動的に終了すると、次のようになります。
終了タイムスタンプは回復期間の開始時点に遡ります
評価はリセットされ、前のインシデントが終了したときから再開されます
すべての条件には、長時間続くインシデントを自動的に強制終了する、インシデントの時間制限が設定されています。
New Relicでは自動的にデフォルトで3日間が設定されるため、最初のアラートにはデフォルト設定を使用することをお勧めします。
信号がデータを返さない場合に未解決のインシデントを閉じるもう 1 つの方法は、loss of signal
閾値を設定することです。詳細については、上記の損失信号閾値のセクションを参照してください。
カスタムインシデントの説明を設定する WebPortal
アプリケーションにレイテンシの問題があるかどうかを知らせるアラート条件を作成しているため、開発者がこのインシデントについて通知されたときに必要な情報をすべて入手できるようにする必要があります。インシデントが作成されたときに、ワークフローを使用してチームのSlackチャネルに通知します。
カスタムインシデントの説明について詳しくは、ドキュメント をご覧ください。
タイトルテンプレートを使用する タイトルテンプレートの使用はオプションですが、推奨されます。アラート条件は、監視したい一連の閾値を定義します。これらの閾値のいずれかに違反があった場合、インシデントが作成されます。意味のあるタイトルテンプレートを使用することで、問題を正確に特定し、稼働停止の解決を迅速化できます。
タイトルテンプレートの詳細については、ドキュメント をご覧ください。
ランブックURLを追加する 調査、トリアージ、修復手順を詳述した運用ランブックは、このフィールドにリンクされることがよくあります。
既存のアラート条件を編集する 既に作成したアラート条件を編集する場合は、次の操作を行うことができます。
one.newrelic.com > All capabilities > Alerts に移動します。左側のナビゲーションでAlert Conditions を選択します。 編集するアラート条件をクリックします。 これでAlert conditions details ページが表示されます。このページには、条件の作成時に設定したすべての要素が含まれています。各セクションの右上にある鉛筆をクリックすると、アラート条件の特定の項目を編集できます。
信号履歴 Signal history の下に、アラート条件の作成に使用したNRQLクエリの最新の結果が表示されます。この例では、設定した特定の期間におけるWebPortal
アプリの平均レイテンシが表示されます。
NRQLクエリで構築されたすべてのアラート条件について、Signal history に折れ線グラフとして表示されます。
Syntheticモニターで構築されたアラート条件は少し異なります。これは、Syntheticモニターを使用すると、複数の場所からアプリケーションにpingを実行できるため、モニターが実行されるたびに肯定的な結果または否定的な結果が生成される可能性があるためです。このデータは表でのみ表示できます。
条件のタイプ 推奨される主な条件タイプはNRQLアラート条件ですが、他のタイプの条件もあります。以下に、条件タイプを網羅したリストを示します。
複数の場所におけるSyntheticsモニタリングの条件 Javaインスタンス条件 閾値を、Javaアプリインスタンスのメトリクスがその閾値を超えた場合にインシデントをオープンするように設定できます。
閾値を特定のインスタンスにスコープする ことで、潜在的な問題がどこで発生しているかをより迅速に突き止めることができます。たとえば、アプリのインスタンスのサブセットのみで発生している異常を検出する場合に便利です。膨大な数のインスタンスにわたってメトリックスを集計するアプリの場合、このタイプの異常は容易に見過ごされてしまいます。
JVM健全性メトリクス条件(Javaアプリ) APMによって監視されるJavaアプリケーションの場合、単一のJVMのヒープサイズ、またはスレッド数が予想される動作範囲外にある場合にインシデントをオープンする閾値 を設定できます。
各アプリの選択されたインスタンス ごとに、閾値違反のアラートを個別に評価します。条件を作成する際、Javaアプリのアラートポリシーに対する条件タイプとしてJVM health metric を選択してから、いずれかの利用可能な閾値を選択します。
ウェブトランザクションのパーセンタイル条件 条件には閾値 としてパーセンタイルを定義するオプションが含まれます。この条件は、ウェブアプリのレスポンスタイムがこの値を上回る、下回る、または等しい場合として設定します。これは、たとえば運用スタッフがウェブのaverage 平均レスポンスタイムではなく、アプリケーションサーバーのoverall 全体的なウェブトランザクション レスポンスタイムのパーセンタイルに基づいてアラートを発生させる場合に便利です。
パーセンタイル閾値を定義するには:
APM アプリの条件の種類としてWeb transactions percentiles を選択し、アプリを 1 つ選択します(複数のアプリでアラートを発生させるには、それぞれに個別のWeb transactions percentiles 条\
件を作成します)。
インシデントをオープンする閾値を定義するには、Percentile nth レスポンスタイム値を入力し、その頻度(この値より大きい、小さい、または等しい)を選択します。
ユーザーインタフェースにはクリティカルと警告の値が秒単位で表示されますが、New Relicにはトランザクションタイムがミリ秒で保存されます。ミリ秒で定義する場合は、値に小数点を含めます。
アプリのラベルを使用した動的ターゲティング アプリケーションにラベル を適用することで、条件にこれらのエンティティ を自動的にリンクさせることができます。これにより、すべてのアプリケーションを動的環境内で簡単に管理できます。エンティティラベルを最適な状態で管理するため、エージェントの設定ファイル を使用するようお勧めします。
1つのラベルを使用して、関連のあるall すべてのエンティティ(最大10,000エンティティ)を識別できます。ラベルを複数使用する場合は、選択されたすべてのラベルを共有するエンティティのみを識別します。
条件と合わせてダイナミックターゲティングを利用するには、インシデントクローズタイマー を設定する必要もあります。
1つの条件に対して最高で10個のラベルを追加、編集、削除するには:
製品タイプとしてAPM > Application metric を選択します。
エンティティを識別するには、Labels タブを選択します。ラベルを名前で検索するか、カテゴリーのリストからラベルを選択します。
また、インフラストラクチャ を使用して、監視対象の条件を直接作成することもできます。
インフラストラクチャの条件 InfrastructureモニタリングUIから直接リソースの条件を作成 できます。
たとえば、Infrastructureエージェントでデータが受信されなくなったときに通知を受信するには、host not reporting という条件タイプを使用します。これにより、フィルタリングされたホストグループに対してアラートを動的に送信し、5〜60分の時間枠を設定できるようになります。
ポリシーに条件を追加する ポリシーに条件を追加する には:
次のパスに移動します: one.newrelic.com > All capabilities > Alerts > Alert Policies ポリシーを検出します。 Add a condition をクリックします。新しいNRQL条件を作成する には:
次のパスに移動します: one.newrelic.com > All capabilities > Alerts > Alert Conditions Add a condition をクリックします。条件をコピーする ターゲット や閾値など を含む既存の条件をコピーし、選択したアカウントの別のポリシーに追加するには、次の手順を実行します。
one.newrelic.com > All capabilities > Alerts > Alert conditions に移動します。
アラート条件のリストから、コピーしたいアラートの三点アイコンをクリックし、 Duplicate condition を選択します。
Copy alert condition から、リストを検索またはスクロールして、この条件を追加するポリシーを選択します。
オプション:必要に応じて条件名を変更します。
オプション:トグルスイッチを切り替えます: Enable on save
Copy condition を選択します。
デフォルトでは、選択されたアラートポリシーはコピーされた条件を無効 の状態で追加します。標準の手順に従ってアラートポリシーにさらなる条件を追加 またはコピーし、必要に応じて条件を有効にします 。また、新しい条件には、元の条件に追加されたタグは コピーされません。
条件を有効/無効にする 条件を無効にしたり再度有効にするには、以下を行います。
one.newrelic.com > All capabilities > Alerts > Alert Conditions に移動します。次に、 Alert conditions のリストからトグルを使用して条件を有効または無効にします。On/Off スイッチをクリックして切り替えます。条件をコピーする と、元のポリシーで条件が有効( On )だったとしても、新しいポリシーでは自動的に無効( Off )として保存されます。
条件を削除する 条件をオフにしてポリシーを維持するには、条件を無効にします 。1つ以上の条件を削除するには、以下を行います。
one.newrelic.com > All capabilities > Alerts > Alert Conditions に移動します。
Alert conditions のリストから条件を選択し、省略記号メニュー(...)からDelete をクリックします。
ヒント 削除ボタンが表示されない場合は、アカウント管理者が組織の条件の削除を無効にしている可能性があります。
アラート条件ページのトラブルシューティング Alert Condition ページの履歴チャートに空の信号が表示される場合は、次のいずれかを検討してください。
Review the condition's settings :すべての要素が正しく設定されていることを再確認します。Inspect NRQL queries :クエリが有効なメトリクスまたはイベントをターゲットにしており、データを返していることを確認します。Examine entity configuration :エンティティが信号を送信するように正しく設定されていることを確認します。Consult New Relic documentation :特定の問題については、関連するガイドを参照してください。次のステップ