New Relic でアラート条件を作成するには、チャートの使用、NRQL クエリの使用、ゴールデン メトリクスの使用の 3 つのオプションのうち 1 つを使用します。作成プロセスの開始部分は選択したオプションによって異なりますが、その後の手順はすべて同じです。これは、ある方法で条件を作成すると、それによって得た経験が、他のオプションのいずれかを使用して作成した他の条件に転送されることを意味します。
このチュートリアルには、前述の 3 つのオプションすべての手順が含まれているため、好きな方法で最初の条件から始めることができます。最初のステップでたどりたいパスを選択するだけで、手順が終わるまでに New Relic を使用して最初のアラート条件を作成することができます。
ヒント
以下の手順で説明するオプションまたは用語の詳細が必要な場合は、 アラート ドキュメントを参照してください。
チャートから開始することは、New Relic アラート条件を設定する最も簡単な方法の 1 つです。NRQL クエリを最初から作成する代わりに、チャートを使用すると、既存の NRQL クエリを使用してプロセスを開始できます。
この例では、エラー応答チャートを使用してアラート条件を設定します。開始したいチャートの種類を使用して、以下の手順に従います。
- 任意のダッシュボードに移動します。次に、使用するチャートを見つけて [...] メニューをクリックし、 Create alert condition [アラート条件の作成]を選択します。
- アラート条件の作成に使用する信号またはデータ ストリームを選択します。物事を簡単にするために、この方法で作成された条件のデフォルトのオプションは Build a query [クエリの構築] です。
- 必要に応じて、監視対象に一致するように NRQL クエリを変更します。現時点では、クエリをそのままにすることをお勧めしますが、アラートと NRQL クエリをより適切に処理できるようになったら、ほぼすべてのシグナルを監視するようにクエリを変更できます。
- 完了したら Next [次へ] を選択して進行状況を保存し、次のステップに進みます。
チャートの使用は、事前に作成されたクエリからアラート条件を作成する優れた方法ですが、場合によっては、最初からアラート条件を作成する必要があります。NRQL クエリから新しいアラート条件を作成するプロセスは、チャートから作成するプロセスとほぼ同じです。主な違いは、事前に生成された NRQL クエリを使用するのではなく、手動で NRQL クエリを作成することです。
ヒント
NRQL は New Relic の Query Language の略で、すべてのチャートを強化し、データの分析とクエリに使用できる標準化されたクエリメソッドです。NRQL を初めて使用する場合は、 NRQL ドキュメントを 参照して、NRQL の仕組み や 入門チュートリアルなど、NRQL について詳しく学んでください。
one.newrelic.comから、 Alerts & AI [アラートと AI]を選択し、次に Alert conditions (policies) [アラート条件 (ポリシー)] を選択します。
New alert condition [新しいアラート条件]を選択します。
NRQL クエリを記述して条件を作成します。たとえば、遅いトランザクションを監視したい場合は、次のように入力できます。
SELECT average(duration) from Transaction facet name完了したら Next [次へ] を選択して進行状況を保存し、次のステップに進みます。
最も簡単に始める方法の 1 つは、 Golden signal or metric [ゴールデン シグナルまたはメトリック] オプションを使用することです。この機能を選択すると、条件を作成するためのガイド付き作成パスが提供されます。あなたがしなければならないのは、必要なオプションを選択することだけです。あとは私たちにお任せください。
次の例では特定のオプションを使用しますが、特定のニーズに合った正確なアラート条件を作成するために必要なものはすべて変更できます。
- one.newrelic.comから、 Alerts & AI [アラートと AI]を選択し、次に Alert conditions (policies) [アラート条件 (ポリシー)] を選択します。
- New alert condition [新しいアラート条件]を選択します。
- [ゴールデン シグナルまたはメトリクス]を選択します。
- リストされたエンティティ カテゴリのいずれかを選択して、アラート条件が監視するものを決定します。この例では On host integrations [ホスト統合] が選択されていますが、ニーズに適した他のオプションを選択することもできます。
- AWS、Kubernetes、ホスト統合などのサービスを使用している場合は、個々のエンティティを選択する前にエンティティ タイプを選択する必要もあります。エンティティ タイプを選択して、次のステップのオプションを絞り込みます。
- 監視するエンティティを選択します。選択するエンティティが多数ある場合は、フィルター フィールドを使用してリストを短縮し、必要なものを見つけることができます。
監視したい信号を選択します。この例では First input delay (75 percentile) [最初の入力遅延 (75 パーセンタイル)]を使用しますが、ニーズに適した他のオプションを使用することもできます。
厳選されたゴールデン メトリックを選択することも、過去 30 分間にレポートされた他のメトリックから選択することもできます。
完了したら Next [次へ] を選択して進行状況を保存し、次のステップに進みます。
ヒント
利用できるカテゴリは、New Relic がアカウントで何を監視しているかによって異なります。
信号の動作を調整する
データ集約オプションを設定します。
- ウィンドウ期間: Window duration [ウィンドウ期間] 設定を使用して、5 分ごとまたは 1 時間ごとのグループ化など、データを集計する頻度を決定します。この機能の設定は、監視しているデータの種類によって異なります。どのような設定にすべきかわからない場合は、デフォルト設定のままにしておくことができます。
- スライディング ウィンドウ集約: スライディング ウィンドウ集約を使用するかどうかを選択します。この機能は、重複する集計ウィンドウを作成することにより、不規則なデータを処理する場合に、より滑らかなグラフを作成します。この機能はデフォルトでは無効になっており、最初のアラートでは無効のままにすることをお勧めします。
- ストリーミング方式: 最も一般的に使用されるオプションは、 Event flow [イベント フロー] と Event timer [イベント タイマー]です。Event flow [イベント フローは] 、頻繁かつ一貫してレポートするデータに最適ですが、 Event timer [イベント タイマーは]、 一貫性のないデータ、まれにレポートするデータ、またはバッチで取り込むデータに最適です。個々の設定について詳しく知り、各シナリオでどの方法を使用する必要があるかを確認したい場合は、 ドキュメントを参照してください。
タイミング オプションを設定します。これは、各ウィンドウでイベントを評価する前にイベントを待機する時間を決定します。遅延が長くなると、誤ったアラートが少なくなりますが、インシデントがオープンになるまでの潜在的なダウンタイムも長くなります。この機能は、選択したオプションに応じて表示方法も異なります。 Event flow [イベント フロー] および Cadence [ケイデンス] のオプションでは Delay [遅延] と呼ばれ、 Event timer [イベント タイマー] では Timer [タイマー]と呼ばれます。最初のアラートでは、デフォルトの時間設定をそのまま使用することをお勧めします。
ギャップ埋め戦略を選択します: ギャップ埋めは、データ レポートの空白期間をユーザー定義の合成値で埋める事後対応機能です。データ レポートが散発的であると思われる場合は、空の集計ウィンドウにこのデータを入力することで、誤ったアラートを回避できます。最初のアラートでは、 Gap-filling strategy [ギャップ充填戦略] で None [なし]を選択します。
評価遅延を選択します: このオプションを使用すると、設定したしきい値に対して新しい信号を評価する前に New Relic が待機する時間が有効になります。これは、データ ストリームのレポート開始時の誤検知インシデントを防ぐのに役立ちます。最初のアラートでは、このオプションがデータに適用されることがわかっていない限り、トグルを無効のままにしておくことができます。
完了したら Next [次へ] を選択して進行状況を保存し、次のステップに進みます。
静的しきい値を設定する
- まず、 [セキュリティ レベル] セクションで、しきい値のステータスを [重大] にするか、 [警告] にするかを選択します。
- 制限に達した場合にインシデントが開始される制限を設定します。これらの値は、条件で実行したい内容に応じて変化します。たとえば、エラー メッセージの条件を作成する場合は、しきい値を 5 分に 1 回以上 1 に 設定しますが、より長い期間のレイテンシの問題に対応する条件を作成する場合は、 少なくとも 15 分間、しきい値が 50 以上になるようにします。
- 別のしきい値を追加する場合は、必要に応じて、 [しきい値を追加 ] または [損失信号しきい値を追加]を選択します。損失信号しきい値は、レポートを停止する可能性のあるエンティティや、 null 値を返す可能性のあるクエリを監視する場合に重要です。
- 完了したら Next [次へ] を選択して進行状況を保存し、次のステップに進みます。
アラート条件の詳細を追加する
- Name [名前] フィールドにアラートの名前を追加します。これは、この状態を特定するのに役立ちます。また、将来編集または削除する必要がある場合にその状態を見つけるのにも役立ちます。
- この条件に接続するポリシーを選択します。 Existing policy [既存のポリシー]がある場合は、ドロップダウンからそれを選択します。そうでない場合は、 New policy [新しいポリシー] を選択してここから ポリシーを作成する 必要があります。
- アラートの追加設定を設定します。これには、オープンなインシデントが自動的にクローズされるまでの時間を設定したり、インシデントの カスタム説明を 入力したりすることが含まれます。
- Save condition [条件を保存] を選択して終了します。
これでアラート条件が作成され、システム内の症状の特定が非常に簡単になりました。アラートには多くの構成オプションが用意されているため、チームのニーズや監視対象に基づいてアラートを微調整できます。それが最初のアラート条件である場合は、その仕組みに慣れるために、さまざまなオプションを使用してグラフからさらに作成することをお勧めします。NRQL クエリから条件を作成することもできます。これについては、このチュートリアル シリーズの次のトピックです。
アラートからさらに多くのことを得る
チームにとってアラートをより効率的かつ管理しやすくするのに役立つ、高度なアラート機能がいくつかあります。
- アラートをいつどこで受信するかをより詳細に制御し、問題について適切な担当者に確実に通知できるようにしたい場合は、 「ワークフローの使用方法」を参照してください。
- 重要なアラートのほぼ即時通知を有効にして平均解決時間 (MTTR) を短縮したい場合は、 応用インテリジェンスを備えた異常検出の使用方法を参照してください。
- API を使用して New Relic アラートを管理する場合は、 REST API または GraphQLを使用して実行できます。