New Relicのデータタイプ

New Relicプラットフォームは、当社が完全で効率的なシステム監視に必要と考える、次の4つの基本的なテレメトリデータタイプについて構築されます: メトリックスイベントログトレース

スタートガイド

This doc will give you a fairly technical explanation of our core data types, their structure, and how they're used in our features. You can use most of our features without needing to understand the underlying data structure. この点をよく理解すると、New Relicへのデータ入力やUIに表示されるデータの理解、データのクエリに役立ちます。

実際の例を使用しての、これらのデータタイプの簡単な説明については、必須のテレメトリデータタイプの説明をご覧ください。Another good way to understand your data is to just start querying it.

メトリックス

最初に、モニタリング業界の観点から見たメトリックスの定義について説明し、その後、どのようにしてNew Relicがメトリックスを処理しているかについて説明します。

モニタリング業界におけるメトリックス

ソフトウェアモニタリング業界において、メトリックはアプリケーションまたはシステムの数値計測を意味しています。メトリックスは一般的に規則的なスケジュールでレポートされます。

メトリックスには主に2つのタイプがあります。

  • 総計値。例えば:1分間にカウントされたイベントの数、または1分あたりのイベントの割合。
  • 時間のある瞬間における数値的なステータス。例えば:CPU温度の読み値、または「使用されているCPU%」のステータス。

メトリックスは比較的、レポートとストレージが簡単です。なぜなら、単一のレコードで時間の範囲を示せるからです。また、時間をかけてさらに多くのメトリックを集計することもできます。たとえば、ある一定の時間後に、1分あたりのデータを「ロールアップ」して1時間あたりで集計し、最終的には、1日あたりで集計することができます。このアプローチは長期にわたるデータストレージにおいて効果的です。

メトリックスはデータの長期保管および経時的なトレンドの把握に適した強力なソリューションです。不都合かもしれないひとつのことは、時間をかけて集計した古いデータの詳細な分析の実施が困難である可能性があることです。つまり、特定の重要なアクションについて高度な詳細が必要な場合、イベントデータを使用することが可能です。

New Relicにおけるメトリックス

概念的に「メトリックス」は広範で一般的なカテゴリーです。New Relicは、メトリックスの測定と報告を様々な方法で行っていますが、実際には、New Relic UIを利用する際に厳密な仕組みについて理解する必要はほぼありません。お客様が詳細を知る必要がある場合(データのクエリ方法の把握など)を除き、当社はそのドキュメンテーションにおいて、基本的にデータの報告方法に関係なく「メトリックス」についてのみ言及します。

以下は、New Relicプラットフォーム全体におけるメトリックスの報告および格納方法を示しています:

モニタリング業界において、「ディメンショナル」メトリックスは、継続時間に関連する属性(開始時間、終了時間)、エントリーID、リージョン、ホストといったさまざまな属性(ディメンション)が添付されたメトリックデータを指します。この詳細の量によって徹底的な分析と照会が可能になります。

New Relicにおいて、このメトリックデータはMetricデータタイプに添付され、複数のソースから送信されます:

このデータのクエリを行い、属性(「次元」)を表示するには、次のようなNRQLクエリを使用できます:

Select * from Metric

時間が経過するにつれ、これらのメトリックスはより大きな時間バスケットに集約されていきます。これは、長期にわたってデータクエリ能力を最適化するために行われるものです。

このデータの取得および格納方法の詳細については、メトリックAPIドキュメンテーションを参照してください。クエリのヒントについては、メトリックスのクエリの例を参照してください。

New Relic's APM, Browser, and Mobile report and display metrics in a simple data format that we refer to as metric timeslice data. メトリックタイムスライスは3つの部分で構成されています。つまり、メトリック名、メトリックを示す時間のセグメント(「タイムスライス」)、数値(測定結果)です。

例えば:an APM metric timeslice for time spent in a particular transaction is named WebTransaction/URI/foo, and might have a response time of 0.793 for a one-minute time slice from 10:20am to 10:21am. These metrics usually follow a pattern like <category>/<class>/<method>.

当社のエージェント(APM、Browser、Mobile)は、さまざまなパフォーマンスメトリックスにおいて、1 分あたり数千ものメトリックタイムスライスを収集できます。例えば:エラー率、帯域幅使用量、またはガベージコレクションタイムの計測などです。カスタムメトリックを作成することもできます。

メトリックタイムスライスデータは軽量なデータタイプであり、ディメンショナルメトリックスが持つような詳細がありません。

Ways to explore and query metric timeslice data:

  • For APM: metric timeslice data is converted to dimensional metrics and can be queried via NRQL
  • REST APIを使用する

If you want to learn more about the structure of metric timeslice data and see some examples, expand the collapser below.

Metric timeslice examples

Here are some common metric timeslice data examples, with a focus on common ones used by Ruby applications.

ActiveMerchant

New Relic tracks a variety of metrics on ActiveMerchant transactions which can be used for business analytics as well as performance monitoring. The metrics are summarized by operation as well as by gateway.

