アラート しきい値 を設定して、Javaアプリのインスタンスのいずれかがそのしきい値に違反したときにトリガーすることができます。条件をアプリのインスタンスにスコープすることは、アプリのインスタンスのサブセットでのみ発生する異常を検出するのに役立ちます。
このような異常は、多数のインスタンスに渡ってメトリクスを集約するアプリケーションでは見逃されがちです。インスタンスごとに見ることで、潜在的な問題がどこから発生しているかをより迅速に特定することができます。
例
この例では、3 つのインスタンスを持つ Java アプリのポリシーを設定します。任意のインスタンスのエラー率に対する状態の重大なしきい値が 0.02% を超えている場合に、インシデントをオープンする必要があります。少なくとも5 分間。
5分間での3つのインスタンスのエラー率は以下の通りです。
アプリのインスタンス | 午後4時45分 | 午後4時50分 | 違反したときには？ |
|---|---|---|---|
A | 0.00% | 0.00% | いいえ、このインスタンスはずっと目標値を下回っていました。 |
B | 0.02% | 0.03% | はい。 警告のしきい値が、このインスタンスの0.02%のしきい値を少なくとも5分間超えました。 |
C | 0.10% | 0.00% | いいえ。違反をオープンにするには、 の閾値が少なくとも5分連続で破られる必要があります。 ただし、 を5分間に1回以上 に設定していた場合は、5分間の間に を少なくとも1回 破る必要があります。 |
インスタンスベースのアラート条件の作成
アプリの個々のインスタンスによるインシデントの通知をトリガーするポリシーを作成するには:
- 基本的なワークフローのプロセス に従って、ポリシーを設定します。
- 条件 を作成するとき（ステップ2）、 APM を選択します。
- 条件の種類として、 アプリケーション・メトリック を選択します。
- アラート閾値違反 個別に アプリの選択された各インスタンスについて計算するには、 Scope to Java application instances を選択します。
- Select 次に、Entity を選択し、この条件に対応する1つまたは複数のアプリを特定します。
- オプション: アラートがインシデントを強制終了する時間を変更します (デフォルトは 24 時間です)。
- Use By condition or By condition and signal incident preference.
- ポリシーワークフローの残りのプロセスを続ける（ステップ3）.
ヒント
アプリのすべてのインスタンスの平均に基づいてインシデントを開くには、[ Java アプリケーション インスタンスにスコープする]ではなく、[アプリケーションにスコープする] を選択します。
Use"By condition" incident preference
インスタンスベースの条件を含むポリシーに インシデントの優先順位 を設定する際には、 By condition and signal ではなく By condition を選択することをお勧めします。この条件ではアプリが選択されていますが、各JVMを個別のエンティティとして評価します。
インシデントの環境設定 を By condition and signal に設定すると、クリティカルな閾値を超えた各JVMに対して個別のインシデントが開かれます。アプリが複数のJVMにまたがって障害を起こすと、アラート"疲労" やフラストレーションにつながる可能性があります。
インスタンスアラートにREST APIを使用
New Relic REST API でインスタンスベースの アラート条件を作成するには、REST API コールに以下の項目を含めてください。
- あなたの API キー.
- 監視対象のエンティティの数値
entity_id condition_id（APIエクスプローラーから入手可能：アラート条件> GET>リスト）entity_type（"application"に設定）condition_scope（Javaアプリケーションインスタンスの場合は"instance"に設定され、Javaアプリケーションの場合は"application"に設定されます）
ここでは、APIリクエストフォーマットとJSONレスポンスの例をご紹介します。