| title | アラート条件 | ||
|---|---|---|---|
| tags |
|
||
| metaDescription | Use the conditions page to identify what triggers an alert policy's notification, starting with the product and type of metric or service. | ||
| freshnessValidatedDate | never | ||
| translationType | human |
アラート条件は、アラートが生成されるタイミングを定義する中核的な要素です。これは、有用なアラートを作成するための重要な開始点となります。アラート条件には、通知を受ける前に満たされた問題または閾値が含まれます。これらは、過剰なアラートを軽減したり、新しい行動や異常な行動が現れた際にチームに通知したりすることができます。
アラート条件は、継続的に実行されるクエリで、特定の一連のイベントを定義された閾値と比較して測定し、指定された時間枠内に閾値に達するとアラートを開始します。
この例では、Alert condition detailsページを使用して新しいアラート条件を手動で作成する方法を示します。アラート条件を作成する方法は多数あります。アラート条件は以下から作成できます。
次のアラートビルダーのいずれかを使用することもできます。
-
Write your own queryを使用してアラートをゼロから作成する
- **Use guided mode**
ガイド付きモードを除くすべての方法で、アラート条件を作成するプロセスは、以下の手順で説明するものとまったく同じになります。
### 信号の動作を設定するこの例では、チームがeコマースサイトの`WebPortal`アプリケーションを管理していると想定します。遅延の問題について警告を受け取りたいと考えています。
<CollapserGroup>
<Collapser id="set-your-query" title="信号の動作を設定する">
NRQLクエリを使用して、アラート条件でアラートの基礎として使用する信号を定義できます。この例では、次のクエリを使用します。
```sql
SELECT average(duration)
FROM PageView
WHERE appName = 'WebPortal'
```
アラート条件にこのクエリを使用すると、`WebPortal`アプリケーションの取得したいページ読み込みの平均レイテンシまたは期間がNew Relicに通知されます。レイテンシに関するプロアクティブなアラートは中核的なゴールデンシグナルであり、潜在的な低下に対する早期警告を提供します。
New Relicのクエリ言語であるNRQLの使用方法の詳細については、[NRQLドキュメント](/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/create-nrql-alert-conditions/)を参照してください。
</Collapser>
</CollapserGroup>
信号を定義したら、<DNT>**Run**</DNT>をクリックします。チャートが表示され、設定したパラメーターが表示されます。
<Callout variant="tip">
クロスアカウントアラートを設定するには、ドロップダウンリストから**データアカウント**を選択します。また、アカウントアカウントアラートの場合、一度にクエリできるのは1つのアカウントのデータのみです。
</Callout>
{/* <img
title="set a query"
alt="A screenshot showing a user how to set the signal behavior for an alert condition."
src="/images/alerts_screenshot-crop_set-a-query.webp"
/> */}
この例では、チャートにはトランザクションの平均期間が表示されます。<DNT>**Next**</DNT>をクリックして、アラート条件の設定を開始します。
この例では、 `WebPortal`アプリケーションのレイテンシを監視するために作成した条件に合わせて、これらの高度な信号設定をカスタマイズします。
<CollapserGroup>
<Collapser id="window-duration" title="ウィンドウ期間">
{/* <img
title="fine tune alert settings"
alt="A screenshot depicting advanced signal settings."
src="/images/alerts_screenshot-crop_fine-tune-alert-signals.webp"
/> */}
ウィンドウ期間は、New Relicがアラート条件での分析のためにデータをグループ化する方法を定義します。適切な設定の選択は、データの頻度と希望する詳細レベルによって異なります。
* <DNT>**High-frequency data (for example, pageviews every minute)**</DNT>：変動や傾向をリアルタイムで把握できるように、データ頻度（この場合は1分）に一致するようにウィンドウ期間を設定します
* <DNT>**Low-frequency data (for example, hourly signals)**</DNT>：パターンや異常を明らかにするのに十分なデータをキャプチャするウィンドウ期間を選択します（たとえば、1時間ごとの信号の場合は60分）
ニーズと経験に応じて、ウィンドウ期間をカスタマイズできます。アラート条件の作成に慣れてきたら、開始時や実験時にはデフォルトを使用することをお勧めします。
</Collapser>
<Collapser id="sliding-window" title="スライディングウィンドウ集計を使用する">
従来の集計方法では、データがまばらに存在したり、間隔の間に大きな変動が見られるデータを処理する場合には不十分である場合があります。スライディングウィンドウ集計を使用してそのようなデータを分析し、タイムリーなアラートを効果的にトリガーする方法を以下に示します。
1. <DNT>**Smooth out the noise**</DNT>：まず、大きな集計ウィンドウを作成します。この時間枠（たとえば、5分）はバッファとして機能し、データに固有の「ノイズ」や変動性を平滑化します。これは、単独の急上昇や急降下によってトリガーされる誤ったアラートを防ぐのに役立ちます。
2. <DNT>**Avoid lag with a sliding window**</DNT>大きなウィンドウはデータ分析に役立ちますが、閾値をチェックする前に間隔全体が経過するまで待機すると、アラート通知が大幅に遅れる可能性があります。スライディングウィンドウを小さくすることをお勧めします（たとえば、1分）。このスライディングウィンドウを、より大きな集計ウィンドウ内でデータをスキャンする移動フレームとして想像してください。フレームが小さい間隔で進むたびに、集計値（平均など）が計算されます。
3. <DNT>**Set your threshold duration**</DNT>：より小さいスライディングウィンドウのコンテキスト内で、アラートの閾値を定義できるようになりました。これにより、現在のフレームの集計値が目的の範囲から大幅に逸脱した場合でも、より大きなウィンドウの平滑化効果を犠牲にすることなく、アラートを迅速にトリガーできます。
<Callout variant="important">
[AdvancedおよびCore Compute価格設定プラン](https://newrelic.com/pricing/compute#pricing_plan-compute)の顧客には、スライディングウィンドウ集計を利用する際に追加のCCU料金が発生する場合があります。この方法は変動を平滑化することでデータ分析を強化しますが、他の方法に比べてコストが増加する可能性があります。詳細については、[スライディングウィンドウの価格設定セクション](/docs/nrql/using-nrql/create-smoother-charts-sliding-windows/#pricing)を参照してください。AdvancedまたはCore Computeのどちらの価格設定プランを利用しているかを確認するには、注文を参照してください。
</Callout>
スライディングウィンドウ集計について詳しくは、[このNRQLチュートリアル](/docs/nrql/using-nrql/create-smoother-charts-sliding-windows)をご覧ください。
</Collapser>
<Collapser id="streaming-method" title="ストリーミング方法">
一般的には、<DNT>**event flow**</DNT>ストリーミングメソッドを使用することをお勧めします。これは、システムに高頻度で安定的に入力されるデータに最適です。<DNT>**event timer**</DNT>を選択する方がよい場合もありますが、最初のアラートにはデフォルトの<DNT>**event flow**</DNT>をお勧めします。ストリーミングメソッドの選び方を理解するには、こちらの短いビデオ（約5分31秒）を視聴することをお勧めします。
<Video type="wistia" id="n6nei987ln" />
</Collapser>
<Collapser id="delay" title="遅延">
アラート条件の遅延機能は、一貫性のないデータ収集から生じる潜在的な問題を防ぎます。これはバッファとして機能し、トリガーされる前にデータが到着して処理されるための追加時間を確保します。これにより、誤検知を防止し、より正確なアラートの作成が保証されます。
使い方：
適切な遅延設定は、受信データの一貫性を評価することによって決定されます。
* 一貫したデータ：データポイントが1分以内にタイムスタンプとともに定期的に到着する場合は、遅延設定を低くしても問題ありません
* 一貫性のないデータ：過去や未来の数分間にわたるタイムスタンプを持つデータポイントが到着した場合、不整合に対応するために遅延設定を大きくする必要があります
バッファの作成：
* 選択した遅延設定により、アラート条件が定義された閾値に対してデータを評価するまでの待機時間が導入されます
* このバッファにより、データの不一致を解決するまでの時間が確保され、誤解を招くアラートが発生する可能性が軽減されます
</Collapser>
<Collapser id="gap-filling-strategy" title="ギャップ埋め戦略">
`WebPortal`アプリケーションのレイテンシの問題をチームに通知するためのアラート条件を作成しています。この例では、アプリケーションは一貫してNew Relicデータを送信します。アプリケーションからNew Relicに信号が継続的に送信されており、信号に予期されるギャップがないため、ギャップ埋め戦略を選択する必要はありません。
ギャップ埋め戦略は、データ収集が断続的または不完全である可能性があるシナリオに対処します。これらは、欠落しているデータポイントを推定値で置き換える方法を提供し、データストリームにギャップがある場合でもアラート条件が効果的に機能することを保証します。
ギャップ埋めをオフのままにする場合：
* <DNT>**Consistent data flow**</DNT>：WebPortalアプリケーションの場合のように、アプリケーションが予想されるギャップなしで一貫してNew Relicにデータを送信する場合、通常はギャップを埋める必要はありません。このような場合、たいていはギャップ埋め戦略を実行しない設定のままにすることが最適なアプローチとなります。
主な考慮事項：
* <DNT>**Popular use case**</DNT>：一般的に、ギャップを埋める際には、データを受信していないウィンドウに値0を挿入します。
* <DNT>**Anomaly thresholds**</DNT>ギャップ埋め値は、異常閾値を使用する場合、最後に観測された値からの標準偏差の数値として解釈されます。たとえば、ギャップを値0で埋めると、最後に確認された値が複製され、実質的には変化がないと想定されます。
ギャップ埋め戦略の詳細については、[損失信号に関するドキュメント](/docs/apis/nerdgraph/examples/nerdgraph-api-loss-signal-gap-filling/)をご覧ください。
</Collapser>
<Collapser id="cross-account-alerts" title="クロスアカウントアラート">
New Relicのクロスアカウントアラートを使用すると、アラートが設定されているアカウントとは異なるアカウントからのデータを監視するアラート条件を設定できます。この機能により、New Relic内の複数のアカウントにわたる依存関係をより柔軟に監視および管理できるようになります。
詳細については、[クロスアカウントアラート](/docs/alerts/create-alert/create-alert-condition/cross-account-alert/)を参照してください。
</Collapser>
</CollapserGroup>
アラート条件がコンテナの場合、閾値は各アラート条件が従う必要があるルールです。データがシステムにストリーミングされると、アラート条件によってこれらのルールに該当するアラートが検索されます。アラート条件で、設定したすべての条件を満たしたデータがシステムから検出されると、アラートが作成されます。アラートは、システムに何か問題があることを示しているため、確認する必要があります。
{/* <img
title="set a threshold"
alt="A screenshot depicting how to set the threshold for an alert condition."
src="/images/alerts_screenshot-crop_set-a-threshold-for-an-alert-condition.webp"
/> */}
<CollapserGroup>
<Collapser id="anomaly-threshold" title="異常閾値">
異常閾値は、特定の数値よりも予想されるパターンから逸脱する場合に最適です。これを使用すると、事前定義された制限を設定することなく、異常なアクティビティを監視できます。New Relicの異常検知は、時間の経過とともにデータを動的に分析し、進化するシステム動作を反映するように閾値を調整します。
異常検知の設定：
1. 上限と下限の選択：
* 予想よりも高い偏差と低い偏差がある場合に警告を受け取るには、上限と下限を選択します。
* 異常に高い値のみに焦点を当てるには、「上限のみ」を選択します。
2. 優先順位の割り当て：
* 潜在的な問題に迅速に対処できるように、最初のアラートの優先度レベルをクリティカルに設定します。
3. 違反基準の定義：
* デフォルト設定から開始：クエリが予測値から5分間以上標準偏差3だけ逸脱する値を返した場合、アラートをオープンします。
* 特定のアプリケーションおよびアラート要件に合わせて、必要に応じてこれらの設定をカスタマイズします。
優先レベルの詳細については、[アラート条件に関するドキュメント](/docs/alerts-applied-intelligence/new-relic-alerts/advanced-alerts/advanced-techniques/set-thresholds-alert-condition#threshold-levels)をご覧ください。
異常の閾値とモデルの動作について詳しくは、異常に関する[ドキュメント](/docs/alerts-applied-intelligence/applied-intelligence/anomaly-detection/anomaly-detection-applied-intelligence/)をご覧ください。
</Collapser>
<Collapser id="static-threshold" title="静的閾値">
異常閾値とは異なり、静的閾値はデータセット全体を参照せず、システムの履歴に基づいて異常な動作を判断します。代わりに、ユーザーが設定した基準とは異なる動作をする場合には、システムが静的閾値に従ってアラートをオープンします。
異常閾値と静的閾値の両方の優先レベルを設定する必要があります。詳細については、上のセクションを参照してください。
</Collapser>
<Collapser id="outlier-threshold" title="外れ値検出">
外れ値検出は、特定の時点において、他のエンティティとは大きく異なる動作をしているエンティティを識別します。時間の経過に伴う異常なパターンを探す異常検知とは異なり、外れ値検出はDBSCANクラスタリングを使用してグループ内の偏差に焦点を当てます。
この閾値タイプは次のような場合に最適です。
* クラスタと比較して異常なリソース消費をしているサーバーの特定
* メッセージを正しく処理していないKafkaブローカーの検出
* マルチテナント環境における「ノイズの多い隣人」シナリオの検出
主な設定パラメーター：
* **イプシロン**：同じクラスタ内のポイント間の最大距離
* **最小ポイント**：クラスタを形成するために必要な最小ポイント（3以上を推奨）
* **評価グループ**：環境や地域などのファセットによるセグメント分析
外れ値検出の詳細については、[外れ値検出のドキュメント](/docs/alerts/create-alert/set-thresholds/outlier-detection/)をご覧ください。
</Collapser>
<Collapser id="disable-health-status-reporting" title="稼働ステータスレポート">
New Relicでは、エンティティは[色分けされた稼働ステータス](/docs/alerts/create-alert/examples/view-entity-health-status-find-entities-without-alert-conditions/#colors)に関連付けられます。これらのエンティティの現在のステータスは、それぞれのインデックスとマップから確認できます。アラート条件がエンティティに関連付けられている場合、エンティティの稼働ステータスはアラート条件によって決定されます。アラートによってアラートがトリガーされると、アラートの重大度レベルに基づいてエンティティの稼働ステータスが変化します。
アラート条件が関連するエンティティの稼働ステータスに影響を与えないようにするには、 <DNT>**Do not report system health status**</DNT>トグルを有効にします。これは、全体的な稼働ステータスに影響を与えずにエンティティを監視する場合に便利です。
<Callout variant="important">
クロスアカウントアラート条件を作成する場合、<DNT>**Do not report system health status**</DNT>トグルがデフォルトで無効になります。クロスアカウントアラート条件によって、関連するエンティティの稼働ステータスが判断されないようにするには、これを有効にします。
</Callout>
</Collapser>
<Collapser id="predict-alert" title="静的閾値による予測アラート">
New Relicの<DNT>**Predictive Alerts**</DNT>履歴データを分析して将来の傾向を予測します。静的閾値をすぐに超える可能性があると予測された場合は、アラート通知が届き、サービスの中断が発生する前に対処することができます。
詳細については、[予測アラートのドキュメント](/docs/alerts/create-alert/set-thresholds/predictive-alerts/)を参照してください。
アラート条件に対して予測アラートを有効にするには、次の手順を実行します。
1. <DNT>**Set condition thresholds**</DNT>セクションで、閾値条件タイプとして<DNT>**Static**</DNT>を選択します。
2. 予測アラートの場合は、<DNT>**Predict future behavior**</DNT>トグルを有効にします。
3. 先読み時間を設定します。これは、予測される違反をどのくらい先まで監視すべきかを示します。最大の先読み時間は[ウィンドウ期間](/docs/alerts/create-alert/create-alert-condition/alert-conditions/#window-duration)の360倍です。
4. 実際の信号が閾値を超えたときに予測されるアラートイベントの動作を設定します。
* 予測したアラートを閉じて、実際のアラートを開きます。
* ノイズを減らすために、予測したアラートを開いたままにしておきます。
</Collapser>
<Collapser id="lost-signal" title="損失信号閾値（オプション）">
[損失信号閾値](/docs/alerts/create-alert/create-alert-condition/create-nrql-alert-conditions/#signal-loss)は、信号が失われたとみなすまで待機する時間を決定します。その時間内に信号が返されない場合は、新しいアラートを開くか、関連するアラートを閉じるかを選択できます。信号の終了が事前に予想されている場合は、アラートを開かないようにすることもできます。システムの予想される動作とデータ収集頻度に応じて、閾値を設定します。例えば、ウェブサイトでトラフィックの完全な損失やスループットが発生した場合、それに対応するNew Relicに送信されるテレメトリーデータも停止します。この信号損失を監視することで、このような停止の早期警告システムとして機能します。
</Collapser>
</CollapserGroup>
プロセスのこの時点で、条件が完全に定義され、必要なときにアラートがオープンされるようにするすべてのルールが設定されました。上記の設定に基づいて、設定した閾値に違反するシステム内の動作をアラート条件が認識すると、アラートが作成されます。ここで必要なのは、この条件に名前を付けてポリシーに添付することだけです。
ポリシーはアラートの分類システムです。ポリシーを作成すると、受信したすべてのアラートを整理するツールが作成されます。ポリシーを<DNT>**[workflows](/docs/alerts/get-notified/alert-event-workflows/)**</DNT>に接続して、このすべての受信情報の送信先、送信頻度、送信先をNew Relicに指示できます。
{/* <img
title="name an alert condition "
alt="A screenshot demonstrating how you can new alert condition."
src="/images/alerts_screenshot-crop_name-your-alert-condition.webp"
/> */}
<CollapserGroup>
<Collapser id="name-your-condition" title="条件に名前を付ける">
条件の命名のベストプラクティスとして、重要な情報がひと目でわかる構造化された形式があります。条件名には次の要素を含めます。
* **優先度**：アラートの重大度または緊急度を、P1、P2、P3のように示します。
* **信号**：高平均レイテンシや低スループットなど、監視するメトリクスや条件を指定します。
* **エンティティ**：WebPortalアプリやデータベースサーバーなど、影響を受けるシステム、アプリケーションやコンポーネントを識別します。
この構造に従うと、適切な条件名の例は「`P2 | High Avg Latency | WebPortal App`」になります。
</Collapser>
<Collapser id="select-an-existing-policy" title="既存のポリシーを選択します。">
アラート条件に接続するポリシーが既にある場合は、既存のポリシーを選択します。
ポリシーの作成について詳しくは、 [こちらを](/docs/alerts/organize-alerts/specify-when-alerts-create-events)ご覧ください。
</Collapser>
<Collapser id="create-a-new-policy" title="新しいポリシーを作成する">
アラート戦略では応答性と疲労のバランスを取ることが重要であり、`WebPortal`アプリケーションの`pageview`モニタリングに関する重要な考慮事項を示しました。ポリシーのオプションを見てみましょう。
1. ポリシーごとに1つのイシュー（デフォルト）：
* 長所：ノイズを軽減し、即時のアクションを保証します
* デメリット：異なる条件でトリガーされた場合でも、すべてのアラートが1つのイシューとしてグループ化されます。複数ページビューを扱う場合には理想的ではありません。
2. 条件ごとに1つのイシュー：
* 長所：条件ごとに個別のイシューを作成するため、特定の遅延問題を分離して対処するのに最適です
* 短所：より多くのアラートが生成され、疲労を引き起こす可能性があります
3. アラートごとのイシュー：
* 長所：外部システムに詳細な情報を提供しますが、過負荷になる可能性があるため、内部利用には最適ではありません
* 短所：これは最もノイズの多いオプションであり、より広範なトレンドを追跡し、効果的に優先順位を付けることが困難です
ポリシーの作成について詳しくは、 [こちらを](/docs/alerts/organize-alerts/specify-when-alerts-create-events)ご覧ください。
</Collapser>
<Collapser id="close-open-alert events" title="開いているアラートのクローズ">
対象の信号が条件の閾値で示された期間にわたって非違反状態に戻ると、アラートは自動的に終了します。この待ち時間を回復期間と呼びます。この待ち時間は回復期間と呼ばれます。
例えば、レイテンシを測定していて、違反行為が「`WebPortal`アプリケーションでページ読み込みの`duration`が3秒以上増加したこと」である場合、インシデントは`duration`が5分間連続して3秒未満になると自動的に終了します。
アラートが自動的に終了した場合：
1. 終了タイムスタンプは回復期間の開始時点に遡ります
2. 評価はリセットされ、前回の評価が終了した時点から再開されます。
すべての条件には、長時間続くアラートを自動的に強制終了するアラートの時間制限設定があります。
New Relicでは自動的にデフォルトで3日間が設定されるため、最初のアラートにはデフォルト設定を使用することをお勧めします。
信号がデータを返さないときに未解決のアラートをクローズするもう 1 つの方法は、 `loss of signal`閾値を構成することです。詳細については、上記の「損失信号閾値」セクションを参照してください。
</Collapser>
<Collapser id="custom-alert event-description" title="カスタムアラートの説明の設定">
`WebPortal`アプリケーションにレイテンシの問題があるかどうかを知らせるアラート条件を作成しているため、開発者がこのアラートについて通知されたときに必要な情報をすべて入手できるようにする必要があります。アラートが作成された際に、ワークフローを使用してチームのSlackチャネルに通知します。
カスタムアラートの説明については、[ドキュメント](/docs/alerts/create-alert/condition-details/custom-alert-event-descriptions)をご覧ください。
</Collapser>
<Collapser id="title-template" title="タイトルテンプレートを使用する">
{/* <img
title="alert details page"
alt="A screenshot depicting the final step of creating an alert condition- the alert details page"
src="/images/alerts_screenshot-crop_adding-alert-details-to-an-alert-condition.webp"
/> */}
タイトルテンプレートの使用はオプションですが、推奨されます。アラート条件は、監視したい一連の閾値を定義します。これらの閾値のいずれかに違反があった場合、アラートが作成されます。意味のあるタイトルテンプレートを使用することで、問題を正確に特定し、稼働停止の解決を迅速化できます。
タイトルテンプレートの詳細については、[ドキュメント](//docs/alerts/create-alert/condition-details/title-template/)をご覧ください。
</Collapser>
<Collapser id="runbook" title="ランブックURLを追加する">
調査、トリアージ、修復手順を詳述した運用ランブックは、このフィールドにリンクされることがよくあります。
</Collapser>
</CollapserGroup>
クロスアカウントアラートの詳細については、クロスアカウントアラートを参照してください。
既に作成したアラート条件を編集する場合は、次の操作を行うことができます。
- one.newrelic.com > All capabilities > Alertsに移動します。
- 左側のナビゲーションでAlert Conditionsを選択します。
- 編集するアラート条件をクリックします。
これでAlert conditions detailsページが表示されます。このページには、条件の作成時に設定したすべての要素が含まれています。各セクションの右上にある鉛筆をクリックすると、アラート条件の特定の項目を編集できます。
Signal historyの下に、アラート条件の作成に使用したNRQLクエリの最新の結果が表示されます。この例では、設定した特定の期間におけるWebPortalアプリの平均レイテンシが表示されます。
NRQLクエリで構築されたすべてのアラート条件について、Signal historyに折れ線グラフとして表示されます。
Syntheticモニターで構築されたアラート条件は少し異なります。これは、Syntheticモニターを使用すると、複数の場所からアプリケーションにpingを実行できるため、モニターが実行されるたびに肯定的な結果または否定的な結果が生成される可能性があるためです。このデータは表でのみ表示できます。
推奨される主な条件タイプはNRQLアラート条件ですが、他のタイプの条件もあります。以下に、条件タイプを網羅したリストを示します。
UIまたは[NerdGraph API](/docs/alerts/alerts-nerdgraph/nerdgraph-examples/nerdgraph-api-alerts-nrql-conditions)を使用して、[数値を返すベーシックなNRQLクエリ](/docs/new-relic-alerts-alert-nrql-queries)に対するNRQL条件を作成します。 NRQLを使用して条件を作成する際のヒントについては、[APMメトリクスアラート条件](/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/apm-metric-alert-conditions)を参照してください。 [異常アラート](/docs/alerts/new-relic-alerts/configuring-alert-policies/create-anomaly-alert-conditions)では、週ごと、または季節ごとのパターンなど、変化するデータとトレンドに動的に適応する条件を作成できます。この機能は、[](/docs/apm/new-relic-apm/getting-started/welcome-new-relic-apm)および[](/docs/browser/new-relic-browser/getting-started/new-relic-browser)アプリのほか、[NRQLクエリ](/docs/alerts/new-relic-alerts/defining-conditions/create-alert-conditions-nrql-queries)でも使用できます。 [複数の場所におけるSyntheticsモニタリングの条件](/docs/alerts/new-relic-alerts/defining-conditions/multi-location-synthetics-alert-conditions)を使用して、モニターを設定し、特定の数の場所で同時に障害が発生している場合に通知を受けられます。 APMでは、[キートランザクション](/docs/apm/transactions/key-transactions/introduction-key-transactions)の条件を設定できます。 閾値を、Javaアプリインスタンスのメトリクスがその閾値を超えた場合にアラートをオープンするように設定できます。[閾値を特定のインスタンスにスコープする](/docs/alerts/new-relic-alerts/configuring-alert-policies/scope-alert-thresholds-specific-instances)ことで、潜在的な問題がどこで発生しているかをより迅速に突き止めることができます。たとえば、アプリのインスタンスのサブセットのみで発生している異常を検出する場合に便利です。膨大な数のインスタンスにわたってメトリックスを集計するアプリの場合、このタイプの異常は容易に見過ごされてしまいます。
各アプリの[選択されたインスタンス](instance-alert-events)ごとに、閾値違反のアラートを個別に評価します。条件を作成する際、Javaアプリのアラートポリシーに対する条件タイプとして<DNT>**JVM health metric**</DNT>を選択してから、いずれかの利用可能な閾値を選択します。
* スレッドのデッドロック
* ヒープメモリの使用
* CPU利用時間
* ガベージコレクションのCPU時間
アラートは、閾値の逆数が満たされると自動的に閉じますが、UIを使用すると、JVM稼働メトリクスに関する[アラート](/docs/new-relic-solutions/get-started/glossary#alert-event)が強制終了する時間も変更できます。デフォルトは24時間です。
<Callout variant="tip">
[ウェブアプリケーション以外のトランザクション](/docs/using-new-relic/welcome-new-relic/getting-started/glossary#non-web-transaction)に対して、条件内に任意の閾値を設定する場合、[NRQLクエリ](#nrql-conditions)機能を使用してください。
</Callout>
パーセンタイル閾値を定義するには：
1. <InlinePopover type="apm" />アプリの条件の種類として<DNT>**Web transactions percentiles**</DNT>を選択し、アプリを 1 つ選択します（複数のアプリでアラートを発生させるには、それぞれに個別の<DNT>**Web transactions percentiles**</DNT>条\
件を作成します）。
2. アラートをオープンする閾値を定義するには、<DNT>**Percentile nth**</DNT>レスポンスタイム値を入力し、その頻度（この値より大きい、小さい、または等しい）を選択します。
ユーザーインタフェースにはクリティカルと警告の値が秒単位で表示されますが、New Relicにはトランザクションタイムがミリ秒で保存されます。ミリ秒で定義する場合は、値に小数点を含めます。
1つのラベルを使用して、関連のある<DNT>**all**</DNT>すべてのエンティティ（最大10,000エンティティ）を識別できます。ラベルを複数使用する場合は、選択されたすべてのラベルを共有するエンティティのみを識別します。
条件と合わせてダイナミックターゲティングを利用するには、[アラートクローズタイマー](/docs/alerts/alert-event-management/how-alert-condition-events-are-closed#time-limit)を設定する必要もあります。
1つの条件に対して最高で10個のラベルを追加、編集、削除するには：
1. 製品タイプとして<DNT>**APM > Application metric**</DNT>を選択します。
2. エンティティを識別するには、<DNT>**Labels**</DNT>タブを選択します。ラベルを名前で検索するか、カテゴリーのリストからラベルを選択します。
また、[インフラストラクチャ](/docs/infrastructure/new-relic-infrastructure/configuration/infrastructure-alerts-add-edit-or-view-host-alert-information)を使用して、監視対象の条件を直接作成することもできます。
たとえば、Infrastructureエージェントでデータが受信されなくなったときに通知を受信するには、[host not reporting](/docs/infrastructure/new-relic-infrastructure/configuration/create-infrastructure-host-not-reporting-condition)という条件タイプを使用します。これにより、フィルタリングされたホストグループに対してアラートを動的に送信し、5〜60分の時間枠を設定できるようになります。
ポリシーに条件を追加するには：
- 次のパスに移動します： one.newrelic.com > All capabilities > Alerts > Alert Policies
- ポリシーを検出します。
- Add a conditionをクリックします。
- 次のパスに移動します： one.newrelic.com > All capabilities > Alerts > Alert Conditions
- Add a conditionをクリックします。
ターゲットや閾値などを含む既存の条件をコピーし、選択したアカウントの別のポリシーに追加するには、次の手順を実行します。
-
one.newrelic.com > All capabilities > Alerts > Alert conditionsに移動します。
-
アラート条件のリストから、コピーしたいアラートの三点アイコンをクリックし、 Duplicate conditionを選択します。
-
Copy alert conditionから、リストを検索またはスクロールして、この条件を追加するポリシーを選択します。
-
オプション：必要に応じて条件名を変更します。
-
オプション：トグルスイッチを切り替えます： Enable on save
-
Copy conditionを選択します。
デフォルトでは、選択されたアラートポリシーはコピーされた条件を無効の状態で追加します。標準の手順に従ってアラートポリシーにさらなる条件を追加またはコピーし、必要に応じて条件を有効にします。さらに、新しい条件には、元の条件に追加されたタグはコピーされません。
条件を無効にしたり再度有効にするには、以下を行います。
- one.newrelic.com > All capabilities > Alerts > Alert Conditionsに移動します。次に、 Alert conditionsのリストからトグルを使用して条件を有効または無効にします。
- On/Offスイッチをクリックして切り替えます。
条件をコピーすると、元のポリシーで条件が有効（ On ）だったとしても、新しいポリシーでは自動的に無効（ Off ）として保存されます。
条件をオフにしてポリシーを維持するには、条件を無効にします。1つ以上の条件を削除するには、以下を行います。
-
one.newrelic.com > All capabilities > Alerts > Alert Conditionsに移動します。
-
Alert conditionsのリストから条件を選択し、省略記号メニュー（...）からDeleteをクリックします。
削除ボタンが表示されない場合は、アカウント管理者が組織の条件の削除を無効にしている可能性があります。
Alert Conditionページの履歴チャートに空の信号が表示される場合は、次のいずれかを検討してください。
- Review the condition's settings：すべての要素が正しく設定されていることを再確認します。
- Inspect NRQL queries：クエリが有効なメトリクスまたはイベントをターゲットにしており、データを返していることを確認します。
- Examine entity configuration：エンティティが信号を送信するように正しく設定されていることを確認します。
- Consult New Relic documentation：特定の問題については、関連するガイドを参照してください。