regex sample metric legend name
ActiveMerchant/.* ActiveMerchant/PayJunctionGateway
ActiveMerchant/gateway/.* ActiveMerchant/gateway/PayJunctionGateway/purchase PayJunctionGateway
ActiveMerchant/operation/.* ActiveMerchant/operation/purchase purchase

For more information, see the ActiveMerchant website.

ActiveRecord

ActiveRecord is the Object-Relational Mapping API used by Ruby on Rails applications. The metrics shown here measure the performance of ActiveRecord's find and save methods.

regex sample metric legend name
ActiveRecord/.*/find ActiveRecord/User/find User#find
ActiveRecord/.*/save ActiveRecord/Product/save Product#save

For more information, see the API documentation for ActiveRecord.

Apdex

Apdex is a measure of user satisfaction with page load times.

Controller

In Ruby on Rails applications, HTTP requests are handled by Controller actions. A Rails application has many controllers, each of which has one or more actions. When your rails application receives an http request, that request is routed to the appropriate controller and action, based on the URL of that request. That action then does whatever processing is neccesary to generate an http response, which is most often a web page, but could also be a page fragment, an xml document, or any other kind of data that is requested by the client.

The following metrics track the performance of controller actions, regardless of routing, and without taking into account any network or web server effects.

regex sample metric legend name
Controller/.* Controller/Users/show /Users/show
Controller/.*/(?!\(other\)).* Controller/Users/show /Users/show
Controller$ Controller All Controller Actions
ControllerCPU/ ControllerCPU/Users/Show /Users/show

For more information, see the API documentation for ActionController.

エラー

This metric tracks the number of errors or exceptions raised while processing requests.

regex sample metric legend name
Errors/all Errors/all

外部サービス

External service instrumentation captures calls to out-of-process services such as web services, resources in the cloud and any other network calls. It does not include other first class back-end components such as MemCache and the database.

In Ruby applications we instrument the Net::Http library to capture all HTTP services.

regex sample metric legend name
External/[^/]+/all$ External/service.example.com/all All service.example.com calls
External/ External/host.aws.com/Net::Http::POST Net::Http::POST[host.aws.com]
External/all$ External/all 外部サービス
External/[^/]+/(?!all)/ External/service.example.com/all All service.example.com calls

HTTP dispatcher

This metric represents a summary of the throughput and response time of all web requests.

regex sample metric legend name
^HttpDispatcher$ HttpDispatcher HttpDispatcher

memcache

MemCache is a popular technology that enables applications to access shared memory provided by any number of physical machines as a global cache. Applications that heavily use the database often use MemCache for performance and scalability benefits.

These metrics measure the frequency and response time of calls to MemCache to read and write data from the cache. Response times should be low (less than 5 ms) for a well performing MemCache deployment.

regex sample metric legend name
MemCache/.* MemCache/read MemCache read operations
MemCache/read MemCache/read MemCache read operations
MemCache/write MemCache/write MemCache write operations

Mongrel

This metric measures the length of the mongrel queue, which holds pending http requests to be processed by mongrel. The HTTP Activity graph overlays the maximimum queue length for a given period. The value is zero if mongrel is processing a request but has no other requests waiting in its queue.

When looking at this value across an aggregate cluster of mongrels, the queue lengths of all mongrels is added together, showing the sum of all queue lengths.

A mongrel queue length should be at or near zero; if it is consistently at a higher level, then it indicates that your rails application is having trouble keeping up with its load requirements.

regex sample metric legend name
Mongrel/Queue Length Mongrel/Queue Length Queue Length

View

ActionView is a package in Rails that is used to render the output that is the response to an http request, such as an html page or an xml document. The View is rendered by the controller that is handling the request.

If View metrics represent a large portion of your controller's response time, it could mean you are doing a lot of database operations inside the view template itself.

regex sample metric legend name
View/.* View/Users/_child.html.erb/Partial Users/_child.html.erb
View/.*/Partial View/Users/_child.html.erb/Partial Users/_child.html.erb
View/.*/Rendering View/Users/show.html.erb/Rendering Users/show.html.erb

For more information, see the API documentation for ActionView.

イベントタイプデータは、添付されたあらゆるタイプのキーの値の組み合わせのデータを有することができるため、メトリックスをイベントに添付された属性として報告できます。

New Relicでのこの2つの例:

  • Infrastructure and its integrations report many metrics that are attached to events. たとえば、Infrastructureは、CPU使用率といったさまざまなサンプルベースのメトリックスを添付したProcessSampleイベントをレポートします。Infrastructureデータの詳細については、Infrastructureイベントをご覧ください。
  • In APM, the Transaction event has several metrics attached to it, including databaseDuration.

このデータとデータのクエリの方法の詳細については、イベントをご覧ください。

メトリックスは、New Relicイベントのカウントによって、あるいはこれらのイベントに関するいくつかのその他の数学的計算を行うことによって生成されます。たとえば、過去30分間のトランザクションイベントの総数を計測したい場合、このNRQLクエリを実行できます。

