カスタムメトリクス

カスタムメトリクスを使用すると、API コール経由で任意のメトリクスを記録できます。たとえば、チェックアウトトランザクションとして、各ショッピングカートの値をレポートできます。その後、カスタムダッシュボード上でショッピングカートの値の動きモニタリングできます。New Relic 中で監視を統一するのに、カスタムメトリクスを使用することができます。

カスタムダッシュボード上でカスタムメトリクスを表示が可能かどうかは、契約しているサブスクリプションによります。

カスタムメトリクスの命名

すべてのカスタムメトリクス名は、Custom/ で始める必要があります。(例えば Custom/MyMetric/My_labelCustom/ 接頭辞はすべてのカスタムメトリクスに必要です。

カスタムメトリック-syntax.png

カスタムメトリクス名は、接頭辞 Custom/、カテゴリまたはクラス名、メソッドまたはラベルをそれぞれスラッシュで区切って構成します。

カスタムメトリクスは、あなたのコードを通過する任意のメトリックを報告できます。たとえば、New Relic は、現在のサブスクリプションの年平均を監視するのにカスタムメトリクスを使用しています。また、ショッピングカートの値、カート内の商品数、アクティブな接続数などを報告するのにカスタムメトリクスを使用できます。

カスタムメトリクスの実装

カスタムメトリクスを実装するには、APIコールが必要です。APIコールの詳細はエージェントによって異なります。

カスタムメトリクスの実装をテストする際は、API 呼び出しが、New Relic に記録されることを確実にするため、すくなくとも 10分間はエージェントを実行してください。

New Relic エージェント:

  • JavarecordMetric
  • .NETRecordMetric
  • Node.jsrecordMetric
  • PHPnewrelic_custom_metric
  • Pythonrecord_custom_metricregister_data_source
  • Rubyrecord_metricincrement_metric

New Relic モバイルエージェントの SDK:

グループ化の問題

あまりにも多くのメトリクスを収集すると、アプリケーションと New Relic の両方のパフォーマンスに影響します。たとえば、数千の個別ユーザーがいる場合、それらの固有のユーザーID のパフォーマンスを追跡するメトリクスは作成しない方がよいです。大量にメトリクスがありすぎるため、データを理解したり、閲覧するのはほぼ不可能になります。この例の最善のアプローチは、ユーザーID の代わりにアスタリスク(*)のようなプレースホルダを使用することです。

ユニークなメトリック名の合計数が 2000 を超えた場合、制約が自動的に適用されて、チャートやテーブルなどのUI上のデータの表示方法に影響を与えます。メトリクスの数が大きくなると管理が難しくなると、自動グループルールは、類したメトリクスを1つにまとめる。これは、データの全体的な再現性の損失を引き起こします。たとえば、すべてのカスタムメトリクスが単一のメトリックとして表示されたり、すべての ウェブ​​トランザクションが単一の URI として表示されたりするかもしれません。詳しくは メトリックグループ化の問題 をご覧ください。

推奨事項:潜在的なデータの問題を回避するために、カスタムメトリクスがレポートするユニークなメトリクスの合計数を 2000 以下に維持しようとします。

関連情報

上記のエージェントの資料に加えて、カスタム計測の関連情報は次のとおりです。