異常検知機能を利用すると、チームはシステム内の異常な挙動をより柔軟に検出できます。異常検出機能により、チームは任意のエンティティやシグナルにアラートを設定し、感度閾値を調整して最適化することができます。異常検出機能では、静的閾値アラートと同じストリーミングアラートパイプラインを使用し、同じ詳細なチューニング設定を使用します。これにより、ストリーム処理がテレメトリーシグナルの特性に合わせて調整され、誤ったアラート発報を抑制できます。
異常検出機能の設定にメタデータを追加することで、より詳細なコンテキストを提供することや、オンコール担当エンジニアに追加の指示を与えるカスタムのアラート説明を追加することができます。異常検出条件では、デフォルトでNew Relicの自動季節性検出を利用します。また、季節性設定をカスタマイズすることもできます。
異常検出の感度閾値を設定する
アラート条件から異常検出の感度閾値を作成できます。異常検出の閾値を設定するためのヒントをいくつかご紹介します。
- 異常値の上振れまたは下振れに対するアラートを監視するため、異常の方向を設定します。
- 季節性を設定することで、既知の季節性パターンを指定できます。
- スライダーバーを使用してCritical感度閾値を調整します。この閾値は、プレビューチャートではシグナルの周囲のライトグレーの領域として表示されます。シグナルの周囲の帯域が狭いほど感度が高くなり、発生するアラートの数も増えます。
- Warning閾値（異常の周囲のダークグレーの領域）を作成できます。
異常検出のアラート条件を作成するには、以下の手順に従ってください。
one.newrelic.com > All capabilities > Alerts > Alert Conditionsに移動します。
+ New alert condition > Use guided mode（またはより高度なクエリモード）をクリックしてください。
Set thresholdsまで、ガイドの手順を進めてください。
Anomalyを選択します。
アラート条件の季節性を計算するオプションを選択します。季節性とそれがアラート条件に与える影響を理解するには、季節性を参照してください。
1つ以上の設定を行います。異常検出機能は、過去のアクティビティをもとに、次のデータポイントを予測します。異常検出の閾値により、実測値が予測値からどの程度逸脱しても許容するかというアラート条件の感度を制御します。閾値とは、シグナル値が予測値からどの程度離れているかを標準偏差で表した値です。New Relicは、過去7日間のデータに基づいて予測値と実測値の差の標準偏差を追跡します。
閾値を設定するには、次の操作が必要です。
「閾値の方向」を上、下、または両方に設定します。この設定により、シグナル値（クエリの出力）が予測値より大きい場合、予測値より小さい場合、またはそのいずれかに該当する場合にアラートが作成されます。
このフィールドでは、指定期間内に何件のデータポイントが閾値を外れる必要があるかを指定します。for at leastとat least once inから選択します。for at leastを選択すると、指定期間内にシグナルのすべてのデータポイントが閾値を外れた場合にのみ、アラートがオープンになります。アラートをクローズするには、逆の条件が成立している必要があります。at least once inオプションは、シグナルのデータポイントのいずれかが閾値を外れた時点ですぐにアラートがオープンになります。このオプションでは、アラートがオープンになるタイミングの判定において期間は考慮されません。ただし、アラートのクローズでは期間が考慮されます。シグナルのすべてのデータポイントが指定期間にわたり閾値の範囲内にある必要があります。
「閾値の継続期間」を設定します。これは、アラートイベントがオープンされる前に、シグナル値が閾値の範囲外にとどまる必要がある時間と考えてください。逆に、アラートイベントをクローズするには、シグナルが閾値の範囲内にどれだけの時間とどまる必要があるかも示しています。
このフィールドでは上記の期間を指定します。シグナルが既定の閾値を外れる期間を指定します。これが実際に適用される閾値の継続期間となります。
「閾値のレベル」を設定します。カスタム異常検出の場合、これはシグナルのデータポイントが予測値からどれだけ離れているかを標準偏差で示します。
アラート条件の詳細を追加して、Save conditionをクリックします。
複数のシグナル条件の閾値設定（ファセットクエリ）
ステップ1で定義したクエリの内容によっては、アラート条件は1つのシグナルだけでなく、複数のシグナルを監視する可能性があります。NRQLを使用する場合、そのようなクエリではFACET句を使用します。1つのアラート条件で監視できるシグナルの最大数は20,000件です。指定した閾値設定は、その条件によって監視されているすべてのシグナルに同じように適用されます。各シグナルは個別に監視・評価されますが、設定はすべてのシグナルに一律に適用されます。プレビューチャートに表示されるシグナルは最大500件です。ただし、チャート上に複数のシグナルが表示されている場合は、予測シグナルと閾値の帯域は表示されません。最適な閾値を決定するためにその情報を表示するには、凡例から1つの時系列シグナルを選択して、チャートを単一の時系列に絞り込みます。
異常の方向：上限または下限を選択
条件が予測値を超える挙動（「Upper」）を検出するか、予測値を下回る挙動（「Lower」）を検出するか、その両方を検出するかを選択できます。これは予測方向セレクターで選択します。
使用例：
- エラー率などのデータソースの場合は、一般に値が下降した場合は問題にならずに上昇した場合にのみ問題になるため、Upper設定を使用します。
- スループットのようなデータソースの場合は、急激な上昇変動はよくあることですが、急激な下降変動は問題の兆候となるため、Lower設定を使用します。
以下に、異常の方向の設定によって、データの大きな変動がどのように扱われるかの例を示します。赤い領域はアラートを表します。
予測値の計算に関するルール
予測値を算出するためのアルゴリズムは、数学的に複雑です。以下に、予測能力に関する主なルールを示します。
- Age of data 初回作成時には、データの可用性と予測の種類に応じて、1週間から4週間分のデータを使用して予測が算出されます。現時点では、
FACET句を使用するクエリは、保存データを使った学習の対象になっていません。作成された後、アルゴリズムは長期間にわたるデータの変動を考慮に入れますが、より新しいデータが重視されます。データが短期間しか存在しない場合、予測値は大きく変動し、精度が低くなる可能性が高くなります。これは、その通常の値や挙動を判断するのに十分なデータがないためです。データの期間が長ければ長いほど、予測の精度は高くなります。 - Consistency of data メトリクス値が一定の範囲内で推移する場合や、緩やかで安定した傾向を示す場合は、挙動を予測しやすいため、感度閾値は予測値の周囲でより狭くなります。より変動が大きく予測しにくいデータでは、感度閾値の範囲は緩く（広く）なります。
- Regular fluctuations 1週間より短い周期的な変動に対して（毎週水曜日午後1時のデプロイメント、夜間レポートなど）、予測アルゴリズムは周期的な変動を探して、それに対応しようとします。
季節性
平日のトラフィックピークなど、シグナルの反復的な変動に対処するために、条件の季節性を指定できます。デフォルトでは、異常検出は** New Relic calculation**を使用して各シグナルの季節性を自動的に算出します。ただし、季節性の算出を特定の値に設定したり、完全に無効にしたりすることもできます。利用可能なオプションは以下のとおりです。
New Relic calculation （デフォルト）：データの経過時間、データの一貫性、規則的な変動など、いくつかの要因に基づいて各シグナルの季節性を自動的に判定します。
例:単一の条件で数十の異なるサービスを監視する動的なマイクロサービスアーキテクチャ。ユーザー向けサービスでは、トラフィックが日常的に急増する可能性がある一方、バックグラウンドで動作するサービスでは、予測可能なパターンが存在しない場合があります。この設定により、システムは手動調整なしで各シグナルに対応できるようになります。
Hourly：異常検出のために、その条件内のすべてのシグナルに時間単位のパターンを適用します。
例：毎時0分にリソースを大量に消費するcronジョブ（1時間ごとに実行されるデータ同期スクリプトやバッチキュー処理プロセスなど）を実行するサーバー。この設定は、CPUやメモリの使用パターンにおける異常を検出するのに役立ちます。
Daily：異常検出のために、その条件内のすべてのシグナルに日単位のパターンを適用します。
例：毎日午前8時からログイン率が急激に上昇し、午後5時以降は急激に低下する社内アプリケーション（人事ポータルやイントラネットなど）。
Weekly異常検出のために、その条件内のすべてのシグナルに週単位のパターンを適用します。
例：トラフィックが月曜日から木曜日にかけてピークに達し、金曜日には大幅に低下し、週末にはほぼゼロになるB2Bソフトウェアプラットフォーム。
None：季節性を完全に無効にし、シグナルを評価する際に季節性によるパターンが考慮されないようにします。
例：HTTP 500エラーやデータベース接続タイムアウトなどの重大なシステムエラー率を監視するモニター。これらのメトリクスは、理想的には常にゼロに近い水平のベースラインを維持する必要があります。午後2時に急増した場合、前日の午後2時に同じ現象が起きていたとしても、異常とみなされます。
ヒント
現在のソリューションでは、データ保持期間、計算、リアルタイム評価といった計算上の制約により、月単位や年単位の季節性オプションをサポートしていません。