最初のアラートの作成

まず、 Web transactions timeというラベルの付いたグラフに移動し、 create an alert conditionをクリックします。

アラート状態にわかりやすい名前を付けることが重要です。 この条件にresponse timeという名前を付け、まったく異なるアプリケーション用に別の条件を作成し、その条件にもresponse timeというラベルを付けるとします。 このような状況が発生すると、どの条件がどのアプリケーションに該当するのかを区別できなくなります。 したがって、症状には必ず具体的で一意の名前を付けるようにしてください。 この場合、この条件にResponse time: Example-appという名前を付けます。

条件に名前を付けたら、必要に応じて NRQL クエリを変更できます。最初のアラートでは、NRQL クエリを調整せず、このセクションをそのままにしておくことをお勧めしますが、NRQL を使用してクエリをカスタマイズする方法について詳しく知りたい場合は、 ドキュメントを参照してください。

あなたのチームはこのアラート条件を作成しているので、Web レスポンス時間が通常より長くなると通知されます。 しかし、Web の トランザクションタイム がどれだけ長くなるかは気にせず、 トランザクションタイム が異常な動作をしているかどうかだけを知りたいとします。 この特定のユースケースでは、 anomaly thresholdを使用することをお勧めします。 当社の異常検出機能は、システムの通常の動作を把握するためにデータを継続的に評価します。 異常閾値を設定すると、Web レスポンスタイムが期待されるパフォーマンスから逸脱した場合に、異常検出機能を使用してチームを集計できます。 ウェブ トランザクションタイムが異常に動作しているかどうかのみを知りたい場合は、すべての偏差の通知が必要なので、 upper and lowerを選択します。 ただし、ウェブレスポンス時間が通常より長くかかった場合にのみアラートを通知したい場合は、 upper only.

次に、優先度を設定する必要があります。 優先度レベルによって、インシデントを作成する内容が決まります。 最初の集計では、優先度レベルをcriticalに設定することをお勧めします。 優先レベルの詳細については、 アラート条件ドキュメントをご覧ください。

次に、 critical anomaly threshold breachを定義するものを選択する必要があります。 この最初の集計では、デフォルト設定を使用し、必要に応じて調整することをお勧めします。 したがって、設定は「クエリが予測値から外れた値を返す場合: for at least five minutes by 3 standard deviations 」のインシデントを開くようにしておきます。

異常の詳細については、異常に関するドキュメントをご覧ください。

異常閾値とは異なり、静的閾値はデータセット全体を調べず、システムの履歴に基づいて異常な動作を判断します。 代わりに、システムが設定した基準と異なる動作をする場合は常に、静的な閾値によってインシデントが開きます。 静的集計閾値はカスタマイズ性が非常に高く、データと探しているものについて明確な認識がある場合に推奨されます。

NRQL ドキュメントで静的アラート条件の詳細をご覧ください。

場合によっては、着信信号が失われることがあり、それが単なる遅延なのか、より広範な問題の兆候なのかを理解することが重要です。 loss signal thresholdは、最後のデータ ポイントが検出されてから信号が失われたと判断するまでにシステムが待機する秒数を示します。 設定した制限時間内に信号が戻らない場合は、新しいインシデントを開く、および/または開いているすべてのインシデントを閉じるという 2 つのアクションのいずれかまたは両方を選択できます。 失われた信号がこのエンティティ上の他のインシデントよりも優先される場合、または信号の損失が予想されていた場合は、関連するオープン インシデントを閉じることができます。

失われた信号の閾値を設定するには、システムに関する知識と、理解したい内容が必要です。 Web トランザクションタイムの場合、 New Relic 1 分ごとに信号を収集するとします。 信号が失われると、さらに大きなレイテンシの問題が発生する可能性があります。 したがって、快適な時間に設定してから、ボックスをopen a new lost signal incidentにチェックすることをお勧めします。

アラート条件のウィンドウ期間を設定すると、データをグループ化する方法が New Relic に伝えられます。New Relic に 1 時間に 1 回シグナルを送信するデータ セットのアラート条件を作成している場合は、ウィンドウ期間を 60 分に近い値に設定すると、パターンや異常な動作を特定するのに役立ちます。ただし、Web トランザクション時間のアラート条件を作成していて、New Relic がそのデータのシグナルを毎分収集する場合は、ウィンドウ期間を 1 分に設定することをお勧めします。

最初のアラートでは、デフォルト設定をそのまま使用することをお勧めしますが、アラート条件の作成に慣れるにつれて、自分の経験に基づいてこれらのフィールドをカスタマイズすることをお勧めします。

一日を通して、データはアプリケーションから New Relic にストリーミングされます。 アラート条件では、インシデントについてそのデータをすぐに評価するのではなく、 aggregation windowと呼ばれる期間にわたってデータを収集します。 追加の遅延により、ウィンドウが集約される前に遅いデータ ポイントが到着できるようになります。

スライディング ウィンドウは、「とがった」チャートを滑らかにする必要がある場合に役立ちます。一般的な使用例の 1 つは、スライディング ウィンドウを使用して、短い時間枠からの集計よりもローリング集計が重要な場合に、短期間に多くの変動がある折れ線グラフを滑らかにすることです。

