• /
  • ログイン

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

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

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

NRQL条件および生成された結果の例のスクリーンショット。

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

ヒント

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

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

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

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

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

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

チャートからのNRQLアラート条件の作成方法を示すGIF動画。

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

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

注意

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

NRQLアラートの構文

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

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

メモ

SELECT関数(属性)

必須

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

  • apdex

  • average

  • count

  • latest

  • max

  • min

  • percentage

  • percentile

  • sum

  • uniqueCount

    ヒント

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

    チャートデータをフェッチ中にエラーが発生しました。

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

FROMデータ型

必須

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

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

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

WHERE属性 [比較] [AND|OR ...]

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

FACET属性

外れ値条件に必要

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

属性別で結果を区切り、各属性に個別のアラートを設定する場合は、FACET句を使用します。LIMIT句は許可されていませんが、すべてのクエリは可能な限り最大数のファセットを受け取ります。ファセットクエリは、静的およびベースライン条件には最大5000の値を、外れ値条件には最大500の値を返せます。

重要

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

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

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

要素

メモ

SINCEおよびUNTIL

例:

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

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

TIMESERIES

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

NRQLアラートの場合は、信号の同等のプロパティが集計ウィンドウです。

histogram()

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

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

複数集計関数

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

元のクエリ:

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データは、互いに重複する時間の「ウィンドウ」に収集されます。これらのウィンドウは、移動集計(移動平均など)が狭い時間枠からの集計よりも重要である場合に、変動の多い折れ線グラフを滑らかにするのに役立ちます。

スライディングウインドウは、NRQLアラートでは現在サポートされていません。

LIMIT:

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

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

NRQLアラート閾値の例

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

アラート条件および演算のクエリ順序

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

  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句は実行されません。

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

例: 返された値ゼロ

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

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

SELECT average(MyCoolAttribute) FROM MyCoolEvent

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

ヒント

このトピックの詳細については、ゼロ値対null値のトラブルシューティングに関するブログ投稿をチェックできます。

ヒント

信号の損失を調整およびアラート条件UIの設定のギャップを埋めて、null値がどのように取り扱われるかを判断できます。

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

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

NRQL条件作成のヒント

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

トピック

ヒント

条件閾値のタイプ

NRQLの条件閾値タイプには 静的、ベースライン、外れ値が含まれます。

説明を作成する

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

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

クエリの結果

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

期間

すべてのアラート条件と同様に、NRQL条件は1回に1分の評価をします。どの1分を評価するかを指定する暗黙的なSINCE ... UNTIL句は、評価オフセット設定により制御されています。直近のデータは不完全なことがあるため、特に次のような場合は、3分以上前のデータのクエリをする場合があります。

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

  • SyntheticCheckデータ: タイムアウトは3分かかる場合があるため、5分以上前のデータのクエリを推奨します。

    さらに、クエリによって生成されるデータが断続的な場合、クエリ結果の合計オプションの使用を検討してください。

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

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

高度な信号設定

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

条件設定

条件設定を使用

条件の制限

最大値を参照します。

稼働ステータス

NRQLアラート条件は、エンティティの稼働ステータス表示には影響を与えません。

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

アラートの閾値タイプ

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

NRQLアラートの閾値タイプ

説明

静的

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

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

ベースライン(動的)

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

外れ値

グループの外れ値になるそのグループの動作と値を検索します。静的タイプと同じNRQLクエリ形式を使用しますが、FACET句が必要です。

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

重要

静的(基本)閾値タイプのみで使用できます。

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

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

信号損失の閾値を設定

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

signal-loss-ui.png

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. 必ず、条件に名前を付けてから保存します。

ヒント

信号損失検出は、ネスト型の集計またはサブクエリを使用するNRQLクエリでは機能しません。

高度な信号設定

screenshot_advanced_signal_settings.png

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

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

  • 集計ウィンドウ
  • 評価オフセット
  • データのギャップを埋める

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

集計ウィンドウ

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

ヒント

ベースラインアラート条件の閾値は、集計ウィンドウの編集をサポートしていません。デフォルトでは1分が使用されます。

評価オフセット

評価オフセットを調整して、データのレイテンシに合わせてストリーミングアルゴリズムを調整できます。データが到着するまでに時間がかかる場合は、評価オフセットを増やす必要があります。

サポートされているレイテンシの合計は、集計ウィンドウ期間と評価オフセットの積になります。上のスクリーンショットの例では、サポートされているレイテンシは3分です(1分の集計ウィンドウが3つ)。

データタイプがAPMの言語エージェントから供給されており、多数のアプリケーションインスタンス(例:TransactionsTransactionErrorsなど)から集計されている場合は、1分間の集計ウィンドウで3分の評価オフセットを使用することを推奨します。

重要

AWS CloudwatchやAzureなどのインフラストラクチャクラウドインテグレーションから収集されたデータのNRQL条件を作成する場合は、15分の評価オフセットから始めて、データの収集にかかる時間に応じて上下に調整することを推奨します。

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

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

その他のヘルプ

さらに支援が必要な場合は、これらのサポートと学習リソースを確認してください:

問題を作成するこのページを編集する
Copyright © 2020 New Relic Inc.