• ログイン今すぐ開始

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

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

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

one.newrelic.comへ移動します。アラートおよびAIをクリックし、左のサイドバーでアラート条件(ポリシー)をクリックしてポリシーを選択してから、条件を追加を選択します。NRQL次に、閾値を定義の順にクリックします。

ヒント

NRQLアラート条件とストリーミングアラートに関連する主要概念の詳細については、ストリーミングアラート:キー条件および概念を参照してください。

始める準備はできていますか?まだお持ちでない場合は、New Relicアカウントにサインアップしてください。永久無料です。

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

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

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

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

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

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

チャートからNRQLアラート条件を作成するには、チャートメニューをクリックしてから、アラート条件の作成をクリックします。

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

注意

少数の旧チャートには、アラート条件を作成するオプションは含まれません。

NRQLアラートの構文

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

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

メモ

SELECT function(attribute)

必須

数字を返すサポートされている関数は、以下のとおりです。

  • apdex

  • average

  • count

  • latest

  • max

  • min

  • percentage

  • percentile

  • sum

  • uniqueCount

    ヒント

    多くのファセットを含むファセットアラート条件でpercentile集計を使用すると、以下のエラーメッセージが表示される可能性があります。

    An error occurred while fetching chart data.

    このエラーが表示される場合は、代わりにaverageを使用します。

FROM data type

必須

1つのデータ型のみをターゲットにできます。

サポートされているデータ型:

  • Event
  • Metric (RAWデータポイントが返されます)

WHERE attribute [comparison] [AND|OR ...]

1つ以上の一連の条件を指定する場合は、WHERE句を使用します。すべての演算子がサポートされています。

FACET 属性

オプションのFACET句をNRQL構文に含めるかどうかは、閾値タイプ(静的またはベースライン)によって決まります。

属性別で結果を区切り、各属性に個別のアラートを設定する場合は、FACET句を使用します。LIMIT句は許可されていませんが、すべてのクエリは可能な限り最大数のファセットを受け取ります。

ファセットクエリは、静的およびベースライン条件には最大5000の値を返せます。

重要

クエリが最大数を上回る値を返す場合、アラート条件は作成できません。条件を作成した後、クエリがこの数以上の値を返した場合、アラートは失敗します。返される値の数が少なくなるようにクエリを変更します。

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

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

要素

メモ

SINCE および UNTIL

例:

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

NRQL条件は決して途切れないウィンドウ表示されたクエリ結果を生成するため、ある時点までクエリを調べるSINCEおよびUNTILキーワードは互換性がありません。便宜上、チャートのコンテキストから条件を作成するときに、クエリから自動的にSINCEおよびUNTILを外します。

TIMESERIES

NRQLクエリでは、TIMESERIES句を使用して、指定期間単位の時系列としてデータを返します。

NRQL条件の場合は、信号の同等のプロパティが集計期間ウィンドウです。

histogram()

histogram()集計関数は、ヒストグラムを生成するために使用されます。

histogram() はNRQLアラートとは互換性がなく、ヒストグラム集計は時系列としてフォーマット化できません。ヒストグラムの一部(95番目のパーセンタイルなど)からアラートを作成するには、percentile()集計関数を使用します。

bytecountestimate()cardinality()

これらの機能は、NRQLアラートではまだサポートされていません。

複数集計関数

各条件は単一の集計値のみをターゲットにできます。複数の値に同時にアラートするには、同じポリシー内の個別条件に分解する必要があります。

元のクエリ:

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

分解済み:

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

COMPARE WITH

COMPARE WITH句を使用して、2つの異なる時間範囲の値を比較します。このタイプのクエリはNRQLアラートとは互換性がありません。ベースラインアラート条件を使用して、特定の信号の偏差を動的に検出することを推奨します。

SLIDE BY

SLIDE BY句は、スライディングウィンドウと呼ばれる機能をサポートしています。スライディングウィンドウを使用すると、SLIDE BYデータは、互いに重複する時間の「ウィンドウ」に収集されます。これらのウィンドウは、移動集計(移動平均など)が狭い時間枠からの集計よりも重要である場合に、変動の多い折れ線グラフを滑らかにするのに役立ちます。

UIでスライディングウィンドウを有効にすることができます。条件を作成または編集する場合は、Fine-tune advanced signal settings(高度な信号設定を微調整) > Data aggregation settings(データ集計の設定) > Use sliding window aggregation(スライディングウィンドウの集計を使用)に移動します。

LIMIT

LIMIT句を使用して、FACETクエリで返されるファセット値の最大数またはSELECT *クエリで返される項目の最大数を管理します。

LIMITはNRQLアラートとは互換性がありません。常に、評価はフル結果セットに対して実行されます。

NRQLアラート閾値の例

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

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

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

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

