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

アラートの作成には、NRQLアラート条件を使用することを推奨します。このドキュメントでは、効率を最大化し、ノイズを削減するNRQLアラート条件のフォーマットと構成について説明します。New Relicを使い始めたばかりの場合や、まだアラート条件を作成していない場合は、アラート条件から始めることをおすすめします。

アラート条件は以下から作成できます。

• チャート
• ポリシーページ
• Alert coverage gapsページ

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

• Write your own queryを使用して、アラートをゼロから作成する。
• Use Guided mode推奨オプションから選択して、NRQLクエリを構築する。

アラート条件の作成をチャートで開始するか自身でクエリを記述するかに関わらず、NRQLはシグナルを定義して閾値を設定できる基礎ブロックとなります。

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 min(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
  (
    SELECT min(cpuPercent) AS 'cpu'
    FROM SystemSample
    FACET hostname
  )

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

NRQL条件作成のヒント

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

条件のタグの管理

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

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

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

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

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

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

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

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

アラート条件のタイプ

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

信号損失の閾値を設定

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

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

Loss of signal settings:

信号損失設定では、期間と複数のアクションを設定します。

• 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です。
  • 上記の両方のアクションを有効にすると、最初に未解決のインシデントがすべて終了します。次に、信号が損失すると、新しいインシデントが発生します。
  • 予想どおりに終了した場合は「信号喪失」インシデントを開かないでください。信号が終了すると予想される場合は、新しいインシデントを開かないように設定できます。これは、特定のタイミングで信号損失が発生することがわかっていて、その信号損失に対して新しいインシデントを開きたくない場合に便利です。このGraphQLノード名はignoreOnExpectedTerminationです。

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

1. 指示に従ってNRQLアラート条件を作成します。
2. Set thresholdsステップにAdd lost signal thresholdのオプションがあります。 このボタンをクリックします。
3. Consider the signal lost afterフィールドで信号の有効期限を分または秒単位で設定します。
4. 信号が失われたときに実行する操作を選択します。Close all current open incidents、Open new "lost signal" incident、Do not open "lost signal" incident on expected terminationのオプションのいずれかまたはすべてを設定できます。これらのアクションによって、該当する状態に対して信号損失インシデントがどのように処理されるかが制御されます。
5. オプションで、静的閾値または異常閾値を追加・削除できます。信号損失閾値のみが設定されていて、静的閾値または異常閾値が設定されていない状態は有効であり、「スタンドアロン」の信号損失状態と見なされます。

6. 引き続き手順を進め、状態を保存します。
7. Do not open "lost signal" incident on expected terminationを選択した場合は、信号損失インシデントの発生を防ぐため、エンティティにtermination: expectedタグを追加する必要があります。詳細についてはエンティティにタグを直接追加する方法を参照してください。

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

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

高度な信号設定

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

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

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

集計ウィンドウの期間

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

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

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

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

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

ストリーミング方法

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

遅延/タイマー

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

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

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

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

ギャップの充填を使用すると、信号にデータがない場合に使用する値をカスタマイズできます。次の設定の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

ガイドモードでのHNR NRQL条件

NRQL条件ガイドモードでは、インフラストラクチャの「ホストが報告しない」（HNR）NRQL条件を作成するためのキュレートされたエクスペリエンスが提供されます。これは、インフラストラクチャの「ホストのレポートなし」条件を作成する代替手段として推奨される方法です。