New Relicのデータインジェスト量（データ取り込み量）は、管理画面の「Usage UI」から簡単に確認できます。また、Usageの詳細画面を展開することで、データソースごとの内訳（データソースごとのUsage）もシームレスに把握可能です。本ブログでは、このデータソースの中でも特に分析が難しくなりがちな 「MetricBytes」 に焦点を当て、その内訳を深く掘り下げて調査する方法を紹介します。
MetricBytesの全体像を把握する
まずは、UsageのUIから Ingestion の詳細ページに遷移し、「MetricBytes」 をクリックしてください。
画面を開くと、MetricBytesが以下の2つのカテゴリに分類されて表示されていることがわかります。
- Dimensional Metrics（ディメンショナルメトリクス）
- Metric Time Slices（メトリクスタイムスライス）
※注意点： 右側のチャートに 「Note: The view shown is an estimate. Actual billing may vary.」 と表示されている通り、ここで確認できる数値はあくまで「推測値（推定インジェスト量）」であることにご留意ください。
グラフを描画しているNRQLクエリを確認する
現状の分類をより詳細に理解するために、このチャートの元となっているNRQLクエリを確認してみましょう。
チャート右上にある三点リーダー（...）をクリックし、「View query」 を選択します。すると、以下のようなクエリが表示されます。
SELECT bytecountestimate()/10e8 FROM `Metric`
WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie'
FACET CASES (
WHERE newrelic.source = 'agent' AS 'Metric Time Slices',
WHERE newrelic.source != 'agent' OR newrelic.source IS NULL AS 'Dimensional Metrics'
)
TIMESERIES 5 minutes
SINCE <開始日時> UNTIL <終了日時>
LIMIT 25
クエリの解説
- FROM Metric:
- Metric データタイプ（Namespace）を対象にクエリを実行しています。
- bytecountestimate() / 10e8:
- bytecountestimate() 関数を使用し、データの推定インジェスト量をギガバイト（GB）単位に換算して算出しています。
- WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie':
- Metricの課金対象（Usage）に含まれない特定のプロバイダー（Kentik、Pixie）のデータを除外しています。
- FACET CASES (...):
- newrelic.source = 'agent' に合致するデータを 「Metric Time Slices」 として分類・集計しています。
- newrelic.source != 'agent' または null のデータを 「Dimensional Metrics」 として分類・集計しています。
ここからは、これら2つのカテゴリ（Metric Time Slices と Dimensional Metrics）それぞれの具体的な分析・対策方法を解説します。
Metric Time Slices（タイムスライスメトリクス）の分析
Metric Time Slices は、主にAPMエージェントなどが直接、またはエージェント経由で送信する従来型のメトリクスです。このメトリクスは、HTTP API（Metric API）経由での直接送信はできません。
基本的には特定のエージェント（アプリケーション）に紐づくため、以下のようにFACET句にappNameを指定したのNRQLクエリを使用することで、アプリケーションごとの推定インジェスト量を特定できます。
SELECT bytecountestimate()/10e8 FROM `Metric`
WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie'
AND newrelic.source = 'agent'
FACET appName
LIMIT MAX特定アプリに紐づくタイムスライスを確認する
特定のアプリケーションにどのようなタイムスライスメトリクスが含まれているかを調べるには、New Relicの Data Explorer（データエクスプローラー） が便利です。
- クエリバーの左側メニューから 「Data explorer」 をクリックします。
- データタイプ（Type）で 「Timeslice」 を選択します。
- 調査対象のエンティティ（アプリケーション）を指定すると、そのエンティティに紐づくタイムスライスメトリクスの一覧が確認できます。
不要なタイムスライス削減の注意点
不要なタイムスライスメトリクスは、Metric Normalization Rules（メトリクス正規化ルール）を設定することで破棄（ドロップ）できます。
⚠️ 注意： タイムスライスメトリクスを安易に破棄すると、UIの表示に影響が出る可能性があります。
例えば、APMの「Transactions」画面は、Transactionイベントだけでなく、対応するタイムスライスメトリクスも併用して画面のグラフやデータを描画しています。そのため、これらを破棄するとAPMの一部のUIが正常に表示されなくなるなどの弊害が発生します。基本的には、ルールによる事後破棄ではなく、エージェント側の設定を見直し、トランザクション名が集約（ロールアップ）されるように調整するアプローチを第一に検討してください。
Dimensional Metrics（ディメンショナルメトリクス）の分析
Dimensional Metrics は、各種エージェント、クラウドインテグレーション、OpenTelemetry、Metric APIなど、多様な経路から多次元データとして送信されます。送信元やインテグレーションにより付随する属性が異なるため、調査や分析の難易度が高くなりがちです。
これらに共通する一貫したプロパティは（timestamp を除けば）metricName のみかと思われます。しかし、単純に FACET metricName で集計しようとすると、メトリクス名が細分化されすぎており、全体像を掴むのが困難になります。そこで、以下の正規表現を利用したクエリを使用し、メトリクス名の「プレフィックス（接頭辞）」でグルーピングすることをおすすめします。
SELECT bytecountestimate()/10e8 FROM `Metric`
WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie'
AND (newrelic.source != 'agent' OR newrelic.source IS NULL)
FACET capture(metricName, r'(?P<prefix>^([^._]*)).*')
LIMIT MAX多くのメトリクス名は . や _ を区切り記号として命名されているため、このクエリによって先頭の主要なカテゴリ（例: aws, k8s, net など）ごとにインジェスト量を把握できます。
特定のプレフィックス配下を詳細に調査する
例えば、上記のクエリで aws から始まるメトリクスのインジェスト量が多いと判明した場合、以下のようにクエリを絞り込んで、具体的なメトリクス名の一覧を展開します。
SELECT bytecountestimate()/10e8 FROM `Metric`
WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie'
AND (newrelic.source != 'agent' OR newrelic.source IS NULL)
AND capture(metricName, r'(?P<prefix>^([^._]*)).*') = 'aws'
FACET metricName
LIMIT MAXメトリクスの送信元（インテグレーション等）を特定する
特定のメトリクスが「どのインテグレーションや設定から送られているか」を特定したい場合、該当メトリクスに付随している属性（メタデータ）を確認するのが近道です。以下のクエリを実行し、どのようなキーや値が含まれているか確認してください。
SELECT * FROM `Metric` WHERE metricName = '<対象のMetricName>'エンティティ（entityGuid）ごとにグルーピングして特定する
もう一つの強力なアプローチとして、entityGuid（または entity.guid）を用いた集計があります。これにより、インフラやホストなどの「どのリソース」がメトリクスを大量に消費しているかを特定できます。
FROM Metric
SELECT bytecountestimate()/10e8
FACET CASES (
WHERE entity.guid IS NULL AND entityGuid IS NULL AS 'No Entity GUID'
) OR entityGuid OR entity.guid
LIMIT MAXこのクエリでは、特定のエンティティに関連付けられていない野良メトリクス（クラウドのカスタムメトリクスやAPI経由のものなど）は 'No Entity GUID' に集約され、それ以外のものは各リソースのGUID単位で集計されます。
まとめ
MetricBytesのインジェスト量を削減・最適化するためには、まず 「Metric Time Slices」 と 「Dimensional Metrics」 のどちらが支配的であるかを見極めることがスタートラインです。
本記事で紹介したNRQLクエリや正規表現、Data Explorerを活用してデータソースを特定し、エージェント設定の最適化やクレンジングを実行してみてください。本記事がみなさまのNew Relicのコスト最適化とプラットフォーム運用の一助となれば幸いです。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
