アラート条件を作成する

所有者(オーナー)、アドミン、またはアドオン管理者

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

関連ドキュメント:

アラート条件を作成する

所有者(オーナー)、アドミン、またはアドオン管理者

アラート条件を作成するには、

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

    または

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

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

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

アラート条件のタイプ

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

NRQLクエリ条件

現在、New Relic Insightsでは、New Relic アラートを利用できません。ただし、アラート UIもしくはREST APIの呼び出しを使用して、数値を返すベーシックなNRQLクエリに対するアラート条件を作成することができます。

ベースライン条件

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

外れ値検出条件

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

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

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

Javaインスタンス条件

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

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

JVM健全性メトリクス条件(Javaアプリ)

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

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

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

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

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

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

ウェブアプリケーション以外のトランザクションに対して、条件内に任意の閾値を設定する場合、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タブを選択します。ラベルを名前で検索するか、カテゴリーのリストからラベルを選択します。

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

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

インフラストラクチャから直接、リソースに対するアラート条件を作成できます。

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

Apdexとレスポンスタイムのアラート条件

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

アラート条件の名前を変更する

所有者(オーナー)、アドミン、またはアドオン管理者

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

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

既存のアラート条件の名前を変更するには:

  1. alerts.newrelic.comからAlert policies > (選択したポリシー)> Alert conditionsを選択します。
  2. アラート条件の名前の上にカーソルを移動し、Edit[pencil icon]アイコンを選択します。
  3. 条件に対して意味のある名前を入力し、変更を保存します。

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

アラートのポリシーと条件を管理する

所有者(オーナー)、アドミン、またはアドオン管理者

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

既存の条件を表示する

アラートポリシーのインデックスには、ポリシーがアルファベット順にリストされます。既存の条件を表示するか検索するには:

  1. alerts.newrelic.comから、Alert policiesを選択する。
  2. 検索ボックスを使用して、列をソートするかリストをスクロールして、ポリシー名を選択して条件を表示します。

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

その他のヘルプ

推奨する詳細情報: