外れ値検出

New Relic の外れ値検出は、他のエンティティとは大きく異なる動作をしているエンティティを自動的に識別するように設計された高度な機能です。時間の経過とともに異常なパターンを探す従来の異常検出とは異なり、疑わしい検出は、特定の瞬間におけるグループ内の逸脱に焦点を当てます。

この機能により、次のような潜在的な問題を事前に特定できます。

クラスタ内の他のサーバーと比較して、CPU 使用率が高いサーバーが 1 つある
Kafka ブローカーがメッセージを正しく処理しない

これらの「外れ値」を正確に特定することで、関連する下流システムを迅速に見つけ、障害の可能性を推測し、平均検出時間 (MTTD) と平均回復時間 (MTTR) を短縮できます。

重要な概念

これらのコア概念を理解すると、外れ値検出を効果的に構成するのに役立ちます。

DBSCAN:密接に詰め込まれた点をグループ化すると同時に、どのクラスタにも属さない点として想定値を識別する、密度ベースのクラスタアルゴリズム。
Epsilon (Eps): 2 つのポイントが同じ近傍の一部であるとみなされる最大距離を定義します。値が小さいほどクラスターが密になり、値が大きいほどクラスターが緩くなります。
最小ポイント (MinPts):クラスターを形成するために必要な最小ポイント数。ほとんどのユースケースでは、3 より大きい値が推奨されます。
評価グループ:想定値分析をさまざまなファセット (環境、地域、アプリケーションなど) ごとにセグメント化して、データセット全体ではなく各グループ内で個別に想定値を検出できるようにします。これにより、各グループ内で外れ値が個別に検出され、複数のアラート条件の必要性が軽減されます。

自動モードと手動モード

コアを設定するには 2 つの異なるモードがあり、データの適切な集計を確実に取得できます。

Auto mode [自動モードは]、推測値集計を設定する最も簡単な方法です。これにより、アルゴリズムの技術的な詳細をスキップできるため、複雑な機械学習を理解する必要がなくなります。

技術的な問題を設定する代わりに、単純な感度スライダーを調整します。システムは自動推定を使用して、選択した感度レベルに対応する最適なイプシロン (Eps) と最小ポイント (MinPts) の値を即座に計算します。

自動推定がデータに適切かどうかを確認するには、データの視覚化を観察します。チャート上で外れ値としてフラグが付けられた信号が、異常に関する常識的な理解と一致している場合、自動モードは効果的に機能しています。

Manual mode [手動モード]は、上級ユーザー向け、またはシステムの自動推定がデータの固有の特性に完全には適合しない状況向けです。手動モードに切り替えると、DBSCAN を直接制御できるようになります。

自動モードの結果が不正確な場合は、手動モードに切り替える必要があります。

システムは、視覚的にはまだクラスターの一部である信号を外れ値としてフラグ付けします。
システムは、メインデータクラスターから明らかに離れている信号をフラグ付けできません。
感度スライダーを全範囲にわたって動かしても、検出された外れ値に意味のある変化はほとんどまたはまったく生じません。

外れ値検出アラート条件を作成する

外れ値検出によるアラート条件を作成するには、次の手順に従います。

New Relicアカウントで、 one.newrelic.com > All capabilities > Alerts > Alert Conditionsに移動します。
+ New alert conditionをクリックし、Use guided mode [ガイドモードの使用]またはQuery** [クエリ]モードのいずれかを選択します。どのモードを選択したかに関係なく、set thresholds「閾値の設定」ページでアラート条件の閾値を設定します。
閾値設定ページに到達するまで手順を進めます。
Outliers [外れ値]を選択します。
アルゴリズムモードを選択します。
- Auto [自動]モードを選択した場合は、感度スライダーを調整して検出を微調整します。このモードでは、システムは履歴データに基づいて最適な内部点 (DBSCAN のイプシロン点や最小点など) を自動的に決定します。
- Manual [手動]モードを選択した場合は、イプシロンと最小ポイントの値を自分で指定できます。
必要に応じて、評価グループを構成します。
残りのアラート条件の設定を完了します。

設定ベストプラクティス

イプシロン値の選択

デフォルト値から始めて、データの特性に応じて調整します。
誤検知率を監視し、それに応じて調整します。
イプシロンが小さいほど、検出感度が高くなります。
イプシロンが大きいほど、検出感度が低くなります。

最低ポイントの設定

ほとんどのシナリオでは 3 より大きい値を使用します。
値を大きくするとノイズは減りますが、微妙な外れ値が見逃される可能性があります。
この値を設定するときは、通常のグループのサイズを考慮してください。

評価グループを効果的に活用する

論理境界 (環境、地域、サービス) 別にグループ化します。
効果を低下させる可能性がある過度なセグメンテーションは避けてください。
グループ化する際には、季節性とビジネスパターンを考慮してください。

