メトリックのグループ化問題

問題

アカウントまたはアプリケーションが、グループで管理した方がよい個別のメトリックスを送信し過ぎた場合、New Relicはメトリックのグループ化問題またはMGIとしてこの問題を表現します。これが起きている際、エージェントは不必要に大量なデータをNew Relicに送信しており、これが原因となってNew Relicユーザーインターフェース内のチャート、表、そしてレポートの有効性が損なわれることとなります。

メトリックのグループ化問題が最も起きやすいのはWebトランザクションであり、特に当てはまるのはURLに基づく命名が行われた場合です。また、ご利用のアプリケーションが報告した他のメトリックスにおいても発生する場合があります。例えば:

  • ご利用のアプリケーションがインターネットをクローリングしており、それぞれの外部呼出しが異なるドメインに達する場合
  • ご利用のソフトウェアが、リクエストを受信する度にデータベースの一時テーブルを動的に生成する場合
  • UUID、記事名、またはその他の類似したユニークコンポーネントを含むカスタムインストゥルメンテーションを使用している場合

メトリックスを効果的にグループ化するのではなく、メトリックスの無限なリストを作成できるかもしれない状況(コントローラー、恒久的なデータベースの表、もしくは具体的な外部サービス同様)では、メトリックのグループ化問題につながる可能性があります。

解決策

メトリックのグループ化問題とは何か、またその問題がどのように発生するかを把握することで、メトリックスをより効果的にグループ化し、メトリックのグループ化問題の発生を防ぐためにNew Relicが御社のアプリケーションとどのように動作しているのか理解を高めることができます。

メトリックのグループ化:グループ化の前後
ここで示しているのは、メトリックのグループ化がトランザクションの整理を容易にし、パフォーマンス問題を特定しやすくしていることを示す、グループ化の「前」と「後」の例です。

アプリケーションでメトリックのグループ化が発生するのを防ぐには:

  1. New Relicのリリースノートを参照して、New Relicエージェントの最新版を実行していることを確認してください。
  2. 必要であれば、ご利用のNew Relicエージェントを最新版にアップグレードしてください。
  3. 数分待ってから、新しいデータをNew Relic UIで確認してください。

それでも問題が解決しない場合は、次のエージェントの手順に従います。

エージェント MGIの防止
すべてのエージェント 何がメトリックのグループ化問題を引き起こしているのか見直しましょう。
Browser URLグループの追加
C SDK トランザクションの名前に、URLを使用しないでください。その代わりに、手順に従ってアプリをC SDKで測定します。
Go Goトランザクションの名前を変更します。
Java Javaのメトリックのグループ化問題を参照してください。
.NET SetTransactionNameでメトリクスの名前を変更してください。XMLを使用して詳細を追加するには、名前のトランザクションを参照してください。
Node.js Request API呼び出しを使用してトランザクションの名前を変更します。
PHP PHPトランザクションの名前を変更します
Python set_transaction_nameを使用してPythonトランザクションの名前を変更します。
Ruby Rubyトランザクションの名前を変更します

原因

メトリックのグループ化問題は、メトリック名の粒度(多くの場合はトランザクション名)が細かすぎる場合に発生することで、少数のコードパスのために何百、何千という数の異なるWebトランザクション名が出来上がることになります。いくつかの主要なコードパスは、ユニークなドキュメント、記事、ページなどに異なる完全なURLパスを生成する可能性があります。このURLパスのユニークな要素がトランザクション名に含まれている場合、こうした共通のパスが独自のユニーク名をそれぞれ保有することにつながります。

MGIの例

この例のアプリケーションでは、ユーザーがあらゆる主題に関して記事を書き、他のユーザーが閲覧できるよう投稿することができます。あなたのアプリケーションには、主に3つの関数があります:記事の追加、記事の検索、そして記事の表示。

検索エンジン最適化(SEO)を改善させるため、「記事を表示」コードは各記事を参照するユニークなURLを生成します。たとえば、以下のURLは、それぞれこの例で扱うWebサイトの異なる記事を参照しています:

http://example.com/article/view/How_to_Install_New_Relic
http://example.com/article/view/How_New_Relic_Saved_the_Day
http://example.com/article/view/Where_do_I_get_New_Relic

この3つは、どれも異なります。コンテンツが異なるほか、URLも異なります。ただし、各記事を生成するコードパスは同じです。いずれも、「記事を表示」関数を利用しているのです。

Webフレームワークの多くは、このテクニックを使用しています。コントローラーまたはルート(この場合はarticle/viewと命名)がURLの一部となっています。New Relicは、こうしたパターンを自動的に識別して類似したルートをグループ化することで、メトリックのグループ化問題の発生を防ぎます。

コントローラー検出メカニズムが無ければ、この例のアプリケーションはサイト訪問者によってリクエストされる個別の各URL向けにメトリクスを送信します。100万の記事を抱えており、御社のサイトが人気な場合、1分ごとに数千のユニークなURLが訪問されている可能性があります。これは、各収集サイクルでNew Relicに送信される追加データが膨大な量に達し、New Relic APMトランザクションページが数千のユニークなURLの一覧化を試みるため、メトリックのグループ化問題につながることとなります。

アプリケーションパフォーマンスを監視・向上するには、個別の記事がどれだけ早く表示されるかよりも、ある関数の平均的パフォーマンス(例:御社サイトにおける記事の表示)を把握した方がはるかに有用です。メトリックのグループ化問題を防ぐため、通常、New RelicはNew Relic APMトランザクションページにおける、その関数の単一のエントリー(例:/article/view/*)を表示します。

このグループ化によって、記事の表示にどれだけの時間が費やされたかを理解できるとともに、記事の表示に関連したパフォーマンス問題を容易に特定できるようになります。こうした統計が数百もしくは数千のトランザクションにわたって伝播した場合、動向、回帰、またはパフォーマンス改善を検出することが極めて困難になります。

それぞれのNew Relic APMエージェントには、コントローラーとフレームワークを検出できる、明確に異なる方法が備わっています。ほとんどは自動ですが、中には設定ファイルで有効もしくは無効のオプションを選ばなくてはならないものもあります。また、New Relicの推奨に従い、メトリックのグループ化問題の発生を防ぐこともできます。

その他のヘルプ

推奨する詳細情報: