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

We recommend creating an alert using a NRQL alert condition. This doc will guide you through formatting and configuring your NRQL alert conditions to maximize efficiency and reduce noise. If you've just started with New Relic, or you haven't created an alert condition yet, we recommend starting with Alert conditions.

You can create an alert condition from:

• チャート

• ポリシーページ

• Alert coverage gaps

  ページ

次のアラートビルダーのいずれかを使用することもできます。

• Use

  Write your own query

  to build alerts from scratch.

• Use Guided mode

  to choose from recommended options and have your NRQL query built for you.

No matter where you begin creating an alert condition, whether through a chart or by writing your own query, NRQL is the building block upon which you can define your signal and set your thresholds.

NRQLアラートの構文

すべてのNRQLアラート条件を作成するための基本的な構文は、以下のとおりです。

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

SELECT count(*) from Transaction TIMESERIES 1 minute SLIDE BY 5 minutes

NRQLアラート閾値の例

以下に示すのは、NRQL条件の一般的な使用ケースです。これらのクエリは、静的および異常の条件タイプにおいて動作します。

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 http.statusCode = '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 = 'FAILED'

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

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が返されます。

例: 返されたnull値対ゼロ値

null値の処理方法を決定するには、アラート条件UIで信号損失とギャップ充填の設定を調整します。

NULL値を完全に回避するには、クエリ操作のショートカット順序を使用します。これを行うには、filterのサブ句を使用してから、そのサブ句内にすべてのフィルター要素を含めます。クエリの本文には、1つ以上のエンティティを定義するWHERE句を含める必要があります。モニターがチェックを実行する集計ウィンドウの場合、信号はそのエンティティに関連付けられます。その後、SELECT句が実行され、クエリの本文によって返されるデータにフィルタ要素を適用します。フィルタ要素に一致するデータがない場合、0の値が返されます。

FAILEDの結果に関するアラートの例を以下に示します。

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

この例では、成功した結果を伴うウィンドウは0を返します。これにより、条件の閾値は単独で解決されます。

詳細については、ゼロ値対null値のトラブルシューティングに関するブログ投稿をご覧ください。

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

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

SELECT max(cpu) FROM (FROM SystemSample SELECT min(cpuPercent) as 'cpu' FACET hostname) ​​​​

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

NRQL条件作成のヒント

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

条件のタグの管理

既存のNRQL条件を編集する場合、条件エンティティに関連付けられたタグを追加または削除することができます。これを行うには、条件名の下にあるManage tagsボタンをクリックします。ポップアップ表示されるメニューで、タグを追加または削除します。

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

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

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

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

• クエリの変更
• 集計ウィンドウ、集計方法、集計遅延/タイマー設定の変更
• 「信号損失時の終了インシデント」設定の変更
• ギャップ塗りつぶし設定の変更
• 異常方向の変更（該当する場合）– 高、低、または高/低
• 閾値、閾値ウィンドウ、または閾値演算子の変更
• スライドごとの間隔を変更する（スライディングウィンドウの集計条件のみ）

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

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

アラート条件のタイプ

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

信号損失の閾値を設定

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

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

Loss of signal settings:

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

• Signal loss expiration time

  • UIラベル：

    Signal is lost after:

  • GraphQLノード: expiration.expirationDuration

  • 有効期限とは、ストリーミングアラートパイプラインでデータポイントを受信すると開始およびリセットされるタイマーです。「有効期限」が切れる前に別のデータポイントを受信しないと、その信号は損失したと見なされます。これは、New Relicにデータが送信されていないか、アラートパイプラインにストリーミングされる前に、NRQLクエリのWHERE句がそのデータを除外しているためです。ファセットクエリがある場合、各ファセットはシグナルであることに注意してください。したがって、これらのシグナルのいずれかが指定期間中に終了すると、シグナルの損失と見なされます。

  • 閾値の有効期限に関係なく、タイマーが期限切れになるとすぐに信号損失がトリガーされます。

  • 最長の有効期限は48時間です。これは、頻度の低いジョブの実行をモニタリングするときに役立ちます。最小は30秒ですが、少なくとも3〜5分に設定することを推奨します。

• Loss of signal actions

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

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

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

1. ポリシーについて条件を作成するときは、

   Select a product

   で

   NRQL

   をクリックしてから、

   Next, define thresholds

   をクリックします。

2. アラートする値を返すNRQLクエリを作成します。

3. Threshold type

   には、

   Static

   または

   Anomaly

   を選択します。

4. + Add lost signal threshold

   をクリックし、

   Consider the signal lost after

   フィールドで信号の有効期限を分または秒で設定します。

5. 信号が失われたときに実行する操作を選択します。

   Close all current open incidents

   と

   Open new "lost signal" incident

   のいずれかまたは両方を確認できます。これらのアクションによって、該当する状態に対して信号損失インシデントがどのように処理されるかが制御されます。

6. 必ず、条件に名前を付けてから保存します。

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

• インシデントが発生します。新しく開かれた信号損失インシデントは、新しいデータが評価されるとすぐに閉じられます。

• それらが属する条件が期限切れになります。デフォルトでは、条件は3日後に期限切れになります。

• Close all current open incidents

  オプションを使用して、インシデントを手動で閉じます。

高度な信号設定

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

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

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

集計ウィンドウの期間

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

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

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

この短いビデオでスライディングウィンドウの設定方法を紹介します（2分30秒）。

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

ストリーミング方法

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

遅延/タイマー

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

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

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

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

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

• None

  ：（デフォルト）空の集計ウィンドウでアクションを実行したくない場合は、これを選択します。評価時に、空の集計ウィンドウは閾値期間タイマーをリセットします。たとえば、すべての集計ウィンドウに5分間の閾値を超えるデータポイントが必要であり、5つの集計ウィンドウの1つが空であるという条件が設定されている場合は、その条件はインシデントにはなりません。

• Custom static value

  ：評価する前に空の集計ウィンドウにカスタム静的値を挿入する場合は、これを選択します。このオプションには、（APIで指定されたとおり）使用する静的値を指定する追加の必須fillValueパラメーターがあります。この値のデフォルトは0です。

• Last known value

  : このオプションは、評価が行われる前に最後に表示された値を挿入します。最後に表示された値の状態は最低2時間維持されます。設定された閾値の期間が2時間を超える場合、代わりにこの値がその期間に保持されます。

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

• NRQL条件UIで、

  Condition settings > Advanced signal settings > fill data gaps with

  に移動し、オプションを選択します。

• Nerdgraph API（推奨）を使用している場合、このノードは次の場所にあります： actor : account : alerts : nrqlCondition : signal : fillOption | fillValue

• NerdGraphは推奨APIですが、REST APIを使用している場合、この設定はアラートNRQL条件APIの

  "signal"

  セクションにあるREST APIエクスプローラーにあります。

評価遅延

Use evaluation delayフラグを有効にし、最大120分を設定して、受信信号の評価を遅らせることができます。

新しいエンティティが最初にデプロイされると、そのエンティティのリソース使用率が異常に高くなることがよくあります。オートスケール環境では、誤ったアラートが多数作成されやすくなります。新しいエンティティから発信された信号のアラート検出の開始を遅らせることで、オーケストレーション環境またはオートスケール環境でのデプロイメント関連の誤警報の数を大幅に減らすことができます。

評価遅延を有効にするオプション：

• NRQL条件UIで、

  Adjust to signal behavior > Use evaluation delay

  に移動します。

• Nerdgraph APIを使用している場合、このノードは次の場所にあります： actor : account : alerts : nrqlCondition : signal : evaluationDelay