New Relicのデータタイプ

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

スタートガイド

このドキュメントでは、コアデータタイプやその構成、機能での使用方法についてかなり技術的に説明しますが、お客様は下層のデータ構造を理解しなくてもほとんどの機能を使用できます。この点をよく理解すると、New Relicへのデータ入力やUIに表示されるデータの理解、データのクエリに役立ちます。

実際の例を使用しての、これらのデータタイプの簡単な説明については、必須のテレメトリデータタイプの説明をご覧ください。クエリを開始しても、データについて理解できます。

メトリックス

最初に、モニタリング業界の観点から見たメトリックスの定義について説明し、その後、どのようにして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 APM、Browser、Mobileは、メトリックタイムスライスデータと呼ばれる単純なデータフォーマットでメトリックスをレポートし、表示します。メトリックタイムスライスは3つの部分で構成されています。つまり、メトリック名、メトリックを示す時間のセグメント(「タイムスライス」)、数値(測定結果)です。

例えば:特定のトランザクションに費やされた時間に対するAPMのメトリックタイムスライスはWebTransaction/URI/fooと命名され、これには午前10時20分から午前10時21分までの1分間のタイムスライスに対して0.793のレスポンスタイムを持つ場合があります。このメトリックは通常、<category>/<class>/<method>のようなパターンに従います。

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

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

メトリックタイムスライスデータについて詳しく調べクエリを行う方法:

  • APMについて:メトリックタイムスライスデータは次元メトリックスに変換され、NRQLを介してクエリを行えます。
  • REST APIを使用する

メトリックタイムスライスデータの構造の詳細について知り、例を表示するには、以下の折り畳みを拡張します。

メトリックタイムスライスの例

Rubyアプリケーションで使用する一般的なものに重点を置いた、一般的なメトリックタイムスライスデータの例は次のとおりです。

ActiveMerchant

New Relicは、ActiveMerchantトランザクションでさまざまなメトリックスを追跡します。これは、ビジネス分析やパフォーマンスモニタリングに使用できます。メトリックスは、オペレーションおよびゲートウェイごとにまとめられます。

regex サンプルメトリック 凡例名
ActiveMerchant/.* ActiveMerchant/PayJunctionGateway
ActiveMerchant/gateway/.* ActiveMerchant/gateway/PayJunctionGateway/purchase PayJunctionGateway
ActiveMerchant/operation/.* ActiveMerchant/operation/purchase purchase

詳細については、ActiveMerchantウェブサイトをご覧ください。

ActiveRecord

ActiveRecordは、Ruby on Railsアプリケーションが使用するオブジェクトリレーショナルマッピングAPIです。ここに示されたメトリックスは、ActiveRecordの検索および保存方法のパフォーマンスを測定します。

regex サンプルメトリック 凡例名
ActiveRecord/.*/find ActiveRecord/User/find User#find
ActiveRecord/.*/save ActiveRecord/Product/save Product#save

詳細については、ActiveRecordに関するAPIドキュメントをご覧ください。

Apdex

Apdexは、ページロード回数でユーザー満足度を測定したものです。

Controller

Ruby on Railsアプリケーションで、HTTPリクエストはControllerアクションにより扱われます。Railsアプリケーションには多くのコントローラがあり、それぞれに1つ以上のアクションがあります。Railsアプリケーションがhttpリクエストを受信すると、そのリクエストは、リクエストのURLに基づき、適切なコントローラとアクションに転送されます。そのアクションはその後、httpレスポンスの生成に必要なあらゆる処理を行います。レスポンスは大半の場合ウェブページですが、ページの一部やxmlドキュメント、クライアントがリクエストしているその他の種類のデータの場合もあります。

次のメトリックスは、経路にかかわらず、ネットワークやウェブサーバの影響を考慮せずに、コントローラのアクションのパフォーマンスを追跡します。

regex サンプルメトリック 凡例名
Controller/.* Controller/Users/show /Users/show
Controller/.*/(?!\(other\)).* Controller/Users/show /Users/show
Controller$ Controller すべてのコントローラのアクション
ControllerCPU/ ControllerCPU/Users/Show /Users/show

詳細については、ActionControllerに関するAPIドキュメントをご覧ください。

エラー

このメトリックは、リクエストの処理中に生じたエラーや例外の数を追跡します。

regex サンプルメトリック 凡例名
Errors/all Errors/all

外部サービス

外部サービスのインストゥルメンテーションは、ウェブサービス、クラウド上のリソース、その他のネットワーク呼び出しなどのプロセス外サービスを取得します。MemCacheやデータベースなど、その他の第一級のバックエンドコンポーネントは含まれません。

Rubyアプリケーションでは、Net::HttpライブラリをインストゥルメントしてすべてのHTTPサービスを取得します。

regex サンプルメトリック 凡例名
External/[^/]+/all$ External/service.example.com/all すべてのservice.example.com呼び出し
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 すべてのservice.example.com呼び出し

HTTPディスパッチャー

このメトリックは、すべてのウェブリクエストのスループットとレスポンスタイムのまとめを表します。

regex サンプルメトリック 凡例名
^HttpDispatcher$ HttpDispatcher HttpDispatcher

memcache

MemCacheは、グローバルキャッシュとして物理マシンの数により提供された共有メモリにアプリケーションがアクセスすることを可能にする、一般的なテクノロジーです。データベースを頻繁に使用するアプリケーションは多くの場合、パフォーマンスと拡張性のメリットでMemCacheを使用します。

このメトリックスは、キャッシュからのデータの読み取りと書き込みのためのMemCacheの呼び出しの頻度とレスポンスタイムを測定します。レスポンスタイムは、適切に動作するMemCacheデプロイメントでは、短い(5 ms以下)としてください。

regex サンプルメトリック 凡例名
MemCache/.* MemCache/read MemCacheの読み取り操作
MemCache/read MemCache/read MemCacheの読み取り操作
MemCache/write MemCache/write MemCacheの書き込み操作

Mongrel

このメトリックは、Mongrelが処理する保留中のhttpリクエストを保持する、Mongrelキューの長さを測定します。HTTPアクティビティグラフは、所定の期間の最大キュー長を重ねて表示します。Mongrelがリクエストを処理しているがキューにその他のリクエストが待機していない場合、値はゼロとなります。

この値をMongrelの集計クラスタで見ると、すべてのMongrelのキュー長がともに足され、すべてのキュー長の合計が表示されています。

Mongrelキュー長はゼロまたはゼロに近い値となるはずです。一貫して高い値の場合、Railsアプリケーションにロード要求への対応で問題があることを示しています。

regex サンプルメトリック 凡例名
Mongrel/Queue Length Mongrel/Queue Length キュー長

View

ActionViewは、htmlページやxmlドキュメントなど、httpリクエストへのレスポンスである出力のレンダリングに使用する、Rails内のパッケージです。Viewは、リクエストを扱っているコントローラーによりレンダリングが行われます。

Viewのメトリックスがコントローラのレスポンスタイムの大半を表す場合、Viewテンプレート自体内で多くのデータベース操作を行っている可能性があります。

regex サンプルメトリック 凡例名
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

詳細については、ActionViewに関するAPIドキュメントをご覧ください。

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

New Relicでのこの2つの例:

  • Infrastructureとそのインテグレーションは、イベントに添付された多くのメトリックスをレポートします。たとえば、Infrastructureは、CPU使用率といったさまざまなサンプルベースのメトリックスを添付したProcessSampleイベントをレポートします。Infrastructureデータの詳細については、Infrastructureイベントをご覧ください。
  • APMで、Transactionイベントには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は、アプリケーションにおける論理的な作業ユニットを示す、Transactionと呼ばれるイベントタイプをレポートします。このイベントに添付された属性を確認するには、以下のようなNRQLクエリを使用できます。

Select * from Transaction

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

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

ログデータ

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

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

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

New Relicにおけるログ

New Relic Logsは、お客様のログデータとNew Relicがモニタリングするその他のデータをつなぐ集中型ログ管理プラットフォームを提供します。たとえば、APMデータとともにログを表示できます。

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

Select * from Log

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

トレースデータ

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

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

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

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

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

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

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

Select * from Span

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

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

データのクエリと送信

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

詳細情報

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

その他のヘルプ

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