アラート条件を作成する

条件では、監視されたデータソース、そして違反と見なされるデータソースの行動を定義する閾値が含まれます。本ドキュメントでは、利用可能な条件の種類、条件の作成方法、そして既存条件の確認方法について解説しています。

関連ドキュメント：

条件の作成

条件を作成するには：

  1. ポリシーを作成すると、条件を追加するよう自動的にプロンプトが表示されます。

    または

    既存のポリシーのページから、Create/add a conditionを選択します。

  2. 次のものを含む、UIのプロンプトに従います。
  3. オプション：条件の作成が終わったら、その条件をコピーし、その他のポリシーに追加します。

数値の入力フィールドがある条件は、小数第2位までの数値を受け入れます。たとえば、0.01が最小限の値です。

条件のタイプ

条件のさまざまなタイプの説明は次のとおりです。

NRQLクエリ条件

UIまたはNerd-Graph APIを使用して、数値を返すベーシックなNRQLクエリに対するNRQL条件を作成することができます。

ベースライン条件

ベースラインアラートでは、週ごと、または季節ごとのパターンなど、変化するデータとトレンドに動的に適応する条件を作成できます。この機能は、APMおよびBrowserアプリケーションのほか、NRQLクエリでも利用できます。

外れ値検出条件

外れ値検出は、データ内のグループの検索を試み、これらのグループからの外れ値である値を探します。外れ値検出は、NRQLアラート用にしか利用できません。

複数の場所におけるSyntheticsモニタリングの条件

複数の場所におけるSyntheticsモニタリングの条件を使用して、モニターを設定し、特定の数の場所で同時に障害が発生している場合に通知を受けられます。

キートランザクションメトリクス条件

APMでは、キートランザクションの条件を設定できます。

Javaインスタンス条件

閾値は、Javaアプリインスタンスのメトリックがその閾値を超えた場合に違反をオープンするように設定できます。

閾値を特定のインスタンスにスコープすることで、潜在的な問題がどこで発生しているかをより迅速に突き止めることができます。例えば、アプリのインスタンスのサブセットのみで発生している異常を検出する場合に便利です。膨大な数のインスタンスにわたってメトリックスを集計するアプリの場合、このタイプの異常は容易に見過ごされてしまいます。

JVM健全性メトリクス条件（Javaアプリ）

APMによって監視されるJavaアプリケーションの場合、単一のJVMのヒープサイズまたはスレッド数が予想される動作範囲外にある場合に違反をオープンする閾値を設定できます。

アプリの選択したインスタンスのそれぞれに対して、個別にアラートの閾値の違反を計算します。条件を作成する際、Javaアプリのアラートポリシーに対する条件タイプとしてJVM health metricを選択し、いずれかの利用可能な閾値を選択してください。

  • スレッドのデッドロック
  • ヒープメモリの使用
  • CPU利用時間
  • ガベージコレクションのCPU時間

違反は、閾値の逆数が満たされると自動的に閉じますが、UIを使用すると、JVM稼働メトリックに関する違反が強制終了する時間も変更できます。デフォルトは24時間です。

ウェブトランザクションのパーセンタイル条件

条件には閾値としてパーセンタイルを定義するオプションが含まれます。この条件は、ウェブアプリのレスポンスタイムがこの値を上回る、下回る、または等しい場合として設定します。このオプションは、例えば、運用スタッフがウェブの平均レスポンスタイムでなく、アプリケーションサーバーの全体的なウェブトランザクションのパーセンタイルについてアラートを発生させる場合に便利です。

ウェブアプリケーション以外のトランザクションに対して、条件内に任意の閾値を設定する場合、NRQLクエリ機能を使用してください。

パーセンタイル閾値を定義するには：

  1. APMアプリの条件に対する条件タイプとして、Web transactions percentilesを選択し、1つのアプリを選択します。（複数のアプリにアラートを作成するには、各アプリに個別にWeb transactions percentiles条件を作成してください。）
  2. 違反をオープンする閾値を定義するには、Percentile nthレスポンスタイム値を入力し、その頻度（この値より大きい、小さい、または等しい）を選択します。

ユーザーインタフェースにはクリティカルと警告の値が秒単位で表示されますが、New Relicにはトランザクションタイムがミリ秒で保存されます。ミリ秒で定義する場合は、値に小数点を含めます。

アプリのラベルを使用した動的ターゲティング

アプリケーションにラベルを適用することで、条件にこれらのエンティティを自動的にリンクさせることができます。これにより、すべてのアプリケーションを動的環境内で簡単に管理できます。エンティティラベルを最適な状態で管理するため、エージェントの設定ファイルを使用するようお勧めします。

1つのラベルを使用して、関連のあるすべてのエンティティ（最大10,000エンティティ）を識別できます。複数のラベルは、選択されたラベルをすべて共有するエンティティのみ識別します。

条件と合わせてダイナミックターゲティングを利用するには、違反クローズタイマーを設定する必要もあります。

1つの条件に対して最高で10個のラベルを追加、編集、削除するには：

  1. 製品タイプとして、APM > Application metricを選択します。
  2. エンティティを識別するには、 Labelsタブを選択します。ラベルを名前で検索するか、カテゴリーのリストからラベルを選択します。

Infrastructureを使用して、監視対象の条件を直接作成することもできます。

インフラストラクチャの条件

Infrastructureから直接、リソースに対する条件を作成できます。

たとえば、Infrastructureエージェントからデータが受信されなくなったときに通知を受信するには、host not reportingの条件タイプを使用します。これにより、フィルタリングされたホストグループに対してアラートを動的に送信し、5〜60分の時間枠を設定できるようになります。

Apdexとレスポンスタイムの条件

レスポンスタイムに対する違反をオープンし、通知を送信できます。ただし、ほとんどの場合、Apdexスコアは有用性がより高く、アプリケーションパフォーマンスをより正確に反映します。例えば、異常値が存在する場合、平均応答時間は結果に歪みが生じることがありますが、Apdexスコアはユーザーの許容レスポンスタイムをより正確に評価します。

条件の名前を変更

デフォルトの条件の名前を変更する場合は、分かりやすい短い名前を使用してください。電子メールの件名の行、オンラインチャットなど、文字制限のある通知メッセージには有益な情報を提供してください。

  • キャメルケースまたはドット付き10進表記を使用します。
  • 何に違反しているのか簡潔に説明します。

既存の条件の名前を変更するには：

  1. one.newrelic.com のトップナビゲーションで、Alerts & AIをクリックし、Alert policiesをクリックしてから（ポリシーを選択をクリックします。
  2. 条件の名前をクリックして編集してから、条件に見合う名前を入力します。

条件に関連付けられている製品と条件タイプは、編集できません。代わりに、条件を削除して別の製品および条件タイプで新たに作成してください。

ポリシーと条件を管理する

条件を保存すると、現在選択されているポリシーに、その条件に適用されるすべてのアラート条件がリストされます。ここから、以下の操作を行えます。

また、Nerd-GraphポリシーAPI経由でポリシーを管理することもできます。

既存の条件を表示する

ポリシーの索引で、アルファベット順に条件が一覧表示されます。既存の条件を表示するか検索するには：

  1. one.newrelic.com のトップナビゲーションで、Alerts & AIをクリックしてから、Alert policiesをクリックします。
  2. 検索ボックスを使用して、列をソートするかリストをスクロールして、ポリシー名を選択して条件を表示します。

特定のエンティティのポリシーと条件情報を表示するには：そのエンティティの製品UIから、Settingsを選択し、 Alert conditionsをクリックします。

その他のヘルプ

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