NRQLアラート条件を作成する

NRQLクエリを使用してアラート条件を作成できます。信号を定義した後、警告とクリティカルな閾値レベルをさらに定義できます。これでアラート違反を作成するタイミングが決定されます。

この操作方法の詳細については、以下をお読みください。

NRQLアラート条件を作成する

ポリシーのNRQLアラート条件を作成する場合は、以下の手順に従います。

• one.newrelic.comで、ヘッダーにあるアラートおよびAIをクリックしてから、左のサイドバーでポリシーをクリックします。
• 既存のポリシーを選択、または新しいアラートポリシーをクリックし、新しいポリシーを作成します。
• 条件を追加をクリックします。
• 条件を作成するときは、製品の選択で。NRQLをクリックしてから、次に、閾値を定義をクリックします。

既存の条件を編集すると、評価がリセットされることがあります。

チャートから条件を作成する

チャートを使用してNRQLアラート条件を作成できます。

命名し、条件をカスタマイズしたら、既存のポリシーに追加または新しいポリシーを作成できます。

NRQLアラートの構文

すべてのNRQLアラート条件を作成するための基本的な構文は、以下のとおりです。FACET句は、外れ値の条件タイプに必要です。これは静的およびベースラインのオプションです。

SELECT function(attribute)
    FROM Event
    WHERE attribute [comparison] [AND|OR ...]

再フォーマット化された互換性がないNRQL

チャートで使用されるNRQLの一部の要素は、アラートのストリーミングコンテキストに意味はありません。以下は、NRQLアラートクエリを再フォーマットして同じ効果をあげる最も一般的な互換性のない要素と提案のリストです。

SELECT percentile(largestContentfulPaint, 75) FROM PageViewTiming WHERE (appId = 837807) SINCE yesterday

SELECT count(foo), average(bar), max(baz) from Transaction

SELECT count(foo) from Transaction

SELECT average(bar) from Transaction

SELECT max(baz) from Transaction

NRQLアラート閾値の例

以下に示すのは、NRQL条件の一般的な使用ケースです。これらのクエリは、静的およびベースラインの条件タイプに動作します。外れ値の条件タイプには、FACET句が追加で必要になります。

SELECT average(duration) FROM Transaction WHERE account_id in (91290, 102021, 20230)

SELECT percentile(duration, 95) FROM Transaction WHERE name LIKE 'Controller/checkout/%'

SELECT percentile(duration, 95) FROM Transaction

SELECT percentile(databaseDuration, 75) FROM Transaction

SELECT max(duration) FROM Transaction

SELECT average(duration) FROM Transaction

SELECT percentage(count(*), WHERE duration > 2) FROM Transaction

SELECT percentage(count(*), WHERE httpResponseCode = '500') FROM Transaction

SELECT apdex(duration, t:0.5) FROM Transaction WHERE appName like '%prod%'

NRQL条件および演算のクエリ順序

デフォルトで、集計ウィンドウの期間は1分ですが、必要に応じてウィンドウは変更できます。集計ウィンドウが何であろうと、New RelicはNRQL条件のクエリの関数を使用して、そのウィンドウのデータを集計します。クエリは構文解析され、以下の順序でシステムによって実行されます。

1. FROM句 – どのイベントタイプを取り込む必要があるのか?
2. WHERE句 – 何を除去できるのか?
3. SELECT句 – 今、フィルタリングしたデータセットから何の情報を返す必要があるのか?

例: 返されたnull値

これがアラート条件クエリとしましょう。

SELECT count(*) FROM SyntheticCheck WHERE monitorName = 'My Cool Monitor' AND result = 'FAILURE'

集計ウィンドウに失敗がない場合:

1. システムは、アカウント上のすべてのSyntheticCheckイベントを取り込んで、FROM句を実行します。
2. 次に、モニター名と指定した結果が一致するもののみを見て、イベントをフィルタリングするWHERE句を実行します。
3. FROMおよびWHERE演算を完了後も、スキャンするイベントが残っている場合は、SELECT句が実行されます。イベントが残っていない場合、SELECT句は実行されません。

つまり、ｇcount()およびuniqueCount()などの集計が、ゼロ値を返すことはありません。カウントが0の場合、SELECT句は無視され、データは返されず、結果値はNULLとなります。

例: 返された値ゼロ

正当な数値ゼロを配信するデータソースがある場合、クエリはnull値ではなく、ゼロ値を返します。

これがアラート条件クエリとし、MyCoolEventが時々ゼロ値を返せる属性としましょう。

SELECT average(MyCoolAttribute) FROM MyCoolEvent

集計ウィンドウが評価されるときに、少なくとも1つのMyCoolEventのインスタンスがあり、そのウィンドウからのすべてのMyCoolAttribute属性の平均値ゼロの場合は、0値が返されます。その間にMyCoolEventイベントがない場合は、演算の順序によりNULLが返されます。

