New Relic APM、Browser、Mobile機能を使っていると、メトリクスの名前のパターン(種類)を大量に生成してしまうことがあります。メトリクスの名前のパターンが増えると、チャート、レポート、テーブルの項目が増え、その有用性が下がってしまいます。New RelicではこれをMetrics Grouping Issue (MGI)と呼んでいます。この記事では、MGIの起きる最も大きな原因であるトランザクション名の命名のガイドラインについて説明したあとに、実際にMGIが起きてしまった場合の対応方法について説明します。

MGIは例えば次のような状況で起きます。

  • アプリケーションがインターネットをクロールしていて、各外部呼び出しが異なるドメインの場合。External/<ドメイン名>/XXX というメトリクスが増えていきます。

  • リクエストを受信するたびに一時データベーステーブルを動的に生成する場合。Datastore/statement/<DB種類>/<テーブル名>/XXX というメトリクスが増えていきます。

  • UUID、記事の名前といった種類が無数にある名前を指定したカスタムインストルメンテーションを使用している場合。たとえばトランザクション名の場合、トランザクション名ごとにメトリクスが増えていきます。

トランザクションの名前付け

実際にMGIが起きる原因としては、トランザクションの名前づけに起因するものが多いです。一例として、ブログやニュースなどの記事を表示するWebアプリのトランザクションを考えてみましょう。個別の記事を表すために次のようなURLがつけられるでしょう。

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
もし、このURLのパス(/article/view/How_to_Install_New_Relic)をトランザクションを一意に識別するための名前として作成すると、記事の数Nに対してO(N)でトランザクション関連のメトリクスが増えていきます。しかし、多くのWebアプリでは個別の記事を生成するためのアプリケーションコードは同一であるはずです。同一のコードを別々のトランザクションとして計測するメリットは少なく、メトリクスの数がふえ見るべき数値を追えなくなるデメリットのほうがはるかに多いです。
いわゆるMVCスタイルで開発できる多くのWebフレームワークでは、ひとつのController(あるいはView)にarticle/viewというパスを割り当てています。New RelicのAPM Agentではこのパターンを認識し、適切な単位でトランザクションの名前をつけます。
この適切な単位でのトランザクションの名前づけができない場合にMGIが発生します。まず、サポートしていないフレームワークを利用している場合など、New Relic APM Agentによる適切な単位にわけるグルーピングがうまく機能しなかった場合が挙げられます。もう一つが、トランザクション名を指定するAgentのAPIを利用する際に指定した名前が不適切だった場合です。先程のURLの例のように、多数のパターンがある名前を指定すると問題になります。

MGIが発生した場合の対応

MGIが発生すると、New Relicプラットフォーム側でDENY_NEW_METRICルールというものが作成されます。これは以下の2つの方法で確認できます。

  • 新しくできたMetric Normalizationビュー
  • NrIntegrationErrorイベント

発生した場合、まずはMGIを引き起こしている要因を特定し、排除することをおすすめします。例えばトランザクションの名前付けが原因であれば、AgentのAPIを適切に利用するようにコードを修正します。

コードをすぐには変更できない場合などやむをえない場合は、Metrics Normalizationビューから正規表現でマッチしたメトリクスを置換(Replcae)あるいは無視(Ignore)するルールを作成することで緊急避難的に対応できます。こちらの詳細についてはドキュメントを参照ください。

コードの修正が完了し、メトリクスの種類が正常に戻ったことが確認できたら、作成されたDENY_NEW_METRICルールを削除することができます。

 

MGIについてご不明な点があればぜひNew Relicにお問い合わせください。