遅延データと古いタイムスタンプの処理

外れ値検出は、同一時点における複数のエンティティのメトリクスを比較することで機能します。公平な比較を行うには、すべてのエンティティが同じ時間枠のデータを報告する必要があります。

遅延したタイムスタンプの問題

午後2:00に3台のサーバーのCPU使用率を監視していると想像してください：

サーバーAはタイムスタンプ付きで45％のCPUを報告します 2:00 PM
サーバーBはタイムスタンプ付きで50％のCPUを報告します 2:00 PM
サーバーCはタイムスタンプ付きで95％のCPUを報告します 1:30 PM

サーバーCのデータには、より古いタイムスタンプ（午後2:00ではなく午後1:30）があります。システムは午後1:30のデータと午後2:00のデータを比較できません — それは全く異なるものを比較するようなものです。その結果、サーバーCは外れ値分析から完全に除外されます。サーバーCで明らかに問題が発生しているにもかかわらず、一度も評価されていないため、集計を受け取ることはありません。

これは、エンティティが、分析対象の現在のタイムウィンドウよりも古いタイムスタンプを持つデータを継続的に報告する場合に発生します。

よくある原因

クラウドプロバイダーのポーリング: AWS CloudWatchや同様のサービスはスケジュールに従ってメトリクスを収集し、その後New Relicがそれらをポーリングします。たとえば、午後2:00を表すメトリクスが午後2:05までNew Relicに到着せず、5分の遅延が生じることがあります。
長時間実行トランザクション: バックグラウンドジョブは、終了時ではなく開始時にタイムスタンプが記録されます。1:30 PMに開始して30分間実行されるジョブは、そのデータが2:00 PMに到着したときに1:30 PMのタイムスタンプを持ちます。
バッファされたデータ: ネットワークの問題やエージェントの設定により、データがローカルでキューに格納される場合があります。接続が復旧すると、バッファリングされたすべてのデータは元のタイムスタンプとともに到着します。

除外されたエンティティの特定

どのエンティティが除外されているか、およびその理由を確認するには、NrAiSignalイベントをクエリします：

FROM NrAiSignal
SELECT *
WHERE conditionId = 1234
  AND outlierProcessingSkippedReason IS NOT NULL

1234をアラート条件IDに置き換えてください。確認すべき主要なフィールド：

outlierProcessingSkippedReason: シグナルが除外された理由（通常、遅延データの場合はLATEが表示されます）
outlierProcessingSkippedTimeDelta: データのタイムスタンプと現在の評価ウィンドウ間の秒単位の時間差

問題の解決

条件エディタでシグナルが除外されているという警告が表示された場合：

オプション1：条件を分割する（推奨）

レポート動作が異なるエンティティには、別々のアラート条件を作成します：

リアルタイムアプリケーションサーバーの1つの条件
クラウドでポーリングされるリソース（AWS CloudWatchメトリクスなど）の別の条件

これにより、各条件の集計ウィンドウが、エンティティが実際にデータを報告する方法と確実に一致するようになります。

オプション2：集計ウィンドウを拡大する

遅延に対応するため、集計ウィンドウを拡張してください。たとえば、データが常に3～5分遅延する場合は、1分ではなく5分の集計ウィンドウを使用してください。

トレードオフ: ウィンドウを大きくすると、短期的なスパイクが平滑化され、集計がトリガーされるまでの時間が長くなります。午後2:00にスパイクが発生したサーバーは、午後2:05以降になるまで集計をトリガーしない場合があります。

ユースケースと例

バランスの悪い Kafka ブローカー: CPU I/O待機時間が異常なブローカーを迅速に特定し、アドミニストレーターがパフォーマンスに影響を与える前に積極的にワークロードのバランスを再調整できるようにします。
リソース使用率の外れ値:常に十分に活用されていない、または過剰に活用されているリソースを特定します。これにより、より適切なキャパシティプランニングが可能になり、無駄や潜在的なボトルネックを防ぐことができます。
「騒々しい隣人」の識別:不均衡な量の共有リソースを消費しているリソースを大量に消費するエンティティを検出します。これにより、リソース割り当てのバランスをとるための是正措置が可能になります。
Javaアプリケーションのメモリの問題:異常なメモリ不足 (OOM) エラー率を伴うJava仮想マシン (JVM) を早期に検出し、広範なアプリケーション障害を防ぐためのタイムリーな介入を可能にします。
環境固有の監視:評価グループを使用してステージングと本番環境を個別に監視し、ある環境での膨大な値が別の環境での検出を妨げないようにします。

この機械翻訳は、参考として提供されています。

重要な概念 .css-21sua1{background:none;border:none;width:0;padding:0;}