安定した一貫したデータ ストリームが期待されていないが、データに多少の落ち込みや急増が予想される場合は、スライディング ウィンドウ集計を使用することをお勧めします。

スライディング ウィンドウ集計の詳細については、 この NRQL チュートリアルまたはこのビデオをご覧ください。

一般的には、 event flowストリーミング メソッドを使用することをお勧めします。 これは、システムに頻繁かつ安定して入力されるデータに最適です。 event timerを選択する方がよい場合もありますが、最初の集計ではデフォルトのevent flowをお勧めします。 どのストリーミング方法を選択すればよいかをよりよく理解するには、この短いビデオを視聴することをお勧めします。

遅延機能は、一貫性のないデータ収集からユーザーを保護します。インシデントを作成するかどうかを決定する前に、アラート条件に少し余裕を持たせます。データが 1 分間だけのタイムスタンプで New Relic に到着する場合は、低遅延設定で十分です。一方、その 1 分間に New Relic が数分前または数分前のタイムスタンプを持つデータ ポイントを受信した場合、シグナルはより一貫性がなくなり、より高い遅延設定が必要になります。

私たちは、Web ランタイムに関するレイテンシの問題をチームに通知するためのアラート条件を作成しています。 この場合、アプリケーションは New Relic データを一貫して送信します。 アプリケーションから New Relic に送信される信号ストリームが一定量存在し、信号にギャップは予想されないため、ギャップを埋める戦略を選択する必要はありません。 このユースケースと最初の集計では、 gap-filling strategyをnoneに設定したままにしておくことをお勧めします。

24 時間ごとに 1 回 New Relic にシグナルを送信する一貫性のないデータ セットがある場合は、チームの特定のニーズに基づいてこの機能をカスタマイズすることをお勧めします。

失われたシグナルのドキュメントで、ギャップを埋める戦略の詳細をご覧ください。

アラート条件に関連付けるポリシーがすでにある場合は、既存のポリシーを選択します。

ポリシーの作成方法について詳しくは、 こちらをご覧ください。

このアラート条件に対して新しいポリシーを作成する場合は、ここがチャンスです。ポリシーはワークフローに関連付けられており、ワークフローはインシデントについて通知される頻度を制御することに注意してください。これは、Web トランザクション時間の問題をできるだけ早く把握することと、開発者が疲労を感じたり、情報過多のために重要な情報を見逃したりするほど多くのアラートを受信しないようにすることとのバランスです。

ポリシーには、1 つまたは複数の条件を保持できます。Web トランザクションの遅延を監視する場合は、いくつかのオプションがあります。

まず、ポリシーごとに 1 つの問題のみを添付するポリシーを作成できます (デフォルトのオプション)。 ポリシーごとに 1 つの問題を指定すると、ノイズは減りますが、即時の対応も必要になります。 ただし、これは、このポリシーにResponse time: Example appだけでなく複数の条件を添付した場合、何があっても、このポリシー内のすべてのインシデントが 1 つの問題にグループ化されることを意味します。

または、条件ごとに 1 つの問題を作成することもできます。 つまり、 Response time: Example app条件がインシデントを開くたびに、それらのインシデントはすべて、条件に関連付けられた 1 つの問題にまとめられます。 この特定のユースケースでは、Web トランザクションタイムに関するレイテンシの問題を監視するという主な目的を満たすため、このオプションを選択する必要があります。

または、インシデントごとに問題を作成することもできます。このオプションは最もノイズが多いですが、外部システムに情報を送信したい場合にはうまく機能します。

ポリシーの作成方法について詳しくは、 こちらをご覧ください。

対象の信号が条件のしきい値で示された期間にわたって非違反状態に戻ると、インシデントは自動的に終了します。この待ち時間を回復期間と呼びます。

たとえば、違反行為が「Web トランザクション時間が 0.50 秒を超えている」である場合、少なくとも 5 分に 1 回秒」の場合、Web トランザクション時間が 0.50 以下になると、インシデントは自動的に終了します。連続5分間。

インシデントが自動的にクローズされる場合:

1. クロージングのタイムスタンプは、リカバリー期間の開始時にさかのぼって表示されます。

2. 評価はリセットされ、前のインシデントが終了した時点から再開されます。

   すべての条件には、長期にわたるインシデントを自動的に強制終了するインシデントの時間制限設定があります。

   デフォルトは自動的に 3 日間であり、最初のアラートにはデフォルト設定を使用することをお勧めします。

Web トランザクション時間に遅延の問題があるかどうかを知らせるアラート条件を作成しているため、開発者がこのインシデントについて通知されたときに必要なすべての情報を確実に入手できるようにしたいと考えています。ワークフローを使用して、インシデントが作成されたときにチームの Slack チャネルに通知します。

カスタム インシデントの説明について詳しくは、 ドキュメントをご覧ください。

Runbook にリンクする場合は、Runbook URL フィールドに URL を入力できます。