SELECT filter(count(*), WHERE result = 'SUCCESS' AND monitorName = 'My Favorite Monitor') FROM SyntheticCheck

ネスト構造の集計NRQLアラート

ネスト構造の集計クエリは、データに対してクエリを実行する強力な方法です。ただし、注意すべき重要な制限がいくつかあります。

SELECT max(cpu) FROM (FROM Event SELECT min(cpuTime) as cpu) ​​​​​

SELECT max(cpu) FROM (FROM Event SELECT min(cpuTime) as cpu TIMESERIES 30 seconds)​​

NRQL条件作成のヒント

ここに、NRQL条件の作成と使用のヒントをいくつか示します。

条件の編集により、条件の評価をリセットできます

NRQLアラート条件を特定の方法で編集する場合（詳細は以下を参照）、その評価がリセットされます。つまり、その時点までの評価がすべて失われ、その時点から評価をやり直します。これは、次の2つの方法で影響します。

• 「x分以上」の閾値の場合：評価ウィンドウがリセットされたため、違反が報告されるまで少なくともx分の遅延が発生します。
• ベースライン条件の場合：条件を最初からやり直し、すべてのベースライン学習は失われます。

以下のアクションにより、NRQL条件の評価がリセットされます。

• クエリの変更
• 集計ウィンドウ、集計方法、集計遅延/タイマー設定の変更
• 「信号損失時の終了違反」設定の変更
• ギャップ塗りつぶし設定の変更
• ベースラインの方向の変更（該当する場合）– 高、低、または高/低
• 閾値、閾値ウィンドウ、または閾値演算子の変更

以下のアクション（および上記リストに記載されていないその他のアクション）は、評価をリセットしません。

• 信号損失タイムウィンドウ（有効期限）の変更
• 時刻機能の変更（「少なくとも」を「少なくとも1回」に変更する、またはその逆）
• 「信号損失時のオープン違反」設定の切り替え

アラート条件のタイプ

NRQLアラートを作成する際、異なる条件のタイプを選択できます。

クエリ結果の合計（制限または間欠データ）

クエリが間欠的、または限定的なデータを返す場合、意味のある閾値の設定が困難になる可能性があります。欠落したデータや限定的なデータがあると、誤検出または検出漏れを生じることがあります。これらの誤った通知を最小限に抑えるため、信号損失、集計期間、およびギャップ充填設定を使用できます。

この問題を回避するために、静的閾値タイプを使用する際は、セレクタをクエリ結果の合計値に設定できます。こうすることで、単一の収集サイクルからの値の代わりに、集計された合計数に対してアラートを設定できるようになります。1分間のデータ確認は、最長で2時間まで集計できます。移動合計の幅は選択する期間で決まり、それに従ってプレビューチャートが更新されます。

信号損失の閾値を設定

信号損失は、特定の期間にわたってNRQL条件に一致するデータがない場合に発生します。信号損失の閾値期間と、閾値を超えたときに何が起こるかを設定できます。

これらの設定は、GraphQL API（推奨）またはREST APIを使用して管理することもできます。特定のGraph QL APIの例については、こちらを参照してください。

信号損失の設定：

信号損失の設定には、継続時間と2つの可能なアクションが含まれます。

• 信号損失の有効期限

  • UIラベル: 信号は、以下の後で損失します。
  • GraphQLノード: expiration.expirationDuration
  • 有効期限とは、ストリーミングアラートパイプラインでデータポイントを受信すると開始およびリセットされるタイマーです。「有効期限」が切れる前に別のデータポイントを受信しないと、その信号は損失したと見なされます。これは、New Relicにデータが送信されていないか、アラートパイプラインにストリーミングされる前に、NRQLクエリのWHERE句がそのデータを除外しているためです。ファセットクエリがある場合、各ファセットはシグナルであることに注意してください。したがって、これらのシグナルのいずれかが指定期間中に終了すると、シグナルの損失と見なされます。
  • 閾値の有効期限に関係なく、タイマーが期限切れになるとすぐに信号損失がトリガーされます。
  • 最長の有効期限は48時間です。これは、頻度の低いジョブの実行をモニタリングするときに役立ちます。最小は30秒ですが、少なくとも3〜5分に設定することを推奨します。

