トレース | OpenTelemetry

トレース は、リクエストがアプリケーションに投げられたときに何が起こるかの全体像を教えてくれます。 あなたのアプリケーションが、単一のデータベースを持つモノリスであろうと、洗練されたメッシュサービスであろうと、トレースは、リクエストがアプリケーションの中でたどる完全な「経路」を理解するために不可欠です。
スパンで表現される以下の3つのJSONデータで、これを探ってみましょう。
以下のJSONの例は、特定のフォーマット、特にOTLP/JSONを表すものではありません。OTLP/JSONは、より冗長です。
これはルートスパンであり、オペレーション全体の始まりと終わりを示します。 トレースを示す trace_id フィールドがありますが、parent_id がないことに注意してください。 これがルートスパンであることを示します。
hello-greetings スパンは次のとおりです。
このスパンは、挨拶（greetings）のような特定のタスクをカプセル化していて、その親は hello スパンです。 このスパンはルートスパンと同じ trace_id を共有していて、同じトレースの一部であることを示しています。 さらに、 hello スパンの span_id と一致する parent_id を持っています。
hello-salutations スパンは次のとおりです。
このスパンはこのトレースにおける3つ目の操作を表し、前のスパンと同様にhelloスパンの子です。 また、hello-greetingsスパンの兄弟でもあります。
これらの3つのJSONブロックはすべて同じ trace_id を共有していて、parent_id フィールドは階層を表しています。 これは1つのトレースになります！
もうひとつ、各スパンが構造化されたログのように見えることにお気づきでしょう。 それはその通りだからです！トレースについて考える一つの方法は、トレースはコンテキスト、相関関係、階層構造などを持つ構造化されたログの集まりであるということです。 しかし、これらの「構造化されたログ」は、異なるプロセス、サービス、VM、データセンターなどから来る可能性があります。 これにより、トレースはあらゆるシステムのエンドツーエンドのビューを表現できます。
OpenTelemetryでのトレースがどのように機能するかを理解するために、コードの計装の一翼を担う一連のコンポーネントを見てみましょう。
トレーサープロバイダー（TracerProvider と呼ばれることもあります）は Tracer のファクトリーです。 ほとんどのアプリケーションでは、トレーサープロバイダーは一度だけ初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。 トレーサープロバイダーの初期化には、リソースとエクスポーターの初期化も含まれます。 これは通常、OpenTelemetry によるトレースの最初のステップです。 いくつかの言語SDKでは、グローバルなトレーサープロバイダーがすでに初期化されています。
トレーサーは、サービス内のリクエストなど、与えられた操作で何が起こっているかについての詳細な情報を含むスパンを作成します。 トレーサーはトレーサープロバイダーから作成されます。
トレースエクスポーターはトレースをコンシューマーに送信します。 このコンシューマーは、デバッグや開発時間用の標準出力、OpenTelemetryコレクター、あるいは任意のオープンソースやベンダーのバックエンドです。
コンテキスト伝搬（プロパゲーション）は、分散トレースを可能にする中心となる概念です。
コンテキスト伝搬を使用すると、スパンがどこで生成されたかに関係なく、スパンを相互に関連付け、トレースとして組み立てられます。 このトピックについては、コンテキスト伝搬の概要を参照してください。
スパン は、作業や操作の単位を表します。 スパンはトレースの構成要素です。 OpenTelemetryでは、以下の情報を含みます。
次はスパンの例です。（訳注：JSON形式で表現しているだけで、必ずしもJSONではありません）
スパンは、親スパンIDの存在によって暗示されるように、入れ子にできます。 これによって、スパンはアプリケーションで行われる作業をより正確に把握できます。
スパンコンテキストは、各スパンの不変オブジェクトであり、以下を含みます。
スパンコンテキストは、分散コンテキストやバゲッジと共にシリアライズされ、伝搬されるスパンの一部です。
スパンコンテキストにはトレースIDが含まれているため、スパンリンクを作成する際に使用されます。
属性（アトリビュート）はキーと値のペアで、スパンにアノテーションを付けるためのメタデータを含んでいます。このメタデータは追跡している操作に関する情報を伝えるためのものです。
たとえば、eコマースシステムでユーザーのショッピングカートに商品を追加する操作をスパンが追跡する場合、ユーザーのID、カートに追加する商品のID、カートIDを捕捉できます。
スパンには、スパン作成中または作成後に属性を追加できます。 SDKでのサンプリングで属性を利用できるようにするには、スパン作成時に属性を追加することをおすすめします。 スパン作成後に値を追加する必要がある場合は、その値でスパンを更新してください。
属性には、各言語SDKが実装する以下のルールがあります。
さらに、セマンティック属性があり、これは一般的な操作に通常存在するメタデータのための既知の命名規則です。 システム間で共通の種類のメタデータが標準化されるように、可能な限りセマンティック属性の命名を使用することは有用です。
スパンイベントは、スパン上の構造化ログメッセージ（またはアノテーション）と考えられます。通常、スパンの期間中、意味のある特異な時点を示すために使われます。
たとえば、ウェブブラウザでの2つのシナリオを考えてみましょう。
スパンは、開始と終了がある操作なので、最初のシナリオを追跡するのに最も適しています。
スパンイベントは、意味のある特定の時点を表すため、2つ目のシナリオを追跡するのに最も適しています。
スパンイベントにも属性が含まれるため、属性のかわりにいつイベントを使用するかという質問には、必ずしも明白な答えがあるとは限りません。 決定するための参考として、特定のタイムスタンプに意味があるかどうかを考えてみてください。
たとえば、スパンで操作を追跡していて、操作が完了した時、操作からのデータをテレメトリーに追加したいと思うかもしれません。
リンクは、あるスパンと別の1つ以上のスパンを関連付け、因果関係を示唆するために存在します。 たとえば、ある操作がトレースによって追跡される分散システムがあるとしましょう。
これらの操作のいくつかに対して、追加の操作がキューに入れられ実行されますが、その実行は非同期です。 この後続の操作もトレースで追跡できます。
後続の操作のトレースを最初のトレースに関連付けたいと思っても、後続の操作がいつ始まるかは予測できません。 この2つのトレースを関連付ける必要があるので、スパンリンクを使用します。
最初のトレースの最後のスパンを、2番目のトレースの最初のスパンにリンクできます。 これで、これらのスパンは互いに因果関係があることになります。
リンクは必須ではありませんが、トレーススパン同士を関連付ける良い方法として役立ちます。
各スパンにはステータスがあります。可能な値は以下の3つです。
デフォルト値は Unset です。 スパンのステータスが Unset である場合は、追跡した操作がエラーなしで正常に完了したということです。