Select count(*) from Transaction since 30 minutes ago

もう1つの例としては、お客様のサービスの平均応答時間を計算したい場合、以下のようなクエリを実行できます。

FROM Transaction SELECT average(duration) SINCE 30 minutes ago

いくつかのNew Relicチャートはこうした種類のクエリで生成されます。このアプローチにおける不都合な点は、モニタリングシステム(当社のものを含む)がレポート可能なイベントの数に制限があることです。これは、高スループットのシステムにおいて、カウントがそのシステムの合計アクティビティ数を正確に示していない可能性があることを意味します。この対処方法の詳細に関しては、イベントの制限およびサンプリングを参照してください。

カスタムメトリックをレポートしたいですか? データをNew Relicに投入を参照してください。

イベントデータ

最初に、モニタリング業界の観点から見た イベント の定義について説明し、その後、どのようにしてNew Relicがイベントデータを処理しているかについていくつか具体的に説明します。

モニタリング業界におけるイベント

ソフトウェア業界において、イベントはシステムにおいて発生する単なる「もの」と思われているかもしれません。たとえば、サーバ設定の変更はイベントになるでしょう。もう1つの例としては、ウェブサイトユーザーのマウスクリックもそうです。

一部のイベントは保存されたレコードを生成し、そのレコードも一般的にイベントと呼ばれます。

イベントデータは離散的に発生し、一般的に高レベルの詳細を有しているため、イベントデータは詳細な分析やクエリに適しています。イベントデータ使用の不利な点は、通常報告されるイベントが非常に多いために、大規模なデータセットの長期にわたるクエリが困難になる可能性があることです。

New Relicにおけるイベント

New Relicでは、イベントとも呼ばれるデータオブジェクトに対するイベントをレポートします。これらのイベントは、複数の属性(キーと値のペア)を有します。イベントデータはいくつかのUIチャートと表で使用され、イベントデータのクエリを行うこともできます。イベントデータをどのくらいの間使用できるかは、データ保持期間についてのルールにより決定されます。

イベントの一例:APM reports an event type named Transaction, which represents a logical unit of work in an application. このイベントに添付された属性を確認するには、以下のようなNRQLクエリを使用できます。

Select * from Transaction

イベントデータのクエリの例については、NRQLの概要をご覧ください。

New Relic イベントデータについてのその他の詳細:

ログデータ

最初に、モニタリング業界の観点から見たログの定義について説明し、その後、どのようにしてNew Relicが ログ レポーティングを処理しているかについていくつか具体的に説明します。

モニタリング業界におけるログ

ログは、システムのアクティビティを理解して問題を診断するための、システムに関するメッセージです。

New Relicにおけるログ

New Relic's Logs gives you a centralized log management platform that connects your log data with other New Relic-monitored data. For example, you can see logs alongside your APM data.

New Relicにおいて、ログデータは複数の属性(キー値データ)が添付された状態でレポートされます。ログデータをクエリするには以下のようなNRQLクエリを使用できます。

Select * from Log

カスタムログデータをレポートするには、Log APIをご覧ください。

トレースデータ

最初に、モニタリング業界の観点から見たトレースの定義について説明し、その後、どのようにしてNew Relicがトレーシングを処理しているかについていくつか具体的に説明します。

モニタリング業界におけるトレーシング

アプリケーションインフラストラクチャモニタリングの世界において、トレーシングは、プログラムやシステムの運用方法にまつわる情報をレポートするためのさまざまな方法を指す一般的な用語です。たとえば、スタックトレースはプログラムのサブルーチンに関する徹底的な情報を提供します。

大規模かつ近代的なシステムの場合、多くのサービスやマイクロサービス全体に分散していることが多く、「トレーシング」は多くの場合、複雑な分散型環境を通じて伝播する時にリクエストをモニターする方法であるディストリビューティッド(分散)トレーシングを指します。

New Relicにおけるトレーシング

New Relicは、分散型システム全体のリクエストを追跡してお客様のトレースを把握、分析する専用のUIを提供するディストリビューティッド(分散)トレーシング機能を提供しています。New Relicにおいて、トレースデータは、複数の属性(キー値のペア)を添付したスパンオブジェクトとしてレポートされます。

トレーシングデータをクエリするには以下のようなNRQLクエリを使用できます。

Select * from Span

ディストリビューティッド(分散)トレーシングの詳細については、ディストリビューティッド(分散)トレーシングを理解するをご覧ください。

カスタムのディストリビューティッド(分散)トレーシングデータをレポートするにはトレースのAPIを参照してください。

データのクエリと送信

New Relicのデータタイプを理解すると、以下のような点で役に立ちます。

詳細情報

実際の例を使用しての、これらのデータタイプの簡単な説明については、必須のテレメトリデータタイプの説明をご覧ください。

その他のヘルプ

さらに支援が必要な場合は、これらのサポートと学習リソースを確認してください: