アラートの作成には、NRQLアラート条件を使用することを推奨します。このドキュメントでは、効率を最大化し、ノイズを削減するNRQLアラート条件のフォーマットと構成について説明します。New Relicを使い始めたばかりの場合や、まだアラート条件を作成していない場合は、アラート条件から始めることをおすすめします。
アラート条件は以下から作成できます。
次のアラートビルダーのいずれかを使用することもできます。
- Write your own queryを使用して、アラートをゼロから作成する。
- Use Guided mode推奨オプションから選択して、NRQLクエリを構築する。
アラート条件の作成をチャートで開始するか自身でクエリを記述するかに関わらず、NRQLはシグナルを定義して閾値を設定できる基礎ブロックとなります。
NRQLアラートの構文
すべてのNRQLアラート条件を作成するための基本的な構文は、以下のとおりです。
SELECT function(attribute) FROM Event WHERE attribute [comparison] [AND|OR ...]
Clause | Notes |
---|---|
Required | 数字を返すサポート対象の関数は、以下のとおりです。
|
Required | 複数のデータ型をターゲットにできます。 サポートされているデータ型:
|
| 1つ以上の一連の条件を指定する場合は、 |
| オプションの 属性別で結果を区切り、各属性に個別のアラートを設定する場合は、 ファセットクエリは、静的および異常条件には最大5000の値を返せます。 重要クエリが最大数を上回る値を返す場合、アラート条件は作成できません。条件を作成した後、クエリがこの数以上の値を返した場合、アラートは失敗します。返される値の数が少なくなるようにクエリを変更します。 |
再フォーマット化された互換性がないNRQL
チャートで使用されるNRQLの一部の要素は、ストリーミングアラートのコンテキストに意味はありません。以下は、NRQLアラートクエリを再フォーマットして同じ効果をあげる最も一般的な互換性のない要素と提案のリストです。
Element | Notes |
---|---|
| 例:
NRQL条件は決して途切れないウィンドウ表示されたクエリ結果を生成するため、ある時点までクエリを調べる |
| NRQLクエリでは、 NRQL条件の場合、およびスライディングウィンドウ集計を使用しない場合、 |
|
|
| これらの機能は、NRQLアラートではまだサポートされていません。 |
複数集計関数 | 各条件は単一の集計値のみをターゲットにできます。複数の値に同時にアラートするには、同じポリシー内の個別条件に分解する必要があります。 元のクエリ:
分解済み:
|
|
|
|
UIでスライディングウィンドウを有効にすることができます。条件を作成または編集するときは、Adjust to signal behavior > Data aggregation settings > Use sliding window aggregationの順に移動します。 たとえば、以下と同等のアラート条件を作成するには、
データ集計ウィンドウ期間を5分、スライディングウィンドウ集計を1分として使用します。 |
| NRQLクエリでは、
|
サブクエリ | サブクエリの実行にはデータを介しての複数のパスが必要なため、サブクエリはストリーミングと互換性がありません。 |
サブクエリのJOIN | サブクエリの実行にはデータを介しての複数のパスが必要なため、サブクエリのJOINはストリーミングアラートと互換性がありません。 |
NRQLアラート閾値の例
以下に示すのは、NRQL条件の一般的な使用ケースです。これらのクエリは、静的および異常の条件タイプにおいて動作します。
NRQL条件および演算のクエリ順序
デフォルトで、集計ウィンドウの期間は1分ですが、必要に応じてウィンドウは変更できます。集計ウィンドウが何であろうと、New RelicはNRQL条件のクエリの関数を使用して、そのウィンドウのデータを集計します。クエリは構文解析され、以下の順序でシステムによって実行されます。
FROM
句。どのイベントタイプを取り込む必要があるのか?WHERE
句。何を除去できるのか?SELECT
句。今、フィルタリングしたデータセットから何の情報を返す必要があるのか?
例: 返されたnull値
これがアラート条件クエリとしましょう。
SELECT count(*) FROM SyntheticCheck WHERE monitorName = 'My Cool Monitor' AND result = 'FAILED'
集計ウィンドウに失敗がない場合:
- システムは、アカウント上のすべての
SyntheticCheck
イベントを取り込んで、FROM
句を実行します。 - 次に、モニター名と指定した結果が一致するもののみを見て、イベントをフィルタリングする
WHERE
句を実行します。 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分を評価するかを指定する暗黙的な
|
信号損失の閾値(信号損失検出) | 信号損失検出を使用すると、データ(テレメトリ信号)が失われたと見なされる時点でアラートを出力できます。サービスまたはエンティティがオンラインではなくなったか、定期的なジョブの実行に失敗した可能性を示しています。エラーカウントなどの散発的なデータのインシデントが、信号を受信していないときに確実に終了するためにも使用できます。 |
高度な信号設定 | この設定で、場合によってはない継続的なストリーミングデータ信号の取り扱いを改善するオプションを使用できます。この設定には、集計ウィンドウの期間と遅延/タイマー、データギャップを埋めるオプションが含まれます。これらの使用の詳細については、高度な信号設定を参照してください。 |
条件設定 | Condition settingsを使用して次のことを行います。
|
条件の制限 | 最大値を参照します。 |
稼働ステータス | NRQLアラート条件の稼働ステータス表示を適切に機能させるには、クエリを単一のエンティティに設定する必要があります。これを行うには、WHERE句(例: |
例 | 詳細については、以下を参照してください。 |
条件のタグの管理
既存のNRQL条件を編集する場合、条件エンティティに関連付けられたタグを追加または削除することができます。これを行うには、条件名の下にあるManage tagsボタンをクリックします。ポップアップ表示されるメニューで、タグを追加または削除します。
条件の編集により、条件の評価をリセットできます
NRQLアラート条件を特定の方法で編集する場合(詳細は以下を参照)、その評価がリセットされます。つまり、その時点までの評価がすべて失われ、その時点から評価をやり直します。これは、次の2つの方法で影響します。
- 「x分以上」の閾値の場合:評価ウィンドウがリセットされたため、インシデントが報告されるまで少なくともx分の遅延が発生します。
- 異常条件の場合:条件を最初からやり直し、すべての異常学習が失われます。
以下のアクションにより、NRQL条件の評価がリセットされます。
- クエリの変更
- 集計ウィンドウ、集計方法、集計遅延/タイマー設定の変更
- 「信号損失時の終了インシデント」設定の変更
- ギャップ塗りつぶし設定の変更
- 異常方向の変更(該当する場合)– 高、低、または高/低
- 閾値、閾値ウィンドウ、または閾値演算子の変更
- スライドごとの間隔を変更する(スライディングウィンドウの集計条件のみ)
以下のアクション(および上記リストに記載されていないその他のアクション)は、評価をリセットしません。
- 信号損失タイムウィンドウ(有効期限)の変更
- 時刻機能の変更(「少なくとも」を「少なくとも1回」に変更する、またはその逆)
- 「信号損失時のオープンインシデント」設定の切り替え
アラート条件のタイプ
NRQLアラートを作成する際、異なる条件のタイプを選択できます。
NRQLアラート条件のタイプ | 説明 |
---|---|
静的 | これは、最もシンプルなNRQL条件のタイプです。数値を返すNRQLクエリに基づいた条件を作成できます。 オプション: |
異常(動的な異常) | 監視対象値の過去の動作に基づいた自己調整型の条件を使用します。オプションの |
信号損失の閾値を設定
重要
信号損失機能では、信号が失われたことを検出する前に、信号が存在する必要があります。信号が存在しない状態で条件を有効にすると、信号の損失は検出されず、信号損失機能はアクティブ化されません。
信号損失は、特定の期間にわたってNRQL条件に一致するデータがない場合に発生します。信号損失の閾値期間と、閾値を超えたときに何が起こるかを設定できます。
one.newrelic.com > All capabilities > Alerts > Alert conditions (Policies)に移動し、次に+ New alert conditionに移動します。信号損失は、NRQL条件でのみ使用できます。
これらの設定は、GraphQL API(推奨)またはREST APIを使用して管理することもできます。特定のGraph QL APIの例については、こちらを参照してください。
Loss of signal settings:
Loss of signal settings include a time duration and a few actions.
Signal loss expiration time
- UIラベル: Signal is lost after:
- GraphQLノード: expiration.expirationDuration
- 有効期限とは、ストリーミングアラートパイプラインでデータポイントを受信すると開始およびリセットされるタイマーです。「有効期限」が切れる前に別のデータポイントを受信しないと、その信号は損失したと見なされます。これは、New Relicにデータが送信されていないか、アラートパイプラインにストリーミングされる前に、NRQLクエリの
WHERE
句がそのデータを除外しているためです。ファセットクエリがある場合、各ファセットはシグナルであることに注意してください。したがって、これらのシグナルのいずれかが指定期間中に終了すると、シグナルの損失と見なされます。 - 閾値の有効期限に関係なく、タイマーが期限切れになるとすぐに信号損失がトリガーされます。
- 最長の有効期限は48時間です。これは、頻度の低いジョブの実行をモニタリングするときに役立ちます。最小は30秒ですが、少なくとも3〜5分に設定することを推奨します。
Loss of signal actions
Once a signal is considered lost, you have a few options:
- 現在未解決のインシデントをすべて閉じる:これにより、特定の信号に関連する未解決のインシデントがすべて終了します。必ずしも、条件のすべてのインシデントが終了するとは限りません。一時的なサービスまたは散発的な信号で警告している場合は、インシデントが適切に終了するように、このアクションを選択することをお勧めします。この場合、GraphQLノード名は 「closeViolationsOnExpiration」 です。
- 新しいインシデントを開く:これにより、信号が損失したと見なされると、新しいインシデントが発生します。これらのインシデントは、信号の損失が原因であることを示します。インシデントプリファレンスに基づいて、通知がトリガーされます。この場合、graphQLノード名は、「openViolationOnExpiration」 です。
- When you enable both of the above actions, we'll close all open incidents first, and then open a new incident for loss of signal.
- Do not open "lost signal" incidents on expected termination. When a signal is expected to terminate, you can choose not to open a new incident. This is useful when you know that a signal will be lost at a certain time, and you don't want to open a new incident for that signal loss. The GraphQL node name for this is
ignoreOnExpectedTermination
.
重要
In order to prevent a loss of signal incident from opening when "Do not open "lost signal" incident on expected termination", the tag termination: expected
must be added to the entity. This tag tells us the signal was expected to terminate. See how to add the tag directly to the entity.
UIで信号損失検出を使用して設定されたNRQLアラートを作成する場合は、以下の手順に従います。
- Follow the instructions to create a NRQL alert condition.
- On the Set thresholds step you'll find the option to Add lost signal threshold. Click this button.
- Set the signal expiration duration time in minutes or seconds in the Consider the signal lost after field.
- Choose what you want to happen when the signal is lost. You can check any or all of the following options: Close all current open incidents, Open new "lost signal" incident, Do not open "lost signal" incident on expected termination. These control how loss of signal incidents will be handled for the condition.
- You can optionally add or remove static/anomaly numeric thresholds. A condition that has only a loss of signal threshold and no static/anomaly numeric thresholds is valid, and it's considered a "stand alone" loss of signal condition.
- Continue through the steps to save your condition.
- If you selected "Do not open "lost signal" incident on expected termination", you must add the
termination: expected
tag to the entity to prevent a loss of signal incident from opening. See how to add the tag directly to the entity.
ヒント
You might be curious why you'd ever want to have bothOpen new "lost signal" incident and Do not open "lost signal" incident on expected termination set to true. Think of it like this: you always want to be notified when a signal is lost until the one time you know the signal is scheduled to stop and you don't want to be notified. In that case, you'd set both to true, and when you expect the signal to be lost, you'd add the termination: expected
tag to the relevant entity.
信号が戻ってくると、信号閉鎖の喪失により、
- インシデントが発生します。新しく開かれた信号損失インシデントは、新しいデータが評価されるとすぐに閉じられます。
- それらが属する条件が期限切れになります。デフォルトでは、条件は3日後に期限切れになります。
- Close all current open incidentsオプションを使用して、インシデントを手動で閉じます。
ヒント
信号損失検出は、ネスト型の集計またはサブクエリを使用するNRQLクエリでは機能しません。
高度な信号設定
NRQLアラート条件を作成すると、高度な信号設定により、ストリーミングアラートデータを管理し、誤検出を防止できます。
NRQL条件を作成する際の高度な信号設定は、次のとおりです。
- 集計ウィンドウの期間
- スライディングウィンドウの集計
- ストリーミング方法
- 遅延/タイマー
- データのギャップを埋める
- 評価遅延
この設定の内容と、相互の関係の説明を読む場合は、ストリーミングアラートのコンセプトを参照してください。設定方法の説明とヒントは、次のとおりです。
集計ウィンドウの期間
データが集計される前に、ストリーミング時間枠に蓄積されるデータの長さを選択する集計ウィンドウを設定できます。30秒から120分の間で設定できます。デフォルトは1分です。
スライディングウィンドウの集計
スライディングウィンドウを使用すると、より滑らかなチャートを作成できます。これを行うには、データの重複ウィンドウを作成します。
この短いビデオでスライディングウィンドウの設定方法を紹介します(2分30秒)。
有効にしたら、「間隔ごとにスライド」を設定して、集計ウィンドウのオーバーラップ時間を制御します。間隔は集計ウィンドウよりも短く、また均等に分割する必要があります。
重要
スライディングウィンドウのアラート条件を新規作成するか、または評価リセットを引き起こす可能性のあるアクションを実行した直後、最初の集計ウィンドウの期間中の条件に「集約バッファ」を構築する時間が必要になります。その間、インシデントはトリガーされません。単一の集計ウィンドウが経過すると、完全な「バッファ」が構築されて、条件は正常に機能します。
ストリーミング方法
3つのストリーミング集計方法から選択して、条件に最適な評価結果を得ることができます。
遅延/タイマー
遅延/タイマーを調整して、データの動作に合わせてストリーミングアラートアルゴリズムを調整できます。データがまばらであるか一貫性がない場合は、イベントタイマー集計法を使用することをお勧めします。
ケイデンス集計法では、サポートされる合計レイテンシは、集計ウィンドウ期間と遅延の合計になります。
データタイプがAPMの言語エージェントから供給されており、多数のアプリケーションインスタンス(例:Transactions
、TransactionErrors
など)から集計されている場合は、デフォルト設定でイベントフロー法を使用することをお勧めします。
重要
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
HNR NRQL conditions in guided mode
NRQL condition guided mode offers a curated experience for creating infrastructure "host not reporting" (HNR) NRQL conditions. This is the preferred to the alternative to creating infrastructure "host no reporting" conditions.