• EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

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

NRQLクエリを使用してアラート条件を作成できます。信号を定義した後、警告とクリティカルな閾値レベルをさらに定義できます。これでアラートインシデントを作成するタイミングが決定されます。NRQLアラート条件とストリーミングアラートに関連する主要概念の詳細については、ストリーミングアラート:キー条件および概念を参照してください。

ポリシーからNRQLアラート条件の作成

one.newrelic.com > All capabilities > Alerts & AI > Alert Conditions & Policiesに移動して、ポリシーからNRQLアラート条件を作成します。次に、+ New alert conditionをクリックします。

one.newrelic.com > All capabilities > Alerts & AI > Alert Conditions & Policies > + New alert conditionに移動します。

以下のステップに従ってください。

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

古いものを除き、チャートのほとんどで、条件を作成できます。

チャートからNRQLアラート条件を作成するには:

  1. one.newrelic.com > All capabilities > APM & Servicesに移動してアプリを選択します。

  2. 左側のペインで、Metrics explorerを選択し、設定を追加します。

  3. チャートの右隅にあるアイコンをクリックし、Create alert conditionを選択します。

  4. ポリシーからNRQLアラート条件を作成で説明されている手順に従いますが、以前に設定したデータでクエリが作成されるため、手順1が少し異なることに注意してください。

NRQLアラートの構文

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

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

Clause

Notes

SELECT function(attribute)

Required

数字を返すサポート対象の関数は、以下のとおりです。

  • apdex

  • average

  • count

  • latest

  • max

  • min

  • percentage

  • percentile

  • sum

  • uniqueCount

    ヒント

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

    An error occurred while fetching chart data.

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

FROM data type

Required

複数のデータ型をターゲットにできます。

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

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

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

1つ以上の一連の条件を指定する場合は、WHERE句を使用します。すべての演算子がサポートされています。これを使用して、クエリで返されたデータを絞り込みます。

FACET 属性

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

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

ファセットクエリは、静的および異常条件には最大5000の値を返せます。

重要

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

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

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

Element

Notes

SINCE および UNTIL

例:

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

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

TIMESERIES

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

NRQL条件の場合、およびスライディングウィンドウ集計を使用しない場合、TIMESERIESと同等のプロパティはデータ集計ウィンドウの期間です。スライディングウィンドウ集計を使用している場合、同等のプロパティはスライディングウィンドウ集計の値です。

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でスライディングウィンドウを有効にすることができます。条件を作成または編集するときは、Adjust to signal behavior > Data aggregation settings > Use sliding window aggregationの順に移動します。

たとえば、以下と同等のアラート条件を作成するには、

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

データ集計ウィンドウ期間を5分、スライディングウィンドウ集計を1分として使用します。

LIMIT

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

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

サブクエリ

サブクエリの実行にはデータを介しての複数のパスが必要なため、サブクエリはストリーミングと互換性がありません。

サブクエリのJOIN

サブクエリの実行にはデータを介しての複数のパスが必要なため、サブクエリのJOINはストリーミングアラートと互換性がありません。

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 = '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アラート

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

NRQL条件作成のヒント

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

トピック

ヒント

条件タイプ

NRQLの条件タイプには静的および異常が含まれます。

説明を作成する

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

クエリの結果

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

期間

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

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

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

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

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

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

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

高度な信号設定

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

条件設定

Condition settingsを使用して次のことを行います。

  • 簡潔で分かりやすい条件名を作成します。

  • インシデントと通知に含まれる

    Add details

    ページの条件について、カスタムインシデントの説明を記入します。

  • インシデント対応に関する自社の手順を含めるには、ランブックのURLを追加します。この情報をカスタムインシデントの説明に追加することもできます。

条件の制限

最大値を参照します。

稼働ステータス

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

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

条件のタグの管理

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

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

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

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

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

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

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

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

アラート条件のタイプ

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

NRQLアラート条件のタイプ

説明

静的

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

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

異常(動的な異常)

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

信号損失の閾値を設定

重要

信号損失機能では、信号が失われたことを検出する前に、信号が存在する必要があります。信号が存在しない状態で条件を有効にすると、信号の損失は検出されず、信号損失機能はアクティブ化されません。

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

one.newrelic.com > All capabilities > Alerts & AI > Alert conditions (Policies)に移動し、次に+ New alert conditionに移動します。信号損失は、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クエリでは機能しません。

高度な信号設定

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

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

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

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

集計ウィンドウの期間

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

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

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

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

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

重要

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

ストリーミング方法

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

遅延/タイマー

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

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

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

重要

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

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

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

  • None

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

  • Custom static value

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

  • Last known value

    : このオプションは、評価が行われる前に最後に表示された値を挿入します。最後に表示された値の状態は最低2時間維持されます。設定された閾値の期間が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

Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.