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

この機械翻訳は、参考として提供されています。

In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.

問題を作成する

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

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

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

one.newrelic.com > All capabilities > Alerts & AI > Alert conditions (Policies) > (select a policy) > Add a conditionNRQLをクリックし、Next, define thresholdsをクリックします。

ヒント

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

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

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

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

  1. one.newrelic.com > All capabilities > Alerts & AI > Alert conditions (policies)

    に移動します。

  2. 既存のポリシーを選択するか、

    New alert policy

    をクリックして新しいポリシーを作成します

  3. Add a condition

    をクリックします。

  4. Select a product

    の下で

    NRQL

    をクリックし、次に

    Next, define thresholds

    をクリックします。

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

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

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

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

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

注意

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

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

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

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

  • Event
  • 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条件の場合は、信号の同等のプロパティが集計期間ウィンドウです。

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 条件は、15 秒刻みで 30 秒から 6 時間までの集計ウィンドウを使用して、データの集計方法に基づいてデータを評価します。 最良の結果を得るには、イベント フローまたはイベント タイマーの集計方法を使用することをお勧めします。

ケイデンス集計方法の場合、評価する分を指定する暗黙のSINCE ... UNTIL句は、 delay/timer設定によって制御されます。 最新のデータは不完全な場合があるので、特に以下の場合には 3 分以上前のデータをクエリすることをお勧めします。

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

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

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

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

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

高度な信号設定

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

条件設定

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

条件の制限

最大値を参照します。

健康状態

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

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

条件のタグの管理

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

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

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

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

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

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

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

  • 信号損失タイムウィンドウ(有効期限)の変更

  • 時間関数の変更(

    for at least

    at least once in

    に切り替える、またはその逆)

  • Add lost signal threshold

    を設定しています。

アラート条件のタイプ

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

NRQLアラート条件のタイプ

説明

静的

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

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

異常(動的な異常)

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

信号損失の閾値を設定

重要

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

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

one.newrelic.com > All capabilities > Alerts & AI > Alert conditions (Policies) > (select a policy)に移動し、次にAdd a 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

    をクリックし、

    Signal is 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時間操作が行われないと失われます。ギャップを埋めるために、この非アクティブ期間の後に受信されたデータポイントは新しい信号として扱われます。

シグナル ロス、ギャップ フィリング、およびこれらの機能へのアクセスをリクエストする方法の詳細については、 このサポート フォーラムの投稿を参照してください。

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

  • 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エクスプローラーにあります。

Copyright © 2024 New Relic株式会社。

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