NULL値を完全に回避するには、クエリ操作のショートカット順序を使用します。これを行うには、filterのサブ句を使用してから、そのサブ句内にすべてのフィルター要素を含めます。クエリの本体が実行され、データが返されます。その際、SELECT句が実行され、フィルター要素が適用されます。フィルター要素に一致するデータがない場合、クエリは0の値を返します。次の例を見てみましょう。

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

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

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

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

NRQL条件作成のヒント

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

トピック

ヒント

条件タイプ

NRQLの条件タイプには静的およびベースラインが含まれます。

説明を作成する

NRQL条件の場合、各違反に追加されるカスタムの説明を作成できます。これらの説明は、特定の違反に関連付けられたメタデータに基づく変数置換を強化します。

詳細については、説明を参照してください。

クエリの結果

クエリは数値を返す必要があります。条件は、返された数値とお客様が設定した閾値を比較することで評価されます。

期間

NRQL条件は、30秒から120分までの集計ウィンドウを15秒刻みで使用して、どのように集計されるかに基づいてデータを評価します。最良の結果を得るには、イベントフローまたはイベントタイマーの集計法を使用することを推奨します。

ケイデンス集計法の場合、どの1分を評価するかを指定する暗黙的なSINCE ... UNTIL句は、遅延/タイマー設定により制御されています。直近のデータは不完全なことがあるため、特に次のような場合は、3分以上前のデータのクエリをする場合があります。

  • 複数のホスト上で動作するアプリケーション。

  • SyntheticCheck データ:タイムアウトは3分かかる場合があるため、5分以上前のデータをクエリするとよいでしょう。

    さらに、クエリによって生成されるデータが断続的な場合、高度な信号設定のslide byオプションの使用をご検討ください。

信号損失の閾値(信号損失検出)

信号損失検出を使用すると、データ(テレメトリ信号)が失われたと見なされる時点でアラートを出力できます。サービスまたはエンティティがオンラインではなくなったか、定期的なジョブの実行に失敗した可能性を示しています。エラーカウントなどの散発的なデータ違反が、信号を受信していないときに確実に終了するためにも使用できます。

高度な信号設定

この設定で、場合によってはない継続的なストリーミングデータ信号の取り扱いを改善するオプションを使用できます。この設定には、集計ウィンドウの期間と遅延/タイマー、データギャップを埋めるオプションが含まれます。これらの使用の詳細については、高度な信号設定を参照してください。

条件設定

条件設定を使用

条件の制限

最大値を参照します。

稼働ステータス

NRQLアラート条件の稼働ステータス表示を適切に機能させるには、クエリを単一のエンティティに設定する必要があります。これを行うには、WHERE句(例:WHERE appName = 'MyFavoriteApp')を使用するか、FACET句を使用して各信号を単一のエンティティに設定します(例:FACET hostnameまたはFACET appName)。

詳細については、以下を参照してください。

条件のタグの管理

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

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

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

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

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

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

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

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

アラート条件のタイプ

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

NRQLアラート条件のタイプ

説明

静的

これは、最もシンプルなNRQL条件のタイプです。数値を返すNRQLクエリに基づいた条件を作成できます。

オプション:FACET句を含む。

ベースライン(動的)

監視対象値の過去の動作に基づいた自己調整型の条件を使用します。オプションのFACET句など、静的タイプと同じNRQLクエリ形式を使用します。

信号損失の閾値を設定

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

one.newrelic.comへ移動します。アラートおよびAIをクリックし、左のサイドバーでアラート条件(ポリシー)をクリックしてポリシーを選択してから、条件を追加を選択します。信号損失は、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クエリでは機能しません。

高度な信号設定

NRQLアラート条件を作成すると、高度な信号設定により、ストリーミングアラートデータを管理し、誤検出を防止できます。

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

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

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

集計ウィンドウの期間

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

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

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

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

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

重要

スライディングウィンドウのアラート条件を新規作成するか、または評価リセットを引き起こす可能性のあるアクションを実行した直後、最初の集計ウィンドウの期間中の条件に「集約バッファ」を構築する時間が必要になります。その間、違反はトリガーされません。単一の集計ウィンドウが経過すると、完全な「バッファ」が構築されて、条件は正常に機能します。

ストリーミング方法

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

遅延/タイマー

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

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

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

重要

AWS CloudwatchやAzureなどのInfrastructureクラウドインテグレーションから収集したデータに対してNRQL条件を作成する場合は、イベントタイマー法を使用することをお勧めします。

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

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

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

ヒント

アラートシステムは、アクティブに報告された信号のギャップを埋めます。この信号の履歴は、2時間操作が行われないと失われます。ギャップを埋めるために、この非アクティブ期間の後に受信されたデータポイントは新しい信号として扱われます。

信号損失、ギャップの充填、アクセスをリクエストする方法の詳細については、このExplorers Hubの記事を参照してください。

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

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