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

NRQLクエリを使用してアラート条件を作成できます。このリソースには、NRQLアラート条件の作成に関する情報が含まれています。

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

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

NRQLアラート条件を作成するには:条件の作成を開始すると、製品を選択がプロンプト表示されるので、NRQLを選択します。

NRQL条件の作成と使用のヒント:

トピック ヒント
条件タイプ

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

説明を作成する

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

クエリの結果 クエリは数値を返す必要があります。条件の仕組みは、返された数値とお客様が設定した閾値を比較診断することで行われます。
期間

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

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

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

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

信号喪失

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

信号喪失の設定:

  • 信号損失の有効期限
    • UI ラベル:次の期間が経過すると信号が喪失する:
    • GraphQL ノード:expiration.expirationDuration
    • これは、ストリーミング アラート パイプラインでデータポイントを受信すると開始およびリセットされるタイマーです。「有効期限」が切れる前に別のデータポイントを受信しないと、その信号は喪失したと見なされます。
    • 閾値の有効期限に関係なく、タイマーが期限切れになるとすぐに信号喪失がトリガーされます。
    • 最長の有効期限は48時間です。これは、頻度の低いジョブの実行をモニタリングするときに役立ちます。
  • 信号喪失アクション
    信号が喪失したと見なさると、2つのオプションを使用できます。一方のオプションまたは両方のオプションを選択できます。
    • 現在、未解決の違反をすべて終了します。これにより、この特定の信号に関連する未解決の違反がすべて終了します。必ずしも、条件のすべての違反が終了するとは限りません。一時的なサービスまたは散発的な信号で警告している場合は、違反が適切に終了するように、このアクションを選択することをお勧めします。この場合、graphQLノード名は "closeViolationsOnExpiration " です。
    • 未解決の新しい違反:これにより、信号が喪失した見なされると、新しい違反が発生します。これらの違反は、信号の損失が原因であることを示します。インシデントプリファレンスに基づいて、通知がトリガーされます。この場合、graphQLノード名は、"openViolationOnExpiration" です。
    • 両方のアクションを有効にすると、最初に未解決の違反がすべて終了します。次に、信号が喪失すると、新しい違反が発生します。

信号の喪失とアクセスを要求する方法の詳細については、この発表を参照してください。

条件設定

条件設定を使用することで:

  • 簡潔で分かりやすい条件名を作成します。
  • 集計ウィンドウの期間を設定します。データが集計される前に、ストリーミング時間枠に蓄積されるデータの長さを選択します。最小の集計ウィンドウは30秒で、最大は15分です。デフォルトのストリーミング集計ウィンドウの期間は1分です。
  • 評価オフセットを調整します。
  • ギャップをデータで埋めるかどうか、および使用する値を選択します。

    ギャップを埋め、アクセスをリクエストする方法の詳細については、この発表を参照してください。

  • 違反と通知に含まれる条件について、テキストによる説明を記入します。
  • 信号には、データを含まない集計ウィンドウが存在する場合があります。この場合、評価対象のデータにギャップが生じます。この機能を使用すると、最後に認識された値または選択したカスタム値でデータのギャップを埋めることができます。カスタム値としてゼロを使用するのが一般的です。デフォルトの動作では、ギャップを空のままにすることで、評価期間のタイマーが再開されます。

トラブルシューティング手順

オプション:インシデント対応に関する自社の手順を含めるには、条件にランブックのURLを追加します。

条件の制限 最大値を参照します。
稼働ステータス NRQLアラート条件は、エンティティの稼働ステータス表示には影響を与えません。

詳細については、以下をご覧ください。

アラートの閾値タイプ

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

NRQLアラートの閾値タイプ 説明
静的

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

オプション:FACET句を含める。

ベースライン
(動的)
監視対象値の過去の動作に基づいた自己調整型の条件を使用します。FACET句を使用できない点を除いて、静的タイプと同じNRQLクエリ形式を使用します。
外れ値 グループの外れ値になるそのグループの動作と値を検索します。静的タイプと同じNRQLクエリ形式を使用しますが、FACET句が必要です。

NRQLアラートの構文

すべてのNRQLアラート条件を作成するための基本的な構文は、以下のとおりです。閾値タイプによっては、FACETも含めます(該当する場合)。

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

必須

ひとつのデータタイプのみをターゲットにすることが可能です。

サポートされるデータタイプ:

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

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

オプション

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

FACET attribute

  • 静的:オプション
  • ベースライン:使用不可
  • 外れ値:必須

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

属性ごとに結果を区切り、各属性に個別のアラートを設定するには、FACET句を使います。ファセットクエリは、静的コンディションには最大5000の値を、 外れ値コンディションには最大500の値を返せます。

クエリがこの個数以上の値を返した場合、アラート条件は作成できません。条件を作成した後、クエリがこの個数以上の値を返した場合、アラートは失敗します。

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

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

クエリが間欠的、または限定的なデータを返す場合、有意義な閾値の設定が困難になる可能性があります。欠落したデータや限定的なデータがあると、誤検出または検出漏れを生じることがあります。

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

信号喪失の閾値を設定

信号喪失アラートUI のスクリーンショットでは、閾値が5分に設定されています。
one.newrelic.com に移動し、[アラート & AI] をクリックし、左側のサイドバーで [ポリシー] をクリックし、ポリシーを選択してから条件を作成します。信号喪失は、NRQL 条件でのみ使用できます。

