ここでは、New Relic の分散トレースがどのように機能するかについて、技術的な詳細を説明します。
トレースのサンプリング
トレースをどのようにサンプリングするかは、お客様の設定や使用している New Relic トレーシングツールによって異なります。たとえば、サードパーティのテレメトリサービス（OpenTelemetryなど）を利用して、データが弊社に届く前にトレースのサンプリングを実施している場合があります。また、 Infinite Tracing を使用している場合は、すべてのトレースデータを弊社に送り、弊社のサンプリングに頼ることになるでしょう。
いくつかのサンプリング戦略が利用可能です。
- ヘッドベースのサンプリング（標準のディストリビューティッド（分散）トレーシング）
- テールベースのサンプリング（Infinite Tracing）
- サンプリングなし
ヘッドベースのサンプリング（標準のディストリビューティッド（分散）トレーシング）
Infinite Tracing 機能を除いて、当社のほとんどのトレースツールはヘッドベースのサンプリングアプローチを採用しています。これは、トレース内のすべてのスパンが到着する前に、個々のスパンにフィルタを適用するものです。つまり、スパンを受け入れるかどうかの判断は、フィルタリングプロセスの最初（"head" ）で行われます。このようなサンプリング手法を用いることで、ストレージやパフォーマンスの問題を回避しつつ、アクティビティの代表的なサンプルを取得することができます。
標準のディストリビューティッド（分散）トレーシングツールでのヘッドベースのサンプリングの実行方法の詳細を、以下に示します。
テールベースのサンプリング（Infinite Tracing）
当社のInfinite Tracing機能は、テールベースのサンプリングアプローチを使用します。「テールベースのサンプリング」では、トレース保持の決定は、トレースのすべてのスパン到着後の処理の最終時点で行われます。
Infinite Tracingでは、お使いのアプリケーションまたはサードパーティのテレメトリサービスからトレースデータを100%当社に送信でき、Infinite Tracingが最も重要なトレースデータを解明します。また、重要なトレースが保持されるようにサンプリングを設定することができます。
重要
Infinite Tracingは、アプリケーションまたはサードパーティのテレメトリサービスからより多くのトレースデータを収集して転送できるため、結果として出力コストが増加する可能性があります。Infinite Tracingを展開するときは、これらのコストに注意して、このソリューションが適切であることを確認することをお勧めします。
サンプリングなし
当社の一部のツールはサンプリングを使用しません。これらのツールのサンプリング詳細を、以下に示します。
トレースデータの構成方法
ディストリビューティッド（分散）トレースの構造を理解すると以下のようなことに役立ちます。
- トレースがUIでどのように表示されるかを理解する
- トレースデータのクエリに役立つ
ディストリビューティッド（分散）トレーシングには木のような構造があり、一つの「親」スパンを参照する「子」スパンがあります。この図ではトレースの重要なスパン関係を示しています。
この図では、ディストリビューティッド（分散）トレーシングのスパンが相互にどのように関連しているかを示しています。
この図では、以下のような重要な概念を示しています。
トレースのルート。トレースにおける最初のサービスまたはプロセスは、ルートサービスまたはプロセスと呼ばれます。
プロセスの境界。プロセスはコードの論理部分の実行を表します。プロセスの例には、バックエンドサービスまたはLambda関数が含まれます。プロセス内のスパンは、以下のどれかに分類されます。
- 開始スパン：プロセスの最初のスパン。
- 出口スパン：スパンがa）入口スパンの親である場合、またはb）
http.またはdb.属性を持ち、したがって外部呼び出しを表す場合、スパンは出口スパンと見なされます。 - インプロセススパン：インターナルメソッド呼び出しまたは関数を表し、終了または開始スパンではないスパン。
クライアントスパン。クライアントスパンは、別のエンティティまたは外部依存関係への呼び出しを表します。現在、以下の2つのクライアントスパンタイプがあります。
- データストア。クライアントスパンに
db.のプレフィックスが付いた属性（db.statementなど）がある場合、それはデータストアスパンとして分類されます。 - 外部。クライアントスパンに
http.のプレフィックスが付いた属性（http.urlなど）がある場合、または別のプロセスに子スパンがある場合、それは外部スパンとして分類されます。これは、データストアクエリではない外部呼び出しの一般的なカテゴリです。
- データストア。クライアントスパンに
トレース持続時間。トレースの合計持続時間は、最初のスパンの開始から最後のスパンの終了までの時間の長さで決まります。
api.newrelic.com/graphiqlでNerdGraph GraphiQLエクスプローラーを使用して、スパン関係データのクエリを行えます。
トレースデータの保存法
トレースデータの保存方法を理解するとご自分のトレースデータをクエリするのに役立ちます。
トレースデータは、次のように保存します。
Span：スパンは、分散トレースの一部である操作を表します。スパンが表すことができる操作には、ブラウザー側のインタラクション、データストアクエリ、他のサービスへの呼び出し、メソッドレベルのタイミング、 Lambda関数が含まれます。一例：HTTPサービスでは、スパンはHTTPリクエストの開始時に作成され、HTTPサーバーがレスポンスを返すときに完了します。スパン属性には、トレース関係の詳細（traceId、guidなど）を含む、その操作に関する重要な情報（期間、ホストデータなど）が含まれます。スパン関連のデータについては、スパン属性を参照してください。Transaction：トレース内のエンティティがエージェントによって監視されている場合、そのエンティティへの要求は単一のTransactionイベントを生成します。トランザクションにより、トレースデータを他のNewRelic機能に関連付けることができます。トランザクション関連のデータについては、トランザクション属性を参照してください。- コンテキスト連動メタデータ。トレースとそのスパン間の関係についての計算を表示するメタデータを保存します。このデータのクエリを行うには、NerdGraph GraphiQLエクスプローラー を使用します。
アプリケーション間でトレースコンテキストを渡す方法
当社はW3Cトレースコンテキスト標準をサポートしているため、ネットワークやサービス間のトランザクションのトレースを簡単にします。ディストリビューティッド（分散）トレーシングが有効な場合、New Relicエージェントは、サービスの外部送信リクエストにHTTPヘッダーを追加します。HTTPヘッダーは、海外旅行でのパスポートのように機能します。さまざまなネットワーク、プロセス、セキュリティシステムを移動する際にソフトウェアのトレースを識別し、重要な情報を伝達します。
また、ヘッダーには、トレースID、スパンID、New RelicアカウントID、サンプリング情報などのメタデータのような、後でスパンをまとめてリンクする上で役立つ情報も含まれています。ヘッダーの詳細については、下の表を参照してください。
項目 | 説明 |
|---|---|
| これは、お客様のNew RelicアカウントIDです。ただし、このIDをアカウント情報に関連付けることができるのは、アカウント管理者とNew Relic管理者だけです。 |
| これは、トレースヘッダーを生成するアプリケーションのアプリケーションIDです。 |
| 分散トレースでは、トレース内の作業の各セグメントは |
親の種類 | モバイル、ブラウザ、Rubyアプリなどの場合の、トレースヘッダーのソース。これは、このヘッダーが添付されているリクエストによってトリガーされるトランザクションの |
優先度 | サンプリング制限に達したときに、どのデータをサンプリングするかを決定するのに役立つ、ランダムに生成された優先順位の値。これは、リクエストの一部である最初のNew Relicエージェントによって設定されたフロート値であるため、トレース内のすべてのデータは同じ優先度の値を持ちます。 |
Sampled | リクエストに対してトレースデータを収集するかどうかをエージェントに指示するブール値。これはまた、収集されたすべてのスパンおよびトランザクションデータの属性としても追加されます。このサンプリングプロセスについてさらに詳しくお読みになりたい場合は、このガイドを参照してください。 |
タイムスタンプ | ペイロードが作成されたときのUnixタイムスタンプ（ミリ秒単位）。 |
| ユニークID（ランダムに生成された文字列）で、プロセス間およびプロセス内の境界をまたがる単一のリクエストを識別するのに使用されます。このIDでは、ディストリビューティッド（分散）トレース内のスパンをリンクできます。これは、スパンおよびトランザクションデータにも属性として追加されます。 |
| トランザクションイベントの一意の識別子。 |
信頼できるアカウントキー | これは、ご利用のアカウントに関連付けられている他のアカウントを識別するのに役立つキーです。したがって、トレースが交差する複数のサブアカウントがある場合、トレースに含まれるデータが信頼できるソースから送信されたものであることを確認して、どのユーザーがデータにアクセスできるかを把握できます。 |
バージョンとデータキー | これにより、メジャー/マイナーバージョンが識別されるため、エージェントが現在のバージョンから重大な変更が加えられたバージョンのトレースヘッダーを受信した場合、そのヘッダーを拒否し、拒否と理由を報告できます。 |
このヘッダー情報は、ヘッダーの書式を認識しないミドルウェアまたはエージェントなどにより進捗が停止している場合を除き、トレースの各スパンとともに渡されます（図1を参照）。
図1
ヘッダー伝搬の問題に対処するため、当社は、2つの標準化されたヘッダーを必要とするW3Cトレースコンテキスト仕様をサポートしています。当社の最新のW3C New Relicエージェントは、この2つの必要なヘッダーを送受信し、デフォルトで以前のNew Relicエージェントのヘッダーも送受信します。
- W3C（
traceparent）：トレース全体（トレースID）と呼び出し元サービス（スパンID）を識別するプライマリヘッダー。 - W3C（
tracestate）：ベンダー固有の情報を伝達し、トレースが行われた場所を追跡する必須のヘッダー。 - New Relic（
newrelic）：以前のNewRelicエージェントとの下位互換性を維持するために引き続き送信される元の独自のヘッダー。
3つのヘッダーを組み合わせることで、これらのタイプのエージェントでインストゥルメントされたサービス全体にトレースを伝搬できるようになります。
- W3C New Relicエージェント
- W3C以外のNew Relicエージェント
- W3Cトレースコンテキスト対応エージェント
重要
リクエストがW3CTraceContext互換エージェントにのみ触れる場合は、NewRelicヘッダーをオフにすることを選択できます。 newrelicヘッダーをオフにする方法の詳細については、エージェント構成のドキュメントを参照してください。
以下のシナリオには、さまざまな種類の適切なヘッダ伝搬が示されています。