• 信号損失アクション信号が損失したと見なされると、未解決の違反を閉じるか、新しい違反を開くか、またはその両方を行うことができます。

  • これにより、特定の信号に関連する未解決の違反がすべて終了します。必ずしも、条件のすべての違反が終了するとは限りません。一時的なサービスまたは散発的な信号で警告している場合は、違反が適切に終了するように、このアクションを選択することをお勧めします。この場合、GraphQLノード名は 「closeViolationsOnExpiration」 です。
  • これにより、信号が損失したと見なされると、新しい違反が発生します。これらの違反は、信号の損失が原因であることを示します。インシデントプリファレンスに基づいて、通知がトリガーされます。この場合、graphQLノード名は、「openViolationOnExpiration」 です。
  • 両方のアクションを有効にすると、最初に未解決の違反がすべて終了します。次に、信号が損失すると、新しい違反が発生します。

UIで信号損失検出を使用して設定されたNRQLアラートを作成する場合は、以下の手順に従います。

1. ポリシーについて条件を作成するときは、製品選択でNRQLをクリックしてから、次に、閾値を定義をクリックします。
2. アラートする値を返すNRQLクエリを作成します。
3. 閾値タイプには、静的またはベースラインを選択します。
4. 失われた信号の閾値を追加をクリックし、信号損失後フィールドで信号の有効期限を分または秒で設定します。
5. 信号が失われたときに実行する操作を選択します。現在未解決の違反をすべて閉じると新しい「信号損失」違反を開くのいずれかまたは両方を確認できます。これらのアクションによって、該当する状態に対して信号損失違反がどのように処理されるかが制御されます。
6. 必ず、条件に名前を付けてから保存します。

信号が戻ってくると、信号閉鎖の喪失により、

• 違反が発生します。新しく開かれた信号損失違反は、新しいデータが評価されるとすぐに閉じられます。
• それらが属する条件が期限切れになります。デフォルトでは、条件は3日後に期限切れになります。
• 現在開いているすべての違反を閉じるオプションを使用して、違反を手動で閉じます。

高度な信号設定

NRQL条件を作成する際の高度な信号設定は、次のとおりです。

• 集計ウィンドウの期間
• スライディングウィンドウの集計
• ストリーミング方法
• 遅延/タイマー
• データのギャップを埋める

この設定の内容と、相互の関係の説明を読む場合は、ストリーミングアラートのコンセプトを参照してください。設定方法の説明とヒントは、次のとおりです。

集計ウィンドウの期間

データが集計される前に、ストリーミング時間枠に蓄積されるデータの長さを選択する集計ウィンドウを設定できます。30秒から120分の間で設定できます。デフォルトは1分です。

スライディングウィンドウの集計

スライディングウィンドウを使用すると、より滑らかなチャートを作成できます。これを行うには、データの重複ウィンドウを作成します。

有効にしたら、継続時間別にスライドを設定して、集計ウィンドウのオーバーラップ時間を制御します。継続時間別のスライドは、集計ウィンドウの長さよりも短く、均等に分割する必要があります。

ストリーミング方法

3つのストリーミング集計方法から選択して、条件に最適な評価結果を得ることができます。

遅延/タイマー

遅延/タイマーを調整して、データの動作に合わせてストリーミングアラートアルゴリズムを調整できます。データがまばらであるか一貫性がない場合は、イベントタイマー集計法を使用することをお勧めします。

ケイデンス集計法では、サポートされる合計レイテンシは、集計ウィンドウ期間と遅延の合計になります。

データタイプがAPMの言語エージェントから供給されており、多数のアプリケーションインスタンス（例：Transactions、TransactionErrorsなど）から集計されている場合は、デフォルト設定でイベントフロー法を使用することをお勧めします。

データのギャップを埋める

ギャップの充填を使用すると、信号にデータがない場合に使用する値をカスタマイズできます。次の設定の1つを使用して、データストリームのギャップを埋めることができます。

• なし: デフォルト）空の集計ウィンドウでアクションを実行したくない場合は、これを選択します。評価時に、空の集計ウィンドウは閾値期間タイマーをリセットします。たとえば、すべての集計ウィンドウに5分間の閾値を超えるデータポイントが必要であり、5つの集計ウィンドウの1つが空であるという条件が設定されている場合は、条件に違反することはありません。
• カスタム静的値: 評価する前に空の集計ウィンドウにカスタム静的値を挿入する場合は、これを選択します。このオプションには、（APIで指定されたとおり）使用する静的値を指定する追加の必須fillValueパラメーターがあります。この値のデフォルトは0です。
• 最後の既知値: このオプションは、評価が行われる前に最後に表示された値を挿入します。最後に表示された値の状態は2時間維持されます。

データギャップ設定を編集するオプション：

• NRQL条件UIで、条件設定 > 高度な信号設定 > データギャップを埋めるの順に移動し、オプションを選択します。
• Nerdgraph API (優先)を使用中の場合は、このノードはここにあります。actor : account : alerts : nrqlCondition : signal : fillOption | fillValue
• NerdGraphは推奨APIですが、REST APIを使用している場合、この設定はアラートNRQL条件APIの「信号」セクションにあるREST APIエクスプローラーにあります。