信号喪失とは、New Relicでデータを受信できない期間を指します。データが送信されない場合もあれば、データが損失する場合もあります。信号喪失を使用して、最後の既知の信号の後に通知を送信するかどうか、いつ通知されるかをカスタマイズできます。

信号喪失を使用するNRQLアラートを作成するには:

  1. 条件を作成するときは、[製品の選択] の下で NRQL をクリックしてから、[次に、閾値を定義] をクリックします。
  2. アラートする値を返すNRQLクエリを作成します。
  3. 閾値タイプには、静的またはベースラインを選択します。
  4. [ +失われた信号の閾値を追加] をクリックし、信号が喪失したと見なされるまでの時間を分または秒で設定します。
  5. 信号が喪失した場合は、[現在未解決の違反をすべて閉じる]および[新しい信号喪失の違反を開く]のチェックボックスをオンにします。
  6. 必ず、条件に名前を付けて保存します。

信号喪失を使用して、現在未解決の違反をすべて終了するか、信号喪失の違反を開始する、またはその両方を行うことができます。

クエリ時間枠をオフセットする

毎分、1分間の時間枠でNRQLクエリを評価します。開始時間は、NRQL条件のAdvanced settings > Evaluation offsetで選択した値によって決まります。

例: デフォルトの時間枠を使用して違反を評価する

評価オフセットをデフォルト設定の3分に設定すると、クエリに適用されるNRQL時間枠は次のようになります。

SINCE 3 minutes ago UNTIL 2 minutes ago

イベントタイプがAPMの言語エージェントから供給されており、多数のアプリケーションインスタンス(例:TransactionsTransactionErrorsなど)から集計されている場合は、3分以上前のデータから評価することを推奨します。3分未満のオフセットの場合は違反がより速くトリガーされますが、データ転送の遅延の影響で誤検出と検出漏れが増える可能性があります。

AWSインテグレーションなどのクラウドデータの場合、3分以上のオフセットが必要になる場合があります。最適なセッティングを見つけるには、当社のAWSポーリング間隔のドキュメンテーションを確認してください。

NRQLアラート閾値の例

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

データの特定セグメントでアラート

重要な顧客や一定範囲のデータなど、データの特定セグメントをターゲットとする制約付きアラートを作成します。これらの条件を定義するにはWHERE句を使用してください。

 SELECT average(duration) FROM Transaction WHERE account_id in (91290, 102021, 20230)
SELECT percentile(duration, 95) FROM Transaction WHERE name LIKE 'Controller/checkout/%'
データのN番目のパーセンタイルでアラート

データのN番目のパーセンタイルが指定の閾値に達したときにアラートを作成します。例えば、SLAサービスレベルの管理など。当社は、NRQLクエリを1分間の時間枠で評価しているため、パーセンタイルは各分ごとに個別に算出されます。

 SELECT percentile(duration, 95) FROM Transaction
SELECT percentile(databaseDuration, 75) FROM Transaction
データの最大、最小、平均でアラート

データが最大、最小、平均に達したときにアラートを作成します。例えば、処理時間やレスポンスタイムが一定の閾値に達しないようにできます。

 SELECT max(duration) FROM Transaction
SELECT average(duration) FROM Transaction
データのパーセンテージでアラート

データの一部が特定の閾値を上回るとき、または下回るときにアラートを作成します。

 SELECT percentage(count(*), WHERE duration > 2) FROM Transaction
SELECT percentage(count(*), WHERE httpResponseCode = '500') FROM Transaction
T値のApdex (Application Performance Index)でアラート

特定のトランザクションに対して、T値を適用したApdexでアラートを作成します。例えば、本番アプリケーションに対して、トランザクションに500ミリ秒のT値を設定したApdexが0.8を下回ると、アラート通知を受信します。

SELECT apdex(duration, t:0.5) FROM Transaction WHERE appName like '%prod%'

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

ネスト構造の集計クエリは、データをクエリし、アラートを発生する新しい可能性を実現する強力な方法です。ただし、注意すべき重要な制限がいくつかあります。

現在、ネスト構造の一番内側で FACET のないクエリはサポートされていません。

FACETがないと、内部クエリは単一の結果を生成するため、外部クエリには何も集計されません。これは、内部クエリのみを登録するのと同等です。

SELECT max(cpu) FROM (FROM Event SELECT min(cpuTime) as cpu) ​​​​​
すべてのレベルのクエリには、同じ集計ウィンドウが必要になります。

1分の集計ウィンドウにアラートが登録されていると仮定すると、この内部クエリは、幅30秒の2つの小さなウィンドウを生成し、外部クエリで集計できます。ただし、現在この機能はサポートされていません。

SELECT max(cpu) FROM (FROM Event SELECT min(cpuTime) as cpu TIMESERIES 30 seconds)​​
ネスト構造のクエリでは、信号喪失はまだサポートされていません

信号喪失の詳細については、NerdGraph API:信号の喪失とギャップの充填を参照してください。

説明を作成する

違反への対応を改善、または川下のシステムで使用するために、有用な情報を川下に伝える説明を定義できます。詳細については、説明をご覧ください。

その他のヘルプ

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